You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I think the Secure Context's many definitions are confusing. You can talk about an environment settings object in three ways: "Is settings object contextually secure?", "settings object is contextually secure", and "settings object is a secure context". I only surfaced the last one, although I added data-lt="" to preserve autolinks the first one. I can't figure out how to preserve autolinks to the middle one as it would require a data-dfn-for="", which would break the other two. /cc @tabatkins
I also did not bother defining "secure context" for globals. It seems easy enough to grab their relevant settings object. (Note that no autolinks will break since the Secure Context spec only has one definition.)
I was planning to send a PR to update the Secure Context spec to point to this (while preserving existing IDs), but given how many open PRs on it have been sitting with no response, I'm feeling discouraged. (And I'd want to wait for at least Meta: no more fork of WHATWG HTML w3c/webappsec-secure-contexts#76 to land before doing mine.) /cc @mikewest
Hmm, I guess HTTPS state should be checked although there's only a single implementation who cares about "deprecated" at the moment and that's Chrome. But that seems fairly easy to add. An environment is not a secure context if its HTTPS state is "deprecated".
We might also want to expose the API in worklets at some point, but I guess we can wait until there are requests and we wouldn't want to use this PR to add new features anyway.
OK, force-pushed a new commit that takes into account HTTPS state (which led to some algorithm restructuring), and also a separate commit on top of this which uses the resulting definition for COOP.
One thing I was thinking of is renaming the internal concept to "secure environment" to more accurately capture what it is about.
I agree that would have been a better name from the beginning, but the current terminology is so deeply embedded in how we talk about security on the web, I'd rather not shift things now.
For workers I think we technically only have to check owner set[0] as they are either all a secure context or not due to the way we allocate shared workers. Otherwise secure context could change over time which should not be the case. So perhaps we should make that explicit somehow.
This would still apply COOP if HTTPS state of the response is "deprecated" as you're not checking the response, only the reserved environment.
The reason will be displayed to describe this comment to others. Learn more.
If we get many things like COOP we might need another abstraction layer, but hopefully we don't. Ideally @mikewest would look at this, but I haven't been able to get in touch either...
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This supersedes the definition in
https://w3c.github.io/webappsec-secure-contexts/, and fixes several bugs
while doing so.
Closes #5558. Closes w3c/webappsec-secure-contexts#56. Closes
w3c/webappsec-secure-contexts#57. Closes
w3c/webappsec-secure-contexts#74. Closes
w3c/webappsec-secure-contexts#75.
Notes/things to discuss:
data-lt=""to preserve autolinks the first one. I can't figure out how to preserve autolinks to the middle one as it would require adata-dfn-for="", which would break the other two. /cc @tabatkinsisSecureContexthere since that is mentioned as an open item in https://w3c.github.io/webappsec-secure-contexts/#monkey-patching-global-object/browsing-the-web.html ( diff )
/infrastructure.html ( diff )
/origin.html ( diff )
/parsing.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )