The `document-domain` policy controlled feature governs access to `document.domain`. It is enabled by default, and, if disabled, causes `document.domain`'s setter to throw.
`document.domain` is an unfortunate API that allows developers to relax the same-origin policy to enable direct access between two documents with identical registrable domains, even when their origins don't match.
Among the security issues it directly and intentionally enables, this API also makes it difficult for browser vendors to implement origin-based process isolation (as opposed to site-based isolation), as it's impossible to know a priori whether or not the origin boundary will actually be respected.
Adding a policy-controlled feature which causes the document.domain setter to throw gives us some opt-in options. We can initially enable this feature by default, and ratchet it down over time if we're able to drive usage down. This model seems like it'll be successful for sync XHR, and I hope it'll be applicable here as well.
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals
I've had off-hand conversations with folks about this that were positive, but nothing that rises to the level of a clear, vendor-level signal. I'm hopeful to get that level of support on the PR against HTML, linked above.
As defined here, the `document-domain` feature policy is enabled by default, and can be disabled on an opt-in basis. In that sense, it's similar to the existing `sandbox` mechanism, which also disables `document.domain`
(along with other bits and pieces). It's quite possible for a page to break its embedees by disabling features they rely upon, but this policy doesn't seem to create unique risk above and beyond the existing capability exposed by `sandbox`.
Ongoing technical constraints
Will this feature be supported on all six Blink platforms?
OWP launch tracking bug
Link to entry on the Chrome Platform Status
Requesting approval to ship?