On Fri, Oct 16, 2015 at 10:45 PM, Bobby Holley <bhol...@mozilla.com> wrote: > On Fri, Oct 16, 2015 at 12:58 PM, Anne van Kesteren <ann...@annevk.nl> > wrote: >> Hmm. One problem with the proposed design (assuming we're not defining >> compartments in the specification) is that it overrides === which TC39 >> would not be happy with. Not having to do that would be preferable I >> think. === works fine for Window since there's WindowProxy. It seems >> like Location would need something similar. > > It may, at least conceptually, but I'm kind of loathe to do that just for > document.domain. > > Basically, the one piece of magical behavior here is that, when Document a > grabs a reference |x| to cross-origin Document b's location, and then both > Documents become same-origin via Document.domain, |x| suddenly points to the > now-accessible b.location. Furthermore, any method pulled off of |x| before > a given change in document.domain retains its distinct identity. > > This is all nasty and document.domain-specific, so it really sucks to > complicate the spec model further on its account. But maybe it can't be > helped.
It does seem that if we are to specify Location in terms of ECMAScript and, as you said elsewhere, the separate cross-origin objects are not actually observable since [[Set]] throws, we could maybe get away with a simpler model. Where the internal methods of the object simply branch on same-origin vs cross-origin and then do the right thing. E.g., [[GetPrototypeOf]] would return null when cross-origin, but would return the Location prototype object when same-origin. And since Location is marked [Unforgeable] it doesn't even have much of a prototype object to speak of. Everything interesting are own properties. I realize this does not match what Adam Barth wanted, but it does seem to preserve the invariants from the Etherpad while also resulting in a sane specification that adheres to the invariants valued by ECMAScript/TC39. And since it should have the same observable outcome (unless I missed something, which I might well have) in terms of tests and behavior, everyone can still keep their respective implementation strategies. (document.domain revoking access remains unaddressed, but personally I have a hard time seeing that as a important security hole.) -- https://annevankesteren.nl/