Guten TAG!

I would be thrilled if y'all could peruse the following suggestion that we start seriously looking into removing the document.domain setter from the platform.

We all know that document.domain's setter is a mechanism of weakening the same-origin policy to allow same-site-but-cross-origin documents direct DOM access to each other. This is unfortunate to begin with, but particularly so in light of Spectre and related side-channel attacks that have convinced us that aligning origins to processes is essential. document.domain makes it difficult to accurately commit documents into an origin-bound process, since its level of access to same-site documents could shift at runtime. Rather than asking developers to opt-out of this via COOP/COEP, Origin-Isolated, or Feature/Permission Policy, it would be ideal to first shift to an opt-in model, and then remove the mechanism entirely after usage is sufficiently low.

The proposal, then, entails the following:

1. After a sufficient amount of communication with developers, shift the document-domain feature policy's allowlist from * to 'none'. This would break document.domain usage by default, allowing developers to opt-into it via Feature-Policy: document-domain 'src' or similar. (Here, it may be more compatible to shift from throwing an exception when the setter is disabled to simply ignoring its usage.)

2. After driving down usage in step 1, shift to a more restrictive opt-in (enterprise policy, reverse origin trial, etc).

3. After more usage disappears in step 2, remove the setter entirely.

4. 🎉

---

• Explainer¹ (minimally containing user needs and example code): https://github.com/mikewest/deprecating-document-domain/
• Security and Privacy self-review²: This is a strict removal, which is security-positive along every axis the self-review document asks us to evaluate.
• GitHub repo (if you prefer feedback filed there): https://github.com/mikewest/deprecating-document-domain/
• Primary contacts (and their relationship to the specification):
  • Mike West (@mikewest), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5428079583297536

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): The change is small enough that it would proceed through PRs against WHATWG specifications.
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG for HTML, WebAppSec for Feature/Permission Policy.
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design: Usage in the wild is high, something like ~0.4% of Chrome page views.
• This work is being funded by: Google.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify moi.