guidance on inheritance between contexts

[wanderview]

There are a number of places in the web platform where some policy or state is inherited from one context to another. Its up to each feature in the platform to define how it gets inherited or not. The result is that there are a number of inconsistent inheritance behaviors.

Some downsides of this inconsistent behavior are:

1. Confusing API surface for developers.
2. Special case logic is required in implementations resulting in brittleness and increased security risk. (Many of the policies have security implications.)
3. Increased cost to specifying a new feature because inheritance must be figured out again for each feature individually.

It might be nice to have some guidance on how inheritance should work on the web platform to produce a more consistent system.

Off the top of my head I can think of the following types of inheritance:

• origin: Local URLs like about:blank, about:srcdoc, and blob: inherit the origin from another context. The about: URLs inherit from their parent context while blob: URLs inherit from the context where createObjectURL() was called.
• service worker controller: The service worker group decided to inherit the controller from the parent context to any local URL of the same origin. So about:blank, about:srcdoc, and blob: URL contexts inherit the controlling worker from their parent. Note, this deviates from how the origin for the blob: URL is inherited. See Should an IFRAME without src be controlled by SW when its parent is controlled? w3c/ServiceWorker#612, should blob URLs inherit controller from parent environment or environment that called createObjectURL()? w3c/ServiceWorker#1261, should a frame navigated to about:blank inherit a service worker controller? w3c/ServiceWorker#1350.
• CSP: I believe the latest spec requires CSP to be inherited not just for local URLs, but also sometimes for contexts with a non-local URL. For example, it defines that dedicated workers should inherit CSP from their document, but does not apply this inheritance to iframes or other worker types. There has been a request from mozilla to possibly change the spec here. See Should Workers inherit CSP directives from the parent context? w3c/webappsec-csp#336.
• feature policy: The feature policy spec is also discussing possibly inheriting just for dedicated workers similar to CSP. See Add Feature Policy for workers w3c/webappsec-permissions-policy#174.
• referrer policy: I believe referrer policy is inherited from documents to a dedicated worker, but I'm less sure about this one.

There are probably more cases to consider.

My personal preference would be to make all inheritable attributes align to the same source. So if a local URL inherits an origin from a context, then all other attributes are inherited from that same source context. If a context has its own URL that defines its own origin, then nothing is inherited from other contexts.

Thanks for your help sorting this out!

[annevk]

(Note that I've found at least one case where we have to inherit into dedicated workers (though alternatively we could treat this header as setting a policy for the agent cluster, which seems somewhat attractive in a way and would sidestep this inheritance question): Upgrade-No-CORS.)

[nhiroki]

• COEP: The COEP spec requires a dedicated worker to inherit its parent's embedder policy (spec, COEP + non-HTTP Dedicated Workers whatwg/html#4916)

• referrer policy: I believe referrer policy is inherited from documents to a dedicated worker, but I'm less sure about this one.

In the current HTML spec, a dedicated worker doesn't inherit its parent's referrer policy (whatwg/html#3270)

[nhiroki]

2. Special case logic is required in implementations resulting in brittleness and increased security risk. (Many of the policies have security implications.)

+1. This inconsistency makes the Blink implementation and WPT complicated. cc: @hiroshige-g

[annevk]

@nhiroki did you see whatwg/html#4916?

[nhiroki]

@annevk Sorry for the late reply. Yes, I read the issue.

I heard there was a discussion about the policy inheritance at TPAC from @hiroshige-g. I'll update/close whatwg/html#3270 based on the final decision.

[hiroshige-g]

We (mainly @mikewest @annevk @wanderview @hiroshige-g) had a discussion around TPAC 2019, and reached a consensus:
NOT to inherit parent context's policy, except for <iframe srcdoc>,
<iframe src="about:blank">, data: dedicated workers etc., and use the same inheritance rule across policies (CSP, referrer policy, etc).
@annevk's whatwg/html#4926 is based on the discussion.

More detailed summary is here:
https://docs.google.com/document/d/1CAegq63QY0HMW-66zG4wgawIaWGi33MHtmU3azQQNz8/edit?usp=sharing

[hiroshige-g]

@annevk please let me know if I'm missing something or not summarizing correctly.

[annevk]

Thanks for writing that up @hiroshige-g, looks good to me!

[hober]

@kenchris and I took a look at this during the TAG F2F this week. We're really happy that the TPAC discussion was so fruitful. We'll hold off on adding something to the Design Principles document until whatwg/html#4926 is resolved. Thanks!

[hiroshige-g]

FYI some updates:
I'm doing some investigation to see how policies etc. are set in different contexts and how (in)consistent they are.
I've found some issues (e.g. whatwg/html#5474 whatwg/html#421) but they look relatively minor.

I also investigated the of feasibility of changing CSP inheritance rule. Originally I was wondering comparing CSPs of parent Documents and worker script's response headers and seeing whether they are the same, but when I looked at some major websites, they set different policies (due to nonce, due to minor diffs, or just setting completely different CSPs).

[kenchris]

@hiroshige-g Do you think some recommendations can be crafted from your investigation? In which case what would they be?

[kenchris]

Friendly ping @hiroshige-g !