domenic at domenicdenicola.com (2013-08-12T02:43:00.149Z)
Mark S. Miller wrote: > But does the html5 spec say anything about what is supposed to happen? Sure: > 3.1.2 Security > > *Ready for first implementations* > > User agents must throw a [SecurityError](http://www.whatwg.org/specs/web-apps/current-work/#securityerror) exception whenever any properties of a [Document](http://www.whatwg.org/specs/web-apps/current-work/#document) object are accessed when the [incumbent script](http://www.whatwg.org/specs/web-apps/current-work/#incumbent-script) has an [effective script origin](http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin) that is not the [same](http://www.whatwg.org/specs/web-apps/current-work/#same-origin) as the [Document](http://www.whatwg.org/specs/web-apps/current-work/#document)'s [effective script origin](http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin). > > *Ready for first implementations* > > Latest Internet Explorer beta: buggy support > > Latest Firefox trunk nightly build: buggy support > > Latest WebKit or Chromium trunk build: buggy support > > Latest Opera beta or preview build: buggy support > > JavaScript libraries, plugins, etc: unknown > > 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.
Mark S. Miller wrote: > But does the html5 spec say anything about what is supposed to happen? Sure: 3.1.2Security *Ready for first implementations* User agents must throw a|SecurityError <http://www.whatwg.org/specs/web-apps/current-work/#securityerror>|exception whenever any properties of a|Document <http://www.whatwg.org/specs/web-apps/current-work/#document>|object are accessed when theincumbent script <http://www.whatwg.org/specs/web-apps/current-work/#incumbent-script>has aneffective script origin <http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin>that is not thesame <http://www.whatwg.org/specs/web-apps/current-work/#same-origin>as the|Document <http://www.whatwg.org/specs/web-apps/current-work/#document>|'seffective script origin <http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin>. *Ready for first implementations* Latest Internet Explorer beta: buggy support Latest Firefox trunk nightly build: buggy support Latest WebKit or Chromium trunk build: buggy support Latest Opera beta or preview build: buggy support JavaScript libraries, plugins, etc: unknown When theincumbent script <http://www.whatwg.org/specs/web-apps/current-work/#incumbent-script>'seffective 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'seffective script origin <http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin>, the user agent must act as ifall the properties of that|Document <http://www.whatwg.org/specs/web-apps/current-work/#document>|object had their [[Enumerable]] attribute set to false. /be > > > On Wed, Jul 31, 2013 at 7:29 PM, Brendan Eich <brendan at mozilla.com > <mailto:brendan at mozilla.com>> wrote: > > Mark S. Miller wrote: > > > That's not the hard problem relevant to the current question. > Given two frames both starting at foo.bar.com > <http://foo.bar.com> <http://foo.bar.com>. While they're both > there, their object graphs become arbitrarily entangled, which > is as it should be. Then, one of them truncates to bar.com > <http://bar.com> <http://bar.com>. Now they are separate > origin iframes. What happens to their inter-frame pointers, > which are now cross-origin pointers? In a membraneless > browser, how are the newly-cross-origin pointers even > distinguished from the same-origin pointers? > > > The answer in pre-membrane Firefox was badly: a reference monitor > would walk the DOM "parent" link (not parentNode) and try to find > the right global object, from whose document to get an effective > script origin (essentially). > > The problem there was performance. I don't know of fast but > incorrect implementations that allowed access where they should > not have, but I am old and forgetful (relatively speaking; still > have a memory like an elephant :-P). > > Cc'ing Boris in case he knows more. > > /be > > > > > -- > Cheers, > --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/0e0b2d2f/attachment-0001.html>