CORS readability for no-cors requests

[pmeenan]

What problem are you trying to solve?

There are some web platform features that are not available when responses are not CORS-readable. The protection is in place to make sure private data from responses can't inadvertently be leaked. The features that come to mind are some of the details like content-encoding from the resource timing API and compression dictionary content-encoding.

There are a lot of "public" resources that are embedded in a third-party context where it is difficult, if not impossible to enable CORS on the requests (either anonymous or credentialed). This includes things like images loaded through CSS and scripts that are sprinkled across the web (like analytics, ads, etc) where the content of the response is the same when fetched with and without credentials.

We would like to explore a mechanism for an origin to explicitly mark responses to no-cors requests as being readable.

What solutions exist today?

For the image-in-css case today, there is no way to opt-in to CORS so there is no solution.

For the case of scripts or stylesheets embedded in a third-party context, the solution is to add crossorigin attributes to the markup. That is somewhat impractical to apply at web-scale but, more importantly, it comes with side-effects. Depending on the CORS mode used, the requests will either require a separate connection from no-cors requests or they will require a preflight check.

How would you solve it?

For no-cors requests, add a Sec-Accept-Content-Readability: public request header to advertise support to the origin for marking responses as readable.

Responses would be considered CORS-readable if they contain both of the following response headers:

Content-Readability: public
Access-Control-Allow-Origin: *

For redirect chains, every response in the redirect chain would need both headers for the final response to be readable (similar to CORS tainting on the request path).

The client-advertisiment/negotiation for cases like compression dictionary encoding where the response will fail if it is not readable.

Anything else?

Original discussion in the HTML spec: whatwg/html#8143

Chrome platform status: https://chromestatus.com/feature/5509970048843776
Mozilla standards position: mozilla/standards-positions#1240
Webkit standards position: WebKit/standards-positions#505

[domenic]

For no-cors requests, add a Sec-Accept-Content-Readability: public request header to advertise support to the origin for marking responses as readable.

Is this part necessary?

[pmeenan]

> For no-cors requests, add a Sec-Accept-Content-Readability: public > request header to advertise support to the origin for marking responses as readable. Is this part necessary?

Maybe not if we caught it in time with recent additions to the web platform tests for compression dictionary. The risk is if there is client that sends "Accept-Encoding: dcb" for `no-cors` requests that the response will work for clients that support readibility override but fail for clients that don't with no way to distinguish them. The WPTs were updated to make sure the Accept-Encoding isn't sent for no-cors requests. Chrome hasn't sent it since the feature launched and is the only browser that has shipped support so it should be safe to unilaterally assume that any client that includes the encoding does it because it also supports readibility override. As far as I know, compression dictionary encoding is the only feature that depends on it where the origin needs to know and varies the response as a result.