-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Introduce COEP #5454
Introduce COEP #5454
Conversation
@domenic should weigh in I suspect, but in general we want commits to be able to stand on their own. Perhaps things can be split where infrastructure and requirements land after each other, but the moment a following commit is needed for a prior commit to make sense there's a problem of sorts. |
Also note that every time you push a commit (or collection of commits) it sends an email to the 391 watchers of the repo. Not a big deal, but perhaps consider working on things locally until they're ready, instead of continually pushing "fix" commits. |
This PR was a "draft PR" until I uploaded the last commit. Is notification sent for draft PRs? |
Yep! All that does is prevent merging. |
Oh I didn't know that. Sorry, and thank you. |
What is our current status here? @yutakahirano, would you like review on what you've done so far, or were you planning on adding the rest into this PR? I tend to agree with @annevk that we should only merge when everything is present, but we could do some early review. |
As you prefer a big one change I'll do that. I have some time this and next weeks so hopefully I will be able to upload something ready for review. |
44cf23b
to
48d6105
Compare
I think this is now ready for review. Some checks were not successful but the error message was "/bin/sh: 1: /whatwg/wattsi/build.sh: not found" so think it is an infra issue. I simplified and inlined Initializing a global object’s Embedder policy. I put helper algorithms (e.g., "queue a Cross-Origin Embedder Policy violation on worker initialization") closer to their callers. If you think it's better to group them into one place, I'll do that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Mostly typographical issues. I'm happy for you to do one pass and then I or another editor can do any final touchups.
I believe I've addressed the comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I pushed some editorial tweaks and also added the full header definition. This LGTM.
However, it seems like we should hold off merging until some of the following are done:
- Define "Request URL serialization for reporting" fetch#1028
- https://wicg.github.io/cross-origin-embedder-policy/#integration-fetch is merged into Fetch (or maybe we merge both PRs at the same time?)
- https://wicg.github.io/cross-origin-embedder-policy/#integration-sw has a PR out for service worker
- A PR is out for service worker adding the new environment settings object field (embedder policy)
- A PR is out for worklets adding the new environment settings object field (embedder policy)
Does that seem right?
This is part of whatwg/html#5454.
Thank you!
Is it possible to have a reference from fetch to the HTML without this change (e.g., |
This is part of the introduction of COEP (whatwg/html#5454). The CORP check now takes COEP into account. Also, responses coming from service workers are checked.
It is not; we'd need to merge HTML first then give things ~24 hours to propagate to the cross-linking databases. So I guess we should merge the HTML PR first. Does the Fetch PR build entirely on top of the HTML PR, or would it be better to land them both as close together as possible? What is the complete list of terms you'll want to reference from Fetch? You need to manually mark them up using
I am a bit worried about not introducing the secure context restriction in the initial PR. But maybe it is fine. @annevk any thoughts? |
This is part of the introduction of COEP (whatwg/html#5454). The CORP check now takes COEP into account. Also, responses coming from service workers are checked.
Updated. Here is the change log from the last round:
PTAL again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused now as I see this now includes reporting for navigation as well.
source
Outdated
<dt>"<dfn data-x="coep-unsafe-none" data-export="" data-dfn-for="embedder policy value"><code | ||
data-x="">unsafe-none</code>"</dfn></dt> | ||
<dd><p>This is the default value. When this value is used, cross-origin resources can be fetched | ||
without giving explicit permission through the <span>CORS protocol</span> or the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CORS protocol is not at all involved, right? It seems this is old text that didn't account for the switch to CORP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I want to say here is, with cross-origin-embedder-policy: require-corp, all cross-origin requests should be verified by CORS or CORP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But that's not what it's saying, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence is about "unsafe-none", so cross-origin resources that are not verified by CORS or CORP can be fetched... Does this answer your question?
Defined the "coep" report type, to address #5634. cc: @jugglinmike
Anne, I don't understand this comment. Could you rephrase it? |
From a clarity perspective, I'd like OP to be updated and indicate which of
topic: cross-origin-embedder-policy
My question with respect reporting is that Fetch also includes COEP reporting for navigation, so I'm wondering why there's an algorithm here as well and how they differ. |
Updated the PR description.
There are two checks in the navigation process. One is the CORP check for the navigation and that will be covered by the fetch spec (the call site will exist in the HTML spec). The other is checking the parent COEP and the child COEP. They are checking different things each other, and violation reports are made independently. |
Anne, have your comments and questions been addressed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a final pass and pushed some very minor nit fixes. This looks good to me, although I guess we should try to land this around the same time as whatwg/fetch#1030 because of the modified CORP check.
Thank you! Do you think it's good to start adding links whatwg/fetch#1030 before landing this? I'm asking because my ability to find and fix problems hugely rely on the build and preview tools. |
Probably it's best to wait until the review is done there, so that you can add the links in a single commit and not have to go back and change anything else. |
# This is the 1st commit message: # This is a combination of 23 commits. # This is the 1st commit message: Integrate CORP and COEP This is part of the introduction of COEP (whatwg/html#5454). The CORP check now takes COEP into account. Also, responses coming from service workers are checked. # This is the commit message #2: Update fetch.bs Co-authored-by: Domenic Denicola <d@domenic.me> # This is the commit message #3: Update fetch.bs Co-authored-by: Domenic Denicola <d@domenic.me> # This is the commit message #4: fix # This is the commit message #5: fix # This is the commit message #6: fix # This is the commit message #7: fix # This is the commit message #8: fix # This is the commit message #9: fix # This is the commit message #10: fix # This is the commit message #11: fix # This is the commit message #12: fix # This is the commit message #13: fix # This is the commit message #14: fix # This is the commit message #15: fix # This is the commit message #16: fix # This is the commit message #17: fix # This is the commit message #18: Update fetch.bs Co-authored-by: Anne van Kesteren <annevk@annevk.nl> # This is the commit message #19: Update fetch.bs Co-authored-by: Anne van Kesteren <annevk@annevk.nl> # This is the commit message #20: fix # This is the commit message #21: fix # This is the commit message #22: fix # This is the commit message #23: fix # This is the commit message #2: fix
ff85f47
to
f833ad9
Compare
This merges much of https://wicg.github.io/cross-origin-embedder-policy/ into the HTML Standard.
f833ad9
to
770ea12
Compare
I rebased this on master (where COOP was merged), and fixed several merge conflicts (both literal, and more indirect ones, e.g. the COOP PR referenced https://wicg.github.io/cross-origin-embedder-policy/ and I updated those sections to point to the appropriate definitions here instead). I squashed all that work into a single commit to make rebasing easier. I also pushed an additional commit that splits the new section into a couple subsections, to be symmetrical with the COOP section. So this looks good to go from my end. I'd like @annevk to coordinate merging this and reviewing/merging whatwg/fetch#1030. (As mentioned above, the plan is to merge this first and then update the Fetch PR with cross-links and merge it once the linking databases populate. But we probably shouldn't merge this until the Fetch PR is approved-modulo-crosslinks.) Note that @yutakahirano's OP has a great amount of detail which will make it easy to write a useful commit message when we merge this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @yutakahirano for all your work on this! Let's land it.
Tentative commit message:
|
Thank you! |
This adds support for cross-origin embedding policy, which primarily is a way of enforcing the Cross-Origin-Resource-Policy header to be set on responses. See also this HTML change which links tests and the various issues and standards efforts involved here: whatwg/html#5454. The earlier added "serialize a request URL for reporting" has been replaced with "serialize a response URL for reporting" as centering things around responses was found more logical.
* Introduce Cross-Origin Embedder Policy This is part of whatwg/html#5454. - Define embedder policy in environment settings object for service workers. - Add the CORP check in #dom-cache-matchall. * fix * fix * fix * fix * fix * fix
Merging https://github.com/WICG/cross-origin-embedder-policy to the HTML spec.
WorkerGlobalScope's embedder policy, and environment settings
object's embedder policy.
cross-origin-embedder-policy
HTTP header.for service workers).
a service worker.
algorithm.
This fixes #5368, #5634, whatwg/fetch#985, and w3c/ServiceWorker#1490.
This doesn't fix the following issues:
(See WHATWG Working Mode: Changes for more details.)
/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 )
/window-object.html ( diff )
/workers.html ( diff )