Intent to Implement and Ship: Battery status API gated by feature policy

[Roguski, Piotr]

Contact emails

piotr....@mobica.com 

Explainer

https://github.com/w3c/webappsec-feature-policy

Design doc/Spec

https://w3c.github.io/webappsec-feature-policy/

Summary

Battery status API gated by feature policy provides developers with a way to control this API availability. 

Motivation

Battery status API provides a way to check host device battery status. This might be important eg. for applications which need to ensure enough power is available for completing the task. Unfortunately this kind of API might be misused for fingerprinting, profiling etc. By gating battery status API using feature policy mechanism, developers will be able to disable usage of this API within application, also for third party components.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Negative signals - Battery API was removed thus there can’t be feature policy control over this API

Safari: No signals

Web / Framework developers: No signals.

Please include links where possible. Examples include resolutions from relevant standards bodies (e.g. W3C Working Group), tracking bugs, or links to online conversations.

Ergonomics

NA

Activation

NA

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

https://github.com/web-platform-tests/wpt/tree/master/battery-status

Link to entry on the feature dashboard

NA

Requesting approval to ship?

Yes.

Mobica is a global software services company, delivering and enabling technologies that transform business outcomes for the leading brands in Automotive, Silicon, FinTech, Media and Telecoms. Headquartered in Wilmslow UK with offices across Europe and the US, our established technical and delivery excellence in high quality software engineering drives success for our multinational customers on every continent, every day.

Find out more at Mobica.com

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information.

If you have received this message in error, please send it back to us, and immediately and permanently delete it.
Do not use, copy or disclose the information contained in this message or in any attachment.
Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/

[Yoav Weiss]

On Wed, May 27, 2020 at 11:13 PM 'Roguski, Piotr' via blink-dev <blin...@chromium.org> wrote:

Contact emails

piotr....@mobica.com 

Explainer

https://github.com/w3c/webappsec-feature-policy

Design doc/Spec

https://w3c.github.io/webappsec-feature-policy/

Neither the explainer nor the spec outline the Battery API.

But it does seem like Feature Policy integration was added to the relevant spec. 

However, this change would break the API in cross-origin contexts and insecure contexts, which have 3.1% and 0.5% respectively.

+Rick Byers and +Mounir Lamouri on that thread seemed to have differing opinions at the time. I'm curious to hear what they think today.

Summary

Battery status API gated by feature policy provides developers with a way to control this API availability. 

Motivation

Battery status API provides a way to check host device battery status. This might be important eg. for applications which need to ensure enough power is available for completing the task. Unfortunately this kind of API might be misused for fingerprinting, profiling etc. By gating battery status API using feature policy mechanism, developers will be able to disable usage of this API within application, also for third party components.

Risks

Interoperability and Compatibility

As noted above, the compatibility impact here may require further analysis.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTqMstuFj8TFRvnwfWEFiQDMLWn9Pq1QhFsreS4HctfZRQ%40mail.gmail.com.

[sligh...@chromium.org]

Apologies in advance for a digression:

Per Yoav's questions, I wasn't able to quickly understand how this intent intersects with secure contexts. The latest draft of the spec seems to restrict the feature to Secure Contexts (good!), but Yoav's usage numbers suggest usage on insecure origins.

I can't tell if we actually block use there today; can someone verify that we do? If we do not, will this work also add this restriction?

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mounir Lamouri]

Non-secure context is indeed supported by Chromium. The spec says otherwise but we started by adding a UseCounter. The usage on non-secure context seems low and in general, we are blocking enough APIs on non-secure contexts so it's probably fair to go forward with that. Though, should we start by adding a deprecation message before simply breaking this?

3.1% is however a significant usage. If we have an idea of which websites are impacted, it may help evaluate the risks here but I'm aware of legit usage of the API in x-origin iframes and it may be unfortunate to break.

-- Mounir

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[sligh...@chromium.org]

On Thursday, May 28, 2020 at 12:52:56 PM UTC-7, Mounir Lamouri wrote:

