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

@jyasskin commented on this pull request.

Thanks for writing this!

> +<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.

This paragraph may be too focused on users. What are specs using Fetch supposed to do to help with the SOP? It seems like their job is to ensure that resources are fetched with one of the [request modes](https://fetch.spec.whatwg.org/#concept-request-mode), which will ensure that one origin can't get illegitimate access to resources protected by credentials or network identity.

> +<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.

How is this connected to the same-origin policy? A site that wants to leak this kind of information can always embed an `<iframe>`.

> +<p>The main way to access cross-origin data is via the <a>cors protocol</a>, described in detail in
+this standard. CORS (Cross Origin Resource Sharing) is built on the principle that origins that want

Mention that this is selected by setting the [request mode to `"cors"`](https://fetch.spec.whatwg.org/#concept-request-mode).

> +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.
+
+<p>This mechanism of fetching should not be used in new specs. However, specs should be written with

Mention that it's the default request mode, and so every new spec should set a request mode explicitly.

> +<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

What spec language should consuming specs use to opt into or cooperate with this protection?

> +<p>Instead, the embedder must use
+<a data-lt="cross-origin isolated capability">cross-origin isolation</a>, using the
+`<a http-header><code>Cross-Origin-Embedder-Policy</code></a>` header to restrict embedding of
+cross-origin resources only to resources that explicitly allow this.
+
+<p>Note that CORP and cross-origin isolation are not designed to be a "lighter version of CORS".
+Their purpose is to restrict embedding of existing resources that are normally embeddable without
+CORS, in order to enable safe usage of powerful platform features.
+
+<p>Other specifications should consider requiring CORP if they expose a powerful platform feature,
+regardless of whether they themselves invoke <a for=/>fetch</a>.
+
+<h4 id=fetch-elsewhere-TAO>Accessing timing information (TAO)</h4>
+
+<p>Beside the protections for the resource's data itself, the Fetch standard enforces restrictions
+on accessing timing information associated with the <a for=/>fetch</a>. This timing information

Similarly, what do specs need to write in order to mark some information as "timing information"?

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

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