Add cross-site ancestor flag to environment. #11133
Conversation
|
This looks good to me, but talking to @cfredric we'd slightly prefer the term "ancestry" with "cross-site" or "same-site" as values. @bvandersloot-mozilla WDYT? |
|
I think that feedback makes a lot of sense- hanging it on the ESO is probably right. With respect to behavior when disconnected, I think the only corner case I worry about is if a disconnected document is able to perform fetches and then get reconnected later. In that case it should matter and we'd want some kind of latching to prevent disconnecting documents from being a way to escalate their privileges. If not, then this update should match your sketch for imlementation as a new algorithm on ESOs. |
There was a problem hiding this comment.
Nice, this looks good to me! Please also work on an update to the service worker spec, as the only other environment settings object on the platform.
I think the only corner case I worry about is if a disconnected document is able to perform fetches and then get reconnected later.
There's no way to reconnect disconnected documents, so I think we're safe!
|
I'm going to land the PRs identified in #9000 (comment) (including this one) soonish. We have reduced the scope to essentially only tackle the new way we integrate with Cookies at the IETF (and only for the Cookie and Set-Cookie header at this point). So in effect this should be a non-normative change. PRs building on top of this work will need to fill out the PR template completely however. |
This builds on whatwg/html#10991 and whatwg/html#11133. This should be a mostly editorial change, but with much more clarity about how the state flows into the IETF side. Co-authored-by: Johann Hofmann <[email protected]> Co-authored-by: Anne van Kesteren <[email protected]>
Updates whatwg#11133 This reverts commit c736250.
Updates whatwg#11133 This reverts commit c736250.
This builds on whatwg/html#10991 and whatwg/html#11133. This should be a mostly editorial change, but with much more clarity about how the state flows into the IETF side. Co-authored-by: Johann Hofmann <[email protected]> Co-authored-by: Anne van Kesteren <[email protected]>
This is commandeering #8036, and is meant to land with whatwg/fetch#1807 in its place.
(See WHATWG Working Mode: Changes for more details.)
/acknowledgements.html ( diff )
/nav-history-apis.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )
/worklets.html ( diff )