- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Thu, 7 Jul 2016 09:04:25 +0000
- To: Domenic Denicola <d@domenic.me>
- CC: "marcos@marcosc.com" <marcos@marcosc.com>, Dominique Hazael-Massieux <dom@w3.org>, W3C Device APIs WG <public-device-apis@w3.org>, "Frederick Hirsch" <w3c@fjhirsch.com>
> 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. 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. Thanks, -Anssi
Received on Thursday, 7 July 2016 09:07:10 UTC