2 ms·
> 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
by 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 agoThe 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.
- illiarian 4y ago> The linked article is a bit different We could go for a different one: https://cybernews.com/privacy/android-apps-are-asking-for-too-many-dangerous-permissions-heres-how-we-know/ 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.