Remove the risk of document.domain.

[mikewest]

Based on discussion in the F2F, we'd like to prevent secure contexts from pretending to be an origin other than it's actual origin. To that end, we'd like to try to:

1. Make document.domain and [SecureContext] mutually exclusive: touching one makes the other throw.
2. document.domain will throw for a Service Worker-controlled document.
3. We should measure document.domain usage for TLS-delivered pages to see if we can drop it.

[annevk]

Copying @bholley since he's been wanting to do something like this.

[bholley]

This sounds great! Years ago Hixie, abarth and I agreed on a theoretical goal of eventually deprecating document.domain, and this sounds like a great way to make some meaningful progress in that direction.

[mikewest]

So, @hillbrad let me know that document.domain is a required portion of Facebook's SDK at the moment. That, plus the sincerely high usage makes it tough for this to be a requirement. I've put it in as optional, and I hope Chrome/Firefox, et al. can help developers migrate away from this API by ratcheting down enforcement over time.

[annevk]

That seems like a rather terrible cop out. We shouldn't have optional features like that if they cannot actually be implemented.

[mikewest]

I disagree. The spec shows the future direction we'd like to take things, and gives browsers the freedom to experiment in the same way that the mixed content spec says something like "Browser, you can totally block all mixed content if you feel like it, and we'll revise the spec based upon the way things go."

[annevk]

Okay. Still disappointed, but more in Facebook I guess.

[annevk]

So couldn't we still do this for new features that Facebook has not yet adopted or have not been implemented yet? Or do we want to effectively endorse their development practices?

[bholley]

@hillbrad Can you elaborate on why Facebook needs document.domain here, and how feasible it is to move to something better?

[hillbrad]

I'm not arguing to remove it from the roadmap. I'd like to get rid of it,
too. Facebook has been doing cross-frame communication between different
subdomains for a long time and postMessage, the most logical replacement
for our usage, wasn't supported until IE8 and Safari 4. (and we also
support a long tail of crazy, old and low-feature browsers with users in
the millions that don't show up on caniuse)

So basically, this is old code, it works, and there's simply been very
little reason to invest in reworking it. Priorities. Knowing it will no
longer play nice with other valuable APIs will change those priorities; I
just hope it doesn't happen, say, next week. It would definitely break
Facebook and that would make me sad.

-Brad

On Tue, Feb 9, 2016 at 12:29 PM Bobby Holley [email protected]
wrote:

@hillbrad https://github.com/hillbrad Can you elaborate on why Facebook
needs document.domain here, and how feasible it is to move to something
better?

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[bholley]

Ok. Presumably the browsers that can't do postMessage also can't use any of the new features we're talking about gating here. So it seems fine to let them continue using document.domain, and add a postMessage path to take advantage of the newer stuff.

I think we should do this in the near-term, before any other big sites start using these new features in tandem with document.domain. I think this is pretty important to do, and Jochen agreed last we spoke.

I'm guessing Facebook can fix their stuff faster than browser vendors anyway, but I'm happy to delay until some explicit date as long as we get a clear timeline.

[annevk]

We should just identify some features and start doing it for those, e.g., https://storage.spec.whatwg.org/ is not deployed yet. That could be our guinea pig.

[mikewest]

Hrm. shrug I can get behind doing this for new features. I don't see a clear way to do so without forking the definition of "secure context", however, which I'd prefer to avoid doing.

That is, Chrome is busy tying old APIs to secure contexts. Geolocation, Appcache, getUserMedia, etc. I worry about retroactively pulling the rug out from under developers (again), which is why the usage of document.domain continues to worry me in terms of actual deprecation.

I'll add some metrics to Chrome to see how much of the document.domain usage would block otherwise secure contexts from being considered secure in a way that would impact these APIs. Perhaps y'all could do the same for Firefox? :)

[annevk]

It would be acceptable to me to have "secure context" and "deprecates document.domain" as orthogonal bits.

I'm a little bit skeptical about using "secure context" for legacy APIs if the plan for JavaScript/IDL is still to not expose those APIs from insecure contexts. So if that is the plan I think there too we might have orthogonal bits.

[annevk]

I'm willing to setup some specification infrastructure for a "deprecates document.domain" handle new methods could use. We could even use it for new methods we'd expose outside of secure contexts.

[hillbrad]

+1 to starting with new APIs if possible. Provides a good incentive to
move away but doesn't set a "break the web" ticking clock.

[bholley]

Sure. Once we have a spec model and buy-in from other vendors, I'm happy to add the infrastructure to implement this on the Gecko side.

[annevk]

So the way to do this is to set a flag if document.domain is set and to set a flag if the "new thing" is used and have both sides check whether the opposite flag is set before they're allowed to be used. However, what should be the scope of these flags. Is just document enough?

[bholley]

s/the "new thing"/any "new thing"/, but yes. Putting it on the document should be fine.

[annevk]

The main problem I see that this would still make it easy to circumvent this e.g., by using an <iframe srcdoc> that implements a postMessage() protocol and use the feature from there. And e.g., with persistent storage would we also disable document.domain if the permission was ever granted? Probably not as then one part of a site could have nasty side effects for another. Maybe just document for now is good enough. Gets complicated fast otherwise.

[jwatt]

The way that the spec is currently written, if implementations act on the document.domain "MAY" section they would need to iterate through the entire descendant-and-auxiliary browser context graph, updating the secure context status of all history entries for all of those browser contexts. Walking the descendant browser context graph is doable, but if implementations don't keep a list of a Window's auxiliary browser contexts that's a bit more annoying to implement.

Conversely, if [SecureContext] API is used, implementations would need to walk the ancestor-and-opener browser context graph marking document.domain as throwing. Any given Document in a popup may have multiple documents that can access it and implementations may well only keep track of one of those as the document's opener and not currently have access to the others.

Given the above, regardless of whether we split out document.domain status into a new attribute separate from [SecureContext], I'd be quite keen to stop taking account of document.domain changes outside top level browsing contexts (i.e. not follow the openers). Whether this attribute should only pay attention to document.domain changes to the current document I'm less sure about.

Given the desire to restrict document.domain use with both shipped and not yet shipped API, I'd definitely be in favor of creating a new attribute separate from [SecureContext]. That avoids conflating unrelated concepts into [SecureContext] and gives us more flexibility to maximize the number of APIs we can ban from use with document.domain changes.

[bholley]

I'm generally happy to 80/20 this one. People are using document.domain out of laziness, so they're unlikely to try too hard to work around whatever we put in place if doing so involves opening popups and restructuring the frame hierarchy.

I think we should prevent simple subframe tricks if we can, but not worry about much else.

[annevk]

whatwg/html#829 has a concrete proposal for how we could do this. It uses the furthest same-origin browsing context as keeper of state for document.domain and new features. Curious to hear what everyone thinks.

[jwatt]

I think we can close this issue and continue any discussion in whatwg/html#829

[mikewest]

Yeah. This won't be in Secure Contexts.