W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

Re: [whatwg] Location object identity and navigation behavior

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 20 Nov 2012 13:50:59 -0500
Message-ID: <50ABD113.1010901@mit.edu>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Johnny Stenback <jst@mozilla.com>, Bobby Holley <bobbyholley@gmail.com>, Adam Barth <w3c@adambarth.com>
On 11/20/12 12:46 PM, Ian Hickson wrote:
> Given the way JavaScript works, I just don't see a sane way to make a
> non-symmetric model work.

How does "JavaScript work" in your mind?  We have a good amount of 
experience making a non-symmetric model work in Gecko, for what it's worth.

> Any time you pass a string from one to the other, you're also passing a way for the
> callee to call back into the caller, for example (via the string's
> methods).

Spidermonkey effectively copies strings when passing across globals; the 
callee never gets the caller's actual string.  The methods the callee 
sees on strings are its own methods, not the callers.

> Passing any sort of structured objects similarly means passing
> mehods.

In the case of Gecko, what the caller gets in this case is a proxy for 
the actual object which enforces security invariants like "only 
properties on a whitelist are exposed" for cases when the security check 
is asymmetric.  This is handled completely on the underlying JS 
implementation level; individual callers don't have to do anything 
special to be safe this way.

> We have mechanisms for safe passing of data from one context to another,
> such as postMessage(). Doing it by having one-way glass in JS just seems
> like asking for trouble.

postMessage doesn't work unless both sides are cooperating...

> Yeah, like running getters with the ability to abort them if they don't
> return promptly.

Perhaps, yes.  ;)  I agree that debuggers have all sorts of weird going 
on, obviously!

> But your underlying point, that we can't rely on the entry script and the
> real origin, is sound. In particular, anything that's to be affected by
> document.domain has to use the calling script, not the entry script, and
> has to use the effective origin, not the real origin. It would be useful
> if someone (other than me) were to review the spec's uses of the term
> "entry script" and "origin" and verify that the checks all make sense.

I'll see what I can do about finding someone for this.  Might be a few 
weeks given holidays and whatnot, obviously.

I'll let Bobby handle the Location parts of this.  ;)

Received on Tuesday, 20 November 2012 21:24:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:48 UTC