- From: Domenic Denicola <d@domenic.me>
- Date: Thu, 7 Jul 2016 13:08:48 +0000
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- 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>
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?
Received on Thursday, 7 July 2016 13:09:25 UTC