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

Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 20 Apr 2011 16:05:15 -0700
Message-ID: <BANLkTikM1vW9wdM4eQ-vGw-ddSwuTW3nFg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Travis Leithead <Travis.Leithead@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, "public-webapps-request@w3.org" <public-webapps-request@w3.org>, Adrian Bateman <adrianba@microsoft.com>, public-webapps <public-webapps@w3.org>
On Wed, Apr 20, 2011 at 3:57 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Apr 20, 2011 at 3:41 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>> On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>>> Please correct me if I'm missing something, but I don't see any new
>>>>> privacy-leak vectors here.  Without Shared Workers, 3rdparty.com can
>>>>> just hold open a communication channel to its server and shuttle
>>>>> information between the iframes on A.com and B.com that way.
>>>>
>>>> Not if the user disables third-party cookies (or cookies completely), right?
>>>
>>> No, what I described is independent of cookies.  You just have to use
>>> basic long-polling techniques, so the iframe on A.com sends a message
>>> to the server, and the server then passes that message to the iframe
>>> on B.com.
>>
>> But how does the server know to pair the two incoming connections and
>> forward data between them? If 50 users visit these sites, all the
>> server sees is 100 incoming connections with no idea which are coming
>> from the same user.
>
> True, you need some side-channel to link the two iframes for a
> particular client.  You can use something simple like one of the
> *other* within-domain communication mediums (cookies, localStorage,
> etc.) to share a uniqueid,

Yes, that's why those features needs to be similarly isolated when 3rd
party cookies are disabled to be truly effective.

> or you can just pull information out of the
> client, which the two windows are likely to share, and use that as the
> identifier.  We already know that you can fingerprint a larger
> percentage of users with only a handful of information sources
> available to JS.

That's why we're working on trying to fix fingerprinting.

The point is that privacy is something that we're all working on
trying to improve (right?), and the WebWorkers spec needs to be
changed to aid with that. As far as I can see all that's needed is to
say that a UA is allowed to not share a worker, and ideally point out
that such sharing could be disabled when the frame-parent chain
contains cross origin iframes.

Which reminds me that I need to add a similar note to IndexedDB.
Firefox 4 completely disables use of IndexedDB in iframes which has
cross origin frame ancestors. I know we talked about this with the
chrome folks, but I don't remember what they ended up doing in this
regard.

/ Jonas
Received on Wednesday, 20 April 2011 23:06:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT