[whatwg] Location object identity and navigation behavior

[Ian Hickson]

On Thu, 8 Nov 2012, Bobby Holley wrote:
>
> The current spec for the Location object doesn't match reality. At the 
> moment, the spec says that Location is a per-Window object that 
> describes the associated Document. However, in our testing, it appears 
> that none of the user-agents (Gecko, WebKit, Trident, Presto) do this 
> [1]. Instead, all implementations of Location describe the active 
> document in the browsing context (that is to say, the referent of the 
> WindowProxy). This suggests that the spec's current language is likely 
> not web-compatible.

Fixed.


> If the Location object describes the browsing context, we're left to 
> consider whether there should be one Location object per Window or one 
> Location object per browsing context. Gecko and Webkit currently do the 
> former, and Trident and Presto do the latter (see again [1]).

It seems IE changed in IE10 and now acts like WebKit.


Arguments for the one-LocationProxy-per-WindowProxy behaviour:

 - it would likely improve Gecko's security story since it would simplify 
   Gecko's security invariants.

 - it's what Opera and old IEs implement (I think?).

Arguments for the one-Location-per-Window behaviour:

 - it would likely improve WebKit's security story since it would simplify
   Webkit's security checks (relative to the other option).

 - it's what WebKit and new IEs implement (I think?).

 - it has the clearer story for authors. Objects that change identity, or 
   that gain or lose properties when a page navigates, are unintuitive.


On Thu, 8 Nov 2012, Boris Zbarsky wrote:
> On 11/8/12 6:09 PM, Adam Barth wrote:
> > 
> > In WebKit at least, it would be a security vulnerability to expose 
> > JavaScript objects that belong to Document B to Document A because 
> > that would give Document A access to the prototype objects for 
> > Document B.
> 
> You presumably have a solution for this situation for the WindowProxy 
> case, right?  Certainly Gecko does, and we would be using the same 
> solution for Location if we tie the lifetime of a Location to the 
> lifetime of a WindowProxy.

This problem exists regardless of whether we have proxies, since the 
Location object is visible cross-origin. Whether we proxy or not is 
orthogonal. The question is just how we should protect the object.


On Fri, 9 Nov 2012, Adam Barth wrote:
> 
> The WindowProxy is a special, magical object because references to it 
> magically change which JavaScript object they refer to over time.  If 
> possible, I would like to avoid infecting other objects with its magic.

I do agree with this. I don't see why we would ever introduce an object 
like this if we can help it.


On Fri, 9 Nov 2012, Bobby Holley wrote:
> 
> Right now, the Location object is the only object whose security 
> characteristics are not guaranteed to match its global, which is a major 
> pain point for us.

The Window object, the Document object, and the Location object, per spec, 
all have exactly the same security characteristics, except that Window and 
Location have certain properties that can be accessed. (This is also quite 
similar to the Storage model, except Storage uses the actual origin, not 
the effective script origin.)


On Fri, 9 Nov 2012, Bobby Holley wrote:
> 
> As noted, the Location object is the only object whose security 
> characteristics don't match its scope. This requires a lot of extra goop 
> in our compartment-based security model, and the goop is brittle 
> (recently forcing us to release two out-of-band updates, 16.0.1 and 
> 16.0.2). We've got enough belt-and-suspenders code now that I'm not 
> particularly worried, but I still want to make Location just like any 
> other object from a security perspective.

I don't think making it one of those proxy objects, of which there's only 
one so far and it's very complicated, is making it "just like any other 
object", but I understand that the Gecko security model does make this 
different than it first appears.


> Also, FWIW, from the perspective of an average web-developer, IMO it 
> makes much more semantic sense to have one Location per WindowProxy if 
> the Location object describes the WindowProxy.

It has some pretty serious implications. It means if you have the object 
in an iframe and install a shim to implement some of Anne's new features, 
your shim will break as soon as you navigate the iframe. That's very odd. 
It also means that the object's "instanceof" characteristic will keep 
changing. Again, very unusual and not something authors normally see.


On Fri, 9 Nov 2012, Boris Zbarsky wrote:
> 
> One thing I'd like is some comment from Opera and Microsoft about what 
> their situation is, since implementing what WebKit does would mean both 
> of those changing.  This is probably the wrong venue to get hold of 
> Microsoft for an official statement, sadly.  :(

Microsoft seems to have already changed, from what I hear of IE10 (I 
unfortunately don't have access to an instance to test for myself).

Input from Opera people would indeed be welcome.


On Fri, 9 Nov 2012, Bobby Holley wrote:
> On Thu, Nov 8, 2012 at 6:09 PM, Adam Barth <w3c at adambarth.com> wrote:
> >
> > == Document A ==
> > <script>
> > Object.prototype.foo = "A1";
> > window.location.bar = "A2";
> >
> > function f() {
> >   var loc = window.location;
> >   print(loc.foo); // print is a magic function that lets me see this value
> >   print(loc.bar);
> > }
> > </script>
> >
> > == Document B ==
> > <script>
> > Object.prototype.foo = "B1";
> > window.location.bar = "B2";
> > </script>
> >
> > 1) Document A is displayed in browsing context X.
> > 2) Browsing context X is navigated and now displays document B.
> > 3) Function f is called.
> >
> > What values are printed?
> 
> Under the proposed behavior, both documents share the same Location 
> object.

Well, the proposal is that there's two Location objects, but 
window.location always returns an object that refers to the active 
document's one, right? Or is the proposal that there really only be one 
instance? If the latter, whose prototype does it have? I don't see how we 
could do the latter really.


> As for loc.foo, our new implementation would give "B1", because the 
> Location object has entirely transplanted into the new Document's scope. 
> This seems sane to me, but it's certainly up for discussion.

I don't think it seems sane from the author's perspective.


For now I've tightened up the spec so it should be implementable, secure, 
and Web-compatible, but it still has a unique instance per Document, not 
the one-object-whose-prototype-keeps-changing model, nor the proxy model 
(it's not entirely clear to me which is being proposed for Gecko).

But more input on this is definitely welcome. I'm in particular curious 
about what authors would find most intuitive, about what Gecko's plans are 
regarding which Location interface object to use for the prototype of the 
Location object instance(s), whether the proposal would enable 
cross-origin shims (or indeed same-origin shims) on Location instances, 
etc. I'm also curious as to why figuring out the "entry script"'s 
characteristics needs to use the stack introspection rather than just 
having an event-loop global "first script" variable, much as the spec 
describes it -- the latter seems safer and more efficient to me. If the 
spec's description can't be implemented, then it's something that should 
be fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'