Removing the Battery Status API?

[Chris Peterson]

What is the use case for the Battery Status API [0],
navigator.getBattery()? Can we remove the Battery API or perhaps
restrict it to non-web content like browser extensions or privileged web
apps? Chrome and Firefox support the Battery API, but neither Edge nor
WebKit have signaled an intent to implement it [3].

In theory, web developers would use the Battery API to save document
data before the battery dies, to ease off heavy computation when the
battery is low, or to implement the Firefox OS settings app. The real
world use cases, however, seem to be fingerprinting users [1] and
inflating Uber prices for desperate users with low batteries [2]. Can
anyone point to a real website using the Battery API for a legitimate
purpose?

The BATTERY_STATUS_COUNT probe [4] reports over 200M battery API calls
for Firefox 49. The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE probe
[5] reports that 6% of web pages use the Battery API, IIUC. That seems
surprisingly high given the few legitimate use cases. (Could that
counter be inadvertently triggered by web content that simply enumerates
the navigator object's properties without actually calling
navigator.getBattery()?)

I have a patch that makes the Battery API chrome-only and fixes the
web-platform tests.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API
[1]
http://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf
[2] http://www.forbes.com/sites/amitchowdhry/2016/05/25/uber-low-battery/
[3] https://www.chromestatus.com/feature/4537134732017664
[4] https://mzl.la/2eDFvbR
[5] https://mzl.la/2eDG4Cj
[6] https://mzl.la/2eKcZ6d

[Anne van Kesteren]

On Wed, Oct 26, 2016 at 9:30 AM, Chris Peterson <cpet...@mozilla.com> wrote:
> (Could that counter be
> inadvertently triggered by web content that simply enumerates the navigator
> object's properties without actually calling navigator.getBattery()?)

That seems unlikely given it's a method so enumerating would not
trigger any side effects.

(I support removal by the way. I tried to advocate for removal at some
point, but it didn't really go anywhere.)


--
https://annevankesteren.nl/

[Gijs Kruitbosch]

Not that it matters much, but I would support removal so we get rid of
this class of bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1274731
, which is at least incidental evidence that "random" webpages use this
API, likely for fingerprinting reasons (that is, I can't think of a
"real" reason something like imgur.com would care about your battery).

Perhaps Andrea also has an opinion they would like to share, so CC'ing.

~ Gijs

[Jonathan Kew]

On 26/10/2016 08:30, Chris Peterson wrote:
> What is the use case for the Battery Status API [0],
> navigator.getBattery()? Can we remove the Battery API or perhaps
> restrict it to non-web content like browser extensions or privileged web
> apps? Chrome and Firefox support the Battery API, but neither Edge nor
> WebKit have signaled an intent to implement it [3].
>
> In theory, web developers would use the Battery API to save document
> data before the battery dies, to ease off heavy computation when the
> battery is low, or to implement the Firefox OS settings app. The real
> world use cases, however, seem to be fingerprinting users [1] and
> inflating Uber prices for desperate users with low batteries [2].

Maybe it was just me, but I initially (mis)interpreted this as a claim
that Uber does this. The article at [2], however, doesn't say that. It
does suggest this -could- be done, but not that it -has- been; and the
Uber representative is quoted as saying that "[w]e absolutely don’t use
that...".

I imagine the negative publicity if a company like Uber were caught
actually doing this -- which seems like it wouldn't be too hard for an
investigative reporter to confirm -- could well outweigh any benefit
they might hope to reap.

JK

[Boris Zbarsky]

On 10/26/16 3:30 AM, Chris Peterson wrote:
> The BATTERY_STATUS_COUNT probe [4] reports over 200M battery API calls
> for Firefox 49. The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE probe
> [5] reports that 6% of web pages use the Battery API, IIUC. That seems
> surprisingly high given the few legitimate use cases. (Could that
> counter be inadvertently triggered by web content that simply enumerates
> the navigator object's properties without actually calling
> navigator.getBattery()?)

In Firefox 49, the BATTERY_STATUS_COUNT thing counts actual calls to
getBattery() _and_ calls to the .battery getter (it distinguishes the
two, though); the latter would be affected by enumeration of Navigator
but the former would not. Also, it counts only the first call for the
given document, which means that 200M number is NOT inflated by multiple
per-page calls.

In particular, looking at the actual histogram, we have about 105M uses
of navigator.battery and 116M uses of navigator.getBattery(). Out of
how many loads? See below. Also, this may somewhat undercount
getBattery() calls, because the way our telemetry code is written if the
page does .battery before doing .getBattery() we will count the former
but not the latter. If the order is reversed we will count both.

The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE counter counts gets of
Navigator.battery and _would_ be affected by enumeration. This attibute
was removed in Firefox 50 (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1259335 which I'm pretty
sure you knew about already ;) ).

The good news is that the deprecated counter lets us answer the "out of
how many loads?" question, sort of. The numbers above are out of 924
million toplevel pageloads. However, note that BATTERY_STATUS_COUNT
counts per _document_, so can count multiple accesses per pageload when
iframes are involved.

One way to reconcile the two sets of numbers is that the 105M
_documents_ that use navigator.battery per the BATTERY_STATUS_COUNT
counter corresponds to 57M _pageloads_ that use navigator.battery per
the deprecated operation counter. Assuming that this ratio holds for
getBattery() (may not be a good assumption), that means about 6% of
pageloads also end up using getBattery(). That does seem ludicrously high.

So I decided to see what sites were doing with it. I set a breakpoint
in getBattery() and tried browsing. The first site I tried loading was
cnn.com, and it hit the breakpoint. It's hitting it because it's using
the "boomerang" library from https://github.com/yahoo/boomerang (or one
of its various clones) as far as I can tell, and
https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/memory.js#L177-L203
pokes at the battery API. Looks like it reports the battery level as
part of its telemetry? The original commit that introduces that is
https://github.com/yahoo/boomerang/commit/b0c41b144913338ea905f03fc28f32130c5521e5
which is not terribly informative as to _why_ that data is being collected.

