Hacker News Reader

Comment by illiarian | Hacker News Reader

> 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.

View on HN

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.

> 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.

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.

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.

> 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.

> This is already done by MacOS with its incessant "app X wants to access files in Y".

Of course this happens a lot after installing a new machine. Once I have my machine running however, I don't encounter this anymore. I think it has to do with the fact that I very infrequently install new applications.

I've had this happen to me just twice in the past week. One was something to do with Zoom, and one I can't even remember what (I think an app I installed, but didn't run).

In at least one of those cases I was like "you want my Downloads? Fine, go away" because I was in the middle of some task :)

Seems there are about 18 APIs that require explicit user permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions...

7 of those are actually available in Firefox at all.

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

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.

> 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/...

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

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), so sites won't know if the user doesn't grant access vs. gives them an empty folder.

> The linked article is a bit different

We could go for a different one: https://cybernews.com/privacy/android-apps-are-asking-for-to...

There's no world in which "good sites" ask for many permissions in one go, and the bad ones don't.

> 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

When a site/app requests several permissions at once, this "really obvious" becomes a wall of text full of technical and non-technical implications that very few users will read or indeed understand.

We literally have this already on Android and to a somewhat lesser extent on iOS.

Reply on news.ycombinator.com