Ian Hickson wrote:
> On Thu, 1 Aug 2013, Brendan Eich wrote:
>>> 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?
>
> The difference between the model I described and the Gecko model is that
> the isolation is amongst groups of similar-origin browsing contexts, so
> document.domain doesn't cause a problem. That is, two sibling iframes at
> http://victim.example.com:80 and http://hostile.example.com:81 would be in
> the same process, not isolated from each other. It's essentially the model
> described in the spec, implemented with Gecko-style defense-in-depth.

So object refs not linked through window or document do get revoked on 
domain change, or do not?

>> 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.
>
> I'm not sure what this refers to. Can you elaborate?

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window

"""
When theincumbent script 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#incumbent-script>'seffective 
script origin 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#effective-script-origin>is 
different than a|Window|object's|Document| 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#concept-document-window>'seffective 
script origin 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#effective-script-origin>, 
the user agent must act as if any changes to that|Window 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#window>|object's 
properties, getters, setters, etc, were not present, and as if all the 
properties of that|Window 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#window>|object 
had their [[Enumerable]] attribute set to false.
"""

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130801/fa045f20/attachment.html>

Ian Hickson wrote:
> On Thu, 1 Aug 2013, Brendan Eich wrote:
>>> 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?
>
> The difference between the model I described and the Gecko model is that
> the isolation is amongst groups of similar-origin browsing contexts, so
> document.domain doesn't cause a problem. That is, two sibling iframes at
> http://victim.example.com:80 and http://hostile.example.com:81 would be in
> the same process, not isolated from each other. It's essentially the model
> described in the spec, implemented with Gecko-style defense-in-depth.

So object refs not linked through window or document do get revoked on 
domain change, or do not?

>> 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.
>
> I'm not sure what this refers to. Can you elaborate?

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window

> When the [incumbent script](http://www.whatwg.org/specs/web-apps/current-work/#incumbent-script)'s [effective script origin](http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin) is different than a [Document](http://www.whatwg.org/specs/web-apps/current-work/#document) object's [effective script origin](http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin), the user agent must act as if all the properties of that [Document](http://www.whatwg.org/specs/web-apps/current-work/#document) object had their [[Enumerable]] attribute set to false.