Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Raphael Kubo Da Costa]

Contact emails raphael.ku...@intel.com, rei...@chromium.org

Explainer
None

Specification https://w3c.github.io/battery

Summary Deprecate and remove the Battery Status API on insecure origins, such as HTTP pages or HTTPS iframes embedded in HTTP pages.

Blink component Blink>BatteryStatus

Motivation The Battery Status API allows web developers to have access to, among other things, a system's battery charging level and whether it is being charged. It is a powerful feature that has been around for over a decade and, as such, was originally designed with different security constraints.

https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins mentions how powerful features should not be exposed on insecure origins. We would like to add the [SecureContext] attribute to the spec's Web IDL so that navigator.getBattery() and the BatteryManager interface are only available in secure contexts.

This has also been discussed in W3C at the Devices and Sensors WG April 2021 meeting, where we agreed to fix https://github.com/w3c/battery/issues/15 by adjusting the Blink implementation.

Risks
Interoperability and Compatibility Blink is the only engine implementing the Battery Status API, so most/all users are already expected to check for the presence of navigator.getBattery() before using it.

We've been measuring usage of navigator.getBattery() in insecure contexts since M64. Per https://chromestatus.com/metrics/feature/timeline/popularity/2199 the counter sits at around 0.3% at the moment.

However, none of the URLs listed there are using the Battery Status API directly. The largest occurrence is embedded YouTube videos: embedded HTTPS iframes on HTTP pages count as insecure contexts. Thomas Steiner reached out to the YouTube team internally and they said this change would not adversely impact them. Other usages of navigator.getBattery() in insecure origins come from trackers and RUM (real user monitoring) code added to the URLs listed in chromestatus.com. In all cases, feature detection is already done so existing code would not break. Gecko: N/A Gecko does not implement this API. WebKit: N/A Safari does not implement this API. Web developers: No signals

Is this feature fully tested by web-platform-tests? Yes: https://wpt.fyi/results/battery-status?label=experimental&label=master&aligned (existing tests will be modified along with the Blink and spec changes)

Requires code in //chrome? False

Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1286748

Estimated milestones Add a deprecation message in M100, stop exposing the Battery Status API to insecure origins in M103.

Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4878376799043584

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

This generally looks good to me, and probably safe to do. However, it'd make me more confident if we could reduce the 0.3%. Is YouTube willing to turn off their usage now? My guess is that will be most of the 0.3%. @Thomas Steiner is that doable?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3336a23c-7486-4312-a095-3928303c66e4n%40chromium.org.

[Thomas Steiner]

On Thu, Jan 13, 2022 at 6:29 PM Chris Harrelson <chri...@chromium.org> wrote:

This generally looks good to me, and probably safe to do. However, it'd make me more confident if we could reduce the 0.3%. Is YouTube willing to turn off their usage now? My guess is that will be most of the 0.3%. @Thomas Steiner is that doable?

YouTube have said in http://b/19428619#comment16 (sorry, Google-internal) that this would not be a problem for them.

Cheers,

Tom

[Mike West]

LGTM1 to restrict this API to secure contexts with a 3 milestone deprecation window. If blockers come up in the meantime, we can reevaluate, but I'm satisfied with the spot checks you've done against existing usage.

-mike

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLnow3GAvQEPW0BHOg8uzzyubzfZQxD0YWbhHrCJqMpy7g%40mail.gmail.com.

[Mike Taylor]

LGTM2 - can you please file a bug to explicitly remove usage by YouTube?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcLeMWvo4ifTMq6N49v%3D5d_5h9qwNYZC__T9Q-wZs8CkQ%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fc5a5538-bdeb-fd98-1035-07e417f418fc%40chromium.org.

[bratell.d via Chromestatus]

LGTM4 (also testing new intent tracking UI)

[Raphael Kubo Da Costa]

Thanks everyone for the LGTMs.

Due to an oversight I ended up landing the CL that adds a deprecation warning before M99 branched, so compared to what I originally wrote the deprecation has started in M99 instead of M100. The plan to keep the deprecation message until M102 and stop exposing the API in insecure origins in M103 remains.

If you prefer, I can revert the CL in the M99 branch and return to the plan I'd announced.

[Mike Taylor]

I think it's fine to keep the warning CL in M99 as long as we stick to the original timeline of removal.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b89dca3f-3e44-47ba-9f79-8e7616912aaen%40chromium.org.

[Raphael Kubo da Costa]

Hi everyone,

M103 is here, so I'd like to double-check if I can go ahead and stop exposing the Battery Status API to insecure origins as described below. The numbers in https://chromestatus.com/metrics/feature/timeline/popularity/2199 remain flat (as explained, the percentage is pretty high but most of it comes from embedded https YouTube videos, trackers and RUM (real user monitoring) code in https pages.

