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 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.

<!-- Content below this is maintained by @w3c-tag-bot -->

---

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