Question: Using Cross-Origin-Resource-Policy to enable compression dictionary support for opaque responses

[pmeenan]

Compression dictionary transport (mdn, rfc) is currently disabled for cross-origin no-cors requests by design because it is susceptible to exposing the payload through side-channel attacks.

In the web performance working group and in last year's TPAC general session we discussed various options for marking responses as "safe" (contains no private data) and landed on using the existing Cross-Origin-Resource-Policy: cross-origin header since that is exactly what it was designed to indicate (that a response did not need protection against side-channel attacks in a cross-origin context).

This is important for enabling delta-compression for all of the third-party scripts deployed on the web with a basic no-cors <script src=...> tag.

Currently browsers disable dictionary support for no-cors requests (don't store dictionaries and don't advertise available-dictionary).

This approach should be web-safe to add but it does depend on origins making sure that they include the CORP header for responses to cross-origin requests when they use dictionary compression (if the dictionary was cors-fetched but the resource was no-cors fetched). If existing origins are blindly dictionary-compressing every request that advertises an Available-Dictionary then those resources will start to fail in a cross-origin no-cors context if they don't include the CORP header (the RFC already warns that they should not be doing this).

There are only a few compression dictionary deployments at this point and I'm not aware of any that would have an issue with this extension but, if we're going to make a change, it would be good to do it sooner rather than later.

I have work in-flight with the fetch spec and with a chrome feature and would like to have the TAG's opinion on the approach.

---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1203

[yoavweiss]

FWIW, I think the approach is extremely reasonable and the semantics you're after align really well with CORP: cross-origin

This approach should be web-safe to add but it does depend on origins making sure that they include the CORP header for responses to cross-origin requests when they use dictionary compression (if the dictionary was cors-fetched but the resource was no-cors fetched). If existing origins are blindly dictionary-compressing every request that advertises an Available-Dictionary then those resources will start to fail in a cross-origin no-cors context if they don't include the CORP header (the RFC already warns that they should not be doing this).

This seems mostly risky in the case of a dictionary that's set to a wide path range (e.g. a separate dictionary that covers large portion of the site). As such, it's less applicable to the existing resource case.

So IIUC, this is likely only an issue with cross-origin resources compressed by a separate dictionary, which I'd expect to be relatively rare. Does that match your understanding?

If deploying this hits hurdles due to deployments we're not aware of, it seems like we could at that point add an opt-in signal (to Use-As-Dictionary or to <link rel=compression-dictionary>).

[pmeenan]

Correct. It's less likely for the delta-update case since the dictionary would likely be fetched the same way as the resource being compressed so it would be most likely to happen if you fetch a stand-alone dictionary with <link rel=compression-dictionary...> (or the header version) which defaults to crossorigin=anonymous and then used the dictionary for resources that are fetched no-cors.

Today that will not generate an Available-Dictionary header for the no-cors requests so it's currently safe to always assume if you see the header that the client will successfully decompress.

If we ever want to add no-cors support, now is probably the best time to do it without having to use a completely different negotiation so that developers will see the decoding fail if they don't include the CORP header as well (with appropriate error messages in dev tools).

[jyasskin]

Thanks for sending us this review. We think this is a better question for a security-focused group. We passed it to @simoneonofri who organized a discussion in the Security IG (we don't see minutes posted yet). WebAppSec might also be a reasonable venue.