Do I start another thread and get new LGTMs for the actual removal?

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/w80tJL8uEV8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3336a23c-7486-4312-a095-3928303c66e4n%40chromium.org.

[Yoav Weiss]

The LGTMs you got on this thread should be enough. Please make sure to monitor any issues related to this, and revert if needed. (while keeping the feature flag around to enable urgent re-activation of this if breakage turns out to be untenable)

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/78a58b86-f261-a6d5-7078-bd62aee0e30f%40intel.com.

[Ian Clelland]

Hi Raphael,

There was some work done towards this deprecation a while ago. Are you taking over https://chromium-review.googlesource.com/c/chromium/src/+/2206655 for this deprecation, or is there a new line of work underway?

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/78a58b86-f261-a6d5-7078-bd62aee0e30f%40intel.com.

[Raphael Kubo da Costa]

Hey Ian. AFAICS these are all tasks to get the current implementation to match the spec, but they are independent: this intent covers only exposing navigator.getBattery() to secure origins, whereas the CL you linked to covers permissions policy integration (it also happens to perform some secure context checks manually that are covered by this intent though).

https://crbug.com/1007264 is assigned to me, but I haven't gotten around to working on it yet.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKXxJDiMaGvVxb3btpToOjoG9AOEc19E-83TeCAmXZL2Q%40mail.gmail.com.

[Raphael Kubo da Costa]

Thanks, Yoav. I've submitted https://chromium-review.googlesource.com/c/chromium/src/+/3605588 to implement this change. There's never been a feature flag for this though (in M99 we just added a deprecation warning), should I add one now?

[Yoav Weiss]

I think it'd be better to add a feature flag disabled by default, and then work with someone at Google to enable it on the server side for a release, before enabling it in code.

That way it'd be easy to revert this in case this unexpectedly breaks things.

[Mike West]

I'm less worried about this than Yoav is. Given the lack of support in any other browser, and the progressive-enhancement nature of this API, it's difficult for me to imagine embedded content visibly breaking at scale. If y'all do some spot-checking of the sites currently showing up through HTTP Archive, and have some evidence of the lack of user-visible breakage, I'd be comfortable without the additional complexity of percentage rollouts through Finch.

If we do decide that that's necessary, we'll need to make sure that we have some sort of reasonable error message in the console so that the subset of developers who do experience some sort of breakage have a chance of understanding why.

-mike

On Monday, April 25, 2022 at 9:36:26 PM UTC+2 Yoav Weiss wrote:

I think it'd be better to add a feature flag disabled by default, and then work with someone at Google to enable it on the server side for a release, before enabling it in code.

That way it'd be easy to revert this in case this unexpectedly breaks things.

On Mon, Apr 25, 2022 at 5:00 PM Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> wrote:

Thanks, Yoav. I've submitted https://chromium-review.googlesource.com/c/chromium/src/+/3605588 to implement this change. There's never been a feature flag for this though (in M99 we just added a deprecation warning), should I add one now?

On 25-04-2022 16:40, Yoav Weiss wrote:

The LGTMs you got on this thread should be enough. Please make sure to monitor any issues related to this, and revert if needed. (while keeping the feature flag around to enable urgent re-activation of this if breakage turns out to be untenable)

On Thu, Apr 21, 2022 at 3:00 PM Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> wrote:

Hi everyone,

M103 is here, so I'd like to double-check if I can go ahead and stop exposing the Battery Status API to insecure origins as described below. The numbers in https://chromestatus.com/metrics/feature/timeline/popularity/2199 remain flat (as explained, the percentage is pretty high but most of it comes from embedded https YouTube videos, trackers and RUM (real user monitoring) code in https pages.

Do I start another thread and get new LGTMs for the actual removal?

On 13-01-2022 16:09, Raphael Kubo Da Costa wrote:

Contact emails raphael.kubo.da.costa@intel.com, rei...@chromium.org

Explainer
None

Specification https://w3c.github.io/battery
Summary Deprecate and remove the Battery Status API on insecure origins, such as HTTP pages or HTTPS iframes embedded in HTTP pages.
Blink component Blink>BatteryStatus
Motivation The Battery Status API allows web developers to have access to, among other things, a system's battery charging level and whether it is being charged. It is a powerful feature that has been around for over a decade and, as such, was originally designed with different security constraints.

https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins mentions how powerful features should not be exposed on insecure origins. We would like to add the [SecureContext] attribute to the spec's Web IDL so that navigator.getBattery() and the BatteryManager interface are only available in secure contexts.

