Lukasz, you forgot to add an important pointer to the spec issue where we are discussing further mitigation strategies for implementers to consider:

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

I'd invite Chromium implementers to chime in on that issue, or in this bug.

With my spec co-editor hat on, I'd like to note that the current Chromium implementation is already as is of better quality and more privacy-aware than the other implementations that had reported privacy issues. Chromium implements the specification's security and privacy considerations to a greater extend, and in fact, the privacy aspects of the spec were improved based on Google's concrete feedback (thanks!) before the API was implemented in Chromium, and shipped in Chrome 38. Regrettably, other implementers were slow to adopt these spec improvements, or did not do that at all. And that's why the recent news.

To compare:

Mozilla's implementation (first landed in Firefox OS) exposed too precise readouts and did not gate BatteryManager behind a promise initially.

WebKit's implementation is not relevant to this discussion, given it is based on a very old obsolete version of the spec, and did not ship in any port with significant market share (notably, not in Safari).

The first privacy-aware implementation shipped in Chrome 38 in Oct 2014, while Mozilla adopted these improvements in Firefox 43 in Dec 2015. WebKit implementation has not kept up with the spec.

(I'd like to note that Mozilla's and WebKit's decisions to consider removal of the feature have little to no real-world impact in terms of total addressable market.)

Anssi,

Thanks you! Right (and I'm sorry - I could not edit the post to include more links). I'm all for a broad consideration of all the points, and I agree on mitigation strategies (that I helped to distill).

For what it's worth, in Yandex Browser for Android, we made the Battery API report default values (fully charged, charger connected) unless the user explicitly enables reporting of real values in the browser settings (disabled by default). This is compliant with the current Battery API spec and provides high level of privacy by default.

Anssi, can you please elaborate on what privacy protection mechanisms Chromium uses with respect to the Battery API, other than rounding to 2 digits of precision? We have found the Battery API to just report actual values without any kind of permission request or notification that the API is being used. The API is indeed gated behind a promise, but the promise is always resolved as soon as BatteryManager receives battery status update.

Andrey, credits are due to the Yandex Browser team for your innovative approach to add an extra layer of privacy protection on top of the Chromium base.

AFAIK vanilla Chromium behaves as you described, but I'll defer to the Chromium contributors for the authoritative answer.

Assigning to the only code OWNER for the battery module in Blink. No blink bug component seems to match this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3543d97ca7a33fb8ad48261ad252428555747896

commit 3543d97ca7a33fb8ad48261ad252428555747896
Author: rijubrata.bhaumik <rijubrata.bhaumik@intel.com>
Date: Thu Jun 01 13:00:03 2017

[Battery] Allow usage from SecureContext or top-level browsing context only.

Make the Battery Status API available only within a secure context that is
also a top-level browsing context. This disallows the use of the API within
framed content, as well as from any content that is not a secure context.

Details: https://github.com/w3c/battery/issues/10

WPT updated in https://github.com/w3c/web-platform-tests/pull/5871

BUG=661792

Review-Url: https://codereview.chromium.org/2880763002
Cr-Commit-Position: refs/heads/master@{#476263}

[modify] https://crrev.com/3543d97ca7a33fb8ad48261ad252428555747896/third_party/WebKit/LayoutTests/battery-status/detached-no-crash-expected.txt
[modify] https://crrev.com/3543d97ca7a33fb8ad48261ad252428555747896/third_party/WebKit/LayoutTests/battery-status/detached-no-crash.html
[delete] https://crrev.com/5d0edd94b0f86092c267bc9f5fc77396a994a135/third_party/WebKit/LayoutTests/external/wpt/battery-status/battery-iframe.https-expected.txt
[delete] https://crrev.com/5d0edd94b0f86092c267bc9f5fc77396a994a135/third_party/WebKit/LayoutTests/external/wpt/battery-status/battery-insecure-context-expected.txt
[modify] https://crrev.com/3543d97ca7a33fb8ad48261ad252428555747896/third_party/WebKit/Source/modules/battery/NavigatorBattery.cpp

Battery Status API must ask the user permission

Battery Status API has been removed in Firefox 52 due to privacy concerns. It used by malicious advertisements to track users across websites based on their battery levels and unique device identifiers. For more info see https://www.bleepingcomputer.com/news/software/battery-status-api-being-removed-from-firefox-due-to-privacy-concerns/.

Currently, besides Firefox, only Chromium has shipped this feature. But I still think the removing Battery Status API is a bad decision, because it can be useful for Progressive Web Apps to detect the status of the user's battery level, and use this information e.g. to save critical data to disk before the device shuts down, etc.

IMO, Battery Status API must not removed from Chromium, but must ask the user permission. Currently, Chromium doesn't ask the user permission to access Battery Status API.

On the other hand, anybody knows the useful Battery Status API use cases? IMO, detecting the status of the user's battery level and using this information to save critical data to disk before the device shuts down should be the operating system level task, not the web app level task.

If there is no useful Battery Status API use cases, Battery Status API should be removed.

Please see Uber pricing phone battery low scandal (https://thenextweb.com/insider/2016/05/20/uber-riders-will-pay-9-9-times-surge-pricing-phone-battery-low/).

Since moving Taxi services to PWA, it makes sense to ask the user permission to access Battery Status API or remove Battery Status API at all.

I enumerated useful use cases at https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0011.html

+rbyers@ for interop and as an api owner.

I've reverted the CL because it did not go trough a Intent to Ship and I believe it should have because it is significantly changing an observable behaviour. In addition, I do not think that preventing third party iframes to use the Battery API is a real solution to the problem and we should instead reduce the entropy of the information shared to a minimum.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f5f500ccbe3aa6f5bc50071c97f3fe6df3ef9efb

commit f5f500ccbe3aa6f5bc50071c97f3fe6df3ef9efb
Author: mlamouri <mlamouri@chromium.org>
Date: Tue Jun 13 15:21:49 2017

Revert of [Battery] Allow usage from SecureContext or top-level browsing context only. (patchset #6 id:160001 of https://codereview.chromium.org/2880763002/ )

Reason for revert:
This CL should have gotten a API OWNER lgtm with an Intent to Ship. If the change is accepted by the API OWNERS, we should re-land this.

Original issue's description:
> [Battery] Allow usage from SecureContext or top-level browsing context only.
>
> Make the Battery Status API available only within a secure context that is
> also a top-level browsing context. This disallows the use of the API within
> framed content, as well as from any content that is not a secure context.
>
> Details: https://github.com/w3c/battery/issues/10
>
> WPT updated in https://github.com/w3c/web-platform-tests/pull/5871
>
> BUG=661792
>
> Review-Url: https://codereview.chromium.org/2880763002
> Cr-Commit-Position: refs/heads/master@{#476263}
> Committed: https://chromium.googlesource.com/chromium/src/+/3543d97ca7a33fb8ad48261ad252428555747896

TBR=timvolodine@chromium.org,foolip@chromium.org,rijubrata.bhaumik@intel.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=661792

Review-Url: https://codereview.chromium.org/2937553005
Cr-Commit-Position: refs/heads/master@{#479025}

[modify] https://crrev.com/f5f500ccbe3aa6f5bc50071c97f3fe6df3ef9efb/third_party/WebKit/LayoutTests/battery-status/detached-no-crash-expected.txt
[modify] https://crrev.com/f5f500ccbe3aa6f5bc50071c97f3fe6df3ef9efb/third_party/WebKit/LayoutTests/battery-status/detached-no-crash.html
[add] https://crrev.com/f5f500ccbe3aa6f5bc50071c97f3fe6df3ef9efb/third_party/WebKit/LayoutTests/external/wpt/battery-status/battery-iframe.https-expected.txt
[add] https://crrev.com/f5f500ccbe3aa6f5bc50071c97f3fe6df3ef9efb/third_party/WebKit/LayoutTests/external/wpt/battery-status/battery-insecure-context-expected.txt
[modify] https://crrev.com/f5f500ccbe3aa6f5bc50071c97f3fe6df3ef9efb/third_party/WebKit/Source/modules/battery/NavigatorBattery.cpp

 Issue 747610  has been merged into this issue.

I am pretty sure  Issue 747610  is a duplicate of this one. tnagel and timvolodine, you can battle it out to see who gets to fix it. :)

Unlike mlamouri in #18, I don't think we need to harmonize with the community to fix this bug: The community has already fixed it by not supporting Battery API at all. So I really don't see any compatibility risk.

It's still polite and good to send out an Intent To Implement (or, IMO better, Intent To Deprecate And Remove), but I don't think we should hesitate to improve the situation either in large or small steps.

Ian is already working on it. (Thank you, Ian!)

I agree with Chris' report of  issue 747610 : In addition to disabling for non-secure contexts and cross-origin frames, the granularity of "level" should go way down (e.g. {0, 0.33, 0.67, 1} would seem sufficient to me) and likewise granularity of "*Time" should also go way down (rounding to hours?) or maybe we should remove "*Time" completely.

Having battery levels return 4 values seems overly restrictive. Returning 10 values would not share much entropy to possible fingerprinting. Remaining time could be updated every time the level is changed and rounded to 15/30 minutes.

Is there a reason why non-secure contexts should not have access to this?

Concerning granularity: As a rough approximation, 10 buckets would give 3.3 bits of entropy compared to 2 bits for 4 buckets. I'm not convinced there's a use case for more than ~4 buckets, i.e. why would a web app behave differently when battery is 60% than when battery is 70%?

Remaining time may be combined with battery level to determine the ratio of battery capacity over electric power which may be approximately constant, especially while charging, and thus could be used as a stable identifier.

remaining time   battery capacity
-------------- = ----------------
battery level     electric power

For that reason, I'd aim for a solution that makes calculation of that ratio as imprecise as feasible. One way to achieve that would be exponential buckets for remaining time, e.g. 0min, 15min, 30min, 60min, 120min, 240min, ...

> Is there a reason why non-secure contexts should not have access to this?

The latest draft [1] requires it. (I guess any API that reveals information about the client device should be limited to secure contexts?)

[1] https://w3c.github.io/battery/

> > Is there a reason why non-secure contexts should not have access to this?
>
> The latest draft [1] requires it. (I guess any API that reveals information 
> about the client device should be limited to secure contexts?)

It seems fairly clear to me that sensor data meets whatever standard we set for "powerful". I'm on board with deprecating non-secure usage of this API.

tnagel@, having 4 buckets would make the API completely useless. It would give only 2 values between 0 and 1 which would be 0.33 and 0.66. I wouldn't expect applications to actually do much with that information. For example, on Android, applications usually start to behave differently at 15% (at least, the system does).

In general, I'm not entirely convinced that sharing battery information (or any device info) on https is better than http but I'm not gonna die on that hill :)

> In general, I'm not entirely convinced that sharing battery information (or any device info) on https is better than http but I'm not gonna die on that hill :)

Sure. I wouldn't be sad if we removed the API entirely.

> applications usually start to behave differently at 15%

Sure, we can cater for that. How about the following buckets:

[0.00 .. 0.05[ --> 0
[0.05 .. 0.15[ --> 0.1
[0.15 .. 0.35[ --> 0.25
[0.35 .. 0.75[ --> 0.55
[0.75 .. 1.00] --> 1

Or maybe for a slightly cleaner look:

[0.00 .. 0.05[ --> 0
[0.05 .. 0.15[ --> 0.1
[0.15 .. 0.35[ --> 0.25
[0.35 .. 0.65[ --> 0.5
[0.65 .. 1.00] --> 1