Overlap with CSP

[annevk]

Navigation seems like a reasonable point of differentiation, but I think for everything else we'd want both policies to be consulted as to whether to move forward with the connection/request (which then requires addressing an ordering question).

[mikewest]

I agree. As vaguely proposed, this mechanism and CSP would both be consulted prior to issuing a request whenever there's an overlap (e.g. for all fetches). We'd need to define an ordering, for example by picking a spot in which to extend step 7 of Main Fetch (which should probably say something about the ordering of those checks being meaningful now that I read it again?).

[annevk]

Yeah, we should probably make it a set of steps for clarity. And maybe we should rename the algorithms that are side-effecting in some way (e.g., do reporting) to make that more apparent.

[mikewest]

Reporting is what jumped out at me as well, as it seems like that's the only visible side-effect. That wasn't a problem until we added Integrity Policy, as CSP was the only reporting mechanism so ordering didn't matter.

@yoavweiss: Do you have thoughts about the desired relative ordering between CSP and Integrity Policy? IMO, there's no particular reason for it to be one way or the other as long as both are applied, but it would be ideal to define it for consistency.

[mozfreddyb]

think we should make an affort to upstream this into CSP rather sooner htan later. It is where people expect it and CSP is already filling a significant subset of the exfiltration vectors.

Lastly, CSP needs some maintenance overall, so spending time there is also good for the wider ecosystem in terms of compat, interop and maintenance ;-)

[mikewest]

I'd suggest that we separate the questions of CSP maintenance and exfiltration mitigation. There's clearly work to do on the former, and it would be ideal for the ecosystem to spend time solidifying that mechanism given its cross-browser support. The latter is less clear to me.

