I’m so sorry for taking such a long time to get back to you, super busy timers right now and I didn’t want to rush it.
Your points are all well-made and I agree, i’ll just try to highlight the nuances we have - my apologies as this will probably be much less eloquent than your response :-).
This is probably the simplest case I guess, in that it’s page-scoped (rather than domain-scoped) right now - which I personally think is appropriate. Page-scoping gives us fine grained control which we really need, if the rules were origin scoped, being honest, we wouldn’t use CSP as the ruleset would be a. too large to manage effectively, b. too complex to coordinate across teams (in that we’d have tens of teams all making changes concurrently, many of which would clash and we’re a bit of an oil tanker - something which we’re making efforts to remedy but it takes time and i think will likely never be slick enough to make this workable).
For context, our setup WRT CSP is:
We have some page assets which are common to all BBC pages, these are from an internally consumed service called Orb (or the newer version, Orbit) - this provides a common header (inc. nav) and footer which makes pages feel consistent across the various teams websites.
Each product (obviously) has its own assets which are strongly encouraged to be locally (to us) hosted but some e.g. Radio will need to make use of 3rd party API’s for various reasons.
I’d personally like to see HSTS be implementable on a path-by-path basis as a non-default (i.e. not changing the existing behaviour by default) expansion. I am not quite sure how this would work securely or in ops terms (maybe it can’t) but since our products are self-contained and path-routed, this would mean we could ensure on a product-by-product basis that HTTPS is enforced. Currently we can and do enforce HTTPS on some pages (e.g. the UK home page) via origin-issued 301/2’s and it might be that this is the only realistic method but it’s a bit of a shame to force the extra round trip, especially for folk on high-latency/slow connections.
Makes complete sense for this to stay as origin/domain-scoped for us as we control the lower-level plumbing such as DNS & core networking via a single, centralised team. I can’t really see any practical way people could do anything other than this so i’d imagine this fits well for most if not all.
I hope that is somewhat useful, maybe i am rambling (and if so i apologise) and maybe i have misunderstood Origin Policy in some way (please let me know if so!).