Explain relation to CSP, document policy, and sandboxing

[domenic]

Original PR text:

This proposal is a result of me going through the CSP specs and seeing what made sense. Much if it hasn't been discussed before, so review on this PR should also include high-level critiques of the proposal. I just thought it'd be simpler to discuss a concrete PR instead of an issue.

Update:

I've morphed this PR to cover CSP, document policy, and sandboxing all together, as there are cross-cutting concerns.

[domenic]

One choice I made was to not have prefetch-src affect portals, since it seemed like using the separate portal-src category would give better control. Expanding prefetch-src from just <link>s to <portal>s seemed like a net negative. But, I'm open to other opinions.

[domenic]

Also worth discussing is whether frame-src should affect portals. I propose that it does not; the split of child-src into frame-src, object-src, and worker-src makes me think that more granular categories are preferred, and so portal-src should be a sibling of frame-src/object-src/worker-src instead of a child of frame-src.

[jeremyroman]

@lucasgadani was involved when we discussed this previously. I remember being of the view that we should probably respect existing frame-src for consistency e.g. with frame-ancestors (and I think we do), but I admit that in this case since we're talking about the content that's choosing to use <portal> it may make sense to split the directive. Certainly the way you propose is the best in the abstract, it's just a matter of whether this has adverse consequences for existing content.

[jakearchibald]

navigate-to which will need a new directive algorithm, since it would need to analyse the portal URL rather than a response object.

[domenic]

Tagging in @a4sriniv for his specific review

[domenic]

I'm going to file a tracking issue on the fact that the CSP design doesn't feel completely settled, link to it, and then merge this.