Add [SecureContext] to BatteryManager and the Navigator partial interface. #51
Conversation
2a17fcb to
081b09d
Compare
…face. In other words, stop exposing this API to insecure origins. Even though this API is not new, it provides user information that, transmitted insecurely, can pose a risk to user privacy. See https://w3ctag.github.io/design-principles/#secure-context for more information on the guidelines we are trying to follow. This has been discussed since at least 2016 (see #5). #11 made access from an insecure origin throw a SecurityError at a time when the `[SecureContext]` Web IDL extended attribute was not widespread. Unfortunately, the spec change was not accompanied by a change in the implementation(s) and, to this day, Blink's implementation (the only remaining one) continues to expose the API to insecure origins. Years later, #30 was added in the context of the discussions in #15 where it was noted that the spec was still manually throwing a SecurityError when checking if it was called by a secure origin. Besides stopping throwing a SecurityError (which was never implemented), #30 also recognized the current situation by noting that the API _should_ use `[SecureContext]` but did not because it only made sense to do so when the implementation was updated accordingly. This change finally adds `[SecureContext]` to the spec's Web IDL because I am also handling the Blink implementation [1][2]: starting with Chrome 99, users will be warned that using the Battery Status API in an insecure origin is deprecated, and starting with Chrome 103 doing so will no longer be possible. [1] https://chromestatus.com/feature/4878376799043584 [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/w80tJL8uEV8/m/PfrHlvtgAgAJ From a testing perspective, there isn't much to be done: - web-platform-tests/wpt#5871 changed the existing tests to run in HTTPS. - web-platform-tests/wpt#32556 removed the test for the SecurityError exception that never passed. Fixes #15
081b09d to
c706ad9
Compare
|
(Piggypacking [no pun intended] on this PR for context.) @sandandsnow, I'd like share with you an update on our continued work to improve privacy of APIs in scope of Devices and Sensor WG. Feel free to share this news with PING as appropriate: Following https://w3ctag.github.io/design-principles/#secure-context we limited the Battery Status API to secure contexts. This ensures end-to-end integrity and confidentiality of battery status information and protects users' privacy. As you can see from the initial PR comment, the reason this change took rather long to bake into the spec was to ensure we don't break a large number of websites that rely on this API. We also wanted to coordinate this spec change with the required implementation updates that were approved recently and are now rolling out in phases. This is also a heads up that in the near future we will reach out to PING to do another review of this API. Before requesting your review, we'll first do some informative updates such as refresh on the questionnaire, improve documentation of use cases #25 and possibly also note in the spec a high-level API opportunity #52 that'd further improve privacy (the last one would be a long-term effort). I'll get in touch with you when the specification is ready for PING to take another look. Thanks for working with us. |
|
Makes sense. Though secure contexts are probably not adding much value. Not hurting, too. |
|
@lknik thanks for your review. As you know, secure context is now a baseline requirement for modern powerful capabilities. This API predates that time, so we had to work from that point of reference. That said, the WG is committed to maintenance and modernization of its APIs so you should expect us to continue improve also this API with consideration for new use cases, web compatibility, implementability with relentless focus on privacy and security. This is a step by step process and we’ll engage you and other privacy experts for review of any privacy-related changes. Thanks for working with us. |
|
Oh, sure. And I understand that such features should have this by default. All is well :) |
|
@anssiko thank you. I'm very pleased to hear that the API will be now be restricted to secure contexts and that will be working on improving the privacy design of the API. Please keep us posted. |
In other words, stop exposing this API to insecure origins. Even though this
API is not new, it provides user information that, transmitted insecurely,
can pose a risk to user privacy. See
https://w3ctag.github.io/design-principles/#secure-context for more
information on the guidelines we are trying to follow.
This has been discussed since at least 2016 (see #5). #11 made access from
an insecure origin throw a SecurityError at a time when the
[SecureContext]Web IDL extended attribute was not widespread.Unfortunately, the spec change was not accompanied by a change in the
implementation(s) and, to this day, Blink's implementation (the only
remaining one) continues to expose the API to insecure origins.
Years later, #30 was added in the context of the discussions in #15 where it
was noted that the spec was still manually throwing a SecurityError when
checking if it was called by a secure origin. Besides stopping throwing a
SecurityError (which was never implemented), #30 also recognized the current
situation by noting that the API should use
[SecureContext]but did notbecause it only made sense to do so when the implementation was updated
accordingly.
This change finally adds
[SecureContext]to the spec's Web IDL because Iam also handling the Blink implementation [1][2]: starting with Chrome 99,
users will be warned that using the Battery Status API in an insecure origin
is deprecated, and starting with Chrome 103 doing so will no longer be
possible.
[1] https://chromestatus.com/feature/4878376799043584
[2] https://groups.google.com/a/chromium.org/g/blink-dev/c/w80tJL8uEV8/m/PfrHlvtgAgAJ
From a testing perspective, there isn't much to be done:
exception that never passed.
Fixes #15
Preview | Diff