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

[Adam Barth]

It seems like your arguments all originate from wanting to support an
asymmetric access relation.  Supporting an asymmetric access relation
is a bad idea, and we shouldn't do it.

I understand that Mozilla already has technology for implementing an
asymmetric access relation and that you're using it to implement a
number of current and future Mozilla-proprietary features.  That's
fine, of course, but if you're interested in having those features
become part of the web platform, please don't be surprised when other
browser vendors refuse to implement them because of their asymmetric
access relation.

As a consequence, I would recommend that you do not use asymmetric
access relations in features that you would like other browser vendors
to implement in the future.

Adam


On Wed, Jan 9, 2013 at 7:16 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 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