Non-secure context is indeed supported by Chromium. The spec says otherwise but we started by adding a UseCounter.

Thank you for clarifying!

 

The usage on non-secure context seems low and in general, we are blocking enough APIs on non-secure contexts so it's probably fair to go forward with that. Though, should we start by adding a deprecation message before simply breaking this?

I might be more cavalier about insecure context API breakage than others, so perhaps Mike or Yoav can weigh in on that? If we have to go with a deprecation warning, I'd argue for a short timeline and removal from insecure cross-origin iframes ASAP regardless.

 

3.1% is however a significant usage. If we have an idea of which websites are impacted, it may help evaluate the risks here but I'm aware of legit usage of the API in x-origin iframes and it may be unfortunate to break.

Agreed. Hoping we can come to a separate plan for that.

 

-- Mounir

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Joe Medley]

Can you please create a Chrome Status entry for this?

Thanks.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--

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+...@chromium.org.

[Roguski, Piotr]

Hi,

I guess I don't have needed permissions to do that.

Best regards,

PR

[Joe Medley]

Piotr,

I've given you access. Login is in the footer, then look for a blue "Add new feature" near the top of the page. Email me directly if you run into trouble.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Rick Byers]

Despite the huge and scary usecounter numbers, I do suspect this is likely to be fine. But from past experience we're often surprised at the breakage that can ensue. Even if 99% of sites using this API will degrade gracefully, that remaining 1% of 3% is still such a huge number of page loads that it could cause real business and user experience problems for someone who could be surprised by the change. So I think it does behove us to still do some research and follow the process to understand and mitigate potential harm.

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG_Epq99sOswsA0PY2_ihc8_50i4Econ5c7bJxTzQCOncg%40mail.gmail.com.

[Mike West]

Like Alex, I'm quite happy to restrict the API to secure contexts. That seems eminently reasonable to me, and it seems like the direction we should be going in for sensor/device data generally.

Like Rick, I think it's likely that the usecounter numbers are inflated by usage that we don't particularly need to worry about from a compatibility perspective. Still, I think the analysis he's asked for is necessary for us to evaluate the risk here, and I think that's the consensus among API owners based on the conversation at today's meeting. Can you dig in a bit to help us understand the impact?

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTqMstuFj8TFRvnwfWEFiQDMLWn9Pq1QhFsreS4HctfZRQ%40mail.gmail.com.

Mobica is a global software services company, delivering and enabling technologies that transform business outcomes for the leading brands in Automotive, Silicon, FinTech, Media and Telecoms. Headquartered in Wilmslow UK with offices across Europe and the US, our established technical and delivery excellence in high quality software engineering drives success for our multinational customers on every continent, every day.

Find out more at Mobica.com

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information.

If you have received this message in error, please send it back to us, and immediately and permanently delete it.
Do not use, copy or disclose the information contained in this message or in any attachment.
Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/

--
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+unsubscribe@chromium.org.

[Roguski, Piotr]

Hello,

do you have any advice regarding getting and analysing data to get a better understanding of possible impact?  I've tried HTTP Archive, but due to the huge amount of data, js minification and obfuscation it's hard to get to any conclusion. Also, searching within GitHub gives a lot of results.

Best regards,

Piotr Roguski

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTqMstuFj8TFRvnwfWEFiQDMLWn9Pq1QhFsreS4HctfZRQ%40mail.gmail.com.

Mobica is a global software services company, delivering and enabling technologies that transform business outcomes for the leading brands in Automotive, Silicon, FinTech, Media and Telecoms. Headquartered in Wilmslow UK with offices across Europe and the US, our established technical and delivery excellence in high quality software engineering drives success for our multinational customers on every continent, every day.

Find out more at Mobica.com

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information.

If you have received this message in error, please send it back to us, and immediately and permanently delete it.
Do not use, copy or disclose the information contained in this message or in any attachment.
Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG_Epq99sOswsA0PY2_ihc8_50i4Econ5c7bJxTzQCOncg%40mail.gmail.com.

