Realm, schmealm!

Brendan Eich brendan at mozilla.com
Thu Aug 1 10:50:53 PDT 2013


Ian Hickson wrote:
> On Thu, 1 Aug 2013, Boris Zbarsky wrote:
>> On 7/31/13 10:35 PM, Mark S. Miller wrote:
>>> This seems like a bad bug in the html5 spec. Is there any public
>>> discussion explaining why the currently speced behavior should be
>>> considered acceptable?
>> "It's simple and implemented by the majority of UAs" is the main reason
>> as far as I can tell.  Ian is not going to spec something people are
>> unwilling to implement, because that would make the spec pretty
>> useless... and I can definitely understand his position.  The best way
>> to make progress here is to get UAs fixed.
>
> Pretty much.
>
> Personally I'd like to drop document.domain entirely, but that's not going
> to fly any time soon.

Yeah, let's not waste time on things that won't fly.

> Also, note that the Gecko approach to this isn't the only way to approach
> this defense-in-depth problem. Another way would be to do process
> isolation at the browsing context level (i.e. make it possible for iframes
> to be in their own process), and then have one process per group of
> similar-origin browsing contexts.

This isn't different in principle from what we do in Gecko -- we want 
stronger isolation and the option to remote across processes (as IE 
apparently does).

>   That actually gets you closer to what
> the spec says (closer to the legacy model) than the Gecko approach,

How so? Can you give an example where Gecko doesn't do what the spec says?

>   while
> still having a pretty solid defense against accidental leakage of
> cross-origin objects (arguably a stronger model, since you can actually
> prevent the entire process from having access to the data of other origins
> at the OS level, rather than just enforcing it at the JS level).

Yes, process isolation is good. But even membrane mediated same-process 
is pretty darn good.

How about the non-enumerable thing? That doesn't really protect anything 
in ES5 era, and as Allen says it doesn't protect against guessed-name 
probing.

/be



More information about the es-discuss mailing list