Change Origin-Agent-Cluster HTTP header default

[otherdaniel]

This changes the default behavior for the Origin-Agent-Cluster header from false to true. That is, an absent header was equivalent to false (?0) and is now equivalent to true (?1).

• At least two implementers are interested (and none opposed):
  • Chromium (shipped in Chrome 115)
  • Firefox: prototyping
  • WebKit: no reply
• Tests are written and can be reviewed and commented upon at:
  • Will be exported from https://chromium-review.googlesource.com/c/chromium/src/+/4813806
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/40201655
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1948802
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=287848
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: Update document.domain / Origin-Agent-Cluster docs for new default mdn/mdn#638
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsers.html ( diff )
/document-lifecycle.html ( diff )
/webappapis.html ( diff )

[annevk]

Looks good! You'll need to make your membership of the googlers GitHub organization public.

I suggest we merge this after it has successfully shipped and stuck for a month or so.

[domenic]

I think we need more updates, mostly to the non-normative introductory text. E.g. https://whatpr.org/html/7617/origin.html#origin-keyed-agent-clusters says

A Document delivered over a secure context can request that it be placed in an origin-keyed agent cluster, by using the Origin-Agent-Cluster HTTP response header.

but it should probably say something like "By default, a Document is in an origin-keyed agent cluster. The Origin-Agent-Cluster header can be used to opt out of this behavior and become site-keyed."

Similarly, with the paragraph starting "The consequences of using this header are that the resulting Document's agent cluster key is its origin..."

[annevk]

That's a good point. We also want to move/adjust this document.domain warning to instead cover this feature:

Avoid using the document.domain setter. It undermines the security protections provided by the same-origin policy. This is especially acute when using shared hosting; for example, if an untrusted third party is able to host an HTTP server at the same IP address but on a different port, then the same-origin protection that normally protects two different sites on the same host will fail, as the ports are ignored when comparing origins after the document.domain setter has been used.

Because of these security pitfalls, this feature is in the process of being removed from the web platform. (This is a long process that takes many years.)

Instead, use postMessage() or MessageChannel objects to communicate across origins in a safe manner.

Minor adjustments in "Integration with the JavaScript agent formalism" might be welcome as well, although I think the existing text could work.

[otherdaniel]

Heya, it's been a while.

This change was launched on Chrome somewhere late '2023 and has been enabled ever since. I've rebased this spec PR to the current head.

An easy way to check is e.g. to go to https://www.example.org/ (which does not set any headers) and execute document.domain = "example.org"; in the dev console. On any current Chromium-based browser this should no-op (with an error message).

I have not heard any user complaints in the recent months. Early user complaints focused on a particular, no longer sold but still maintained enterprise product. The vendor had provided a timely update but this required manual actions to update for each customer that was still using it, which apparently took a while. (Said vendor's newer products didn't have issues.)

I think now would be a good time to land this change.

[annevk]

Since this is a normative change, it would be good if it followed https://github.com/whatwg/html/blob/main/PULL_REQUEST_TEMPLATE.md. Based on a quick scan we need browser bugs and an MDN issue.

[domenic]

I am working with Daniel on finishing this up. I've updated the OP with the modern pull request template.

The biggest blocker is updating all the WPTs for the new default. Daniel is working on doing so. Once that is done, I'll link to the update, and take care of filing bugs and MDN issues.

[domenic]

All boxes in the OP are filled out, although Daniel's work on updating the tests is currently in "draft" status. (But they are all passing.) I'll merge this once those are slightly more far along.