Yes, I’m still ok with this plan. The risk exists, but seems both reasonably researched and reasonably low. So, still LGTM.
-mike On Fri 29. Apr 2022 at 13:23 Raphael Kubo da Costa < [email protected]> wrote: > 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). > > > On 29-04-2022 12:52, Yoav Weiss wrote: > > 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? > > > On Thu, Apr 28, 2022 at 4:18 PM Raphael Kubo da Costa < > [email protected]> wrote: > >> 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. >> >> On 28-04-2022 13:12, Yoav Weiss wrote: >> >> 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 < >> [email protected]> 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 < >>>> [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> >>>>>> . >>>>>> >>>>> >>>>> >>> >> > -- -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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcP%2BRxNeYQhcAdHcshKWxkz%3DpN28OkkUR5R2NzA2QZ7-w%40mail.gmail.com.
