Add cross-origin opener policy #5334

camillelamy · 2020-03-04T12:59:37Z

This commit adds the notion of cross-origin opener policy (COOP). COOP allows websites to restrict which origins they share their browsing context group with. annevk wrote a first draft of the behavior of COOP here: https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e. This commit takes that draft and merges it into the spec.

Closes: #4580

At least two implementers are interested (and none opposed):
- Chrome
- Mozilla
[Tests] Tests have already been added at:
- https://github.com/web-platform-tests/wpt/tree/master/html/cross-origin-opener-policy
Implementation bugs are filed:
- Chrome: https://crbug.com/922191
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1613066
- Safari: …

/browsers.html ( diff )
/browsing-the-web.html ( diff )
/dom.html ( diff )
/history.html ( diff )
/iana.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/offline.html ( diff )
/origin.html ( diff )
/references.html ( diff )
/webappapis.html ( diff )

yoavweiss

A couple of nits

source

mikewest

I started looking at this, then got distracted: sending the one useful comment I had before my brain disappeared.

source

mikewest

I think the structure here generally makes sense. I've added some comments (mostly nits), but I think the algorithms generally match what I expected this to look like. I think it'd be helpful for @annevk to hop in to verify that the structure matches his expectations as well. If that's the case, we can work through the rest of the nits and indentation and what should link to where and etc. :)

Thanks!

source

camillelamy

Thanks everyone for your review!

source

mikewest

Thanks, @camillelamy! I skimmed through the rewrite, and though I have nits and details, I'm still generally happy. I'd like @annevk to sign off on the general structure (or propose a different way of tackling the problem!) before going through them, just so I don't spend your time on something you'll need to rework more completely later. :)

annevk

Thanks for taking this on @camillelamy. I need to have another look at the generated HTML as that usually helps with blind spots, but it appears to be in pretty good shape. Left a bunch of inline comments and am curious to hear your thoughts on them.

source

camillelamy

Thanks @annevk for your review!

source

arturjanc

I read through the current text and I like it! A couple of tiny nits below.

source

annevk

It looks like replacing the browsing context happens when a document is already created. I'm not sure how that would work.

source

camillelamy

Regarding the timing between browsing context switch and document creation, my understanding is that document creation happens on step 6 of https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object. The spec PR adds the browsing context switch as step 4 of this algorithm. So for me we do the browsing context switch before we create the new document for the navigation.

source

annevk

Ah yeah, I think you're right. Okay, I think this is starting to look pretty good. It needs some more formatting changes (I can help with those) and I wonder if we should add some examples and a bit more introductory text here and there.

It would also be great if @domenic or someone that's not me could have another detailed look to grow the set of people familiar with this and also to ensure I'm not overlooking things as I wrote the Markdown draft of this.

source

camillelamy

Thanks Anne for your review. I have uploaded a new version addressing comments.

source

annevk · 2020-04-24T11:28:28Z

I pushed a commit that changed the cross-origin opener policy value explanations and also did some editorial changes. Things that remain:

The incumbent variables need a new name.
We should link to the actual algorithm that obtains a cross-origin embedder policy (at the moment obtain is not a link).
We should consider changing COOP to be a structured header. I'd be okay with this being a follow-up though.

I suspect I need at least one more pass after that and @domenic should maybe review as well, but things are looking pretty good to me.

