Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #10: Restrict to secure context and top-level browsing context #11

Merged
merged 1 commit into from
May 10, 2017

Conversation

anssiko
Copy link
Member

@anssiko anssiko commented May 10, 2017

No description provided.

@anssiko anssiko requested a review from riju May 10, 2017 08:25
@anssiko
Copy link
Member Author

anssiko commented May 10, 2017

Thanks for the swift review @riju!

@anssiko anssiko merged commit 893dd49 into gh-pages May 10, 2017
rakuco added a commit that referenced this pull request Jan 31, 2022
…face.

In other words, stop exposing this API to insecure origins.

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
rakuco added a commit that referenced this pull request Feb 1, 2022
…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
rakuco added a commit that referenced this pull request Feb 1, 2022
…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
rakuco added a commit that referenced this pull request Feb 1, 2022
…face. (#51)

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants