Code change:
origin and passes the CORS check (https://fetch.spec.whatwg.org/#cors-check). <del> 9.3.2.1. </del> <ins> 9.3.3. </ins> <del> On the client-side, same-origin determination is defined in the fetch spec (https://html.spec.whatwg.org/multipage/browsers.html#origin). </del> <ins> As with any usage of compressed content in a secure context, a potential timing attack exists if the attacker can control any part of the dictionary, or if it can read the dictionary and control any part of the content being compressed, while performing multiple requests that vary the dictionary or injected content.  Under such an attack, the changing size or processing time of the response reveals information about the content, which might be sufficient to read the supposedly secure response. </ins> <del> On the server-side, a request with a "Sec-Fetch-Site:" request header with a value of "same-origin" is to be considered a same-origin request. </del> <ins> In general, a server can mitigate such attacks by preventing variations per request, as in preventing active use of multiple dictionaries for the same content, disabling compression when any portion of the content comes from uncontrolled sources, and securing access and control over the dictionary content in the same way as the response content.  In addition, the following requirements on a server are intended to disable dictionary-aware compression when the client provides CORS request header fields that indicate a cross- origin request context. </ins> <del> For any request that is same-origin: </del> <ins> The following algorithm will return FALSE for cross-origin requests where precautions such as not using dictionary-based compression should be considered: </ins> <del> Response MAY be used as a dictionary. </del> <ins> If there is no "Sec-Fetch-Site" request header then return TRUE. </ins> <del> Response MAY be compressed by an available dictionary. </del> <ins> if the value of the "Sec-Fetch-Site" request header is "same- origin" then return TRUE. </ins> <del> 9.3.2.2. </del> <ins> If there is no "Sec-Fetch-Mode" request header then return TRUE. </ins> <del> For requests that are not same-origin (same-origin), the "mode" of the request can be used to determine the readability of the response. </del> <ins> If the value of the "Sec-Fetch-Mode" request header is "navigate" or "same-origin" then return TRUE. </ins> <del> For clients that conform to the fetch spec, the mode of the request is stored in the RequestMode attribute of the request (https://fetch.spec.whatwg.org/#requestmode). </del> <ins> If the value of the "Sec-Fetch-Mode" request header is "cors": </ins> <del> For servers responding to clients that expose the request mode information, the value of the mode is sent in the "Sec-Fetch-Mode" request header. </del> <ins> If the response does not include an "Access-Control-Allow- Origin" response header then return FALSE. </ins> <del> If a "Sec-Fetch-Mode" request header is not present, the server SHOULD allow for the dictionary compression to be used. </del> <ins> If the request does not include an "Origin" request header then return FALSE. </ins> <del> If the mode is "navigate" or "same-origin": </del> <ins> If the value of the "Access-Control-Allow-Origin" response header is "*" then return TRUE. </ins> <del> Response MAY be used as a dictionary. </del> <ins> If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header then return TRUE. </ins> <del> Response MAY be compressed by an available dictionary. If the mode is "cors": For clients, apply the CORS check from the fetch spec (https://fetch.spec.whatwg.org/#cors-check) which includes credentials checking restrictions that may not be possible to check on the server. If the CORS check passes: Response MAY be used as a dictionary. Response MAY be compressed by an available dictionary. Else: Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. For servers: If the response does not include an "Access-Control-Allow- Origin" response header: Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. If the request does not include an "Origin" request header: Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. If the value of the "Access-Control-Allow-Origin" response header is "*": Response MAY be used as a dictionary. Response MAY be compressed by an available dictionary. If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header: Response MAY be used as a dictionary. Response MAY be compressed by an available dictionary. If the mode is any other value (including "no-cors"): Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. </del> <ins> return FALSE. </ins> 10.

Related discussion:
text: This simplifies the CORS processing language in the doc, leaving all of the client-side readability processing to fetch and clearly spelling out the server responsibilities.
The new language is much better, but I think it still misses the point. We don't need to be shy about why these requirements are in the spec and under what circumstances they are necessary. I suggest starting with an explanation:
Thanks. I pulled in your explanation and tweaked the language to make it clear that precautions should be considered, one of which may be to not use dictionary-based content encoding. I like the new version a lot better as it allows for cacheable, public data to still use dictionary compression even if it is fetched in a cross-origin context and isn't client-readable. I'll have to be careful with the fetch language as, currently, the client will fail a cross-origin non-readable response in case the server hasn't applied relevant protections. It may be reasonable to relax that and allow for the client to process it and put the burden on the server but it might also let a weak configuration go unnoticed (though since attacker-controlled dictionary content isn't particularly practical in this model, maybe it's not really a concern).
For the existing draft, there is a lot of unnecessary confusion regarding features of fetch, like CORS, that don't make any sense from a security perspective. That's not what CORS is capable of covering, nor how it is implemented in practice, so reusing it doesn't make any sense. cc NAME Moved from private ID
CORS covers privacy from a browser perspective as far as the readability of responses relative to the origin of the containing document which is exactly the context that it is needed for here. The concern that it takes care of is to make sure that responses that shouldn't be readable from the document context of the client can't be exposed to oracle timing attacks (because there won't be any client-opaque responses). HTTP itself doesn't really have the same document framing context and need for protecting read access of individual responses on a shared connection by clients running in different document contexts.
From NAME I still don't see how CORS applies to the draft. If the origin is choosing both the available dictionaries and whether or not to apply them to a given response, why is the context of a request relevant to the nature or credibility of the compressed response? Neither one is controlled by the context. The origin server isn't going to attack itself.