Intent to Ship: Compression dictionary transport with Shared Brotli and Shared Zstandard
Tsuyoshi Horo
Contact emails
ho...@chromium.org, pme...@chromium.org, nidh...@chromium.org, yoav...@chromium.org, kenji...@chromium.org
Explainer
https://github.com/WICG/compression-dictionary-transport
Specification
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary
Design docs
https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
https://github.com/WICG/compression-dictionary-transport
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary
https://docs.google.com/document/d/1WCK965Ew0hTN6k05o2JFi9Y-AdGfkB1io_i6LrTSeQs/edit?usp=sharing
Summary
This feature adds support for using designated previous responses, as an external dictionary for Brotli- or Zstandard-compressing HTTP responses. Enterprises might experience potential compatibility issues with enterprise network infrastructure. The CompressionDictionaryTransportEnabled policy is available to turn off the compression dictionary transport feature.
Blink component
Blink>Network
TAG review
https://github.com/w3ctag/design-reviews/issues/877
TAG review status
Issues addressed
Chromium Trial Name
CompressionDictionaryTransportV3
Origin Trial documentation link
https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/compression-dictionary-transport.md
WebFeature UseCounter name
SharedDictionaryUsed
Chromium Trial Name
CompressionDictionaryTransport
Link to origin trial feedback summary
https://github.com/httpwg/http-extensions/issues?q=is%3Aissue+label%3Acompression-dictionary
Risks
Interoperability and Compatibility
Interoperability and Compatibility risk are low. This feature introduces a new compression method for transporting resources over HTTP. Web sites can know the browser support for the new feature by checking `document.createElement('link').relList.supports('dictionary')`. Also web servers can know the browser support by checking the `Accept-Encoding` request header and the new `Use-As-Dictionary` request header.
This feature is an opt-in feature. And the dictionary storage is isolated using the top level site and the frame origin as the key. That means, if there is no dictionary registered for the site, the behavior of Chrome will not change while browsing the site. Also this feature is only usable within a secure-context. So this feature will not increase the risk of having network proxies meddle with the content’s encoding.
Gecko: Positive (https://github.com/mozilla/standards-positions/issues/771)
WebKit: Support (https://github.com/WebKit/standards-positions/issues/160)
Web developers: Positive based on origin trial feedback
Other signals:
Interoperability and Compatibility risk are low. This feature introduces a new compression method for transporting resources over HTTP. Web sites can know the browser support for the new feature by checking `document.createElement('link').relList.supports('dictionary')`. Also web servers can know the browser support by checking the `Accept-Encoding` request header and the new `Use-As-Dictionary` request header. This feature is an opt-in feature. And the dictionary storage is isolated using the top level site and the frame origin as the key. That means, if there is no dictionary registered for the site, the behavior of Chrome will not change while browsing the site. Also this feature is only usable within a secure-context. So this feature will not increase the risk of having network proxies meddle with the content’s encoding.
Gecko: Positive (https://github.com/mozilla/standards-positions/issues/771)
WebKit: Support (https://github.com/WebKit/standards-positions/issues/160)
Web developers: Positive based on origin trial feedback
Other signals:
Ergonomics
To reduce memory usage in network services, dictionary metadata is stored in a database on disk. And to avoid performance degradation for normal requests that do not use a dictionary, the reading of this metadata is designed not to block network requests. In other words, if the reading of metadata from the database is not completed before the request header is ready to be sent to the server, the dictionary may not be used even if it is already registered in the database.
To reduce memory usage in network services, dictionary metadata is stored in a database on disk. And to avoid performance degradation for normal requests that do not use a dictionary, the reading of this metadata is designed not to block network requests. In other words, if the reading of metadata from the database is not completed before the request header is ready to be sent to the server, the dictionary may not be used even if it is already registered in the database.
Activation
To adopt this feature, web developers need to make changes in their web servers. Currently there is no major server softwares which supports compression dictionaries. Some CDNs have shared interest in supporting shared dictionary compression (e.g. publicly mentioned [*] in a blog post by Cloudflare).
[*] https://blog.cloudflare.com/this-is-brotli-from-origin/#:~:text=One%20development%20that%20we%27re%20particularly%20focused%20on%20is%20shared%20dictionaries%20with%20Brotli.
To adopt this feature, web developers need to make changes in their web servers. Currently there is no major server softwares which supports compression dictionaries. Some CDNs have shared interest in supporting shared dictionary compression (e.g. publicly mentioned [*] in a blog post by Cloudflare). [*] https://blog.cloudflare.com/this-is-brotli-from-origin/#:~:text=One%20development%20that%20we%27re%20particularly%20focused%20on%20is%20shared%20dictionaries%20with%20Brotli.
Security
Chrome registers the response as a dictionary only when the response is CORS-readable from the document origin. Also we use a registered dictionary to decompress the response only when the response is CORS-readable from the document origin. Additionally, the dictionary and the compressed resource are required to be from the same origin as each other. So this should not introduce any new attack vector of stealing information.
The dictionaries are partitioned with the storage cache and are cleared whenever cookies or cache is cleared to ensure that the dictionaries can not be abused as a tracking vector.
Chrome registers the response as a dictionary only when the response is CORS-readable from the document origin. Also we use a registered dictionary to decompress the response only when the response is CORS-readable from the document origin. Additionally, the dictionary and the compressed resource are required to be from the same origin as each other. So this should not introduce any new attack vector of stealing information. The dictionaries are partitioned with the storage cache and are cleared whenever cookies or cache is cleared to ensure that the dictionaries can not be abused as a tracking vector.
WebView application risks
None
None
Debuggability
We have introduced chrome://net-internals/#sharedDictionary. Using it, web developers can manage the registered dictionaries. Also web developers can check the related HTTP request and response headers (Use-As-Dictionary, Sec-Available-Dictionary, Accept-Encoding, Content-Encoding) using DevTools' Network panel.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
https://wpt.fyi/results/fetch/compression-dictionary
Flag name on chrome://flags
chrome://flags/#enable-compression-dictionary-transport-backend chrome://flags/#enable-compression-dictionary-transport
Finch feature name
CompressionDictionaryTransportBackend CompressionDictionaryTransport
Requires code in //chrome?
True
Tracking bug
https://crbug.com/1413922
Launch bug
https://launch.corp.google.com/launch/4266286
Sample links
https://compression-dictionary-transport-threejs-demo.glitch.me
https://compression-dictionary-transport-shop-demo.glitch.me
Estimated milestones
| Shipping on desktop | 130 |
| Origin trial desktop first | 123 |
| Origin trial desktop last | 125 |
| Origin trial desktop first | 117 |
| Origin trial desktop last | 122 |
| Origin trial desktop first | 127 |
| Origin trial desktop last | 129 |
| Shipping on Android | 130 |
| Origin trial Android first | 123 |
| Origin trial Android last | 125 |
| Origin trial Android first | 117 |
| Origin trial Android last | 122 |
| Origin trial Android first | 127 |
| Origin trial Android last | 129 |
| Shipping on WebView | 130 |
| Origin trial WebView first | 123 |
| Origin trial WebView last | 125 |
| Origin trial WebView first | 127 |
| Origin trial WebView last | 129 |
Anticipated spec changes
None. The draft has been reviewed by the IETF http working group and steering committee and approved for publication as a RFC. There are a few mechanical process issues that need to happen for publication but the spec itself will not be changing.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5124977788977152?gate=5186705503551488
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-Vb1ON2XT2%2BBP27tJ4ivjgyu63jcd667am4TwcVFGsbuw%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/7YdP2YxRQn4/m/9oPxLDdjAAAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-WyukWVPpFMFYSWVZ1%2BOuXVjtNfWiCqKvDYcdRwaApZLA%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/9iMl0kAA2LE
This intent message was generated by Chrome Platform Status.
Jeffrey Yasskin
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-X5SPHneF3WuaDYQREdDs_vAyE3JxeRA6s5RMXXL6rVBw%40mail.gmail.com.
Patrick Meenan
Congratulations on getting compression dictionaries through the standards gauntlet!On Tue, Aug 27, 2024 at 2:36 AM Tsuyoshi Horo <ho...@chromium.org> wrote:The explainer still has "All actual header values and names still TBD". I assume that's not the case anymore?
Is there a specification for the browser side of this? I'd expect to find something in Fetch that describes, for example, the CORS, same-origin, and partitioning behavior.
Interoperability and Compatibility
Interoperability and Compatibility risk are low. This feature introduces a new compression method for transporting resources over HTTP. Web sites can know the browser support for the new feature by checking `document.createElement('link').relList.supports('dictionary')`.
https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-17.html#name-the-compression-dictionary- says the link relation is "compression-dictionary" instead of "dictionary". Which is being shipped?
Patrick Meenan
Patrick Meenan
Alex Russell
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/893b961c-c763-44a0-abe4-361ba276ab1en%40chromium.org.
Mike Taylor
LGTM3
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8sO5p%3D0MB78QRKM71MK59Ov4KAK928ZtPHDQnn4CeAgw%40mail.gmail.com.