- From: Mats Wichmann <mats@osg.samsung.com>
- Date: Thu, 7 Jul 2016 07:47:34 -0600
- To: public-device-apis@w3.org
On 07/07/2016 07:08 AM, Domenic Denicola wrote: > From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com] > >>> 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. > > Sure. But this doesn't really answer my question. Why is battery different than all the other permission-based APIs, such as notifications? > I don't get it either. App needs permission. App doesn't get permission. App concludes the user probably clicked a button to deny permission. So? It that constitutes unacceptable fingerprinting exposure, seems like we just need to do away with all permission requests. I get that Uber is abusing an otherwise useful API, but that's presumably based on actually getting permission and reading the status, not on drawing conclusions off of not getting permission to do so.
Received on Thursday, 7 July 2016 13:48:08 UTC