This has also been discussed in W3C at the Devices and Sensors WG April 2021 meeting, where we agreed to fix https://github.com/w3c/battery/issues/15 by adjusting the Blink implementation.

Risks
Interoperability and Compatibility Blink is the only engine implementing the Battery Status API, so most/all users are already expected to check for the presence of navigator.getBattery() before using it.

We've been measuring usage of navigator.getBattery() in insecure contexts since M64. Per https://chromestatus.com/metrics/feature/timeline/popularity/2199 the counter sits at around 0.3% at the moment.

However, none of the URLs listed there are using the Battery Status API directly. The largest occurrence is embedded YouTube videos: embedded HTTPS iframes on HTTP pages count as insecure contexts. Thomas Steiner reached out to the YouTube team internally and they said this change would not adversely impact them. Other usages of navigator.getBattery() in insecure origins come from trackers and RUM (real user monitoring) code added to the URLs listed in chromestatus.com. In all cases, feature detection is already done so existing code would not break. Gecko: N/A Gecko does not implement this API. WebKit: N/A Safari does not implement this API. Web developers: No signals

Is this feature fully tested by web-platform-tests? Yes: https://wpt.fyi/results/battery-status?label=experimental&label=master&aligned (existing tests will be modified along with the Blink and spec changes)
Requires code in //chrome? False
Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1286748
Estimated milestones Add a deprecation message in M100, stop exposing the Battery Status API to insecure origins in M103.
Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4878376799043584

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/w80tJL8uEV8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3336a23c-7486-4312-a095-3928303c66e4n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Raphael Kubo da Costa]

I tend to agree with Mike here; none of the users of navigator.getBattery() in insecure contexts I checked in the past (via chromestatus.com) would break with this change, as they're all checking if it's available first (including the largest user so far, YouTube), which makes sense since other engines don't ship this API.

What I can do is write another CL that adds a new Blink runtime feature set to experimental and updates the current deprecation message and mentions the feature will be removed in M104, not M103. What's not clear is whether it would be possible to warn users if the feature flag is on and a website tries to use the Battery Status API in an http page, as adding something like [SecureContext=MyFeatureFlag] to the IDL files would prevent the code where the warning would go from even being reached if MyFeatureFlag is on.

With that said, I guess it's up to the API owners to decide on the course here?

[Yoav Weiss]

OK, if you ran through a sample of users and saw none of them break, that's reassuring. How many users have you sampled?

At the same time, I'm not aware of a real way in IDL today to indicate that an API is not accessible in non-secure contexts and at the same time to have such access trigger a warning.

On Thu, Apr 28, 2022 at 12:04 PM Raphael Kubo da Costa <raphael.ku...@intel.com> wrote:

I tend to agree with Mike here; none of the users of navigator.getBattery() in insecure contexts I checked in the past (via chromestatus.com) would break with this change, as they're all checking if it's available first (including the largest user so far, YouTube), which makes sense since other engines don't ship this API.

What I can do is write another CL that adds a new Blink runtime feature set to experimental and updates the current deprecation message and mentions the feature will be removed in M104, not M103. What's not clear is whether it would be possible to warn users if the feature flag is on and a website tries to use the Battery Status API in an http page, as adding something like [SecureContext=MyFeatureFlag] to the IDL files would prevent the code where the warning would go from even being reached if MyFeatureFlag is on.

With that said, I guess it's up to the API owners to decide on the course here?

On 26-04-2022 09:47, Mike West wrote:

I'm less worried about this than Yoav is. Given the lack of support in any other browser, and the progressive-enhancement nature of this API, it's difficult for me to imagine embedded content visibly breaking at scale. If y'all do some spot-checking of the sites currently showing up through HTTP Archive, and have some evidence of the lack of user-visible breakage, I'd be comfortable without the additional complexity of percentage rollouts through Finch.

If we do decide that that's necessary, we'll need to make sure that we have some sort of reasonable error message in the console so that the subset of developers who do experience some sort of breakage have a chance of understanding why.

-mike

On Monday, April 25, 2022 at 9:36:26 PM UTC+2 Yoav Weiss wrote:

I think it'd be better to add a feature flag disabled by default, and then work with someone at Google to enable it on the server side for a release, before enabling it in code.

That way it'd be easy to revert this in case this unexpectedly breaks things.

On Mon, Apr 25, 2022 at 5:00 PM Raphael Kubo da Costa <raphael.ku...@intel.com> wrote:

Thanks, Yoav. I've submitted https://chromium-review.googlesource.com/c/chromium/src/+/3605588 to implement this change. There's never been a feature flag for this though (in M99 we just added a deprecation warning), should I add one now?