Despite the obvious benefit of its existence, CSP is both conceptually and syntactically a poor fit for exfiltration defense. We can certainly bend it more in that direction, adding directives and behaviors and etc. to cover gaps as we find them. Perhaps that's worth doing? My take at the moment is that I think the story we tell developers can be substantially simplified if we give developers more focused tools based on what we've learned through a decade+ of CSP usage. (This is basically the csp-next discussion we've been having for years now. :))

[yoavweiss]

@yoavweiss: Do you have thoughts about the desired relative ordering between CSP and Integrity Policy? IMO, there's no particular reason for it to be one way or the other as long as both are applied, but it would be ideal to define it for consistency.

Apologies for the delay.

It seems that CSP is a "stricter" requirement compared to Integrity-Policy. As such, I think that running CSP checks first followed by Integrity-Policy checks makes sense. It seems to me that step 7 of main fetch already defines an implicit order (which matches the above), but we could probably make it more expicit.

[noamr]

think we should make an affort to upstream this into CSP rather sooner htan later. It is where people expect it and CSP is already filling a significant subset of the exfiltration vectors.

By upstreaming to CSP do you mean upstreaming this to the CSP spec, or reusing the CSP header?

I don't have an issue with the former, but the latter would mean that we can't cleanly use URL patterns because they are incompatible with "stricly splitting a string". I think it would be unfortunate to impose that kind of restriction on new APIs that protect against very different things.

[mozfreddyb]

This proposal is incompatible with CSP because it was written without CSP syntax in mind, right? What's keeping you from changing this?

[noamr]

This proposal is incompatible with CSP because it was written without CSP syntax in mind, right? What's keeping you from changing this?

CSP syntax is incompatible with URL pattern syntax and strict string splitting on ; is very limiting in that sense.

It's technically possible to make everything new that's loosely related to CSP become part of CSP, with somewhat irritating restrictions such as using * only in allowed spots in the URL or having an exotic subset of URLPattern that doesn't allow ;, but perhaps we can make new APIs that have a different purpose than CSP not require these restrictions?

[noamr]

Regarding ordering - I think that connection allowlist check should come before CSP conceptually. "Am I allowed to connect to example.com" seems like a question that should be asked before "Am I allowed to run scripts from example.com".
But it's not a strong opinion.

[mozfreddyb]

This proposal is incompatible with CSP because it was written without CSP syntax in mind, right? What's keeping you from changing this?

It's technically possible to make everything new that's loosely related to CSP become part of CSP, with somewhat irritating restrictions such as using * only in allowed spots in the URL or having an exotic subset of URLPattern that doesn't allow ;, but perhaps we can make new APIs that have a different purpose than CSP not require these restrictions?

I want to push back on this argument. The draft as it is written right now is already using an exotic subset of URLPattern, given that you have to throw aways host names.

[noamr]

This proposal is incompatible with CSP because it was written without CSP syntax in mind, right? What's keeping you from changing this?

It's technically possible to make everything new that's loosely related to CSP become part of CSP, with somewhat irritating restrictions such as using * only in allowed spots in the URL or having an exotic subset of URLPattern that doesn't allow ;, but perhaps we can make new APIs that have a different purpose than CSP not require these restrictions?

I want to push back on this argument. The draft as it is written right now is already using an exotic subset of URLPattern, given that you have to throw aways host names.

Fair point. I think the main reason to separate this from CSP is less technical and more about the notion that CSP became quite a Swiss army knife with a big set of dos and donts and perhaps having different tools for different problems can make things cleaner going forward. I think it would be good to understand the benefits you see as making this part of CSP.

[mikewest]

Hey Freddy, Noam!

I want to push back on this argument. The draft as it is written right now is already using an exotic subset of URLPattern, given that you have to throw aways host names.

Pedantically, the allowlist the developer writes isn't using an exotic subset. :)

Still, I agree that the algorithm's written in a potentially confusing way. If the URLPattern spec exported a different set of definitions, we'd rewrite that algorithm to call just the hostname matching portion rather than synthesizing a hostname-only URLPattern. That's how this algorithm is implemented in Chromium.

[CSP vs CA syntax discussion]

Using a new header gives us the opportunity to use more modern syntax, which is nice. It's not enough of a reason in itself to use a new header, so I'm not going to debate too much whether the representation is better, worse, or equivalent.

The more important reasons for me are wrapped up in complexity for developers. We've worked for years to explain how to use CSP to control script execution. The patterns we've recommended to mitigate XSS (hashes and nonces) are entirely inappropriate for exfiltration mitigation because the threats are orthogonal to each other: the former is tied to elements on a page, the latter to hosts on the net. I agree that it's possible to adjust our definition and implementations of CSP to address both threats, but I think it complicates rather than simplifies the mental model, and makes the advice we give to developers even more complicated than it already is.

To make this more concrete: we're strongly advocating CSP usage along the lines of strict CSP:

Content-Security-Policy:                        \
  script-src 'nonce-{RANDOM}' 'strict-dynamic'; \
  object-src 'none';                            \
  base-uri 'none';

That's a robust policy against XSS, but the presence of the nonce means that any URL is allowable. Developers might imagine that they could tighten the policy by adding a default-src directive, but since it's overridden for script tags by script-src. The following policy looks stricter, but it's actually just as leaky as the original:

Content-Security-Policy:                        \
  script-src 'nonce-{RANDOM}' 'strict-dynamic'; \
  object-src 'none';                            \
  base-uri 'none';                              \
  default-src https://trusted.site

Instead, developers will need to more fully understand CSP's model, and to recognize that they can deliver more than one policy with orthogonal effect:

Content-Security-Policy:                        \
  script-src 'nonce-{RANDOM}' 'strict-dynamic'; \
  object-src 'none';                            \
  base-uri 'none',                              \
  default-src https://trusted.site

It's a one-character difference with more dramatic effect than I think developers would expect. I'm confident that we could get developers comfortable with the pattern if it's all we can agree on. I think it would do them a disservice in the long run, and present a pretty clear pain point since it looks like a typo to the unenlightened.

I think I'm advocating a simplification: developers should use CSP to control the usage of resources on their sites, and they should use connection allowlists to exhaustively control the contact their sites have with the wider web. Different things that have different effects are simpler to explain and use correctly than one thing with multiple, unintuitive effects.

[noamr]

@mikewest what if we used a different keyword for this?

Content-Security-Policy:                        \
  script-src 'nonce-{RANDOM}' 'strict-dynamic'; \
  object-src 'none';                            \
  base-uri 'none',                              \
  strict-allow-only 'self' https://trusted.site

can bikeshed the name but not having src or looking like one of the other policies can maybe help hhere?