4 ms·

> but the API has to explicitly request for user permissions anyways You mean, just like all other 200 [1] or so APIs that want to request that access? It's a

> but the API has to explicitly request for user permissions anyways You mean, just like all other 200 [1] or so APIs that want to request that access? It's a good thing some browser vendors don't look at these APIs in isolation, but look at the whole picture. So they see all the other APIs that also want to spring a pop up requesting access to something, and are concerned about confirmation fatigue. [1] Exaggeration. Or maybe not. These days between all the hardware APIs chrome is pushing, and existing APIs like notifications and locations, and half-consensus APIs like file system access and MIDI there might be more than 200 hundred already.

deleted 4y ago
[deleted]
capableweb 4y ago
Seems there are about 18 APIs that require explicit user permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API https://developer.mozilla.org/en-US/docs/Web/API/Permissions... 7 of those are actually available in Firefox at all.
- illiarian 4y ago
  It's definitely more complex than that because many of those APIs have additional areas that may or may not be covered by permissions. For example, Firefox implemented permissions for enumerating MIDI devices, and Chrome didn't, with predictable results: https://twitter.com/denschub/status/1582730985778556931?s=20 https://twitter.com/denschub/status/1582730985778556931?s=20
AshleysBrain 4y ago
Arguably looking at the whole picture means recognizing that some of these use cases will instead be done by traditional desktop apps that have far more invasive access often without needing to prompt the user for permission at all. In my view web browsers are a more secure and privacy-preserving option than that.
- illiarian 4y ago
  > In my view web browsers are a more secure and privacy-preserving option than that. Indeed. That's precisely why some browser vendors don't want to give random access to your computer to any and all website. And don't want to give every app and site access to the data that should be private to a particular web site. From this point of view sandboxing websites seems like a good compromise. --- It's also strange that the argument I keep hearing is "but apps have unrestricted access, so to preserve security and privacy... let's give web sites the same access as native apps". It doesn't work lime this.
  - AshleysBrain 4y ago
    Browsers don't have the same access as native apps, and shouldn't. There are permission prompts, privacy controls and access limits. For example the File System Access API is not unfettered access, it's limited to only files and folders manually selected by the user and nothing else. This is not at all "random access to your computer", which is in fact what traditional desktop apps tend to have.
    - cxr 4y ago
      It becomes effectively "random" (arbitrary) when higher order effects take over. We saw this with ActiveX controls. It becomes a game of chicken that eventually leads to an imbalance where website operators always win.
    - illiarian 4y ago
      > Browsers don't have the same access as native apps, and shouldn't. Indeed. That's why browser vendors (well, some of them) take a dim view of "oh just let them access anything, just pop a confirmation prompt in there" > There are permission prompts, privacy controls and access limits. And users are surely aware of those and can definitely understand where to find them, and what implications those have? Literally the entire history of computing tells us: no. > This is not at all "random access to your computer" It is. This is already done by MacOS with its incessant "app X wants to access files in Y". Even I, a programmer, and a power user, end up clicking "to hell with it, yes" more often than not. Especially if I'm in the middle of an important task.
armchairhacker 4y ago
Put "block this page from requesting any future permissions" checkbox in the confirmations, and create another API (I know...) so that good sites can request multiple permissions at once. There are many sites which would really benefit from file system access and a unified API so that they don't have to resort to constant upload/download or roll their own virtual file system. It's more than worth slight inconvenience of another popup, and while it also makes scamming less tech-savvy people easier (e.g. if they store all their passwords in the "Documents" folder which the phishing site is now requesting access), there are already so many ways to scam these people that we need better solutions.
- illiarian 4y ago
  > Put "block this page from requesting any future permissions" checkbox in the confirmations, and create another API (I know...) so that good sites can request multiple permissions at once. "Good sites". Like the "good" apps on Android that ask for a hundred permissions at once. Like that good Android flashlight that ended up settling with FTC: https://www.ftc.gov/news-events/news/press-releases/2013/12/android-flashlight-app-developer-settles-ftc-charges-it-deceived-consumers https://www.ftc.gov/news-events/news/press-releases/2013/12/... Edit: > there are already so many ways to scam these people that we need better solutions. We're literally in a discussion about one such solution: reduce the chance of scamming by sandboxing. And the question isn't just scamming. It's also things like fingerprinting: https://twitter.com/denschub/status/1582730985778556931?s=20 https://twitter.com/denschub/status/1582730985778556931?s=20
  - armchairhacker 4y ago
    The linked article is a bit different > The FTC’s complaint alleges that the company’s privacy policy deceptively failed to disclose that the app transmitted users’ precise location and unique device identifier to third parties, including advertising networks. In addition, the complaint alleges that the company deceived consumers by presenting them with an option to not share their information, even though it was shared automatically rendering the option meaningless. > Upon first opening the app, they were shown the company’s End User License Agreement, which included information on data collection. At the bottom of the license agreement, consumers could click to “Accept” or “Refuse” the terms of the agreement. Even before a consumer had a chance to accept those terms, though, the application was already collecting and sending information to third parties – including location and the unique device identifier. And just to be clear: the permission screen should make it really obvious that a site which can access the file system API can access files on your computer, which can be dangerous, and allow/encourage the user to only grant access to specific directories. If a site requests many permissions, they don't get to hide them within a big TOS, all requested permissions will be clearly shown. And the FileSystem API is already set up to transparently return a virtual file system (https://developer.mozilla.org/en-US/docs/Web/API/FileSystem https://developer.mozilla.org/en-US/docs/Web/API/FileSystem), so sites won't know if the user doesn't grant access vs. gives them an empty folder.