On 25-04-2022 16:40, Yoav Weiss wrote:

The LGTMs you got on this thread should be enough. Please make sure to monitor any issues related to this, and revert if needed. (while keeping the feature flag around to enable urgent re-activation of this if breakage turns out to be untenable)

On Thu, Apr 21, 2022 at 3:00 PM Raphael Kubo da Costa <raphael.ku...@intel.com> wrote:

Hi everyone,

M103 is here, so I'd like to double-check if I can go ahead and stop exposing the Battery Status API to insecure origins as described below. The numbers in https://chromestatus.com/metrics/feature/timeline/popularity/2199 remain flat (as explained, the percentage is pretty high but most of it comes from embedded https YouTube videos, trackers and RUM (real user monitoring) code in https pages.

Do I start another thread and get new LGTMs for the actual removal?

On 13-01-2022 16:09, Raphael Kubo Da Costa wrote:

Contact emails raphael.ku...@intel.com, rei...@chromium.org

Explainer
None

Specification https://w3c.github.io/battery
Summary Deprecate and remove the Battery Status API on insecure origins, such as HTTP pages or HTTPS iframes embedded in HTTP pages.
Blink component Blink>BatteryStatus
Motivation The Battery Status API allows web developers to have access to, among other things, a system's battery charging level and whether it is being charged. It is a powerful feature that has been around for over a decade and, as such, was originally designed with different security constraints.

https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins mentions how powerful features should not be exposed on insecure origins. We would like to add the [SecureContext] attribute to the spec's Web IDL so that navigator.getBattery() and the BatteryManager interface are only available in secure contexts.

This has also been discussed in W3C at the Devices and Sensors WG April 2021 meeting, where we agreed to fix https://github.com/w3c/battery/issues/15 by adjusting the Blink implementation.

Risks
Interoperability and Compatibility Blink is the only engine implementing the Battery Status API, so most/all users are already expected to check for the presence of navigator.getBattery() before using it.

We've been measuring usage of navigator.getBattery() in insecure contexts since M64. Per https://chromestatus.com/metrics/feature/timeline/popularity/2199 the counter sits at around 0.3% at the moment.

However, none of the URLs listed there are using the Battery Status API directly. The largest occurrence is embedded YouTube videos: embedded HTTPS iframes on HTTP pages count as insecure contexts. Thomas Steiner reached out to the YouTube team internally and they said this change would not adversely impact them. Other usages of navigator.getBattery() in insecure origins come from trackers and RUM (real user monitoring) code added to the URLs listed in chromestatus.com. In all cases, feature detection is already done so existing code would not break. Gecko: N/A Gecko does not implement this API. WebKit: N/A Safari does not implement this API. Web developers: No signals

Is this feature fully tested by web-platform-tests? Yes: https://wpt.fyi/results/battery-status?label=experimental&label=master&aligned (existing tests will be modified along with the Blink and spec changes)
Requires code in //chrome? False
Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1286748
Estimated milestones Add a deprecation message in M100, stop exposing the Battery Status API to insecure origins in M103.
Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4878376799043584

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/w80tJL8uEV8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3336a23c-7486-4312-a095-3928303c66e4n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Raphael Kubo da Costa]

Back when I sent the original Intent to Deprecate and Remove email, I checked the samples from the previous quarter listed in chromestatus.com and surveyed some 50 websites.

Some of them were no longer using the Battery Status API from an insecure context (either because they had switched to HTTPS or because they had stopped embedding whatever was using it before), but 43 had a match in the form of trackers, embedded YouTube videos, Facebook widgets and, in 2 cases, other trackers that also performed feature detection.

Today I surveyed another 40 from the previous quarter. All of them were either using Yandex trackers and/or embedded YouTube videos; a single one was using another tracker that also performed feature detection before using the API.

I ended up doing these checks manually; I can try to perform some larger queries via HTTPArchive if preferred.

[Yoav Weiss]

So, to summarize:

• Spot checking ~50 examples showed none that actually broke. Most seem to be coming from a small number of sources.
• There's no way for us to remove the feature from non-secure contexts without breaking feature detection while also warning users about it going away.

Given the first point, I'm fine with this being controlled by an on-by-default flag (due to the low risk).

Mike - are you OK with the second point?

[Raphael Kubo da Costa]

Just one clarification: the spot-check covers ~80 websites still using the Battery Status API in insecure contexts (out of a total of 90-100 if you include those in chromestatus.com that no longer do).

[Mike West]

Yes, I’m still ok with this plan. The risk exists, but seems both reasonably researched and reasonably low. So, still LGTM.

-mike

--

-mike