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: * will pass muster for the IESG and RFC Ed reviews without a normative reference to the Fetch spec. A link to a web page isn't enough. Personally, I think these details should be moved to the fetch spec (where the right people will read it). The bits needed for the IETF are covered in 9.3.1 and the first two paragraphs of 9.3.2: and then everything else in 9.3 (and below) can be a replaced by a non-normative reference to fetch. Otherwise, this should be a normative reference and the several links to fetch replaced with an appropriate [FETCH] entry in 11.1.
To be clear, I don't object to moving forward with this as is, but I don't believe will be allowed as is, unless the chairs have some extra special hand-waving skills I haven't seen yet.
I almost take that as a challenge...
There is processing model stuff that is browser-specific that will be in fetch but the parts in 9.3.2.1 and 9.3.2.2 are the things that are required from any HTTP server that might be used to serve sensitive information to a browser. I stripped out as much as I could but there is a timing attack that can be performed in fetching cross-origin content that would allow a client to "read" the response even if it doesn't have access to it on the client side and the only way to prevent it entirely is to not serve a response in the first place. By making it only a requirement when the CORS headers are present, it allows servers that never talk to browsers to not have to consider it but it really does need to be considered carefully for any server that might serve responses to a browser (or anything else that implements cross-origin readability restrictions). Making the protection non-normative would make the privacy protections optional and risk servers not being aware or necessarily implementing it (and it is the same side-channel timing attack that killed SDCH). If we're comfortable making that change then I can make the fetch spec parts authoritative about the CORS restrictions on both clients and servers but it would probably have to be a normative reference.
Oh, I see, the server description contains things a server MUST do (or not do) based on the values received in those fields when they indicate a cross-origin request.