Re: ACTION-146, propose spec text for Workers

I mentioned this to Jonas Sicking, one of the developers worked on 
Firefox's Shared Workers implementation, and he mentioned these 
important differences between iframes and Workers that are worth 
considering:

* Workers can link to resources with any mimetype. Iframes can just
link to resources explicitly served as text/html.
* Workers are always same-origin. Iframes can be any origin.
* While workers can't directly read content from the webpage, they can
perform XHR requests to the server, read locally stored data
(including cookies and IDB in the future) and probably in the future
take actions like access geolocation API using the principal of the
opening page.

The last point in particular makes me think that Workers might be closer 
to the "script-src" attack model after all.

On 11/19/2013 12:58 PM, Daniel Veditz wrote:
> On 11/19/2013 11:30 AM, Hill, Brad wrote:
>> Actually, as I think more about it, perhaps workers should be
>> properly be controlled by frame-src, not script-src.  After all,
>> they're a distinct child browsing context.  We already find we need
>> to special-case srcdoc, data:, etc. there, and could apply the same
>> treatment to Workers.
>
> I could go for that. It makes a decision to use the CSP in the worker
> script's headers seem a lot less odd.
>
> What do we break if we change things now? Any Worker-using site that had
> frame-src 'none' instead of 'self' or something broader.
>
>> I suppose a better name would be "child-src", but probably too late
>> for that.
>
> We could deprecate frame-src and browsers could support both for a while
> as synonyms. Not sure it's worth it though.
>
> -Dan Veditz
>

Received on Saturday, 23 November 2013 00:03:29 UTC