Re: [whatwg] Feedback on Web Worker specification

Dear Ian,

Thank you for sharing you views.

> Date: Tue, 20 Nov 2012 23:30:50 +0000
> From: ian@hixie.ch
> To: whatwg@whatwg.org
> Subject: Re: [whatwg] Feedback on Web Worker specification
> 
> 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 requires a JS context without DOM access and with restricted
API access.  Web workers seem the closest match, but this need not be the
same as a 'web worker'.

> > 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.

Just to clarify, the proposal is to separately control the document JS context
and another 'web worker' like JS context.  So the document JS may be disabled
or just restricted, while the 'web worker' like JS context can still be enabled.
The contexts may well even be in different principles.
 
> 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 point is that the parent document JS context has DOM and API access to
read potentially private information and if it can use script to create a worker
that has access to outgoing channels then it also gains a capability to leak
this state.  If the work is created by a declarative mechanism then this channel
is closed.
 
> > 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?

To avoid scripts leaking private state accessible via the DOM and other APIs
the user could disable or restrict JS in contexts that have access to the
DOM or other APIs.  The 'web worker' like context would not have access to
the DOM or other APIs and thus not be a security risk and could be allowed
access to the web to forward information into the UA secure context.  It
is also proposed that the 'web worker' like context receive defined intentional
input from users.
 
> > 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.

No, the point is to control the covert leaking of UA state.
 
> > 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?

Web page content that includes scripts to covertly read the UA state and
leak this to the web.
 
> > 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.

There are contexts in which it is safest to just prohibit JS, such as documents
with user input forms, and there is still a use case for these to be able to be
updated.  Information flowing into a context does not pose a risk of leaking
state from this context.  Enabling JS in the secure context poses a risk of
leaking state out.

> > 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.

The proposal is to control JS separately in different contexts.  JS could be
disabled or restricted in the document JS but enabled in a 'web worker' like
context.

If there are declarative mechanisms to send events from the document to
a worker, and to update the document from worker messages then the worker
could implement a lot of webpage logic (even with the document JS context disabled).

> 
> 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?

Generally the leaking of UA state that the user may well consider private.
The DOM and APIs expose a lot of information about the users use of the UA.
 
> 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.

Your feedback suggests to me that the issue was not communicated well,
sorry it is a work in progress.  Perhaps in future the issues can be
communicated better and an implementation will help demonstrate the
design.

cheer
Freed

Received on Thursday, 22 November 2012 15:12:31 UTC