Anyway, if that library is popular enough, that could account for a lot
of the telemetry we see. :(

-Boris

[Chris Peterson]

On 10/26/2016 9:21 AM, Boris Zbarsky wrote:
> So I decided to see what sites were doing with it. I set a breakpoint
> in getBattery() and tried browsing. The first site I tried loading was
> cnn.com, and it hit the breakpoint. It's hitting it because it's using
> the "boomerang" library from https://github.com/yahoo/boomerang (or one
> of its various clones) as far as I can tell, and
> https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/memory.js#L177-L203
> pokes at the battery API. Looks like it reports the battery level as
> part of its telemetry? The original commit that introduces that is
> https://github.com/yahoo/boomerang/commit/b0c41b144913338ea905f03fc28f32130c5521e5
> which is not terribly informative as to _why_ that data is being collected.

Thanks, Boris. That's a great analysis.

Boomerang reporting users' battery levels, hardwareConcurrency, and
maxTouchPoints sounds like active fingerprinting (what the library calls
"beaconing"). Boomerang also extracts third-party tracking IDs from
Google, Adobe, and IBM analytics cookies:

https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/third-party-analytics.js


chris

[Chris Peterson]

As proposed earlier on the dev-platform list [1], I made the Battery
Status API chrome-only in Firefox Nightly 52 (bug 1313580 [2]). The
battery code and tests remain, available to Gecko code and Firefox add-ons.

There should be little risk of web compat regressions. The battery API
was never implemented by IE, Edge, or Safari, so web content should
already be feature-detecting the API. Also, I know of no non-trivial
websites using the API for anything other than fingerprinting users in
the four years since Firefox introduced the API in 2012 (Firefox 10
[3]). Chrome added support in 2014.

We always have the option to make the API available to web content again
if a website or app demonstrates an interesting use case using Chrome's
battery API. However, I feel the supposed use cases for the battery API
would be better served by something like a lifecycle event API that
includes low battery/memory warnings. That would expose less identifying
information and allow the user and UA to customize the lifecycle settings.


[1]
https://groups.google.com/d/msg/mozilla.dev.platform/5U8NHoUY-1k/9ybyzQIYCAAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1313580
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=678694

[nicj...@gmail.com]

Boomerang is an open-source library [1] for collecting performance telemetry. You're correct that it currently captures the battery level and other device characteristics. While Boomerang was not designed for the purpose of fingerprinting users, it captures many performance metrics and page characteristics on the beacon. Boomerang also only captures battery level, not charging time/discharging time (which we understand to be needed for the fingerprinting case). mPulse RUM itself (which is one of the services that utilizes Boomerang) does not do user fingerprinting -- we capture all of this data to look at aggregate performance.

Boomerang has been collecting the battery level in supported browsers for a while, but we don't consider it an essential device characteristic. In aggregate, it becomes interesting -- we can tell, for example, if certain paths through a customer's website correlate with high battery discharge, indicating possible post-page-load performance issues (like too many ads).

Obviously there are better/others ways of doing this (such as the work being done on the Long Tasks API), measuring FPS, etc. But whenever things like the Battery API are available we love to capture all the data we can to see what interesting conclusions we can find out of it in our aggregate RUM data :)

That being said, if the Battery API went away we would probably shrug, and look forward to more actionable performance metrics such as the Long Tasks API.

PS, we know of customers and open-source users putting Boomerang on a couple thousand websites -- but that probably wouldn't account for 6% of page loads usage!

[1]https://github.com/SOASTA/boomerang

[Chris Peterson]

