[whatwg] Feedback on Web Worker specification

[Ian Hickson]

On Wed, 22 Aug 2012, Jeffrey Pfau wrote:
> 
> While working on enhancing WebKit's privacy infrastructure, I noticed 
> that shared workers don't have a UA security policy escape clause like 
> localStorage and other APIs. The process to create a shared worker does 
> not allow UAs to abort creation with a SecurityError if it decides that 
> a document, origin, or script violates the UA's security policy.

Fixed.


On Sat, 3 Nov 2012, Fred Andrews wrote:
> 
> Feedback and suggestions for appropriate markup to declare web workers 
> would be appreciated.

Workers are only usable from script, so just start them in script. No need 
for anything declarative.


> The use case is a document with JS disabled or restricted so that it can 
> not create web workers, yet still wants to create web workers to process 
> page input and to update the document.

If it's been restricted to not run JS, then starting a worker is 
pointless, since workers only run JS.

If it's been restricted from starting Web workers, then it doesn't matter 
how the mechanism to start workers is presented, the page still won't be 
able to start a worker. It'd be pointless to have a mechanism to block 
workers that could just be circumvented.


> The use case is a document with JS disabled or restricted so that it can 
> not use JS to receive a message and update the DOM, yet still wants to 
> support AJAX style designs.

Why would the user disable JavaScript if they wanted the page to act like 
JavaScript was enabled?


> For example the document JS may be disabled but a declarative mechanism 
> may be defined to enable web workers to be create and these need to be 
> able to post changes to the document.

The whole point of disabling JS is presumably to prevent this, so 
allowing it would defeat the point, as far as I can tell.


> A mechanism specific to the need may be better for security.  For 
> example, being able to bind a HTML <div> element to a specific web 
> worker.  A general mechanism that allows a message to update any element 
> by ID may be less desirable for security.

I don't understand. What attack scenario are you envisaging?


> Would it be appropriate to add a new attribute to HTML elements that 
> allows their inner HTML to be replaced from a received message?

If JS is enabled, you can replace any element's contents at will.

If JS is disabled, presumably it's because the author doesn't want the 
page to be manipulated in this way. I don't see why they'd like a feature 
that circuments JS being disabled.


> For example, a form in a parent document with document JS disabled that 
> still wants to be able to post a submitted form to a web worker for 
> processing, or posting a message when a button is clicked.

If JS is disabled, the worker isn't going to be able to do anything, since 
it's just JS. So posting messages to the worker, or even starting a 
worker, doesn't seem useful. It could't do anything.


On Sat, 3 Nov 2012, Fred Andrews wrote:
> 
> The use case really is to be able to use web workers rather than the 
> document JS. An extension to disable or restrict the document JS will 
> also be added.  The design is intended to limit a large range of 
> security issues.

Could you elaborate on these security issues?


On Mon, 5 Nov 2012, Fred Andrews wrote:
> 
> The use I have in mind is a work-in-progress, see: 
> http://www.w3.org/community/pua/wiki/Draft#Examples

Limiting JS to workers, or indeed disabling JS entirely, doesn't help you 
at all as far as I can tell. It's trivial to fingerprint a user by 
collecting things like the user's IP address, the TCP/IP stack's 
characteristics, the browser's characteristics, the hardware's 
capabilities, etc. And it doesn't matter. When your government is a 
threat, they can just put you under surveillance, and your browser is the 
least of your problems. Advertisers aren't a threat; the worst they can do 
is provide you with ads that are more applicable to your interests; they 
couldn't care less about your personal details, they only care about broad 
demographic trends. Commercial providers like credit card companies, 
ecommerce retailers, utilities, ISPs, phone companies, and the like, 
already have your financial information, personal purchasing habits, 
personal address, geographical position history, and other private 
information, which they are willingly given in exchange for services. 
Stalkers aren't going to be using fingerprinting or data in shared workers 
to stalk you, they'll go through your friends or place of work.

In short, I think the entire approach here (and indeed the concern over 
shared workers in general mentioned at the top of this e-mail) to be 
rather misguided.


On Tue, 6 Nov 2012, Fred Andrews wrote:
> 
> Some concerns (lack of understanding) I have with the Web Worker spec. at:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html
> 
> "9.2.3 The worker's lifetime
> ... Otherwise, o is a Window object, and the relevant Document is just 
> the Document that is the active document of the Window object o."
> 
> Does this mean that the Document object of the caller is made available 
> to be web worker?  I can't see an interface to it?

No, this is just talking about the lifetime, not the API.


> "9.2.4 Processing model
> ...
> 5. A new script is now created, as follows.
> ...
> Set the script's browsing context to owner browsing context.
> ...
> Set the script's document to owner document."
> 
> There does not appear to be an API to actually effect the owner browsing 
> context or document?

Yeah, off-hand I can't actually think of anything that is available in a 
worker that uses the script's browsing context or document.


> Is this just laying a foundation for future work?

All scripts have a browsing context and document. They're used for all 
kinds of things in browsing contexts (e.g. knowing which tab to block 
when you call alert()).


> Are web workers expected to someday be able to cause navigation of the 
> creators browsing context etc?

Workers will never have shared state.


> "9.3 APIs available to workers
> ...
> The DOM APIs (Node objects, Document objects, etc) are not available to 
> workers in this version of this specification."
> 
> Are there plans to allow web workers access to the DOM of their creator?

No plans, only hopes.


> Does this apply to documents created by the web worker, such as via XHR?

Yes.


> Looking at the source code for some implementations will help clarify 
> the current state, but it would also be of interest to know of planned 
> web workers extensions?

Very little is planned, per se, before it happens. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'