Re: [battery] Mitigating potential privacy-invasive usage

@cpeterso Thanks for your comments. My response below is a bit wordy 
since I wanted to include some historical perspective, hope it's 
useful. As the co-editor of the spec, I've been watching from the 
front row how the spec has developed over the years, driven by 
implementers' feedback.

About prompting:

You're right about prompting. [Studies 
show]( normal users do
 not grasp the concept. That's why prompting is not required, it is 
just an 
 ("The user agent may ask the user for battery status information 
access."), and not the only mitigation mechanism.

About use cases:

None of the high value use cases *for browsers* that I know of require
 high precision readouts. For example, [all the use cases I 
 are implementable with less precise readouts. How precise the readout
 is for each of the property of `BatteryManager` is up to the 
implementation to decide, can vary from one to another (and can vary 
during runtime, more on that below). The following [recommendation in 
 is meant to aide implementers in this regard: "The user agent should 
not expose high precision readouts of battery status information as 
that can introduce a new fingerprinting vector."

(We'd be happy to make this even more clear and concrete, we're open 
to suggestions for better wording.)

The spec leaves it up to the implementation to decide what is 
considered the right precision for each property. Each browser strikes
 a different balance between privacy and exposing powerful features. 
The spec as worded allows implementers to innovate and compete in this
 regard, while still remain spec-compliant.

For example, a privacy-aware browser might expose just hardcoded 20% 
or 80% readouts or round time-related readouts to nearest hour, while 
another implementation might offer higher precision readouts e.g. in 
cases when the user has established a stronger trust relationship with
 the web page. For example, a Progressive Web App that has been 
[installed]( might get 
higher precision readouts. The API surface remains the same. There's 
more room for innovation here for browser vendors.

About the history of the API:

The API was refactored since Mozilla's initial Firefox OS-inspired 
proposal to make it browser-friendly and privacy-aware. Namely, in the
 current API 
 is gated behind a promise (in Mozilla's proposal, it was directly 
exposed on `navigator.battery`) and the security and privacy 
considerations have been refined (in the initial proposal, they were 
too relaxed for browsers). These changes were done based on Google's 

After these changes Google felt good shipping the API in Chrome.

GitHub Notification of comment by anssiko
Please view or discuss this issue at using 
your GitHub account

Received on Wednesday, 2 November 2016 11:46:59 UTC