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 < > [email protected]> 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 < >> [email protected]> 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 *[email protected], [email protected] >>> >>> *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 >>> [email protected]. >>> 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 [email protected]. >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34dbbde4-d522-4b89-a653-161f14719e7cn%40chromium.org.
