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
