Intent to Implement: Feature policy control over `document.domain`.

[Mike West]

Contact emails

mk...@chromium.org

Spec

https://github.com/whatwg/html/pull/4170

Summary

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. 

Motivation

`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.

Interoperability risk

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.

Compatibility risk

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

None

Will this feature be supported on all six Blink platforms?

Yes.

OWP launch tracking bug

https://crbug.com/904351

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5341992867332096

Requesting approval to ship?

No.

-mike