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 <http://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 <http://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]
<mailto:[email protected]>,
[email protected] <mailto:[email protected]>
*Explainer*
None
*Specification *https://w3c.github.io/battery
<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
<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
<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.
Perhttps://chromestatus.com/metrics/feature/timeline/popularity/2199
<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 inchromestatus.com
<http://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
<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
<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
<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/5dac2b3f-92d8-1715-31ff-6c6c8123cb8a%40intel.com.