On 10/31/2016 11:23 AM, nicj...@gmail.com wrote:
> Boomerang is an open-source library [1] for collecting performance telemetry. You're correct that it currently captures the battery level and other device characteristics. While Boomerang was not designed for the purpose of fingerprinting users, it captures many performance metrics and page characteristics on the beacon. Boomerang also only captures battery level, not charging time/discharging time (which we understand to be needed for the fingerprinting case). mPulse RUM itself (which is one of the services that utilizes Boomerang) does not do user fingerprinting -- we capture all of this data to look at aggregate performance.
>
> Boomerang has been collecting the battery level in supported browsers for a while, but we don't consider it an essential device characteristic. In aggregate, it becomes interesting -- we can tell, for example, if certain paths through a customer's website correlate with high battery discharge, indicating possible post-page-load performance issues (like too many ads).

Thanks for the explanation of Boomerang. I see how battery level would
be an interesting data point for RUM. I don't know if the battery
measurements would be precise enough for short browsing sessions to be
actionable, though it might be interesting to exclude low-battery users
as outliers with non-representative system performance. :)

Have you seen any such correlations?

chris

[Joseph Lorenzo Hall]

Speaking on behalf of the privacy community (writ large and vaguely) thank
you very much for this!

best, Joe

On Mon, Oct 31, 2016 at 4:24 AM, Chris Peterson <cpet...@mozilla.com>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871

Tech Prom, CDT's Annual Dinner, is April 20, 2017!
https://cdt.org/annual-dinner

[Chris Peterson]

WebKit implemented the battery API, though Safari didn't expose the API
to web content. Yesterday the WebKit team proposed removing the API, too:

https://bugs.webkit.org/show_bug.cgi?id=164213

https://lists.webkit.org/pipermail/webkit-dev/2016-October/028468.html

[ma...@devries.jp]

Here's a real world use case:
https://github.com/jpdevries/mab-recommendations/blob/low-battery/proposed/low-battery.md#-responding-to-battery-levels

An interface whose components reduce their CPU usage based on battery levels. When the battery is low maybe they lower their frame rate, hit the API less often, don't use animation.

I understand the privacy concerns, but why can't these be handled similar to the Geolocation API? Ask permission to use / user opts in.

[Boris Zbarsky]

On 11/29/16 2:36 AM, ma...@devries.jp wrote:
> Here's a real world use case:
> https://github.com/jpdevries/mab-recommendations/blob/low-battery/proposed/low-battery.md#-responding-to-battery-levels

This is the theoretical use case, yes. Is anyone actually doing this in
practice, though? The link is to a recommendation document saying that
people _should_ do this...

> I understand the privacy concerns, but why can't these be handled similar to the Geolocation API? Ask permission to use / user opts in.

Because prompting users is generally an antipattern. If, as a user, you
got a battery API prompt on every single page (because the trackers on
it were trying to use it), what would be your reaction?

-Boris

[ma...@devries.jp]

On Tuesday, November 29, 2016 at 4:17:21 PM UTC+1, Boris Zbarsky wrote:

I'm not sure.

> Because prompting users is generally an antipattern. If, as a user, you
got a battery API prompt on every single page (because the trackers on
it were trying to use it), what would be your reaction?

That would be super annoying. I was thinking more of a click Respond to Battery Levels button then approve pattern.

[Mounir Lamouri]

On Tue, 29 Nov 2016, at 15:17, Boris Zbarsky wrote:
> > I understand the privacy concerns, but why can't these be handled similar to the Geolocation API? Ask permission to use / user opts in.
>
> Because prompting users is generally an antipattern. If, as a user, you
> got a battery API prompt on every single page (because the trackers on
> it were trying to use it), what would be your reaction?

There are other solutions that are not prompting. The specification even
provide guidance such as returning less granular values or even default
values.

-- Mounir

[Boris Zbarsky]

On 11/29/16 10:24 AM, ma...@devries.jp wrote:
> On Tuesday, November 29, 2016 at 4:17:21 PM UTC+1, Boris Zbarsky wrote:
>> Is anyone actually doing this in
> practice, though?
>
> I'm not sure.

OK. That's the part that really matters, in some ways. Everyone agrees
there are theoretical good things that can be done with the battery API;
we just don't observe them being done.

> That would be super annoying. I was thinking more of a click Respond to Battery Levels button then approve pattern.

That would still be super-annoying, I expect....

-Boris

[Anne van Kesteren]

On Wed, Oct 26, 2016 at 9:30 AM, Chris Peterson <cpet...@mozilla.com> wrote:
> I have a patch that makes the Battery API chrome-only and fixes the
> web-platform tests.

We ended up landing this patch and thereby no longer expose the API to
web sites in Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1313580

I'm updating this thread since there doesn't appear to be an intent to
unship email to dev-platform (that I could find) and this thread
appeared inconclusive to me when I was trying to figure out the
status. Glad this got done.


--
https://annevankesteren.nl/