secure contexts and Workers created from data URLs

[yutakahirano]

https://w3c.github.io/webappsec-secure-contexts/#is-settings-object-contextually-secure states:

• If global is a WorkerGlobalScope, then:
  • For each Document (document) in global’s owner set:
    • Assert: Workers must be same-origin with the context that created them, so document’s relevant settings object's origin and HTTPS state is the same as global’s relevant settings object's origin and HTTPS state.
    • If document’s relevant settings object is not contextually secure, return "Not Secure".
  • Return "Secure".
• ...

The assertion is confusing or wrong, because a worker can be created from a data URL, and in that case the worker is not same origin with its parent context.

[yutakahirano]

cc: @annevk @nhiroki

My understanding is that a worker should inherit its owner set documents' HTTPS state, and the assertion should be fixed accordingly. Please let me know if you think otherwise.

Related to https://github.com/web-platform-tests/wpt/pull/22929.

[annevk]

Thanks for spotting that, agreed! See also https://github.com/whatwg/html/issues/5254 for some additional complexity due to data URL workers. (To be clear, we took on that complexity as we also wanted sandboxed workers in due course, which would have a similar model.)

[nhiroki]

+1.

For reference, the HTML spec defines that a data URL worker has an opaque origin:

The origin: Return a unique opaque origin if worker global scope's url's scheme is "data", and inherited origin otherwise.

And, the Fetch spec defines a response for a data URL has fetch client's HTTPS state, that is, the document's HTTPS state:

"data":

3. Return a response whose status message is OK, header list consist of a single header whose name is Content-Type and value is dataURLStruct’s MIME type, serialized, body is dataURLStruct’s body, and HTTPS state is request’s client’s HTTPS state if request’s client is non-null.

[annevk]

https://github.com/whatwg/html/pull/5659 resolved this, but since this specification doesn't appear to be maintained, leaving this open for now for visibility.

[annevk]

Solved by #84.