Intent to Extend Origin Trial: Compression Dictionary Transport

530 views
Skip to first unread message

Tsuyoshi Horo

unread,
Feb 20, 2024, 8:57:41 PMFeb 20
to blink-dev, Patrick Meenan, Yoav Weiss, Kenji Baheux, deno...@chromium.org

Contact emails

ho...@chromium.org, pme...@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/


Summary

An Origin Trial for Compression Dictionary Transport was scheduled to start in Chrome 117 and end in Chrome 122. But due to a critical issue, we could not start the Origin Trial until Chrome 119. The design of the feature has also evolved during the origin trial and RFC process. We’d like to continue the Origin Trial to get more feedback on the updated feature.


Blink component

Blink>Network


TAG review

https://github.com/w3ctag/design-reviews/issues/877

TAG review status

Closed

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. For enterprises that have deployed HTTPS-intercepting proxies that do not properly handle unknown encodings there is an enterprise policy exposed to disable the feature.


Gecko: Positive (https://github.com/mozilla/standards-positions/issues/771)


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/160)


Web developers: Positive


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.



Activation

To adopt this feature, web developers need to make changes in their web servers or build processes for static resources. Currently there is no major server software which supports compression dictionaries. Some CDNs have shared interest in supporting shared dictionary compression (e.g. publicly mentioned in a blog post by Cloudflare).



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

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

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No


Goals for experimentation

We would like to collect feedback on the updated API design of Compression Dictionary Transport feature. Also, we would like to continue some experiments using this feature to measure its performance impact.


Ongoing technical constraints

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



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

No. We will rewrite some browser_tests to WPT.


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


Estimated milestones

OriginTrial desktop last

125

OriginTrial desktop first

123


OriginTrial Android last

125

OriginTrial Android first

123



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5124977788977152


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/-qYpLo9DTjw/m/JX6kbUOtBQAJ

Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E/m/oup5DpbxAAAJ



Tsuyoshi Horo

unread,
Feb 28, 2024, 7:13:26 PMFeb 28
to blink-dev, Patrick Meenan, Yoav Weiss, Kenji Baheux, deno...@chromium.org
Gentle ping. (Am I missing something?)

Domenic Denicola

unread,
Feb 28, 2024, 9:29:12 PMFeb 28
to Tsuyoshi Horo, blink-dev, Patrick Meenan, Yoav Weiss, Kenji Baheux, deno...@chromium.org
This Intent did not show up on the API Owners dashboard, which probably explains the lack of responses. I'm unsure whether this is a bug in the dashboard, or if there's something on ChromeStatus that you need to do (e.g. some stage you need to set for extending the origin trial).

LGTM to extend to M125, as that is within the guidelines of 6 milestones for M119 to M125.

--
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-VPyLaum9rma1cpFZhUSF8FuBy3DBJFcwDUmabWE8VC5g%40mail.gmail.com.

Tsuyoshi Horo

unread,
Feb 29, 2024, 2:25:47 AMFeb 29
to Domenic Denicola, blink-dev, Patrick Meenan, Yoav Weiss, Kenji Baheux, deno...@chromium.org
Thank you!

Tsuyoshi Horo

unread,
Mar 7, 2024, 2:44:52 AMMar 7
to blink-dev, Patrick Meenan, Yoav Weiss, Kenji Baheux, deno...@chromium.org, Domenic Denicola
Hi, blink-dev@ folks.

Let me announce the start of the new Origin Trial for the Compression Dictionary Transport feature.

If you are already experimenting with it you'll need to register for a new token (CompressionDictionaryTransportV2).
There were header changes since the first trial. So please check this list of changes if you have any trouble while experimenting with the Compression Dictionary Transport feature in Chrome 123. 

Thank you.

Reply all
Reply to author
Forward
0 new messages