[battery] Permission model inconsistency (was: Notes of June 30 teleconference)

[Updated the subject line to match the context.]

> On 07 Jul 2016, at 16:08, Domenic Denicola <d@domenic.me> 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?

The promise-based requestAccessToX().then(gotAccess, didntGetAccess) style was still evolving when this API was designed, so there was no clear cowpath to pave.

To clarify, shipping implementations (Chrome, Firefox) do not ask for permission. However, given BatteryManager is gated behind a promise, the hooks are in place for that.

[Plugging in another related reply from Mats sent to the list only (Domenic is not on the list).]

> On 07 Jul 2016, at 16:47, Mats Wichmann <mats@osg.samsung.com> wrote:
> 
> 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.

As said, current implementations do not ask for permission. Alternative mitigation strategy baked into the API is to emulate full battery:

https://w3c.github.io/battery/#dfn-unable-to-report-the-battery-status-information

Mozilla is considering this strategy per Marcos:

https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0000.html

To take this further, an implementation could immediately resolve the promise and report emulated full battery status and only if the user opts in to expose the real battery status expose the real values.

I created an issue where to follow up with proposed solutions:

https://github.com/w3c/battery/issues/5

Thanks,

-Anssi

Received on Thursday, 7 July 2016 15:36:15 UTC