- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 09 Jan 2013 17:16:21 -0500
- To: Adam Barth <w3c@adambarth.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
On 1/9/13 4:12 PM, Adam Barth wrote:
>> window.addEventListener.call(otherWindow, "click", function() {});
>
> This example does not appear to throw an exception in Chrome. It
> appears to just returns undefined without doing anything (except
> logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this
into silent no-ops returning undefined is ok, but throwing an exception
seems like a much better idea to me if you're going to completely not do
what you were asked to do... The other option introduces hard-to-debug
bugs.
> Yes, but this example is unrelated to the example you started this
> thread with.
How so? The example was that IDL methods need to do security checks on
their arguments in various cases.
> The WindowProxy and Location objects are special,
> magical objects that work differently from other interfaces because
> they are visible across origins.
However you prefer to think of it.
> The Document interface (which is
> what we started this thread discussing) is never visible across
> origins
It is in the current spec.
> The WindowProxy object is even more complex than the Location object.
It's actually simpler, in the aspects that matter for WebIDL security,
because underlying it is an actual Window object that you're same-origin
with or not, and you can just do security checks on it as needed. And
since the WebIDL is defined to work on the Window, it has to be able to
get to the Window from the WindowProxy anyway.
-Boris
Received on Wednesday, 9 January 2013 22:16:46 UTC