[Ian Clelland]

There was discussion at TPAC about this some 18 months ago, and we considered that YouTube may be a significant contributor to this, as they may be using the API to select appropriate codecs. I attempted to put UKM in place at the time to check this, but unfortunately UKM only sees the top-level domain, and this is specifically an issue with embeds. (YouTube does have the ability to delegate this in embeds, and have made similar migrations with fullscreen and encrypted media policies already)

There is also a possibility that much of this usage is actually of the kind that we *want* to restrict -- third parties using this for fingerprinting, which is the reason for putting this under policy control in the first place.

I'm happy to help out with adding any additional metrics that could help understand the impact, if there are specific questions that we can ask to determine whether there would be significant breakage of legitimate uses.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTpZf3yQZRBe1ZYiG3Le_z7xL7w6Tc3T7BwHyhGyzUj0cQ%40mail.gmail.com.

[Roguski, Piotr]

I've looked into the first 10000 results from HTTP Archive and within sources there are some domains which appear more often than others. Some of them are related to ads. Others are related to some metrics. There is also a YT player. Below you will find some of them:

securepubads
adsafeprotected
valuecommerce
Yandex.Metrica
adscore
shopify.com
googlesyndication
IMA SDK
YT player

I would guess that in most cases API is used to fingerprint, and to check what kind of device is rendering the page (mobile or desktop).

I'm not sure how useful that would be, but maybe some kind of counter, counting usage of specific battery properties and events could help us to figure out some heuristic helpful in classifying use cases. For example (and that's only a loose idea), I would assume that webapps which need to end some important task, would check dischargingTime and then compare it with estimated finish time. On the other hand, for apps using this API for fingerprinting, battery level might be enough.

