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
> 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?
> 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
More information about the es-discuss