RE: [Workers] Worker same-origin and usage in JS libraries...
From: Ian Hickson [mailto:i...@hixie.ch] On Tue, 17 Jul 2012, Ian Hickson wrote: My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. Just as an update, I still plan to do this, but I'm currently waiting for browser vendors to more widely implement the existing Worker, SharedWorker, MessagePort, and PortCollection features before adding more features to this part of the spec. It would also be helpful to have confirmation from browser vendors that y'all actually _want_ cross-origin workers, before I spec it. I've had many folks as me why they can't just refer to a cross-origin work in the Worker constructor; after all, they can import the worker's dependent scripts via importScripts cross-origin... The only rationale I could give is that the spec indicates the new worker's origin info was based on the document's that spawned it. If the new worker's origin info is established via the requested resource, then you should get the same functionality, but without the same-origin initial restriction. (This may be an oversimplification, but it worked for me.) As to whether we _want_ it, these same folks are apparantely able to live with the current restrictions. They may just be deferring the bulk of the worker's content to importScripts at present to work-around this limitation.
Re: [Workers] Worker same-origin and usage in JS libraries...
On Tue, 17 Jul 2012, Ian Hickson wrote: My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. Just as an update, I still plan to do this, but I'm currently waiting for browser vendors to more widely implement the existing Worker, SharedWorker, MessagePort, and PortCollection features before adding more features to this part of the spec. It would also be helpful to have confirmation from browser vendors that y'all actually _want_ cross-origin workers, before I spec it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On Thu, Nov 29, 2012 at 4:31 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 17 Jul 2012, Ian Hickson wrote: My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. Just as an update, I still plan to do this, but I'm currently waiting for browser vendors to more widely implement the existing Worker, SharedWorker, MessagePort, and PortCollection features before adding more features to this part of the spec. It would also be helpful to have confirmation from browser vendors that y'all actually _want_ cross-origin workers, before I spec it. The only difference with cross-origin workers is that they're in a different execution environment, right? If so, seems like a good thing to support. I don't see any downside and it doesn't sound especially difficult to implement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On Tue, 6 Dec 2011, Jonas Sicking wrote: On Tue, Dec 6, 2011 at 5:05 PM, Travis Leithead travis.leith...@microsoft.com wrote: A new scenario just came to my attention that I thought I might pose to the list. Given the current same-origin restrictions on new Worker(), it is problematic for Worker usage by any JS libraries on a CDN. A site using a CDN simply provides an absolute URL reference to the library, and it is subsequently downloaded and executed in the context of the current page's domain. Relative URLs to a worker script will resolve according to the domain of the hosting page: // http://cdn.net/dowork.js which was included from http://test.com/home.htm var w = new Worker(lib/workers/w1.js); // Tries to open http://test.com/lib/workers/w1.js and absolute URLs will fail due to the cross-origin restrictions on the new Worker constructor: // same setup as before var w = new Worker(http://cdn.net/lib/workers/w1.js;); // Cross-origin failure from http://test.com/home.htm I looked back through the list and at the original worker proposals to try and discover why the same-origin restrictions is in place. The root of the issue seems to be the expectation that WorkerGlobalScope runs and executes everything according to its own location.URL. Thus, allowing http://cdn.net/lib/workers/w1.js to load in the previous example, would allow http://test.com/home.htm to potentially modify any data associated with cdn.net's domain (like through Indexed DB, or XHR, etc). One way to allow the CDN scenario to work would be to provide an explicit way to tell a worker to run in the host context, rather than the context that the Worker is loaded from (which is what script inclusion and importScripts does today). Since Workers _can't_ be loaded cross-origin [currently], the Workers are already running in the host context by virtue of this limitation. Codifying that a WorkerGlobalScope's execution environment is always that of the document that created it, and then allowing workers to be constructed from any URL would effectively solve the CDN problem IMHO. Later, when/if we open up cross-origin workers, we can provide a special way to instruct the workers to set their execution context to that of the URL they are loaded from. Thoughts from the group? It's not an entirely bad idea. We've solve the solution in a somewhat less elegant way. Since firefox generally considers data:-uris to be same-origin with whatever page loaded them, you can create a worker using a data:-uri which then importScripts the cross-origin script. (This is relatively newly implemented so I forget if it's in released versions of firefox). I've specced this. But I can't really come up with any arguments against your proposal... My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On 17.7.2012 23:53, Ian Hickson wrote:
My plan is to make it so that cross-origin URLs start cross-origin
workers. The main unresolved question is how to do this in an
opt-in manner. The best idea I've come up with so far is having
scripts that want to opt-in to being run in such a way start with
a line line: // Cross-Origin Worker for: http://example.net
...or (for multiple domains): // Cross-Origin Worker for:
http://example.com https://example.org
...or (for any domain): // Cross-Origin Worker for all origins
...but that doesn't seem super neat.
Since script is loaded using HTTP, why not use already defined CORS
headers on server side while serving those scripts?
And if you want it to be defined in JS file itself, I'll suggest
"use strict" approach:
file
---
"Access-Control-Allow-Origin: *";
(function(){
"use strict";
var x = 5;
})();
---file
and define CORS headers as a string (maybe with the restriction that
those headers must be first executable/runnable code in JS file - so
there may be comments and whitespaces before)
B.
--
s pozdravem
Bronislav Klučka
http://www.bauglir.com
bronislav.klu...@bauglir.com
* webové aplikace
* software na zakázku
Re: [Workers] Worker same-origin and usage in JS libraries...
On Wed, 18 Jul 2012, Bronislav Klu�~Mka wrote:
Since script is loaded using HTTP, why not use already defined CORS headers on
server side while serving those scripts?
CORS is the wrong semantic. It's not origin A is allowed to read content
from origin B, it's origin A is allowed to cause origin B to run code,
which is a very different threat model. It would be quite bad for us to
say that any file that you can read from another origin, you can cause to
be executed as script in that origin.
And if you want it to be defined in JS file itself, I'll suggest use
strict approach:
file ---
Access-Control-Allow-Origin: *;
(function(){
use strict;
var x = 5;
})();
---file
Whether it's a string or a comment seems like a detail. If we do do this,
I expect we'll find something that's somewhat language-agnostic (e.g.
allowing any leading and trailing punctuation on the first line, or
something to that effect).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On 18.7.2012 1:05, Ian Hickson wrote:
And if you want it to be defined in JS file itself, I'll suggest use
strict approach:
file ---
Access-Control-Allow-Origin: *;
(function(){
use strict;
var x = 5;
})();
---file
Whether it's a string or a comment seems like a detail. If we do do this,
I expect we'll find something that's somewhat language-agnostic (e.g.
allowing any leading and trailing punctuation on the first line, or
something to that effect).
Well not exactly a detail... we already have comment processing in HTML
and JS... (IE). Script minifiers can have issues with that, JS engines
would have to start parse end somehow execute comments to look for
something suspicious in a text without recognizable syntax and semantics
(garbage)
Maybe some specific object, as a property on window / worker scope would
be inline with language and requiremenets (=to define script properties)
(this|self).ScriptProperties = {
DisableCrossOriginExecution = false, //to disable CO script sharing,
since current default is true
AllowCrossOriginWorkerExecution = true //to enable CO in workers,
since current default is false
}
it would also allow any future extensions
BK
[Workers] Worker same-origin and usage in JS libraries...
A new scenario just came to my attention that I thought I might pose to the list. Given the current same-origin restrictions on new Worker(), it is problematic for Worker usage by any JS libraries on a CDN. A site using a CDN simply provides an absolute URL reference to the library, and it is subsequently downloaded and executed in the context of the current page's domain. Relative URLs to a worker script will resolve according to the domain of the hosting page: // http://cdn.net/dowork.js which was included from http://test.com/home.htm var w = new Worker(lib/workers/w1.js); // Tries to open http://test.com/lib/workers/w1.js and absolute URLs will fail due to the cross-origin restrictions on the new Worker constructor: // same setup as before var w = new Worker(http://cdn.net/lib/workers/w1.js;); // Cross-origin failure from http://test.com/home.htm I looked back through the list and at the original worker proposals to try and discover why the same-origin restrictions is in place. The root of the issue seems to be the expectation that WorkerGlobalScope runs and executes everything according to its own location.URL. Thus, allowing http://cdn.net/lib/workers/w1.js to load in the previous example, would allow http://test.com/home.htm to potentially modify any data associated with cdn.net's domain (like through Indexed DB, or XHR, etc). One way to allow the CDN scenario to work would be to provide an explicit way to tell a worker to run in the host context, rather than the context that the Worker is loaded from (which is what script inclusion and importScripts does today). Since Workers _can't_ be loaded cross-origin [currently], the Workers are already running in the host context by virtue of this limitation. Codifying that a WorkerGlobalScope's execution environment is always that of the document that created it, and then allowing workers to be constructed from any URL would effectively solve the CDN problem IMHO. Later, when/if we open up cross-origin workers, we can provide a special way to instruct the workers to set their execution context to that of the URL they are loaded from. Thoughts from the group? -Travis
