The way we plan to implement this in Gecko, conceptually, is that we always check that the thisobj is same-origin with us except for a whitelist of properties and methods that we plan to annotate as not needing such a check in the IDL.

This does happen precisely during the step you cite, when we're checking that the thisobj is of the right type.

I'll add a step that does the same thing as the first paragraph of http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#security-document.

HTML currently only defines effective script origin for Document objects and a handful of other things.  What's the right way to get the effective script origin for some random other platform object?

For what it's worth, in Gecko the effective script origin of an object is the effective script origin of its associated global.

And every object has an associated global: that's needed to set up its initial prototype chain properly...  Note that in some cases (e.g. adoptNode) the associated global can effectively change.

OK.  Is there ever a case when the global doesn't have a corresponding Document?  Can I just follow the chain of

  object -> "associated global environment" [WEBIDL] ->
            WindowProxy object that is the global [HTML] ->
            browsing context for that WindowProxy [HTML] ->
            active document for that browsing context [HTML] ->
            effective script origin for that document [HTML]

?  Maybe there is something simpler.

> Is there ever a case when the global doesn't have a corresponding Document?  

Workers?  I suspect in practice in cases when origins can mix the answer is no.  But it shouldn't matter, because...

> Can I just follow the chain of

No, once you've landed at the browsing context you lose.  In particular, I should not be able to get my hands on a cross-origin object, then navigate the browsing context its global is associated with to some page I'm same-origin with and then access the object!

Luckily, that's not needed: we just need to define the origins of globals and be done with it.

>            WindowProxy object that is the global [HTML] ->

The global is a Window, not a WindowProxy.

(In reply to comment #5)
> Luckily, that's not needed: we just need to define the origins of globals
> and be done with it.

Assigning to Ian to do this bit.  Please give the bug back to me once you've done that.

I don't think this should apply to every object (note: bz contends otherwise, understandably, because doing it everywhere is good defense in depth — but currently, only Gecko does it everywhere, and unless the other browser vendors are willing to change their security model to check this on every operation, I'd rather not require it, since then we wouldn't match the majority of reality).

Also, note that it's not all properties that are blocked; Window and Location in particular allow some but disallow others.

I think the way to do this that most closely matches what most browsers do would be to have a hook in the algorithms for methods, getters, and setters, that checks if this particular object is a "secured object", and if it is, invokes some hook that returns "ok" or "fail". Then, in HTML, I define the hook as being what the spec says now for properties on these objects (Window, and Location, primarily, but also Document - always "fail" if the origin is different - and Storage).

(reassigning to get it back on heycam's radar so he can consider comment 7)

OK, I've added a term "perform a security check" that takes as input the platform object you're using, and the ECMAScript global environment associated with the Function object that you're calling (be it for an operation, attribute getter/setter, etc.).  Let me know if you need something different.

I didn't add a "secure object" term; I figure you can do that check yourself in your "perform a security check" definition.

http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.650;r2=1.651;f=h
http://dev.w3.org/cvsweb/2006/webapi/WebIDL/v1.xml.diff?r1=1.90;r2=1.91;f=h

http://dev.w3.org/2006/webapi/WebIDL/#es-security
http://dev.w3.org/2006/webapi/WebIDL/#dfn-perform-a-security-check
http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute-getter etc.

Sounds good. I'm taking this back to do my side.

I guess I have to have a single "perform a security check" algorithm that then defers to interface-specific algorithms if they exist, and is a noop otherwise.

What am I supposed to return? Or am I just supposed to throw if it fails, and do nothing if it passes? It doesn't look like you check the return value or handle exceptions (e.g. by aborting the calling algorithm) from this, but maybe I'm missing some general rule for interpreting WebIDL algorithms.

(In reply to comment #10)
> What am I supposed to return? Or am I just supposed to throw if it fails,
> and do nothing if it passes? It doesn't look like you check the return value
> or handle exceptions (e.g. by aborting the calling algorithm) from this, but
> maybe I'm missing some general rule for interpreting WebIDL algorithms.

I documented my expectations of what you would do in the "perform a security check" algorithm here:

  http://dev.w3.org/2006/webapi/WebIDL/#dfn-perform-a-security-check

:)

So yes, throw an exception (SecurityError I suppose?) or return normally.  Web IDL algorithms propagate exceptions unless explicitly caught.

Ah, in the non-normative note. Ok. :-) I usually ignore those. :-)

The section Implement IDL's "perform a security check" of https://github.com/annevk/html-cross-origin-objects#implement attempts to solve this.

The only remaining issue is Window vs WindowProxy. I'm not entirely sure how to resolve that. bz, heycam, ideas?

*** Bug 27212 has been marked as a duplicate of this bug. ***

IDL needs to have a concept of WindowProxy, which it doesn't right now.  There's some rambling but relevant discussion in bug 27128.

The right behavior, imo, is for methods/getters/setters that expect a Window or some interface Window inherits from (in practice just EventTarget) to extract the underlying Window from a WindowProxy "this" before performing the security check bits.

Okay, I think it would be best then if Window got the new internal slots, [[crossOriginProperties]] and [[crossOriginPropertyDescriptorMap]], rather than WindowProxy.

Would that do the right thing in the face of navigations?  In particular, when navigation happens, what should happen to those slots?

I'm not sure what the right behavior is. I wish I was a little more confident, but I'm mostly still struggling with the material here.

For crossOriginProperties it seems problematic since the active document changes which means that certain named properties need to change too ("the browsing context name of any child browsing context of the active document whose name is not the empty string"). Not sure about the map.

Would it be better to store this on Document, along with all the other "global" state we store there?

That depends on what the behavior should be across document.open() and navigations from initial about:blank to a same-origin document, right?

Please talk to bholley about what needs to happen with the map and crossOriginProperties on navigation; I don't really have that paged in right now.  :(

Bobby, see comment 13 onwards.

(In reply to Anne from comment #18)
> I'm not sure what the right behavior is. I wish I was a little more
> confident, but I'm mostly still struggling with the material here.

Yeah it's pretty hard to keep all the bits in your head at once :-(
 
> For crossOriginProperties it seems problematic since the active document
> changes which means that certain named properties need to change too ("the
> browsing context name of any child browsing context of the active document
> whose name is not the empty string").

Documents can modify this state of affairs all the time by creating and removing iframes, so that stuff needs to by dynamic in any case. So I think we can't store it in a slot. Watch out for https://code.google.com/p/chromium/issues/detail?id=237022 though.

> Not sure about the map.

See below.

(In reply to Boris Zbarsky from comment #19)
> That depends on what the behavior should be across document.open() and
> navigations from initial about:blank to a same-origin document, right?

Precisely. This is the only situation where it matters whether we store something on the document vs on the window.

> Please talk to bholley about what needs to happen with the map and
> crossOriginProperties on navigation; I don't really have that paged in right
> now.  :(

The map of property descriptors describes the descriptors that have been returned for the given ES Window and Location objects, which are per-global and thus per-Window. So this needs to live on the Window, I think.

https://github.com/whatwg/html/pull/638