(Feel free to make changes as subsequent commits by the way. We'll squash it all together when everyone is satisfied.)

camillelamy · 2020-05-04T15:02:26Z

Thanks for your review Anne! I have pushed a new version that:

changes the incumbent variable names - to make sure I understand correctly, in the navigation algorithm incumbentNavigationOrigin is the current origin and activeDocumentNavigationOrigin is the origin we are navigating to?
Adds a link to the algorithm for obtaining COEP
and makes COOP a structured header (note that I had to import a bunch of definitions to do so, let me know if I have missed something).

Thanks!

annevk

Alright, I have a couple more nits, but at this point I'd really like for @domenic and @mikewest to do a detailed review as I'm afraid I'm missing things due to having written the original text.

changes the incumbent variable names - to make sure I understand correctly, in the navigation algorithm incumbentNavigationOrigin is the current origin and activeDocumentNavigationOrigin is the origin we are navigating to?

I had another look at this and I don't think that's correct. incumbentNavigationOrigin seems to be the origin of the incumbent settings object (one of the parties responsible for making the navigation happen) and activeDocumentNavigationOrigin seems to be the origin of the document currently in the browsing context that is being navigated.

source

camillelamy · 2020-06-10T13:50:09Z

@annevk and @domenic : the latest version should now plumb the variables correctly in the various processing model algorithm. However, for calls to process a navigation response that happens in the navigate algorithm I am not quite sure what to do with some of the variables (in the special cases like JavaScript).

Contrary to the current explanation, when an opener specifies a COOP of `same-origin-allow-popups` and the opened resource specifies `unsafe-none`, then the two documents *will* share the same browsing context group. This is supported by the explanation of `same-origin-allow-popups` which precedes this section: > A top-level document with `same-origin-allow-popups` retains references to > any of its popups which either don't set COOP or which opt out of isolation > by setting a COOP of `unsafe-none`. It is also supported by the proposed specification text [1] which reads: > To check if a response requires a browsing context group switch , > given a browsing context browsingContext , an origin responseOrigin > and a cross-origin opener policy responseCOOP , run the followign > steps: > > [...] > > 6. If all of the following are true: > > - isInitialAboutBlank > - activeDocumentCOOP is " same-origin-allow-popups ". > - responseCOOP is " unsafe-none ". > > then return false. Update the explanation to only include the relevant condition (that is: a COOP of `same-origin`). [1] whatwg/html#5334

annevk · 2020-06-12T12:28:19Z

I think this is wrong for navigating to a response (initial fetching of <object data> also goes through this) and I'm not entirely sure to what extent we should address it here versus leaving it as it doesn't impact COOP I think. I wonder if we can assert that it doesn't happen in a top-level browsing context, but we should probably tackle that separately.

For javascript: URLs we have various open issues, but I think the important conclusion we reached was that they could not impact the existing policy in any way. So they are effectively a no-op as far as COOP goes.

camillelamy · 2020-06-16T12:13:09Z

For the response case, do you think we should do something like:
If the computed origin is the same as the current document, use that COOP.
Otherwise, use unsafe-none/compute it from the reponse?

annevk · 2020-06-16T14:33:57Z

I think only a nested document can be generated by navigating to a response and if that's true COOP doesn't really apply there, right?

camillelamy · 2020-06-17T10:04:21Z

I have updated the PR for the navigation to a response case. Now we assert that we are not in a top-level browsing context and pass an unsafe-none COOP.

annevk · 2020-06-18T13:27:55Z

Looking at various algorithms such as "process a navigate fetch" and its callers, I think that #4664 and #5098 ended up not updating various callers for these algorithms and sometimes even not update the signatures for these algorithms. And untangling this is tricky as it's not always clear what to pass. I guess I'll try to fix what I can and insert some  comments or some such to indicate what is missing.

Edit: this might be smaller than I thought, though it's hard to say for sure.

domenic

LGTM with a couple minor questions. I pushed some nit fixes, but otherwise this seems ready to land.

domenic · 2020-06-19T16:47:58Z

source

+ <li>
+ <p><span data-x="a browsing context is discarded">Discard</span> <var>browsingContext</var>.</p>
+
+ <p class="note">This does not close <var>browsingContext</var>'s <span data-x="tlbc


Is the concept of "closing" a BCG well-defined? If so, could we link to it? If not, maybe there's a better way of phrasing this?

No it's not defined. I have rephrased the comment, hopefully it's better.

domenic · 2020-06-19T16:49:32Z

source

+
+ <p class="XXX">The impact of swapping browsing context groups following a navigation is not
+ defined. It is currently under discussion in <a
+ href="https://github.com/whatwg/html/issues/5350">issue #5350</a>.</p>


Maybe "not fully defined"? After all, there are a lot of effects already defined, simply because the spec defines how different BCGs can't reach each other.

domenic · 2020-06-19T16:55:25Z

source

+ <li>
+ <p>If <var>sandboxFlags</var> is not empty and <var>responseCOOP</var> is not "<code
+ data-x="coop-unsafe-none">unsafe-none</code>", then set <var>response</var> to an
+ appropriate <span>network error</span> and return.</p>


This should not return from the entire algorithm, right? It should just break from the loop. Which makes step 8 below unnecessary? I will push a fix, but please confirm.

No it should return from the algorithm. At this point, we have found that we cannot load the page and will display an error page instead. There is no need to do a BCG switch for this error page, hence the early return.

Displaying an error page requires continuing the algorithm; that's done in step 1 of "process a navigate response".

You are correct. Sorry I got mixed up with the previous version where this was in a separate algorithm.

domenic · 2020-06-19T16:55:35Z

source

+
+ <li>
+ <p>If <var>sandboxFlags</var> is not empty and <var>responseCOOP</var> is not "<code
+ data-x="coop-unsafe-none">unsafe-none</code>", then set <var>response</var> to an


Your IDE is introducing tabs, it seems; I'll fix.

I am not seeing the tabs in the latest version of the file, so maybe you fixed this already?

Fixes whatwg#3740. Closes whatwg#4580. Need to check again if it closes them: * whatwg#4921 * whatwg#5168 * whatwg#5172 * whatwg#5198 (probably not?) Co-authored-by: Anne van Kesteren <[email protected]>

camillelamy

Thanks Domenic for your feedback!

camillelamy · 2020-06-24T12:18:54Z

source

+ <li>
+ <p><span data-x="a browsing context is discarded">Discard</span> <var>browsingContext</var>.</p>
+
+ <p class="note">This does not close <var>browsingContext</var>'s <span data-x="tlbc


No it's not defined. I have rephrased the comment, hopefully it's better.

camillelamy · 2020-06-24T12:20:05Z

source

+
+ <p class="XXX">The impact of swapping browsing context groups following a navigation is not
+ defined. It is currently under discussion in <a
+ href="https://github.com/whatwg/html/issues/5350">issue #5350</a>.</p>


camillelamy · 2020-06-24T12:27:41Z

source

+ <li>
+ <p>If <var>sandboxFlags</var> is not empty and <var>responseCOOP</var> is not "<code
+ data-x="coop-unsafe-none">unsafe-none</code>", then set <var>response</var> to an
+ appropriate <span>network error</span> and return.</p>


You are correct. Sorry I got mixed up with the previous version where this was in a separate algorithm.

camillelamy · 2020-06-24T12:28:27Z

source

+
+ <li>
+ <p>If <var>sandboxFlags</var> is not empty and <var>responseCOOP</var> is not "<code
+ data-x="coop-unsafe-none">unsafe-none</code>", then set <var>response</var> to an


I am not seeing the tabs in the latest version of the file, so maybe you fixed this already?

annevk · 2020-06-24T15:07:55Z

I noticed that multipart/x-mixed-replace also invokes "process a navigate response" and can do so from a top-level browsing context. Those subsequent responses should never be allowed to change COOP+COEP state I think, but this is not specified now. We might also not have test coverage there, because it's in general a somewhat buggy part of the whole navigation algorithm.

(I'm pretty sure I left this comment earlier, but it seems to have gotten lost.)

The other thing I realized thanks to Domenic's secure context work is that Chrome probably wants to also check the HTTPS state on the response and not support this feature when it's "deprecated" as that's technically not a secure context.

I would be okay with landing this and having follow-up issues though as it's rather tricky to keep reviewing this over a lot of rebasing. Especially now that PR Preview is broken.

domenic · 2020-06-24T17:38:43Z

Yay! I merged the result in c9fddd7.

From what I can tell we closed #3740, #4580, #4921, and #5172. #5168 might be closed, but I'm not sure; certainly we didn't do what #5168 (comment) suggests. #5198 is probably not closed. Please check this list carefully, reopening or closing as necessary.

I opened #5669 and #5670 for the followups @annevk mentions in his previous comment. I am tackling #5669.

jugglinmike · 2020-06-24T23:23:35Z

source

@@ -81727,10 +82030,17 @@ interface <dfn>Location</dfn> { // but see also <a href="#the-location-interface
 a <code>javascript:</code> URL request</span> given <var>resource</var>, the <span>source
 browsing context</span>, and <var>browsingContext</var>.</p></li>

+ <li><p>Let <var>finalSandboxFlags</var> be the union of <var>browsingContext</var>'s
+ <span>sandboxing flag set</span> and <var>response</var>'s <span>forced sandboxing flag
+ set</span>.</p></li>


How can response's forced sandboxing flag set be controlled in this case? I first thought it was via CSP directive, but after further research, that no longer seems possible (the header list contains only Content-Type and Referrer-Policy, and the sandbox directive is ignored if specified within a <meta> element).

I would not expect what the specification states around javascript URLs to be particularly reliable. There are still many unresolved issues there, many of them reported against this repository.

My interest is in writing tests, so I'm just as curious about what was intended by this change as what it literally means today. If the spec mechanics are incomplete, "tentative" tests would help communicate the intention and (via wpt.fyi) document current implementation status.

I think the intent is that whatever browsing context is navigated to a javascript URL, its current active document (i.e., at the start of the navigation) doesn't have most of its policy state change. I think this particular step is probably a no-op.

Thanks, Anne! Although I was initially focused on "response's forced sandboxing flag set", that's only part of the change. The new spec text also introduces a reference to "browsingContext's sandboxing flag set," which doesn't appear to be well-defined. I've opened gh-5682 to learn if this is an oversight or just a misreading on my part.

I have some issues with this part in Chrome.

Writing the content of the string returned from the javascript: URL evaluation into the document is considered by chrome not to be a cross-document navigation. This looks closer to executing a document.write(..)

Chrome can't implement this correctly, if this isn't considered a navigation. Many inheritance mechanism that applies during a navigation (including sandbox) are missing.

In the recent past:

I proposed to stop mutating the sandbox flags when doing document.write() in Chrome and converge with Firefox:
https://bugs.chromium.org/p/chromium/issues/detail?id=1186311&q=reporter%3Ame&can=2

I also patched Chrome to stop mutating sandbox when executing javascript: URL:
https://chromium-review.googlesource.com/c/chromium/src/+/2577211
At this point, I believed we were converging with Firefox, since Firefox was passing the new WPT

I believe Firefox behavior doesn't depends on the sandbox of the initiator of document.write/javascript, but still apply the new sandbox_flags of the iframe to the document, resulting in a sandbox_flags mutation.
For instance:

let empty_iframe = document.createElement("iframe"); document.body.appendChild(empty_iframe); // The initial empty document committed. empty_iframe.sandbox = "allow-xxx" // The sandbox flags of the frame have changed, they will be applied during the next navigation. empty_iframe.src = "javascript:\"Hello world\""; // - Chrome consider the previous line not to be a navigation. // As a result the sandbox flags of empty document haven't changed. // - Firefox apply the sandbox_flags of the <iframe> into the empty document.

@ArthurSonzogni can you please file that as a new issue so it doesn't get lost? We have a number of issues around javascript: URLs and perhaps now with appHistory and such it's a good time to figure out how to address them.

camillelamy mentioned this pull request Mar 4, 2020

Cross-Origin-Opener-Policy: provide a clearer spec. #4580

Closed

yoavweiss reviewed Mar 4, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

source Show resolved Hide resolved

camillelamy marked this pull request as ready for review March 4, 2020 15:25

mikewest reviewed Mar 5, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

arturjanc reviewed Mar 5, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

zcorpan reviewed Mar 5, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

mikewest reviewed Mar 6, 2020

View reviewed changes

camillelamy commented Mar 6, 2020

View reviewed changes

camillelamy requested review from mikewest, zcorpan and yoavweiss March 6, 2020 17:07

mikewest reviewed Mar 9, 2020

View reviewed changes

annevk reviewed Mar 9, 2020

View reviewed changes

camillelamy commented Mar 9, 2020

View reviewed changes

arturjanc reviewed Mar 10, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

source Show resolved Hide resolved

annevk reviewed Mar 11, 2020

View reviewed changes

source Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

annevk reviewed Mar 11, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

camillelamy mentioned this pull request Mar 12, 2020

Impact of browsing context group switch during navigation #5350

Closed

camillelamy force-pushed the issue-4580 branch from 55a19ad to 0c7ee85 Compare March 12, 2020 16:48

camillelamy commented Mar 12, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

source Outdated Show resolved Hide resolved

annevk reviewed Mar 25, 2020

View reviewed changes

annevk mentioned this pull request Apr 21, 2020

[COOP] Header syntax #5172

Closed

camillelamy force-pushed the issue-4580 branch 2 times, most recently from c0c121f to 6b15e55 Compare April 22, 2020 13:18

camillelamy commented Apr 22, 2020

View reviewed changes

camillelamy force-pushed the issue-4580 branch from 51e3837 to 0900232 Compare May 4, 2020 14:42

camillelamy mentioned this pull request May 7, 2020

Cross-origin opener policy reporting #5517

Closed

3 tasks

annevk reviewed May 11, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

jugglinmike mentioned this pull request Jun 10, 2020

Correct description of COOP unsafe-none GoogleChrome/web.dev#3185

Merged

camillelamy force-pushed the issue-4580 branch from a23436f to 4c4b7ac Compare June 17, 2020 09:59

domenic approved these changes Jun 19, 2020

View reviewed changes

domenic mentioned this pull request Jun 19, 2020

Cross origin opener policy reporting #5518

Merged

3 tasks

clamy and others added 8 commits June 24, 2020 14:04

Add the Cross-Origin-Opener-Policy header

06b4d8a

Fixes whatwg#3740. Closes whatwg#4580. Need to check again if it closes them: * whatwg#4921 * whatwg#5168 * whatwg#5172 * whatwg#5198 (probably not?) Co-authored-by: Anne van Kesteren <[email protected]>

Fix plumbing of extra parameters in processing models

01597c5

Add correct plumbing of COOP when navigating to a response

84ec089

Add COOP plumbing for JavaScript navigation

93b4680

Fix navigate to response case

6eca6f0

address some argument mismatches

68534cd

Editorial fixes

2ecb243

Rephrase comments

9755018

camillelamy force-pushed the issue-4580 branch from 2ff8d3c to 9755018 Compare June 24, 2020 12:27

camillelamy commented Jun 24, 2020

View reviewed changes

nit

2803530

domenic merged commit c9fddd7 into whatwg:master Jun 24, 2020

domenic mentioned this pull request Jun 24, 2020

COOP and multipart/x-mixed-replace #5670

Open

jugglinmike reviewed Jun 24, 2020

View reviewed changes

jugglinmike mentioned this pull request Jun 26, 2020

COOP: Potential ambiguity in definition of sandboxing flag sets #5682

Closed

caltrops6490 approved these changes Jul 22, 2020

View reviewed changes

Add cross-origin opener policy #5334

Add cross-origin opener policy #5334

Conversation

camillelamy commented Mar 4, 2020 • edited by pr-preview bot

yoavweiss left a comment

Choose a reason for hiding this comment

mikewest left a comment

Choose a reason for hiding this comment

mikewest left a comment

Choose a reason for hiding this comment

camillelamy left a comment

Choose a reason for hiding this comment

mikewest left a comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

camillelamy left a comment

Choose a reason for hiding this comment

arturjanc left a comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

camillelamy left a comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

camillelamy left a comment

Choose a reason for hiding this comment

annevk commented Apr 24, 2020

camillelamy commented May 4, 2020

annevk left a comment

Choose a reason for hiding this comment

camillelamy commented Jun 10, 2020

annevk commented Jun 12, 2020

camillelamy commented Jun 16, 2020

annevk commented Jun 16, 2020

camillelamy commented Jun 17, 2020

annevk commented Jun 18, 2020 • edited

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

camillelamy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Jun 24, 2020

domenic commented Jun 24, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

camillelamy commented Mar 4, 2020 •

edited by pr-preview bot

annevk commented Jun 18, 2020 •

edited