Define a policy container

[annevk]

There are numerous open issues about "inheritance" of policies such as CSP, referrer policy, origin, cookie URL (not defined), base URL, service worker registration, etc. into a dedicated/shared worker or nested document whose URL is about:blank, about:srcdoc, a blob URL, or a data URL.

The idea behind this issue is to research these policies, see if we can make them consistent, and add infrastructure in place that makes existing policies more rigorous and introducing new policies drastically simpler.

The imagined infrastructure takes the form of a "policy container" that supports a "clone" operation. Each policy would also have to define a "clone" operation (unless the policy can be expressed in an Infra map or list perhaps). We'd then define exactly when the policy container is cloned and how to instantiate a new document with a policy container containing a number of policies.

TODO:

• Link existing issues.

(See w3c/FileAPI#142 for dealing with blob URLs. A policy container would it easy to formalize that idea.)

cc @mikewest @hiroshige-g @wanderview

[shhnjk]

I like this idea. From my experience, logic of inheriting policies to local scheme + "javascript" would be:

1. If URL is "about:srcdoc" and parent window exists:
   Inherit policy from parent window
2. If scheme is "about" or "javascript":
   Inherit policy from Navigation Initiator
3. If scheme is "data" and inherit_for_data_ is true:
   Inherit policy from Navigation Initiator
4. If scheme is "blob" (or "filesystem"):
   Inherit policy from Creater

This logic align with how SOP works in the browser (except Data URL, which is optional to inherit a policy). However, I don't know how to write this logic in a spec words...

Another problem is around CSP sandbox where some people seems to have issues deciding logic for it, but this is still unclear since we haven't decided if we want to consider CSP sandbox a same-site or cross-site. If that's decided, then there will be no issues.

[koto]

That would be helpful also for Trusted Types, especially with the clone operation, as the TT guards also have a state that JS APIs can affect - a list of policy names that were already created. If we could bootstrap about:blank (and Blob) documents with the used policy names already marked as such, we could address this bypass vector - at least for applications that limit policies by names.

[domenic]

I've opened #6186 for the specific case of origin isolation, and would love guidance from the folks involved in these threads.

[antosart]

We would like to push this forward. We created an explainer with more details on how the policy container could look like: https://github.com/antosart/policy-container-explained.

We also started a prototype implementation of the idea in chrome, which looks promising at the moment.

[annevk]

That looks great @antosart, thanks so much for working on this! One nit: when talking about blobs you want to talk specifically about creating blob URLs, as creating blobs (as in, new Blob()) is not impacted. There is some other state I noted in OP that could also benefit from this, such as "cookie URL", but it seems very reasonable to scope down and then build it out after integration. Again, very exciting!

[mikewest]

I'm also excited to see this work progressing!

Would it be reasonable to follow the COEP model of creating a label in this repo for conversation/questions? I suspect that @antosart, et al. will end up with a monkey-patch spec to wrap up suggested changes, but keeping discussion on the HTML repo seems better for visibility.

[annevk]

Yes! I added Pâris Meuleman, Antonio Sartori, and Mike West to the WHATWG triage team, meaning you get to set labels and such. I'll also add "topic: policy container" as a label for whatwg/html.

[shhnjk]

Thank you @antosart for looking into this.

I just have a recommendation, which is to almost always use the navigation initiator to inherit the policy to local scheme instead of relying on parent or opener (there have been bugs due to this). There is an exception to this, which is about:srcdoc, which should always inherit policy from the parent.

[antosart]

Thanks!

@annevk thanks for the clarification, I made sure we always talk about blob URL in the explainer now.

@shhnjk yes, that was the intention. I guess "Parent document embeds empty or srcdoc frame" might have been misleading, so I replaced "embeds" with "creates". But the idea would be that this holds only for the initial creation: upon navigation to a local scheme, we would use the initiator's policies. For about:srcdoc, my understanding is that you cannot navigate something to about:srcdoc (the only thing you can do is modify the frame.srcdoc attribute), so that would always come from the parent. But I'd be interested if you could share more background on the bugs you are writing about.

[shhnjk]

In Chrome, cross-origin iframe can navigate to about:srcdoc and that would still trigger a script defined in a srcdoc attribute. Previously, Chrome used to inherit CSP from a navigation initiator, and this caused a CSP bypass.

[antosart]

Indeed, thanks for pointing that out! That's an important observation. I added a sentence to the explainer clarifying that.

[domenic]

I found this somewhat-related issue in #856 that people should be aware of, although I don't think the overlap is 100%.

[domenic]

Some more existing issues: #2592 #2593

[antosart]

I stumbled upon #4510 and I realised the explainer does not define any inheritance for document.open(). Initially, I thought that since document.open() (and document.write()) don't replace the document, but only its content, the policies would just stay as they are.

However, as pointed out in #4510, the ownership of the document's content after document.open() is somehow of the entry global object. In fact, one of the steps of document.open() changes the document url with the entryDocument's url. So I am wondering if also the policies should be inherited from the entryDocument.

[annevk]

I think I prefer keeping policies as-is and not try to do something special for document.open(). While the URL changes the origin of the document does not. There was a time (and a browser) where document.open() was a lot more invasive but now it's only changing document state and none of that warrants policy inheritance in my book.

[antosart]

@annevk that sounds right to me.

Another case I see we did not address in the explainer is navigations to javascript: (the ones which return a string and hence replace the document). I believe the right thing to do for them is keep the policies of the previous document. If I understand correctly from https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents:javascript-protocol, this is what we do for the origin, for example.

[annevk]

I think I agree with that as well, though whatwg/html has many open issues on javascript: so it's hard to be completely sure.

[annevk]

@antosart should we close this and use a new issue to keep track of the remaining work or keep using this until we have covered most things?

Issues I filed today around integration:

• Integrate with policy container w3c/permissions#240
• Align with policy container WICG/document-policy#34

[antosart]

@annevk I would say we can close this and follow up separately on the other policies.

[annevk]

Reading this issue again I'm having cold feet as there are many other issues referenced that also need some kind of action to be taken. So until someone has time to properly triage them all and decide on a plan I guess I rather keep this open.