-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Introduce "cross-origin-isolated" permission #5752
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
Changes from 4 commits
b303ac8
a4857c6
84435fa
6915c76
ad6f98d
3ef2ba4
3e68cd9
cb23065
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4197,6 +4197,10 @@ a.setAttribute('href', 'https://example.com/'); // change the content attribute | |
| <li>"<dfn data-x="autoplay-feature"><code data-x="">autoplay</code></dfn>", which has a <span | ||
| data-x="concept-default-allowlist">default allowlist</span> of <code | ||
| data-x="">'self'</code>.</li> | ||
| <li>"<dfn data-x="cross-origin-isolated-permission"><code | ||
| data-x="">cross-origin-isolated</code></dfn>", which has a <span | ||
| data-x="concept-default-allowlist">default allowlist</span> of <code | ||
| data-x="">'self'</code>.</li> | ||
| <li>"<dfn data-x="document-domain-feature"><code data-x="">document-domain</code></dfn>", which | ||
| has a <span data-x="concept-default-allowlist">default allowlist</span> of <code | ||
| data-x="">*</code>.</li> | ||
|
|
@@ -79107,7 +79111,15 @@ interface <dfn>BarProp</dfn> { | |
| <dt>The <span data-x="concept-settings-object-embedder-policy">embedder policy</span></dt> | ||
| <dd><p>Return <var>window</var>'s <span data-x="concept-document-window">associated | ||
| <code>Document</code></span>'s <span data-x="concept-document-embedder-policy">embedder | ||
| policy</span>.</p> | ||
| policy</span>.</p></dd> | ||
|
|
||
| <dt>The <span data-x="concept-settings-object-effective-cross-origin-isolated">effective | ||
| cross-origin isolated</span> boolean</dt> | ||
| <dd><p>Return the logical conjunction of <var>realm</var>'s corresponding <span>agent | ||
| cluster</span>'s <span>cross-origin isolated</span> and whether <var>window</var>'s <span | ||
| data-x="concept-document-window">associated <code>Document</code></span> is <span>allowed to | ||
| use</span> the "<code | ||
| data-x="cross-origin-isolated-permission">cross-origin-isolated</code>".</p></dd> | ||
|
yutakahirano marked this conversation as resolved.
Outdated
|
||
| </dl> | ||
| </li> | ||
|
|
||
|
|
@@ -87565,6 +87577,12 @@ interface <dfn>ApplicationCache</dfn> : <span>EventTarget</span> { | |
| check">cross-origin resource policy checks</span> for <span data-x="concept-fetch">fetches</span> | ||
| performed using this <span>environment settings object</span> as a <span | ||
| data-x="concept-request-client">request client</span>.</p></dd> | ||
|
|
||
| <dt>An <dfn data-x="concept-settings-object-effective-cross-origin-isolated" data-export="" | ||
| data-dfn-for="environment settings object">effective cross-origin isolated</dfn> boolean</dt> | ||
|
|
||
| <dd><p>A boolean representing whether it is allowed to use APIs that requires cross-origin | ||
|
yutakahirano marked this conversation as resolved.
Outdated
|
||
| isolation.</p></dd> | ||
| </dl> | ||
|
|
||
| <p>An <span>environment settings object</span> also has an <dfn>outstanding rejected promises | ||
|
|
@@ -92513,12 +92531,11 @@ interface mixin <dfn>WindowOrWorkerGlobalScope</dfn> { | |
| <dd><p>Returns the global object's <span>origin</span>, serialized as string.</p></dd> | ||
|
|
||
| <dt>self . <code subdfn data-x="dom-crossOriginIsolated">crossOriginIsolated</code></dt> | ||
| <dd><p>Returns whether the <span>surrounding agent</span>'s <span>agent cluster</span> is | ||
| <span>cross-origin isolated</span>. This depends on the `<code | ||
| data-x="">Cross-Origin-Opener-Policy</code>` and `<code | ||
| data-x="">Cross-Origin-Embedder-Policy</code>` HTTP response headers and determines whether | ||
| <code>SharedArrayBuffer</code> can be used with <code data-x="">postMessage()</code> | ||
| APIs.</p></dd> | ||
| <dd><p>Returns whether it is allowed to use APIs that require cross-origin isolattion. | ||
|
yutakahirano marked this conversation as resolved.
Outdated
|
||
| This depends on the `<code data-x="">Cross-Origin-Opener-Policy</code>` and `<code | ||
| data-x="">Cross-Origin-Embedder-Policy</code>` HTTP response headers and the | ||
| "<code data-x="cross-origin-isolated-permission">cross-origin-isolated</code>" | ||
| permission.</p></dd> | ||
|
yutakahirano marked this conversation as resolved.
Outdated
|
||
| </dl> | ||
|
|
||
| <div class="example"> | ||
|
|
@@ -92550,7 +92567,8 @@ document.body.appendChild(frame)</code></pre> | |
| origin">serialized</span>.</p> | ||
|
|
||
| <p>The <dfn data-x="dom-crossOriginIsolated"><code>crossOriginIsolated</code></dfn> getter steps | ||
| are to return the <span>surrounding agent</span>'s <span>agent cluster</span>'s <span>cross-origin | ||
| are to return <span>this</span>'s <span>relevant settings object</span>'s <span | ||
| data-x="concept-settings-object-effective-cross-origin-isolated">effective cross-origin | ||
| isolated</span>.</p> | ||
|
|
||
| </div> | ||
|
|
@@ -98975,6 +98993,11 @@ interface <dfn>WorkerGlobalScope</dfn> : <span>EventTarget</span> { | |
| data-dfn-for="WorkerGlobalScope" data-x="concept-WorkerGlobalScope-module-map">module map</dfn>. | ||
| It is a <span>module map</span>, initially empty.</p> | ||
|
|
||
| <p>A <code>WorkerGlobalScope</code> object has an associated <dfn data-export="" | ||
| data-dfn-for="WorkerGlobalScope" | ||
| data-x="concept-WorkerGlobalScope-effective-cross-origin-isolated">effective cross-origin | ||
| isolated</dfn> boolean. It is initially false.</p> | ||
|
|
||
| </div> | ||
|
|
||
| <dl class="domintro"> | ||
|
|
@@ -99370,6 +99393,17 @@ interface <dfn>SharedWorkerGlobalScope</dfn> : <span>WorkerGlobalScope</span> { | |
| <li><p>Let <var>destination</var> be "<code data-x="">sharedworker</code>" if <var>is | ||
| shared</var> is true, and "<code data-x="">worker</code>" otherwise.</p></li> | ||
|
|
||
| <li><p>Set <var>worker global scope</var>'s <span | ||
| data-x="concept-WorkerGlobalScope-effective-cross-origin-isolated">effective cross-origin | ||
| isolated</span> to <var>agent</var>'s <span>agent cluster</span>'s <span>cross-origin | ||
| isolated</span>.</p></li> | ||
|
yutakahirano marked this conversation as resolved.
Outdated
|
||
|
|
||
| <li><p>If <var>is shared</var> is false and <var>owner</var>'s <span | ||
| data-x="concept-settings-object-effective-cross-origin-isolated">effective cross-origin | ||
| isolated</span> is false, then set <var>worker global scope</var>'s <span | ||
| data-x="concept-WorkerGlobalScope-effective-cross-origin-isolated">effective cross-origin | ||
| isolated</span> to false.</p></li> | ||
|
|
||
| <li> | ||
| <p>Obtain <var>script</var> by switching on the value of <var>options</var>'s <code | ||
| data-x="">type</code> member:</p> | ||
|
|
@@ -99410,6 +99444,13 @@ interface <dfn>SharedWorkerGlobalScope</dfn> : <span>WorkerGlobalScope</span> { | |
| <span data-x="parse-referrer-policy-header">parsing the `<code>Referrer-Policy</code>` | ||
| header</span> of <var>response</var>.</p></li> | ||
|
|
||
| <li><p>If <var>is shared</var> is false and <var>response</var>'s | ||
| <span data-x="concept-response-url">url</span>'s <span | ||
| data-x="concept-url-scheme">scheme</span> is "<code data-x="">data</code>", then set | ||
| <var>worker global scope</var>'s <span | ||
| data-x="concept-WorkerGlobalScope-effective-cross-origin-isolated">effective cross-origin | ||
| isolated</span> to false. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the reasoning for this? data: URL workers have their own separate agent clusters, so I would think they should be allowed to use cross-origin isolated features...
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is because "data:" origins are opaque. We need these worker-specific logic because permission policy doesn't work with workers (w3c/webappsec-permissions-policy#207).
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, they're opaque, so they should be treated as cross-origin isolated, right? So this should be set to true, if anything...
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm talking about hte "cross-origin-isolated" feature. The worker is cross origin compared to its owner, and it is not able to set permission policies for data: workers so the default policy ("self") is applied, which means effective cross-origin isolated is false.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, according to https://html.spec.whatwg.org/multipage/webappapis.html#obtaining-a-worker/worklet-agent and https://html.spec.whatwg.org/multipage/webappapis.html#obtain-a-dedicated/shared-worker-agent a dedicated worker's agent cluster is its owner's.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I was confused with
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, upon re-reviewing I am still confused why we want to prevent data: URL workers from using cross-origin isolated features. I know they have a different origin. However, for other important things, we inherit from the parent, even though they are cross-origin. For example, for embedder policy.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, we can choose either way. Ultimately that will be resolved in w3c/webappsec-permissions-policy#207 but to be honest I don't want to be blocked by the issue. I'm fine with either options, but starting with effective cross-origin isolated: false and changing the value to true if necessary (when w3c/webappsec-permissions-policy#207 is resolved) seems safer than the other option from the compatibility perspective. Please note that for COEP we didn't have options. As the owner and the worker share the same agent cluster we needed to inherit the value when the owner had COEP: require-corp. @annevk do you have opinions?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Got it. I understand now, and agree this is a good conservative default. I will push a commit adding a note about that reasoning. |
||
|
|
||
| <li><p>If <var>response</var>'s <span data-x="concept-response-url">url</span>'s <span | ||
| data-x="concept-url-scheme">scheme</span> is a <span>local scheme</span>, then set | ||
| <var>worker global scope</var>'s <span | ||
|
|
@@ -99735,6 +99776,12 @@ interface <dfn>SharedWorkerGlobalScope</dfn> : <span>WorkerGlobalScope</span> { | |
| <p>Return <var>worker global scope</var>'s <span | ||
| data-x="concept-WorkerGlobalScope-embedder-policy">embedder policy</span>.</p> | ||
| </dd> | ||
|
|
||
| <dt>The <span data-x="concept-settings-object-effective-cross-origin-isolated">effective | ||
| cross-origin isolated</span> boolean</dt> | ||
| <dd><p>Return <var>worker global scope</var>'s <span | ||
| data-x="concept-WorkerGlobalScope-effective-cross-origin-isolated">effective cross-origin | ||
| isolated</span>.</p></dd> | ||
| </dl> | ||
| </li> | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.