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

[Boris Zbarsky]

On 1/8/13 2:09 AM, Ian Hickson wrote:
> In the spec's security model, origins are never relevant for elements
> except when we're looking at the element's data.

Yes.  I think the spec's security model is not viable long-term, for 
what it's worth, and think we should be designing a security model that 
is instead...  But that's a separate discussion.

>> Is that actually needed?  There are properties you can obtain on objects
>> cross-origin (like window.top) that I see no need to allow via this
>> backdoor since no content depends on it now.  So I would prefer simply
>> checking whether the origin of the caller matches the origin of "this".
>
> Well right now "this" doesn't necessarily have an origin.

Yes, but that's a fixable problem.

> Also, consider Location. If you have a Location object and then navigate its browsing
> context and then call something on it, you need to check that the calling
> script doesn't match the origin of the new active document, not the origin
> of the Location object's Window's Document.

I'm not touching Location with a 10-foot pole.  That's all Bobby.  ;) 
Seriously, though, fitting Location into any sort of security setup is 
somewhat hard.

> Doing a check on _every_ call seems rather expensive for implementations
> that don't use Gecko's security model compared to only doing a check on
> those interfaces that matter.

Clearly I think Gecko's security model is the right one.  ;)

Seriously, though, I'm very much unconvinced by the spec's security 
model.  But you already knew that.

> A Location object has multiple prototypes (one for each origin that
> accesses it).

That's a pretty new development, no?  In any case, I agree that 
specifically for Location (and perhaps Window) there needs to be weirdness.

> For Storage, the access check has to be the actual origin of the Document,
> not the effective script origin as it does for Window and Document.

That's a separate check from whether you can even touch the object, no? 
  Certainly that's how it works in Gecko: first there is a generic check 
for whether you can touch the object at all, then for Storage a second 
check.

Note that this situation is similar to data origins for images and 
whatnot: those are also checked against origins, not effective script 
origins.  I don't see the problem here.

> Assuming the script's effective script origin is not the same as the
> crossOriginDoc's effective script origin, it doesn't matter _what_
> myGetter points to. It should always throw, either TypeError (or some
> such) if myGetter points to something that's not on Document somehow, or
> SecurityError, if myGetter points to something that _is_ on Document.

Well, or TypeError in both cases, yes.  But OK, we agree on this, good.  :)

-Boris