[w3ctag/design-reviews] Deprecating `document.domain`. (#564)

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:

  - [X] I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/564