I read it twice and I don't get it. Can you derive from this text what is supposed to happen to a pointing relationship between two regular JS objects from two different frames?
On Wed, Jul 31, 2013 at 9:51 PM, Brendan Eich <[email protected]> wrote: > Mark S. Miller wrote: > > I don't care about the document objects. What about access between regular > normal JavaScript objects that are now in different origins? > > > 6.2.1 Security > > User agents must throw a > SecurityError<http://www.whatwg.org/specs/web-apps/current-work/#securityerror> > exception whenever any properties of a > Window<http://www.whatwg.org/specs/web-apps/current-work/#window> > 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 Window object's > Document<http://www.whatwg.org/specs/web-apps/current-work/#concept-document-window> > 's effective script > origin<http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin>, > with the following exceptions: > > *Ready for first implementations* > > Tests: 1 — > View...<http://www.whatwg.org/specs/web-apps/current-work/show-tests.html?section=security-2> > > Latest Internet Explorer beta: excellent support > > Latest Firefox trunk nightly build: excellent support > > Latest WebKit or Chromium trunk build: excellent support > > Latest Opera beta or preview build: excellent support > > JavaScript libraries, plugins, etc: excellent support > > - The > location<http://www.whatwg.org/specs/web-apps/current-work/#dom-location> > attribute > - The > postMessage()<http://www.whatwg.org/specs/web-apps/current-work/#dom-window-postmessage> > method > - The window<http://www.whatwg.org/specs/web-apps/current-work/#dom-window> > attribute > - The frames<http://www.whatwg.org/specs/web-apps/current-work/#dom-frames> > attribute > - The self<http://www.whatwg.org/specs/web-apps/current-work/#dom-self> > attribute > - The top <http://www.whatwg.org/specs/web-apps/current-work/#dom-top> > attribute > - The parent<http://www.whatwg.org/specs/web-apps/current-work/#dom-parent> > attribute > - The opener<http://www.whatwg.org/specs/web-apps/current-work/#dom-opener> > attribute > - The > closed<http://www.whatwg.org/specs/web-apps/current-work/#dom-window-closed> > attribute > - The > close()<http://www.whatwg.org/specs/web-apps/current-work/#dom-window-close> > method > - The > blur()<http://www.whatwg.org/specs/web-apps/current-work/#dom-window-blur> > method > - The > focus()<http://www.whatwg.org/specs/web-apps/current-work/#dom-window-focus> > method > - The dynamic nested browsing context > properties<http://www.whatwg.org/specs/web-apps/current-work/#dynamic-nested-browsing-context-properties> > > 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 Window object's > Document<http://www.whatwg.org/specs/web-apps/current-work/#concept-document-window> > 's effective script > origin<http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin>, > the user agent must act as if any changes to that > Window<http://www.whatwg.org/specs/web-apps/current-work/#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/#window> > object had their [[Enumerable]] attribute set to false. > > For members that return objects (including function objects), each distinct > effective script > origin<http://www.whatwg.org/specs/web-apps/current-work/#effective-script-origin> > that is not the same as the > Window<http://www.whatwg.org/specs/web-apps/current-work/#window> > object's > 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> > must be provided with a separate set of objects. These objects must have > the prototype chain appropriate for the script for which the objects are > created (not those that would be appropriate for scripts whose script's > global > object<http://www.whatwg.org/specs/web-apps/current-work/#script%27s-global-object> > is the Window <http://www.whatwg.org/specs/web-apps/current-work/#window> > object in question). > > For instance, if two frames containing > Document<http://www.whatwg.org/specs/web-apps/current-work/#document>s > from different > origins<http://www.whatwg.org/specs/web-apps/current-work/#origin> > access the same > Window<http://www.whatwg.org/specs/web-apps/current-work/#window> > object's > postMessage()<http://www.whatwg.org/specs/web-apps/current-work/#dom-window-postmessage> > method, they will get distinct objects that are not equal. > > > > > /be > > > > On Wed, Jul 31, 2013 at 8:38 PM, Brendan Eich <[email protected]> wrote: > >> 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. >> >> >> /be >> >> >> >> On Wed, Jul 31, 2013 at 7:29 PM, Brendan Eich <[email protected]>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>. 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>. 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 >> >> > > > -- > Cheers, > --MarkM > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