Another idea (I don't know if that is common practice) would be some survey for webapp devs where they could describe their use case and impact of the API change on their software.

BR,
Piotrek

[Daniel Bratell]

Fingerprinting sounds plausible, but as you say, it could also be some kind of "avoid heavy ads on certain devices" heuristic which would be more critical from a compatibility point of view.

Did you try to figure out what the scripts were doing or was it hard to see?

It seems to me that we still don't have a clear enough understanding to make an informed decision.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTp528oDBhNYTZAZux2CEyHMnsurHKhC%2BuvMPdmc%3DbaDDg%40mail.gmail.com.

[Rick Byers]

Coincidentally I just saw this paper suggesting that Akamai may be using the battery status API at scale to understand the performance impact of battery saver mode.

Perhaps we could take a reasonably sized sample of the hits from HA (1000 sites or something) and do a crawl to get the URLs of the scripts invoking the API? I think that might be pretty easy to set up with Puppeteer, but it could also be done with cluster telemetry. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87671386-b794-35f1-2d41-94bc47ba8e7a%40gmail.com.

[Yoav Weiss]

+Goel, Utkarsh - who wrote the paper in question.

Utkarsh - would restricting the Battery API by default in 3rd party contexts (so, inside cross-origin iframes) make it harder/impossible for you to perform this kind of research?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_cRLUM4izU6WC76SEtv6BCr%2BUh6TGac2GPKfp348Kpxw%40mail.gmail.com.

[Mike West]

Per discussion in tonight's API owners' meeting:

I think there's a reasonable constituency of API owners that believes that this is a good change, and support it philosophically. It seems quite reasonable to make this a delegated API, similar to other device-level APIs, and similarly reasonable to restrict it to secure contexts as a side-effect of that restriction. Likewise, it seems that many legitimate use cases will be either top-level, or can be easily delegated by the top-level context to the nested context that's expected to use the API.

As Daniel suggested above, though, it would be helpful to dig into the data a little more to ensure that the breakage this change would introduce is in line with our expectations. In particular, it would be useful to dig into the scripts that actually cause the API calls noted in the research you pointed to above, and determine what they're doing.

HTTPArchive has the complete body of all the scripts loaded for a page. It seems reasonable to grep through those for the battery API usage, and manually examine a random sample of them. My suspicion is that you'll find many of them to be identical code snippets, representing some common library or a set of widely-used third-parties, and that a user-visible purpose (or lack thereof) will be apparent. I'd appreciate it if you could dig a little deeper here, given the usage numbers.

-mike

[Goel, Utkarsh]

+Nic

 

Yoav, if the battery status info is available to first party resources, that should theoretically be sufficient to do this kind of analysis using the RUM data. But since I used mPulse for that analysis, I’ll let Nic confirm/comment.

 

Utkarsh

Error! Filename not specified.

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information.

If you have received this message in error, please send it back to us, and immediately and permanently delete it.
Do not use, copy or disclose the information contained in this message or in any attachment.
Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTqMstuFj8TFRvnwfWEFiQDMLWn9Pq1QhFsreS4HctfZRQ%40mail.gmail.com.

 

Mobica is a global software services company, delivering and enabling technologies that transform business outcomes for the leading brands in Automotive, Silicon, FinTech, Media and Telecoms. Headquartered in Wilmslow UK with offices across Europe and the US, our established technical and delivery excellence in high quality software engineering drives success for our multinational customers on every continent, every day.

Find out more at Mobica.com

Error! Filename not specified.

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information.

If you have received this message in error, please send it back to us, and immediately and permanently delete it.
Do not use, copy or disclose the information contained in this message or in any attachment.
Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG_Epq99sOswsA0PY2_ihc8_50i4Econ5c7bJxTzQCOncg%40mail.gmail.com.

 

Mobica is a global software services company, delivering and enabling technologies that transform business outcomes for the leading brands in Automotive, Silicon, FinTech, Media and Telecoms. Headquartered in Wilmslow UK with offices across Europe and the US, our established technical and delivery excellence in high quality software engineering drives success for our multinational customers on every continent, every day.

Find out more at Mobica.com

Error! Filename not specified.

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information.

If you have received this message in error, please send it back to us, and immediately and permanently delete it.
Do not use, copy or disclose the information contained in this message or in any attachment.
Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTpZf3yQZRBe1ZYiG3Le_z7xL7w6Tc3T7BwHyhGyzUj0cQ%40mail.gmail.com.

 

Mobica is a global software services company, delivering and enabling technologies that transform business outcomes for the leading brands in Automotive, Silicon, FinTech, Media and Telecoms. Headquartered in Wilmslow UK with offices across Europe and the US, our established technical and delivery excellence in high quality software engineering drives success for our multinational customers on every continent, every day.

Find out more at Mobica.com

Error! Filename not specified.

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information.

If you have received this message in error, please send it back to us, and immediately and permanently delete it.
Do not use, copy or disclose the information contained in this message or in any attachment.
Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ1LTp528oDBhNYTZAZux2CEyHMnsurHKhC%2BuvMPdmc%3DbaDDg%40mail.gmail.com.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87671386-b794-35f1-2d41-94bc47ba8e7a%40gmail.com.

[Jansma, Nic]

Akamai mPulse (via boomerang.js) only collects the Battery API data (if available) from the top-level page's context or from inside an anonymous iframe with the document.domain set to the same as the parent frame.  So, theoretically, we're always capturing it from same-origin contexts.

 

 

Nic Jansma
+1.408.650.0848 x70848	Akamai Technologies 150 Broadway Cambridge, MA 02142
Connect with Us:

[Mike West]

Pinging this thread. Were y'all able to gather some data?

-mike

[Mike West]

Hey folks!

We're going to assume that this intent is on-hold until we hear from y'all again.

-mike

[Jansma, Nic]

Hi Mike!

 

Sorry, I may be confused -- is your earlier question about gathering data directed at us (Akamai), or are you asking about the earlier idea to crawl HA to look at third-party script usage of the API?

[Yoav Weiss]

Hey Nic,

I believe Mike's comment was directed at the intent owners (regarding HA crawls) and not y'all.

Cheers,

Yoav