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.

Sign up for GitHub

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

Jump to bottom

COEP + non-HTTP Dedicated Workers #4916

Closed
perryjiang opened this issue Sep 17, 2019 · 10 comments
Closed

COEP + non-HTTP Dedicated Workers #4916

perryjiang opened this issue Sep 17, 2019 · 10 comments
Assignees
@mikewest
Labels
topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal.

Comments

@perryjiang
Copy link

https://mikewest.github.io/corpp/ should specify what COEP to set for non-HTTP Dedicated Workers (e.g. data, blob, file, etc.). I think inheriting the owner's COEP makes sense.

@annevk @mikewest
@annevk annevk added the topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal. label Sep 18, 2019
@annevk

This comment has been minimized.

Sign in to view
@nhiroki nhiroki mentioned this issue Sep 18, 2019
Open
@annevk
Copy link
Member

annevk commented Sep 23, 2019

Yes, for non-HTTP workers we'll need to inherit. Apologies for the misguided earlier comment.

@wanderview
Copy link
Member

Does file:// normally inherit? I thought inheritence was usually just for local urls.

@mikewest
Copy link
Member

file: URLs, at least in Chromium, are not going to support COEP, as they don't have headers (and also they're not loadable (or shouldn't be!) from the web unless you flip command-line flags that warn you against doing terrible things).

I think @perryjiang might have been referring to filesystem: URLs, which are basically the same as blob: for these purposes.

@annevk
Copy link
Member

annevk commented Jan 8, 2020

This applies to workers, shared workers, and frames. Given that we're building on secure contexts about:blank, about:srcdoc, and blob: are the relevant cases that (in certain contexts) ought to work. data: should not work (as it's not a secure context).

Does that make sense?

@annevk annevk mentioned this issue Jan 8, 2020
Open
@annevk
Copy link
Member

annevk commented Jan 13, 2020

I notice that we currently have a test for data: at html/cross-origin-embedder-policy/data.https.html that Firefox passes whereby it inherits cross-origin embedder policy and enforces it, despite not being a secure context. The alternative is a network error for data: URLs, which I'm not sure is what we want?

cc @whatwg/cross-origin-isolation

This was referenced Jan 13, 2020
Merged
Closed
@annevk
Copy link
Member

annevk commented Jan 13, 2020

@whatwg/cross-origin-isolation please see w3c/webappsec-secure-contexts#69 for some further thoughts on data: URLs.

@annevk
Copy link
Member

annevk commented Jan 17, 2020

I created web-platform-tests/wpt#21230 for javascript: URLs and web-platform-tests/wpt#21232 as an investigation as to how javascript: URLs should work (that's for Referrer Policy, but COEP ought to be identical to that imo; unfortunately it wasn't sorted out for Referrer Policy).

@annevk annevk mentioned this issue Mar 26, 2020
Closed
@yutakahirano yutakahirano mentioned this issue Jun 15, 2020
Merged
3 tasks
domenic pushed a commit that referenced this issue Jun 25, 2020
@yutakahirano
Add cross-origin embedder policy
70b8bb4 
Merges https://github.com/WICG/cross-origin-embedder-policy into HTML.

Associated PRs:

* whatwg/fetch#1030
* w3c/ServiceWorker#1516
* w3c/css-houdini-drafts#992

Fixes #5368, fixes #5634, fixes
whatwg/fetch#985, and fixes
w3c/ServiceWorker#1490.

Follow-up: #4916, #4919, #4930 #5223, and #5391. (As well as defining
cross-origin isolated, per #4732.)
@domenic
Copy link
Member

domenic commented Aug 20, 2020

What is the latest on this? Perhaps someone could summarize what's left to do, and if there are any open questions? @yutakahirano

@yutakahirano
Copy link
Member

Currently we inherit parent's policy but we may change that for blobs, depending on the future resolution of #5198.

mfreed7 pushed a commit to mfreed7/html that referenced this issue Sep 11, 2020
@yutakahirano @mfreed7
Add cross-origin embedder policy
add7b6e 
Merges https://github.com/WICG/cross-origin-embedder-policy into HTML.

Associated PRs:

* whatwg/fetch#1030
* w3c/ServiceWorker#1516
* w3c/css-houdini-drafts#992

Fixes whatwg#5368, fixes whatwg#5634, fixes
whatwg/fetch#985, and fixes
w3c/ServiceWorker#1490.

Follow-up: whatwg#4916, whatwg#4919, whatwg#4930 whatwg#5223, and whatwg#5391. (As well as defining
cross-origin isolated, per whatwg#4732.)
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
@antosart @mfreed7
Add embedder policy to the policy container
bf31509 
Part of whatwg#4926. Closes whatwg#4916.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mikewest mikewest

Labels
topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal.
Milestone
No milestone
Development

No branches or pull requests
6 participants
@mikewest @domenic @wanderview @annevk @yutakahirano @perryjiang