Consider removing enforced CSP rules from Report-Only header

[janbrasna]

Non-enforced rules currently contain a copy of enforced policy as a starting point. Which means RO project is flooded with the same known (and usually inactionable) reports as prod. That doesn’t lend itself to great visibility of extra changes added/removed contemplated to potentially move from RO to prod.

Unless an intention is to test interaction of some of the enforced rules with the RO ones inside the same policy, there’s most likely no reason to spam the ingestion project with all of the same by default.

(NB: e.g. currently there are no rules under RO consideration — meaning RO reports the exact same policy violations as prod, just burning quota and being obnoxious.)

Wondering if having no deepcopy as the starting point would be better angle here, leading to empty header if RO tweaks are empty potentially even dropping it from output, and in case an engineer needs to start with a copy of some of the definitions, they’d make it their call whether and how much they need to lift from the prod rules to make their RO representative enough?

---

Success Criteria

• Lower noise from known non–RO violations duplicated into RO project too
• Better visibility into RO–specific violations
• In case CSP RO header is not needed i.e. when empty skip emitting it

[stevejalim]

@janbrasna Yes, yes, yes. Less CSP noise, more CSP RO focus (when we need it). This is a great suggestion.

If you feel like implementing it, please feel free to!

[janbrasna]

I'm currently just contemplating how to best approach, and also investigating if it can break the csp sampling percentage test tooling, while I still remember most of its context from back when it got added;)

Since both the reporting endpoint (the removal of which would turn off the RO) and the sampling percentage are shared between enforced and non–enforced policies, I can't use that to tune down the RO. So I'm leaning towards emptying the rules as the path forward.

I'm not sure if there's an official way to unset the header or otherwise documented in mozilla-django-csp what's both explicitly and implicitly empty/undefined for this purpose, I see the package is relying on particular settings constant for both of its sets, and I see if the RO's missing it's not emitted — now I just need to check how to set it explicitly as empty/nullish correctly to have the same effect as when it's effectively undefined. Just need to verify the expectations in the package code more thoroughly. (I feel like I'll submit just commented out the current setting constant deepcopy, to leave prior art for the next person needing it to uncomment as a boilerplate for their rules, but now just comment it out to "unset" the config to shut down the RO that way.)