Re: [whatwg/fetch] Editorial: Add prose about CORS, cross-origin isolation and TAO (PR #1806)

@domfarolino commented on this pull request.

Looks great, thanks so much!

> +
+<p>The Fetch standard enforces some of the mechanisms that constitute the Same Origin Policy (SOP),
+which is a critical aspect of web security. Specifically, Fetch imposes SOP restrictions on network
+access.
+
+<p>In a nutshell, when a user accesses a certain origin using their browser or other user agent,
+they don't expect that the user agent implicitly grants that <a for=/>origin</a> full access to
+their network, which could, for example, be an intranet, despite the user agent itself having that
+access.
+
+<p>In addition, the user agent may include footprint that identifies the user to the origin,
+explicitly using cookies or client certificates, or implicitly using, for example, the user-agent's
+IP address.
+
+<p>To keep this information from leaking, SOP restricts requests that come from the visited
+<a for=/>origin</a> to only target that same-origin, while allowing a few mechanisms for an origin

```suggestion
<a for=/>origin</a> to only target that same origin, while allowing a few mechanisms for an origin
```

Unless we're mentioning the term "same-origin" I feel like this reads more natural.

> +
+<h4 id=fetch-elsewhere-no-cors>No-CORS requests</h4>
+
+<p>Embedding cross-origin resources, without the ability to read them, existed prior to CORS.
+Cross-origin images, scripts, stylesheets & media are embeddable in a <a for=/>document</a> without
+the embedding <a for=/>origin</a> identifying themselves and receive explicit confirmation.
+
+<p>To maintain backwards compatibility, this form of fetching is still supported. Instead of
+restricting the network access, the embedder is restricted in what they are allowed to do with the
+<a for=/>response</a>. They can embed it in their document and present it to the user, but this has
+to be done in a way that's opaque to the embedding origin. Only the user should have access to the
+resource, not the embedder.
+
+<p>This mechanism of fetching should not be used in new specs. However, specs should be written with
+the notion that no-CORS resources exists, and the new spec should not grant origins the ability to
+read their contents.

You're saying that the new spec should not provide any new way to reveal the contents of existing no-cors requests to an embedder origin, right? Or is this about something else? I'm not sure why this reads a little opaque to me... I might recommend making this recommendation a little more concrete as I think my first sentence in this comment does (provided I'm actually on the right track).

> +restricting the network access, the embedder is restricted in what they are allowed to do with the
+<a for=/>response</a>. They can embed it in their document and present it to the user, but this has
+to be done in a way that's opaque to the embedding origin. Only the user should have access to the
+resource, not the embedder.
+
+<p>This mechanism of fetching should not be used in new specs. However, specs should be written with
+the notion that no-CORS resources exists, and the new spec should not grant origins the ability to
+read their contents.
+
+<h4 id=fetch-elsewhere-cross-origin-isolation>CORP & Cross-origin isolation</h4>
+
+<p>Due to the leaky nature of no-CORS requests, resources can further protect themselves by
+providing a `<a http-header><code>Cross-Origin-Resource-Policy</code></a>` header (CORP). By
+supplying the appropriate CORP header, a resource can opt out from being embedded by a different
+site or origin. For example, this can be used to protect an image's <a>natural dimensions</a> from
+being read by an embedded.

```suggestion
being read by an embedder.
```

> +
+<p>This mechanism of fetching should not be used in new specs. However, specs should be written with
+the notion that no-CORS resources exists, and the new spec should not grant origins the ability to
+read their contents.
+
+<h4 id=fetch-elsewhere-cross-origin-isolation>CORP & Cross-origin isolation</h4>
+
+<p>Due to the leaky nature of no-CORS requests, resources can further protect themselves by
+providing a `<a http-header><code>Cross-Origin-Resource-Policy</code></a>` header (CORP). By
+supplying the appropriate CORP header, a resource can opt out from being embedded by a different
+site or origin. For example, this can be used to protect an image's <a>natural dimensions</a> from
+being read by an embedded.
+
+<p>This protection is especially important when exposing powerful features to the web platform, that
+gain enough access to the underlying platform to read cross-origin resources using attacks like
+Spectre. This category of features, e.g. <code>SharedArrayBuffer</code> or high-resolution

```suggestion
Spectre. This category of features, e.g., <code>SharedArrayBuffer</code> or high-resolution
```

> +
+<p>For any new spec invoking <a for=/>fetch</a> to access cross-origin rersources, CORS should be
+the only option. This has been implemented in multiple newer standards such as web fonts and module
+scripts.
+
+<h4 id=fetch-elsewhere-no-cors>No-CORS requests</h4>
+
+<p>Embedding cross-origin resources, without the ability to read them, existed prior to CORS.
+Cross-origin images, scripts, stylesheets & media are embeddable in a <a for=/>document</a> without
+the embedding <a for=/>origin</a> identifying themselves and receive explicit confirmation.
+
+<p>To maintain backwards compatibility, this form of fetching is still supported. Instead of
+restricting the network access, the embedder is restricted in what they are allowed to do with the
+<a for=/>response</a>. They can embed it in their document and present it to the user, but this has
+to be done in a way that's opaque to the embedding origin. Only the user should have access to the
+resource, not the embedder.

Before jumping into CORP etc., it could be good to briefly allude to efforts like [CORB](https://chromium.googlesource.com/chromium/src/+/HEAD/services/network/cross_origin_read_blocking_explainer.md) and [ORB](https://github.com/annevk/orb), which help ensure protections on these kinds of resources. These aren't exactly standardized yet, but they're on their way, and all browsers ship some version of it so it could make a good editorial addition here with some pointers. Your call though!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1806#pullrequestreview-2579265865
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1806/review/2579265865@github.com>