[whatwg/fetch] CORS readability for no-cors requests (Issue #1839)

pmeenan created an issue (whatwg/fetch#1839)

### 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: https://github.com/whatwg/html/issues/8143

Chrome platform feature entry: <coming soon>
Mozilla standards position: https://github.com/mozilla/standards-positions/issues/1240
Webkit standards position: https://github.com/WebKit/standards-positions/issues/505

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1839
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1839@github.com>