W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [XHR] Constructor behavior seems to be underdefined

From: Simon Pieters <simonp@opera.com>
Date: Mon, 02 Apr 2012 08:50:28 +0200
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: "Cameron McCormack" <cam@mcc.id.au>, public-webapps@w3.org, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <op.wb4laetdidj3kv@simons-macbook-pro.local>
On Mon, 02 Apr 2012 07:50:21 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 4/2/12 1:33 AM, Simon Pieters wrote:
>>> Yes, but what do they use for the origin of the Worker object itself?
>> "Run a worker for the resulting absolute URL, with the script's browsing
>> context of the script that invoked the method as the owner browsing
>> context, with the script's document of the script that invoked the
>> method as the owner document, with the origin of the entry script as the
>> owner origin, and with worker global scope as the global scope."
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-worker
>> Well, that's origin for the worker *script*.
> Yes, that's not the same thing.
>> The Worker *object* doesn't have an origin, I think.
> Well, what controls which scripts can touch the Worker object?  That  
> should be controlled by the origin of the window or document it's  
> associated with, but the spec doesn't define what that is.
>>> I.e. if you create one and then one of the documents involved has
>>> .domain set on it, what happens?
>> The document's effective script origin changes. The origin doesn't.
> Sure.
>> Workers use origin, not effective script origin, so setting
>> document.domain should have no effect on workers even if you set it
>> before creating the worker.
> I think you're missing my point.
> Say I have two documents d1 and d2, in windows w1 and w2 respectively.  
> These are same-effective-origin (whether because they started that way  
> or because both set document.origin to the same thing doesn't matter).  
> Assume script in w1 has a reference to w2 (e.g. w2 is in a subframe).
> Script running in w1 does:
>    var worker = new w2.Worker(some_url);
> Then script in w2 changes d2.origin, which changes the effective origin  
> of w2 and d2.  What happens to script that runs later on in w1 and tries  
> to call a method on |worker|?
> For comparison, if Worker is replaced with Image in the above scenario,  
> the correct answer is "a security exception is thrown" because for  
> purposes of touching the image object itself what matters is whether the  
> effective origin of the script that's running matches the effective  
> origin of the image's ownerDocument.  Not that the spec actually says  
> this anywhere that I can tell...
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0
>> has rules for specific things.
> Yes, that's talking about a different thing entirely (e.g. for images  
> this defines an origin for the image _data_, not for the image object  
> itself; the two can obviously differ when the image load is not  
> same-origin with the page the <img> tag is in).
> Perhaps the spec terminology for the thing I'm after here is "effective  
> script origin"?  That seems to be what it uses for Document.  But maybe  
> it only does that so it can define it for scripts by reference to the  
> document that loaded them?
> In any case, the concept I'm after is "the thing that determines whether  
> script at a particular effective script origin can touch your  
> properties".  The spec (_some_ spec, at least) needs to define the value  
> of this concept for all objects.  The simplest thing is to piggyback on  
> the existing "all objects are associated with some global" bit in WebIDL  
> and say that for a given object this concept has the same value as the  
> global it's associated with (which is what Gecko, say, does in  
> practice).  But then you have to define what the value of this concept  
> is for globals (for Windows it would be the effective script origin of  
> the .document, I believe) and which global each object is associated  
> with (the point of this thread).
> -Boris
> -Boris

Ah, I see what you're saying.

I can find:

"User agents must throw a SecurityError exception whenever any properties  
of a Document object are accessed by scripts whose effective script origin  
is not the same as the Document's effective script origin."

and window has some rules involving effective script origin.


I don't know how well this matches reality though.

It seems the spec forbids access to iframe.contentWindow.document but  
allows iframe.contentDocument.

Simon Pieters
Opera Software
Received on Monday, 2 April 2012 06:51:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC