W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 09 Jan 2013 17:16:21 -0500
Message-ID: <50EDEC35.7080209@mit.edu>
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 

> 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.

Received on Wednesday, 9 January 2013 22:16:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:52 UTC