I don't know if we have any precedent for accessing a chrome:// URL from a web origin (and since we "synthesize" an HTML response the PDF context exists in the hosting origin), so I think that that would be blocked by default currently and we would probably be wary of opening that up. Maybe we would be more open to making a specific chrome-untrusted:// URL web-accessible (which won't have any chrome:// URL superpowers), although that would also be breaking new ground I think.
Brainstorming some possible alternatives for discussion:
- Could we also synthesize a response to a CSS file URL under the same web origin? This might be challenging because it could have conflicts, probably has other security concerns I haven't thought of yet, etc., but it might automatically meet all existing Strict CSP policies (since style-src is origin based) without requiring adding new Chrome-specific src URLs.
- Could we bundle these into a component extension with the CSS files listed as
web accessible resources? This would at least give a stable identifier for these that could be added to the embedding site's CSP, and in practice would act kind of like doing this via a chrome-untrusted:// URL.
- Could we detect when we are in a Chrome-controlled PDF resource context and loosen our CSP enforcement? Maybe we could double check it via a nonce we know internally (and this could possibly apply to any inline resources the PDF resource needs like scripts, etc.)?