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 10:16:41 -0500
Message-ID: <50ED89D9.7010103@mit.edu>
To: Adam Barth <w3c@adambarth.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
On 1/9/13 3:11 AM, Adam Barth wrote:
> I'm not convinced of that.  I understand that Gecko need to deal with
> these complications because of a number of Mozilla-proprietary APIs,

Actually, what I'm talking about here has nothing to do with APIs but 
everything to do with wanting to write web applications that have 
slightly more privileges than your typical web page.  Again, you may 
want to talk to Jonas and Mounir for details.

> If and when features are added to
> the platform that cause these sorts of problems, we can deal with the
> consequences.

My argument is that we should not lock ourselves out of adding such 
features in the future.

> In the mean time, I don't think we should force other
> browser engines to implement a more complicated security model than
> necessary for the platform as it stands.

I'm not saying we should force anyone to implement any particular 
security model.

I'm saying we shouldn't design/spec things that become completely 
insecure if the security model ever changes in any way and hence prevent 
evolution of the security model.  Which means that we should assume as 
little as possible about what the security model guarantees us when 
specifying things.  In my opinion.

> This paragraph was too abstract for me to understand.  Do you have a
> concrete example?

For example, Ian's argument is that you can skip security checks in 
various places because the security model does that already.

My counter-argument is that we should define the behavior of those 
places by referencing the security model explicitly, so that if the 
security model changes we won't have to hunt down all the places that 
had implicit dependencies on it.

Does that make more sense?

>> Put another way, I think we have good evidence that the security model in
>> the spec, as well as that in every browser, Gecko included, is wrong in the
>> same sense that Newtonian mechanics is wrong.  The problem is that we don't
>> know what our equivalent of special relativity is yet.
>
> I don't understand the analogy.

The current security model describes most common cases, but not some 
edge cases (see above about a slightly-elevated-privileges web app that 
can, say, touch nodes from one and only one different origin).

> More seriously, life gets complicated when you introduce an asymmetric
> access relation

I agree.  I believe, however, that for many apps based on web technology 
you in fact might need this.  Again, Sicking and Mounir would know more. 
  https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the 
things in it, but I'm not sure it's all of them.

> However, the open web platform contains only a symmetric access relation

Yes, I understand that's how it stands now.  I'm questioning the 
viability of this going forward, and especially questioning to what 
extent we should be intentionally making it impossible to change away 
from this model.

> and I intent to argue against any attempt to introduce an asymmetric access

That is, of course, your right.  ;)

> Maybe I've lost the thread here, but I don't understand the problem
> you're trying to solve with this thread.  The simplest solution is for
> contentDocument to return null when accessed from a different origin.

That's not enough.  Window has the same problem: the "document" IDL 
getter needs to check that you're allowed to get the document of the 
relevant window, for example.

Is the check you describe for contentDocument based on origin or 
effective script origin?

-Boris
Received on Wednesday, 9 January 2013 15:17:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT