51–60 of 77 posts
With the last option, app-makers cannot bribe the user into installing the app with unwanted permissions anyway.
For example, when the app wants file-system access, the "pretend" option would give the app a view of an empty or dummy (fake) file-system. When the app wants access to GPS coordinates, the "pretend" option would give the app dummy coordinates. Et cetera.
An example is Safari's content blocker API. They've designed it so well that the content blocker doesn't know what it's blocking, or what sites you're visiting. Apple didn't merely reduce the amount of private information collected; they eliminated it.
Another example is iOS, where a permission is needed to access all contacts, but if you just want to pick a content (say to share a document), you can invoke the system picker without needing a permission.
The web needs to adopt such privacy-sensitive subsets of permissions in addition to a blank cheque "access all data on all sites".
Disclosure: I work for Google, but not on Chrome.
I think a permission model should have 3 choices for every question: allow, disallow, and pretend. With the last option, app-makers cannot bribe the user into installing the app with unwanted permissions anyway. For example, when the app wants file-system access, the "pretend" option would give the app a view of an empty or dummy (fake) file-system. When the app wants access to GPS coordinates, the "pretend" option w…
I think a permission model should have 3 choices for every question: allow, disallow, and pretend. With the last option, app-makers cannot bribe the user into installing the app with unwanted permissions anyway. For example, when the app wants file-system access, the "pretend" option would give the app a view of an empty or dummy (fake) file-system. When the app wants access to GPS coordinates, the "pretend" option w…
It probably needs to show notification when actual call to fake api is made.
I think a permission model should have 3 choices for every question: allow, disallow, and pretend. With the last option, app-makers cannot bribe the user into installing the app with unwanted permissions anyway. For example, when the app wants file-system access, the "pretend" option would give the app a view of an empty or dummy (fake) file-system. When the app wants access to GPS coordinates, the "pretend" option w…
I'd like to add a fourth choice: ask every time. When the app wants to access your GPS coordinates, you can grant it temporarily. Much like Android's integrity tools (maybe it's just a Cyanogenmod feature) where you can choose to be asked every time an app wants to access some kind of data.
I think a permission model should have 3 choices for every question: allow, disallow, and pretend. With the last option, app-makers cannot bribe the user into installing the app with unwanted permissions anyway. For example, when the app wants file-system access, the "pretend" option would give the app a view of an empty or dummy (fake) file-system. When the app wants access to GPS coordinates, the "pretend" option w…
Earlier quoted context omitted.
I'd like to add a fourth choice: ask every time. When the app wants to access your GPS coordinates, you can grant it temporarily. Much like Android's integrity tools (maybe it's just a Cyanogenmod feature) where you can choose to be asked every time an app wants to access some kind of data.
The mix of the grandparent's and your options might give a very streamlined UX: the app is always given the full permission which is but only simulated by default, and any actual access the user is noted of that with a non-modal message box, where one can turn the simulation on or off. Some permissions (e.g. storage access) may not be hard to generalize like this, but it may work for other permissions like GPS and so…
In fact doing it this way would be very bad.
In sandbox model it’s usually the container that owns the file selection ui, perhaps accepting some plugins etc. from the client. The client is never granted permissions to see outside the sandbox. Pretend mode in this context would result in requesting unnecessarily broad access.
IMO for things like location the only way to do it both in user-friendly and privacy-friendly way requires a capabilities system. When an app is given privacy-sensitive data it shouldn’t be simultaneously granted any permissions that allow this data to be leaked.
I think a permission model should have 3 choices for every question: allow, disallow, and pretend. With the last option, app-makers cannot bribe the user into installing the app with unwanted permissions anyway. For example, when the app wants file-system access, the "pretend" option would give the app a view of an empty or dummy (fake) file-system. When the app wants access to GPS coordinates, the "pretend" option w…
I don't see "pretend" as being productive. If you're dealing with an app that would otherwise refuse to run without a permission, even if it didn't truly need the permission to function, then it would simply escalate the arms race. It would be pretty easy to detect a fake filesystem (try to write a file, then read it back) and spoofed GPS (GeoIP, ping supposed nearby servers, etc). And, of course, these checks could…
I think a permission model should have 3 choices for every question: allow, disallow, and pretend. With the last option, app-makers cannot bribe the user into installing the app with unwanted permissions anyway. For example, when the app wants file-system access, the "pretend" option would give the app a view of an empty or dummy (fake) file-system. When the app wants access to GPS coordinates, the "pretend" option w…
I don't see "pretend" as being productive. If you're dealing with an app that would otherwise refuse to run without a permission, even if it didn't truly need the permission to function, then it would simply escalate the arms race. It would be pretty easy to detect a fake filesystem (try to write a file, then read it back) and spoofed GPS (GeoIP, ping supposed nearby servers, etc). And, of course, these checks could…
It sounds like a case of overly broad permissions. Have they looked at other permissions models? For one, extensions should be able to include an explanation why they need each permission. Network access should be a separate permission like it is for iOS keyboards. It's safer for an ad blocker to read and modify a page if it has no method of exfiltrating the content. Blacklist updates can be done through the regular…
Do you mean an English description, provided by the plugin? That would be useless. Malware is hardly going to come out and say that it needs permission to modify all requests so that it can hijack your connection.
If you mean a description that tries to read from what the code is doing why it needs the permissions, that's not much different from just "This app needs access to your location Yes/No?" Inferring "reason" from request patterns isn't going to work.