On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak <m...@apple.com> wrote: > On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote: >> On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak <m...@apple.com> wrote: >>> 1) It means the access control goes in fewer places - we don't have to have >>> access control on every document property, only window properties. >> >> I'm not quite sure I understand this. At least for the location >> object, I see an explicit check in JSLocationCustom.cpp: >> http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L71. >> Throwing the exception would happen there too (it won't require custom >> getters for each property). > > Yes, a small handful of objects that hang off of Window are accessible > cross-origin and have their own security checks. However, one property of > Window is handled very differently between WebKit-based browsers and what the > spec calls for. someCrossOriginWindow.document returns undefined in > WebKit-based browsers, but it returns a document object per the spec which > then does its own security check on every property access. This is > unfortunate because the attack surface is increased and performance suffers. > And it's not Web-compatible to just throw on access to the document property > - Web apps expect they can always ask for the document, and it's the *next* > property access that throws, which is fulfilled by returning undefined since > accessing a property of the undefined value throws in JS. For cases like the > location object, it doesn't matter much either way.
I believe the spec no longer exposes someCrossOriginWindow.document. (As to whether it throws a security exception or returns null, I'd have to look more carefully.) Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
