Should Dedicated Workers inherit owner's ReferrerPolicy like CSP?

[nhiroki]

Dedicated Workers inherit the owner's CSP[1], but not ReferrerPolicy[2]. Should we make them aligned?

[1] https://w3c.github.io/webappsec-csp/#initialize-global-object-csp
[2] https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model

11.5. Set worker global scope's referrer policy to the result of parsing the `Referrer-Policy` header of response.

@mikewest @domenic

[nhiroki]

Note that Worklets inherit both CSP and ReferrerPolicy from the owner[1,3].

[3] https://drafts.css-houdini.org/worklets/#script-settings-for-worklets

5. Let inheritedReferrerPolicy be outsideSettings’s referrer policy.

[annevk]

Hmm, I believe for style sheets they do not inherit, but maybe those are special enough. It seems somewhat reasonable to align these, though I think @wanderview wasn't too happy about CSP inheriting.

cc @jeisinger

[mikewest]

I'm not excited about changing the CSP behavior again. We've already changed it twice; unless there's a very good reason to impose another shift on developers, I'd prefer to leave it the way it is.

Given that, it makes sense to me to align referrer policy with CSP rather than the other way around. It seems reasonable to me to treat these workers in the same way we're treating scripts: as extensions of the current page, rather than completely distinct execution environments.

[wanderview]

I'm not excited about changing the CSP behavior again. We've already changed it twice; unless there's a very good reason to impose another shift on developers, I'd prefer to leave it the way it is.

I'm quite unhappy with that CSP change to inherit state to dedicated workers.

I looked back at the issue where it was introduced and it was basically "hey, dedicated workers are just like <script> so lets do it" AFAICT. This is flawed IMO because there is a pretty big difference between workers and <script>. Workers create a global based on a top level resource load. <script> elements do not.

IMO dedicated workers are more like iframes and we should not be trying to conflate their state with their parent (if it exists). We should only inherit if the worker script is a local URL scheme, like blob.

In addition, this inheritance thing creates more special cases between the different kinds of workers. If CSP was simply set based on their top level script load then it would work the same for dedicated, shared, service, etc. The implementation would be simpler and less likely to have weird bugs.

Maybe I'm too late for the CSP debate, but I'd prefer not to double-down on it for referrer policy. And FWIW I'm pushing back on implementing the CSP inheritance in gecko, but its not really up to me.

[annevk]

The conclusion we reached at TPAC (thanks for organizing @hiroshige-g!) was that there is no inheritance for workers other than for blob and data URLs (which need to inherit policies somehow as otherwise they can be used to escape them).

The winning argument was that HTTP documents do not inherit policies either and that it's as likely that you forget to set policies on a worker script as an image (if you navigate a frame to such an HTTP image without policies set you'd have an escape).

See also #4926 for ideas on how to formalize this better and the research that is needed to get there.

[nhiroki]

@annevk Thank you for the summary. I'm happy with the conclusion. Let me close this issue.