Should an opaque origin be able to create a Worker?

[mkruisselbrink]

With classic script workers it wasn't possible for a document in a unique origin (such as a sandboxed iframe) to create a Worker, as it's impossible for the origin of the script URL to be the same as the (unique) origin of the document. With module workers there currently is no such same-origin requirement though, so as spec-ed it should be possible for a unique origin to create a worker (assuming the worker is served with a Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: null header). Is this intentional? Or should some of the same origin checks that got removed from the Worker constructor be put back?
@annevk @domenic

[annevk]

I would not mind requiring a tuple origin.

[annevk]

If we required that for "outside settings" I guess we'd throw inside the constructor? Are you happy to implement that in Blink? @smaug----?

[smaug----]

FWIW, I think any difference in classic Worker vs module Worker loading and security checks feels odd and error prone. But I admit I'm not familiar enough with module workers and why they need to behave so differently. (why does the fetch mechanics depend on the worker type classic vs module, and not some option passed to worker ctor?)

[mkruisselbrink]

I don't quite know the rationale behind allowing module workers to be loaded with CORS while classic workers require same origin scripts. But given that, the question is how much more should module workers and classic workers differ. The same-origin requirements for classic workers I believe prevent a unique origin from creating a classic worker (maybe data: urls would work, except at least the spec doesn't currently treat those as same origin for workers I believe). Since it seemed odd to me to have classic and module workers be too different it seemed like maybe it would make sense to explicitly disallow workers in unique origins (as that was effectively already the case with classic only workers).

(why does the fetch mechanics depend on the worker type classic vs module, and not some option passed to worker ctor?)

Not sure what your asking? The worker type is an option passed to the worker ctor. Are you suggesting that same-origin vs cors and classic vs module should be independent options passed to the ctor?

[smaug----]

The worker type is an option passed to the worker ctor. Are you suggesting that same-origin vs cors and classic vs module should be independent options passed to the ctor?

yes that. The current setup is really odd. Why is fetch depending on the classic vs module.

[domenic]

As I said in #608,

These commits also make it very easy to add CORS support to non-module workers, if people are interested in that while they are mucking around with this area of their implementation. If so let me know and I can tack on another commit doing so.

But the only response I got was from @annevk who said

I was thinking that if we do not change classic workers we might entice folks to upgrade to module workers sooner since they can be hosted on a CDN.

I'm still willing to make that change if there's implementer interest.

[annevk]

This isn't really error prone in a security-sensitive way since same-origin and CORS are identical from that perspective. We could indeed upgrade classic workers to CORS without much trouble (single word change I think).

Anyway, I think that's a separate issue. This issue is about whether or not workers work from an opaque origin.

[smaug----]

Assuming the worker has its origin being set to an opaque origin and loading the script is allowed by CORS, why not?

Workers created using object urls work already even in sandboxed iframes, at least in implementations,
not sure what the spec says.

[annevk]

Hmm, I think blob URLs would fail since they carry the origin in the URL. I have no problem with this working either though.

[mkruisselbrink]

Workers created using object urls work already even in sandboxed iframes, at least in implementations,
not sure what the spec says.

That's interesting, and not something I would have expected... I'm not sure how a blob/object URL could ever be same origin with the sandboxed iframe. Although I supposed from a spec point of view the origin of an object URL created from an opaque origin is implementation defined, so could be pretty much anything; but I'm still not sure how that origin could ever be parsed back into something that is same origin with a different opaque origin.

[smaug----]

Just to ensure we're talking about same stuff, my test for object url is http://mozilla.pettay.fi/moztests/sandbox/sandbox_worker.html

[mkruisselbrink]

Interesting. From reading the spec I wouldn't expect that to work, but it appears at least chrome has special code to get the origin from a blob URL which uses out-of-band data to determine the origin. And I guess if this works in firefox you must be doing something similar.

So even though the URL spec says to "parse the first string in URL’s path." (and get the origin from the resulting string) to get the origin of a blob URL, what chrome actually does is to look up the url in the Blob URL Store and then return the origin of the incumbant settings object at the time createObjectURL was called.

[mkruisselbrink]

https://bugs.webkit.org/show_bug.cgi?id=78648 seems to have the discussion for implementing this different origin-for-blob-url behavior in webkit/blink. Possibly this should just be updated in the URL and/or File API specs.

And since then apparently workers in opaque origins has been working for a long time already (no idea how much they are used though), it makes less sense to add new restrictions here. I didn't realize implementation didn't match spec in this regard.