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 <
raphael.kubo.da.co...@intel.com> wrote:
> Just one clarification: the spot-check covers ~80 websites still
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
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
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
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
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
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
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
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
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
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?
On Thu, Apr 21, 2022 at 9:00 AM Raphael Kubo da Costa <
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
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
LGTM3
On Fri, Jan 14, 2022 at 7:20 PM Mike Taylor wrote:
> LGTM2 - can you please file a bug to explicitly remove usage by YouTube?
>
> On 1/14/22 8:00 AM, Mike West wrote:
>
> LGTM1 to restrict this API to secure contexts with a 3 milestone
> deprecation window. If blockers come up in the
LGTM2 - can you please file a bug to explicitly remove usage by YouTube?
On 1/14/22 8:00 AM, Mike West wrote:
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
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
On Fri, Jan 14, 2022 at 11:28 AM 'Thomas Steiner' via blink-dev <
On Thu, Jan 13, 2022 at 6:29 PM Chris Harrelson
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
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?
On Thu, Jan 13, 2022 at 7:09 AM Raphael Kubo Da
*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
19 matches
Mail list logo
