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.co...@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.co...@intel.com, reil...@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 > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EBatteryStatus> > *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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>*? > *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 > <https://chromestatus.com/>. > > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3336a23c-7486-4312-a095-3928303c66e4n%40chromium.org?utm_medium=email&utm_source=footer> > . > > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/78a58b86-f261-a6d5-7078-bd62aee0e30f%40intel.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvJ13X3k5D2JenmYbtuLNLZNd2umTUUsb%3DfVq6BPXpyw%40mail.gmail.com.
