This gist is no longer relevant.
Please see the Cross-Origin-Embedder-Policy header instead as well as its integration with the Cross-Origin-Opener-Policy header.
This is a semi-formal definition of the Cross-Origin response header, to be merged into the HTML Standard pending various refactoring efforts. See also whatwg/html issue #4175.
Global objects have an associated cross-origin policy (a cross-origin policy). A cross-origin policy is null (Cross-Origin header isn't set), "anonymous" or "use-credentials".
about:blank document's relevant global object inherits cross-origin policy from the about:blank document's creator.
There's also an algorithm to obtain a cross-origin policy from a response. I.e., something that processes a Cross-Origin header, returns null if it's not there or cannot be parsed, and "anonymous" or "use-credentials" otherwise. ABNF (parser algorithm to be defined):
Cross-Origin = %s"anonymous" / %s"use-credentials" ; case-sensitiveWhen fetching a request:
- Let corsCredentials be request's client's global object's cross-origin policy
- If request's mode is "no-cors" and corsCredentials is non-null, then:
- Set request's mode to "cors".
- Set request's credentials mode to "same-origin".
- If corsCredentials is "use-credentials", then set request's credentials mode to "include".
When navigating:
- Let currentCrossOriginPolicy be ... TODO: get it from the source browsing context (which is really a document/global, but not yet refactored) or from the parent browsing context's active document's relevant global object? This matters when a frame navigates a sibling frame and the parent frame doesn't have a policy, for instance.
- Let responseCrossOriginPolicy be the result of obtaining a cross-origin policy from the response.
- If currentCrossOriginPolicy is non-null and responseCrossOriginPolicy is null, then return a network error.
- Create a new global with the response policy, if any.
Note: the value of a cross-origin policy does not influence the request made during navigation. Navigations continue to always include credentials.
When creating a browsing context:
- Inherit cross-origin policy from the creator for the global that's created.
When creating a dedicated worker:
- I think we should inherit here from the creator. We could also check the response and error if the creator has a policy and the response does not. Either way we need to look at the creator. (This is somewhat at odds with the normal model for dedicated workers, where they are treated as more standalone. E.g., they get their own service worker if the scope isn't wide enough to capture it.)
When creating a shared/service worker:
- Checks the response for a policy, cannot fail (because it creates a different agent cluster; user agents would be responsible for using a different process if opaque responses would somehow be able to get into the process).
If when a browsing context group is created it was due to the Cross-Origin-Opener-Policy on the response and that response also has a Cross-Origin header that can be obtained, all agent clusters created in that browsing context group will have the [[HighResolutionTimer]] internal slot set to true. Otherwise it'll be set to false. (We'll also have a flag on the browsing context group for this, to make this easier.)
If a shared/service worker is created with a Cross-Origin header that can be obtained, the agent cluster created for it will also have the [[HighResolutionTimer]] internal slot set to true. Otherwise it'll be set to false.
Where we currently set serialized to a record whose [[Type]] is "SharedArrayBuffer" we'd first check if the encompassing agent's agent cluster's [[HighResolutionTimer]] internal slot is true. If not, we'd throw a "DataCloneError" DOMException.
We could make [AllowShared] also check [[HighResolutionTimer]] and introduce [UnsafeAllowShared] for the cases where we're absolutely sure there are no ways to create a high-resolution timer with the passed in SharedArrayBuffer.