pending/privacy (was Re: Notes of June 30 teleconference)

On Jul 7, 2016, at 2:04 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:
> 
>> On 06 Jul 2016, at 18:00, Domenic Denicola <d@domenic.me> wrote:
>> 
>> I think this is a bit of a misunderstanding. What I am saying in that post is that it's OK to have APIs that always fulfill, and never reject. I'm not explicitly endorsing APIs that stay pending forever.
>> 
>> I'm not against such APIs in principle; it seems like there are many cases where you might wait for something to happen which never happens. But in this case it seems like there's a clear-cut signal that the battery will not be gotten, when the user denies the prompt.
>> 
>> I'm curious why battery uses a different permissions model than most other APIs, which are OK with rejecting when the user denies permission?
> 
> This was due to privacy and fingerprinting concerns. Allowing the promise to reject, would mean the app knows the user probably actively acted on the request (or had a global policy to disallow access to battery), and such information could be used against the user. For example, Uber web app could say: "You must grant access to your battery to use the app". And what would not be said, is they might charge you more if you're low on battery.

While it might be described as a privacy issue, I don't think it was a particular fingerprinting issue, but just an issue of user control over how they communicate with their browser and with the site. As I understand it, the issue with these asynchronous permission dialogs has often been that users either ignore them, or want to ignore them without making a decision. It's not clear if that should be reported as denied-permission back to the site.

That is, it might be that the user just doesn't want to decide on something right now. "pending forever" seems possible in the case where a user just doesn't act on the permission prompt (however presented in UI). The long Firefox bug debate seems to be about taking that to allow the user, from the site's point of view, to not act, but still get rid of the doorhanger or hide whatever the UI is.

> The mitigation strategy was to allow the UA to report default values at will and never reject:
> 
> https://w3c.github.io/battery/#dfn-unable-to-report-the-battery-status-information
> 
> Marcos explained how real world experience from Firefox's Geolocation API (https://bugzil.la/675533) suggests not rejecting has caused UX issues. I think this is a tradeoff between UX and privacy.

There is certainly developer frustration around this topic, but I suspect that developers are always going to have to handle the case where users just don't respond, unless browsers want to move to modal permission dialogs (which I hope they don't!).

Sending fake/default battery values might be one way to respond to the malicious site case (which the Uber hypothetical seemed to be about). But in any case, it seems the API and site developers will have to accommodate the case where the site asks the user for access to the battery and the user doesn't respond.

—Nick