Tag review for Compression Dictionary Transport

[pmeenan]

I'm requesting a TAG review of Compression Dictionary Transport.

This proposal adds support for using designated previous responses as an external dictionary for HTTP responses for compression schemes that support external dictionaries (e.g. Brotli and Zstandard).

• Explainer: https://github.com/WICG/compression-dictionary-transport/blob/main/README.md
• Security and Privacy self-review: https://github.com/WICG/compression-dictionary-transport/blob/main/security-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/compression-dictionary-transport
• Primary contacts (and their relationship to the specification):
  • [Patrick Meenan] (pmeenan), [Google]
  • [Yoav Weiss] (yoavweiss), [Google]
• Organization(s)/project(s) driving the specification: Google Chrome
• External status/issue trackers for this specification: https://chromestatus.com/feature/5124977788977152

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the work on this specification is currently being done: Web Performance working group, IETF HTTP working group
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Web Performance working group, IETF HTTP working group
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google

You should also know that...

We are taking the lower-level HTTP pieces (headers, content encoding, negotiation) through the IETF HTTP working group to create a RFC. The browser-specific parts will be layered on top of that and be integrated into the HTML and Fetch specs.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[ylafon]

Is it possible browser side to refuse to use a compression dictionary received? As hinted in the Security Risks, a dictionary might be enabling attacks if not carefully created, or if intentionally build to enable easy attacks. Are there ways to analyse received dictionary?

[pmeenan]

Is it possible browser side to refuse to use a compression dictionary received? As hinted in the Security Risks, a dictionary might be enabling attacks if not carefully created, or if intentionally build to enable easy attacks. Are there ways to analyse received dictionary?

Sure, there are a few different ways (most of which just behave like a normal request flow without dictionaries):

1. When the Use-As-Dictionary header is received on a response, the browser can choose to ignore it in which case it continues to operate as it normally would without dictionary support. It wouldn't store it and wouldn't advertise it as an Available-Dictionary for future requests. This could be for any number of reasons including:
   • match path was invalid (not same-origin).
   • Response was CORS-opaque.
   • Response was larger than the browser allows for dictionaries (or for storage allowed for the given origin).
2. When a request is going to be sent, if the request is known to be opaque then the browser will not advertise the Available-Dictionary.
3. When a dictionary-compressed response is received (in response to an advertised Available-Dictionary) and it is determined to be opaque (even though the spec calls for servers to not use dictionary compression in this case) then the client will error the request.

As far as analyzing the received dictionaries, I'm not sure if you mean at runtime in the browser or at scale using telemetry of some kind. The dictionaries themselves are normal responses and it would be up to each browser to determine if they want to instrument analysis of the payloads but most likely won't for privacy reasons. Projects like the HTTP Archive can crawl and archive the payloads of advertised dictionaries for the pages they visit if researchers wanted a dataset to operate off of but it's not comprehensive and doesn't have access to any content behind credentials or on private networks.

[ylafon]

Thanks for those clarifications. My question was indeed for runtime detection in the browser.

We reviewed this during our call today and don't have further question or issues. Eager to see progress on that.