deleted 4y ago

[deleted]

capableweb 4y ago

Seems there are about 18 APIs that require explicit user permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API https://developer.mozilla.org/en-US/docs/Web/API/Permissions... 7 of those are actually available in Firefox at all.

illiarian 4y ago
It's definitely more complex than that because many of those APIs have additional areas that may or may not be covered by permissions. For example, Firefox implemented permissions for enumerating MIDI devices, and Chrome didn't, with predictable results: https://twitter.com/denschub/status/1582730985778556931?s=20 https://twitter.com/denschub/status/1582730985778556931?s=20

AshleysBrain 4y ago

Arguably looking at the whole picture means recognizing that some of these use cases will instead be done by traditional desktop apps that have far more invasive access often without needing to prompt the user for permission at all. In my view web browsers are a more secure and privacy-preserving option than that.

illiarian 4y ago
> In my view web browsers are a more secure and privacy-preserving option than that. Indeed. That's precisely why some browser vendors don't want to give random access to your computer to any and all website. And don't want to give every app and site access to the data that should be private to a particular web site. From this point of view sandboxing websites seems like a good compromise. --- It's also strange that the argument I keep hearing is "but apps have unrestricted access, so to preserve security and privacy... let's give web sites the same access as native apps". It doesn't work lime this.
- AshleysBrain 4y ago
  Browsers don't have the same access as native apps, and shouldn't. There are permission prompts, privacy controls and access limits. For example the File System Access API is not unfettered access, it's limited to only files and folders manually selected by the user and nothing else. This is not at all "random access to your computer", which is in fact what traditional desktop apps tend to have.
  - cxr 4y ago
    It becomes effectively "random" (arbitrary) when higher order effects take over. We saw this with ActiveX controls. It becomes a game of chicken that eventually leads to an imbalance where website operators always win.
  - illiarian 4y ago
    > Browsers don't have the same access as native apps, and shouldn't. Indeed. That's why browser vendors (well, some of them) take a dim view of "oh just let them access anything, just pop a confirmation prompt in there" > There are permission prompts, privacy controls and access limits. And users are surely aware of those and can definitely understand where to find them, and what implications those have? Literally the entire history of computing tells us: no. > This is not at all "random access to your computer" It is. This is already done by MacOS with its incessant "app X wants to access files in Y". Even I, a programmer, and a power user, end up clicking "to hell with it, yes" more often than not. Especially if I'm in the middle of an important task.

armchairhacker 4y ago

Put "block this page from requesting any future permissions" checkbox in the confirmations, and create another API (I know...) so that good sites can request multiple permissions at once. There are many sites which would really benefit from file system access and a unified API so that they don't have to resort to constant upload/download or roll their own virtual file system. It's more than worth slight inconvenience of another popup, and while it also makes scamming less tech-savvy people easier (e.g. if they store all their passwords in the "Documents" folder which the phishing site is now requesting access), there are already so many ways to scam these people that we need better solutions.

illiarian 4y ago
> Put "block this page from requesting any future permissions" checkbox in the confirmations, and create another API (I know...) so that good sites can request multiple permissions at once. "Good sites". Like the "good" apps on Android that ask for a hundred permissions at once. Like that good Android flashlight that ended up settling with FTC: https://www.ftc.gov/news-events/news/press-releases/2013/12/android-flashlight-app-developer-settles-ftc-charges-it-deceived-consumers https://www.ftc.gov/news-events/news/press-releases/2013/12/... Edit: > there are already so many ways to scam these people that we need better solutions. We're literally in a discussion about one such solution: reduce the chance of scamming by sandboxing. And the question isn't just scamming. It's also things like fingerprinting: https://twitter.com/denschub/status/1582730985778556931?s=20 https://twitter.com/denschub/status/1582730985778556931?s=20
- armchairhacker 4y ago
  The linked article is a bit different > The FTC’s complaint alleges that the company’s privacy policy deceptively failed to disclose that the app transmitted users’ precise location and unique device identifier to third parties, including advertising networks. In addition, the complaint alleges that the company deceived consumers by presenting them with an option to not share their information, even though it was shared automatically rendering the option meaningless. > Upon first opening the app, they were shown the company’s End User License Agreement, which included information on data collection. At the bottom of the license agreement, consumers could click to “Accept” or “Refuse” the terms of the agreement. Even before a consumer had a chance to accept those terms, though, the application was already collecting and sending information to third parties – including location and the unique device identifier. And just to be clear: the permission screen should make it really obvious that a site which can access the file system API can access files on your computer, which can be dangerous, and allow/encourage the user to only grant access to specific directories. If a site requests many permissions, they don't get to hide them within a big TOS, all requested permissions will be clearly shown. And the FileSystem API is already set up to transparently return a virtual file system (https://developer.mozilla.org/en-US/docs/Web/API/FileSystem https://developer.mozilla.org/en-US/docs/Web/API/FileSystem), so sites won't know if the user doesn't grant access vs. gives them an empty folder.