Re: [w3ctag/design-reviews] Tag review for Compression Dictionary Transport (Issue #877)

> 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](https://httparchive.org") 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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/877#issuecomment-1733510767
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/877/1733510767@github.com>