Editorial: Add guidelines for external specs about CORS, cross-origin isolation and TAO #1806
Conversation
Co-authored-by: Dominic Farolino <[email protected]>
Co-authored-by: Dominic Farolino <[email protected]>
Co-authored-by: Dominic Farolino <[email protected]>
| <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. |
There was a problem hiding this comment.
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, which will ensure that one origin can't get illegitimate access to resources protected by credentials or network identity.
There was a problem hiding this comment.
It was actually important for me to be focused on users! But point taken.
fetch.bs
Outdated
| <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. |
There was a problem hiding this comment.
How is this connected to the same-origin policy? A site that wants to leak this kind of information can always embed an <iframe>.
There was a problem hiding this comment.
Imagine any domain had read access to corp-intranet.com/about-my-computer.json and it gave you all kinds of information about yourself, identifying you by your IP address.
| <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 |
There was a problem hiding this comment.
Mention that this is selected by setting the request mode to "cors".
fetch.bs
Outdated
| 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
What spec language should consuming specs use to opt into or cooperate with this protection?
There was a problem hiding this comment.
This is already mentioned in detail in one of the previous sections about populating the request object, I'll refer back to that.
| <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 |
There was a problem hiding this comment.
Similarly, what do specs need to write in order to mark some information as "timing information"?
noamr
changed the title
Add a section to "using fetch elsewhere" that describes in a nutshell what new standards that invoke fetch should take
into the consideration when integrating with the same-origin policy protections enforced in the Fetch standard.
(See WHATWG Working Mode: Changes for more details.)