1665474 - Implement the Origin-Agent-Cluster header

Status: RESOLVED FIXED

(Core :: DOM: Navigation, enhancement, P3)

Description

[Domenic Denicola]

• Explainer: https://github.com/WICG/origin-isolation

• Spec PR: https://github.com/whatwg/html/pull/5545 + https://github.com/whatwg/html/pull/6214

• Tests: https://github.com/web-platform-tests/wpt/tree/master/origin-isolation (still being updated to the new name)

• Spec entrypoint: https://html.spec.whatwg.org/multipage/origin.html#origin-isolation

Comment 1

[Anne (:annevk)]

This is worth prototyping per https://mozilla.github.io/standards-positions/#domenic-origin-isolation.

Comment 2

[steve]

Please see how this lack-of-support impacts functionality in related projects. It would be a shame if the only browser that is able to perform is Meta.

https://github.com/Igalia/wolvic/issues/46

Comment 3

[Jens Stutte [:jstutte]]

(In reply to steve from comment #2)

Please see how this lack-of-support impacts functionality in related projects. It would be a shame if the only browser that is able to perform is Meta.

https://github.com/Igalia/wolvic/issues/46

IIUC this kind of implies that we would want to use this mainly for performance improvements, not only for enhanced security. In fact the spec says about consequences:

In terms of observable effects, this means that attempting to relax the same-origin restriction using document.domain will instead do nothing, and it will not be possible to send WebAssembly.Module objects to cross-origin Documents (even if they are same site).

And then:

Behind the scenes, this isolation can allow user agents to allocate implementation-specific resources corresponding to agent clusters, such as processes or threads, more efficiently.

So supporting this for the mandatory part might be relatively easy (to be fair, I ignore what it really takes), but having also the resource benefits might be harder. Would it be worth doing one without the other?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Moving this to DOM: Navigation, though this is really cross-module thing. But I think most of the changes would be around document channel and how it selects the right process etc.

Comment 5

[Simon Pieters [:zcorpan]]

Tests: https://wpt.fyi/results/html/browsers/origin/origin-keyed-agent-clusters?label=master&label=experimental&aligned

Comment 6

[Nika Layzell [:nika] (ni? for response)]

Attachment: WIP: Bug 1665474 - Part 1: Return BrosingContext from ChangeRemoteness, r=smaug!

This exposes the specific BrowsingContext which will finish the load to the
caller, which will be required to set up state on the new BrowsingContextGroup
after a navigation.

Comment 7

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 1: Make origin keying explicit in the DocGroup key, r=farre!

The UsesOriginAgentCluster method returns a Maybe<bool>, to allow for an
uncertain state in the future (when the origin-agent-cluster status can be
unknown until a network request is received).

Comment 8

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 2: Add support for the originAgentCluster member on Window, r=farre!

This attribute currently just reflects the potentially-cross-origin-isolated
status of the BrowsingContextGroup.

Comment 9

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 3: Always use origin-keyed agent clusters for non-http(s) principals, r=farre!

This aligns with what is written in the spec, as setting document.domain is
only a concept which is useful for http(s) principals.

Comment 10

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 4: Add a getter method for the Origin-Agent-Cluster header's value, r=#necko-reviewers

This adds a helper method to nsIHttpChannelInternal for parsing the
Origin-Agent-Cluster header. This header is intended to be interpreted as a
boolean structured-field-value header.

Comment 11

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 5: Add support for the Origin-Agent-Cluster HTTP header, r=farre!

This adds support for the Origin-Agent-Cluster header. A map from principals to
their cached origin-agent-cluster status is maintained in the
BrowsingContextGroup, and synchronized to child processes such that it can be
used to create DocGroups.

Note that this patch does not implement origin-keyed process isolation for
Fission. Fission process isolation still always uses the site-origin.

It's likely we'll want to implement additional hereustics and/or tracking to
decide when to perform origin-keyed process isolation to avoid potential
process count increases when the default is changed to origin-isolated.

Comment 12

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 6: Fix bug in wpt test, r=farre!

It appears the about-blank.https.sub.html test incorrectly was resolving the
createBlankIframe test with the load event object, rather than with the
created iframe, which led to an exception being thrown when accessing the
contentDocument property.

This patch makes returning the iframe explicit, fixing that failure.

Comment 13

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 7: Update test expectations for origin-keyed-agent-clusters wpts, r=farre!

This patch stack has implemented the Origin-Agent-Clusters header, meaning that
these WPTs should now pass.

The only remaining exception is for regression-1399759.https.sub.html, which
depends on non-standard behaviour around navigating to about:srcdoc which is
not supported in Gecko.

Comment 14

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 8: Update document.domain warning wording, r=farre!

Previously this warning could only fire in a cross-origin-isolated
context, but after the changes in this patch stack, it can also happen
if the webpage opts in with Origin-Agent-Cluster: ?1.

This updates the wording of the warning to more accurately reflect the
new situations which cause it to fire.

Comment 15

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 9: Handle calls to browser.createAboutBlankDocumentViewer with http(s) principals, r=farre!

It is possible for frontend JS to call this method on a browser element
with an http(s) principal. In this case, treat the new about:blank
document like it was created without a Origin-Agent-Cluster header, and
ensure the map is updated before the message to create the viewer is
sent into the content process.

Comment 16

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 10: Add a global list of all in-process documents, r=smaug!

This is used to replace the places where all documents are iterated using
DocGroup. In another part, DocGroups are changed to hold Window Globals rather
than Document objects, so an alternative mechanism is required to allow for all
documents to be iterated.

A linked list is used to minimize document creation overhead.

Comment 17

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 11: Align DocGroup creation better with the spec, r=smaug!,farre!

This more closely aligns with the spec definition of Similar-origin Window
Agents, which is the concept a DocGroup is intended to implement.

This is required to ensure that DocGroups are not created for a cross-origin
data document in a process which otherwise cannot load those documents. There
is no agent for those documents, they are not loaded with DocumentLoadListener,
and creating them was violating assertions in other parts of the stack.

This change also removes some unused methods from DocGroup, as there's
no reason to re-implement them for Windows if they'll never be used.

Comment 18

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1665474 - Part 11: Don't create DocGroups for cross-origin data documents, r=smaug!,farre!

This is a minimal patch which changes how DocGroups are created to make
cross-origin data documents share a DocGroup with their embedder.

This is required to better align DocGroups with Similar-origin Window
Agents (which correlate with DocGroups), which is required for other
parts of this patch stack.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cfbcedde3e49
Part 1: Make origin keying explicit in the DocGroup key, r=farre
https://hg.mozilla.org/integration/autoland/rev/2fc56ea1e5a1
Part 2: Add support for the originAgentCluster member on Window, r=farre
https://hg.mozilla.org/integration/autoland/rev/52f43d497d4d
Part 3: Always use origin-keyed agent clusters for non-http(s) principals, r=farre
https://hg.mozilla.org/integration/autoland/rev/258f5ad9ffe3
Part 4: Add a getter method for the Origin-Agent-Cluster header's value, r=necko-reviewers,webidl,saschanaz,kershaw
https://hg.mozilla.org/integration/autoland/rev/6c26de8c5e15
Part 5: Add support for the Origin-Agent-Cluster HTTP header, r=farre
https://hg.mozilla.org/integration/autoland/rev/dafc01f02f5b
Part 6: Fix bug in wpt test, r=farre
https://hg.mozilla.org/integration/autoland/rev/54e28a4cba57
Part 7: Update test expectations for origin-keyed-agent-clusters wpts, r=farre
https://hg.mozilla.org/integration/autoland/rev/5a4d6c2e0dec
Part 8: Update document.domain warning wording, r=farre,flod
https://hg.mozilla.org/integration/autoland/rev/81c6cd7f8b5b
Part 9: Handle calls to browser.createAboutBlankDocumentViewer with http(s) principals, r=farre
https://hg.mozilla.org/integration/autoland/rev/154ed8651d58
Part 10: Add a global list of all in-process documents, r=smaug
https://hg.mozilla.org/integration/autoland/rev/2727c78f7920
Part 11: Don't create DocGroups for cross-origin data documents, r=smaug,farre
https://hg.mozilla.org/integration/autoland/rev/6b116c5e4c24
apply code formatting via Lando

Comment 20

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/51082 for changes under testing/web-platform/tests

Comment 21

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/cfbcedde3e49
https://hg.mozilla.org/mozilla-central/rev/2fc56ea1e5a1
https://hg.mozilla.org/mozilla-central/rev/52f43d497d4d
https://hg.mozilla.org/mozilla-central/rev/258f5ad9ffe3
https://hg.mozilla.org/mozilla-central/rev/6c26de8c5e15
https://hg.mozilla.org/mozilla-central/rev/dafc01f02f5b
https://hg.mozilla.org/mozilla-central/rev/54e28a4cba57
https://hg.mozilla.org/mozilla-central/rev/5a4d6c2e0dec
https://hg.mozilla.org/mozilla-central/rev/81c6cd7f8b5b
https://hg.mozilla.org/mozilla-central/rev/154ed8651d58
https://hg.mozilla.org/mozilla-central/rev/2727c78f7920
https://hg.mozilla.org/mozilla-central/rev/6b116c5e4c24

Comment 22

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 23

[Mayank Bansal]

This increase the installer size on windows by 4.6KB, which is below the alert threshold. Please consider this comment only a FYI.

Comment 24

[Hamish Willee]

FF138 MDN docs for this can be tracked in https://github.com/mdn/content/issues/38908. The documentation for the HTTP header and the window property are already pretty good, so this is just a compatibility data update and a release note.