Automatic origin isolation of site = origin cases might not be web compatible

[domenic]

In WICG/origin-agent-cluster#31 @csreis, @annevk and I decided that cases where site = origin should have window.originIsolated return true, because those sites are "automatically origin isolated".

However, when going to implement this (https://chromium-review.googlesource.com/c/chromium/src/+/2426609), I realized this has more impact than we might have anticipated. In particular, being origin-isolated turns off document.domain.

This means that, in the current HTML Standard, sites accessed via IP addresses cannot use document.domain. This breaks at least one Chrome test, and more importantly, it seems likely that sites in the wild are using this. Concretely, before merging origin isolation into HTML, https://192.168.0.1:8080 could set document.domain = "192.168.0.1" and get access to all other ports hosted on that IP. Now, it cannot; https://html.spec.whatwg.org/#relaxing-the-same-origin-restriction:origin-isolated will trigger and make that setter do nothing. This seems especially likely because the HTML Standard has a warning about how dangerous this scenario is; I assume the reason such a warning was added, is because people were actually doing it.

Other cases of interest are sites hosted on a public suffix (e.g., https://github.io/), and file: URLs (whose origin is sometimes opaque, at browser discretion). But the IP address case seems the most worrisome; I find it unlikely that people are using document.domain in the other cases.

---

As much as I'd like to break document.domain in more cases, I think this deserves more discussion, because I don't think anyone anticipated this in WICG/origin-agent-cluster#31.

Possible courses of action:

1. Revisit the decision in API concerns for originIsolationRestricted WICG/origin-agent-cluster#31, and don't count IP address pages as automatically origin-isolated. Maybe only count pages that explicitly set the header as such.

2. Treat this as part of the overall document.domain deprecation program. So, in Chromium we'd initially not automatically origin-isolate these pages, but we'd add a use counter for how many times such pages set document.domain, and if that use counter is low, we'd separately turn on automatic origin isolation for them.

If we take route (2), there's an open question as to what we should do with the spec in the meantime, while Chromium is testing if this is web-compatible.

Thoughts?

[domenic]

In IRC @annevk points out that this actually is a different type of problem: the spec is broken, and was broken even before merging origin isolation.

Tentatively, we think that site = origin was incorrect for IP addresses. Reasoning: site is used as the agent cluster key, and separate ports on the same IP address need to be in the same agent cluster---precisely because they can reach each other with document.domain.

So probably the right thing to do here is fix "obtain a site" from

If origin's host's registrable domain is null, then return origin.

to

If origin's host's registrable domain is null, then return (origin's scheme, origin's host).

We could then separately investigate going back to "return origin", which is kind of like (2) above, but this emphasizes that the change is orthogonal to the origin isolation feature.

Basically, the origin isolation feature is supposed to just reflect the underlying model; "automatic origin-isolation" was always intended to be a no-op that only affected the return value of window.originIsolated. The web-compat problem noticed here reflects that the underlying model is broken, not that origin isolation introduced a brokenness.

[annevk]

I think there are some more things to consider here.

A scheme-and-registrable-domain is a tuple of a scheme and a domain.

1. It's no longer always a registrable domain.
2. It's not even always a domain.

We should probably rename this to scheme-and-host. I notice that it's exported, but I'm not aware of external usage, are you? Should we even export it?

An agent cluster key is a site or tuple origin whose host's registrable domain is non-null. I.e., an agent cluster key can be a scheme-and-registrable-domain or any origin.

We have to remove the conditional upon tuple origin here. All tuple origins now qualify as they are no longer a part of site, ever. We could also define this as being an origin or scheme-and-host if we don't want the indirection. It might be worth pointing out that unless web developers take action, it'll be a site.

Documents for which obtain a site returns an origin can be considered unconditionally origin-isolated; for them the header has no effect.

We can simplify this to "Documents with an opaque origin ...".