- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Nov 2016 11:46:53 +0000
- To: public-device-apis-log@w3.org
@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](http://devd.me/papers/howtoaskforpermission.pdf) normal users do
not grasp the concept. That's why prompting is not required, it is
just an
[option](https://w3c.github.io/battery/#security-and-privacy-considerations)
("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
enumerated](https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0011.html)
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
the
spec](https://w3c.github.io/battery/#security-and-privacy-considerations)
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](https://www.w3.org/TR/appmanifest/#dfn-install) 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
[`BatteryManager`](https://w3c.github.io/battery/#the-batterymanager-interface)
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
feedback.
After these changes Google felt good shipping the API in Chrome.
--
GitHub Notification of comment by anssiko
Please view or discuss this issue at
https://github.com/w3c/battery/issues/5#issuecomment-257842502 using
your GitHub account
Received on Wednesday, 2 November 2016 11:46:59 UTC