Faking permissions

[KOLANICH]

I suggest to state in the standard that the web browser MUST allow the user to fake permission. If the permission is faked, the privileged API user

• MUST get FAKE information instead of genuine one
• MUST get the response from WebAPI as if the permission was really granted

When a user selects "deny" option, this should change the state into "fake" by default. There should be an option allowing a user explicitly deny the app to use the requested API.

FAKE information is the information generated using model and 3 sources of information: 1 API call arguments 2 model parameters, which must be standardized 3 secure PRG 4 model-specific parameters

There should be a standardized API allowing the developers to plug own model.

[petkaantonov]

Why?

[KOLANICH]

Because if an app can know if a user have given it the asked permissions, it'll be able to greenmail a user in a way 'either you give a permission or you won't use the app, you better give the permission because our app is unique and you have no choice ;)'. Most of users will have no choice, and most of devs don't really want to digg into someone's obfuscated crapcode to remove this restriction. It is very widespread on Android ecosystem and if the measures won't be taken at the stage of standard design, we'll have such problem in the Web.

Of course, an app really strongly willing to have permissions will be able to determine if permission was not given, because simulated output always can be distinguished from genuine, but it would be harder and there will be less such webapps.

[petkaantonov]

Yes but presenting yet another complicated option to an user they likely don't understand, is really terrible solution. If this is only happening in android* (which has ahead-of-time permissions) and not in ios which has just-in-time permissions just like web, then this is not a problem in the first place.

^{*Android 6.0 has finally just-in-time permissions.}

[petkaantonov]

How about:

1. No permission can be asked ahead-of-time
2. Since permission is always asked just-in-time, we can make it so that app cannot tell difference between denial and operational error. For example, asking a geolocation and getting denied permission would result in an Error that is indistinguishable from some other error like broken GPS.

This way there is no need to make it more complicated to user

To make this backward compatible, any ahead-of-time permission api query currently in production would always respond with "granted".

[KOLANICH]

Yes but presenting yet another complicated option to an user they likely don't understand, is really terrible solution.

I think the browser devs should ask a user first if he wants 3 or more options or just 2.

Since permission is always asked just-in-time, we can make it so that app cannot tell difference between denial and operational error. For example, asking a geolocation and getting denied permission would result in an Error that is indistinguishable from some other error like broken GPS.

No. An error means the app mustn't work because of the error. When GPU, CPU or motherboard fails, PC cannot work. When it fails because the user's kick, it cannot work too. We need the app working but having no access to the data so It is should be as indistinguishable for an app from _normal operation_ of privileged API as possible.

How about the following: there can be 4 states: initial, granted, denied and faked. When the permission is not asked, it is in initial state. When a user takes action it switches to any of other states. When a user denies, it switches to "fake" state, when a user agrees, it switches to "granted" state. Power users can also switch to "deny" state to explicitly deny to give an app a permission, which will mean that there will be no need to simulate data. In all "granted", "denied" and "faked" states there should be possible to query the API for data, because if "fake" was used instead of "deny" in most cases devs wouldn't consider "deny" case and it'd useless because it'd crash apps.

[petkaantonov]

Error means the app mustn't work because of error.

Huh? Operational errors are completely part of normal application flow, they need to be handled just like success case needs to be handled.

[KOLANICH]

Huh? Operational errors are completely part of normal application flow, they need to be handled just like success case needs to be handled.

Because it is the right of app developer to make the app doing anything he wants. If an app's primary objective is to show GPS coordinates, in the case of GPS receiver failure it may show the message "sorry, this app cannot operate because your GPS is broken. See you when you fix your GPS.". If an app's primary objective to collect user's data as payment for the service, it can say the same. No private data - no service.

[petkaantonov]

"sorry, this app cannot operate because your GPS is broken"

If the app says this then it looks like the goal of preventing blackmail was achieved.

[KOLANICH]

If the app says this then it looks like the goal of preventing blackmail was achieved.

No. Because the user explicitly denied to give the data to the app, he understands that this message was the result of his decision, so he will reload the page and give the app permission it requests, which means the success of the greenmailing.

[petkaantonov]

I think this is very different since the app is no longer coercing the user to do anything. Your assumption that the user will go out of their way in this scenario to allow permission anyway is questionable.

[KOLANICH]

the app is no longer coercing the user to do anything

The usual app in fact never coerces anyone, it trades access to the app's services for a user's private data: it is not going to arrest/kill/hurt/torture/destroy anyone, anyone's friends or relatives or anyone's property. That's why I call it a greenmail, not a blackmail. And I think it should be prevented, by putting in a standard an accessible to everyone way to cheat a greenmailing app.

[petkaantonov]

That is completely different than from what you initially said: 'either you give a permission or you won't use the app, you better give the permission because our app is unique and you have no choice ;). This contains coercion and urges the user to do something which is very bad. An app simply showing an error message is completely fine and it is not any kind of *mail, green, or black or whatever. I will be unsubscribing now.

[KOLANICH]

That is completely different than from what you initially said

No.

'either you give a permission or you won't use the app, you better give the permission because our app is unique and you have no choice ;).' This contains coercion and urges the user to do something which is very bad.

This is how market works. Noone owes you anything, and the webapp developer is not obliged to provide you the service. Neither you obliged to provide them the data. I don't think that trading data for service is "very bad", anyone has right to do with his data anything, including selling it to third parties or bartering for service. But building internet economy over business models based on trading user's data is very bad and should be discouraged with tools, allowing users to cheat in the case the businessman chose this model. IMHO even business models based on forcing the user to see _untargeted_ ads are less dangerous.

An app simply showing an error message is completely fine and it is not any kind of *mail, green, or black or whatever.

An app showing an error message because it is unable to service the user without them is completely fine, but an app which purpose is to make a user to barter his personal data for crap isn't.

I will be unsubscribing now.

OK.

[marcoscaceres]

The privacy section states that:

implementations are encouraged to have an option for users to block (globally or selectively) the querying of permission states.

Regarding a "fake" state, that would never be reflected in the API, so UAs would be free to do that in the UI (even as part of developer tools or whatever). However, this spec doesn't need to say anything about how a UA might go about doing that.

I guess if anything, it might go into the Privacy considerations section - but this honestly might be better on a per API basis (e.g., faking granularity with Geolocation is best handled in the Geo spec).