You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>Shared Workers are similar to dedicated Workers, but need to check through
363
-
each of the documents which share them:</p>
364
-
<pclass="issue" id="issue-c5802c14"><aclass="self-link" href="#issue-c5802c14"></a> The current handling of Shared Workers means that
365
-
the worker’s state will oscillate between secure and insecure based on the
366
-
documents that attach to it. That will likely confuse developers. Several
367
-
options for improvements have been suggested in the associated bug. <ahref="https://github.com/w3c/webappsec/issues/406"><https://github.com/w3c/webappsec/issues/406></a></p>
367
+
<p>Shared Workers can have multiple contexts attached, so their behavior is a
368
+
bit special. In short, if a Shared Worker is created from a secure context,
369
+
it is a secure context, and may only be connected to by other secure
370
+
contexts. If a Shared Worker is created from an insecure context, it is an
371
+
insecure context, and may only be connected to by other insecure contexts.</p>
368
372
<divclass="example" id="example-7e3c52b5">
369
373
<aclass="self-link" href="#example-7e3c52b5"></a>
370
374
<p>If <code>https://example.com/</code> in a <adata-link-type="dfn" href="http://www.w3.org/TR/html5/browsers.html#top-level-browsing-context">top-level browsing
<p>If <code>https://example.com/</code> in a different <adata-link-type="dfn" href="http://www.w3.org/TR/html5/browsers.html#top-level-browsing-context">top-level
391
-
browsing context</a> (e.g. in a new window) access the same shared worker,
392
-
it is still a secure context, as every document accessing it is secure.</p>
395
+
browsing context</a> (e.g. in a new window) is a secure context, so it may
<p>If <code>https://example.com/</code> nested in <code>http://insecure.example.com/</code> runs <code>https://example.com/worker.js</code> as a Shared
418
+
<divclass="example" id="example-6a0d6906">
419
+
<aclass="self-link" href="#example-6a0d6906"></a>
420
+
<p><code>https://example.com/</code> nested in <code>http://insecure.example.com/</code> may not connect to the secure
<p>Likewise, if <code>https://example.com/</code> nested in <code>http://insecure.example.com/</code> runs <code>https://example.com/worker.js</code> as a Shared
417
451
Worker, then both the document and the worker are considered insecure.</p>
<divclass="issue"> The current handling of Shared Workers means that
989
-
the worker’s state will oscillate between secure and insecure based on the
990
-
documents that attach to it. That will likely confuse developers. Several
991
-
options for improvements have been suggested in the associated bug. <ahref="https://github.com/w3c/webappsec/issues/406"><https://github.com/w3c/webappsec/issues/406></a><ahref="#issue-c5802c14"> ↵ </a></div>
992
1023
<divclass="issue"> WHATWG’s HTML for <adata-link-type="dfn" href="https://html.spec.whatwg.org/multipage/webappapis.html#creation-url">creation URL</a>, as W3C’s doesn’t
993
1024
define the primitive we need.<ahref="#issue-091ab16c"> ↵ </a></div>
994
1025
<divclass="issue"><adata-link-type="dfn" href="https://fetch.spec.whatwg.org/#concept-response-https-state">HTTPS state</a> is poorly defined. For example, we should ensure
0 commit comments