1424557 - Tracking users across domains even with cookies/storage disabled.

Status: RESOLVED DUPLICATE of bug 1401359

(Firefox :: Untriaged, defect)

Description

[Konark Modi - @konarkmodi]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171209212710

Steps to reproduce:

1. Changed Accept third-party cookies from always to never.
2. Visit :
https://cdn.cliqz.com/browser-f/fun-demo/some-random-page.html , 
this test page uses a third-party script from https://konarkmodi.github.io, which starts shared worker.
3. In a new tab visit:
https://cdn2.ghostery.com/browser-f/fun-demo/some-random-page.html, 
this test page also uses the same third-party script from http://konarkmodi.github.io

If you visit the these two pages in two tabs, you will notice that as a third-party it can learn the movement of a user across domains, even though the user has disabled 3rd party cookies.


Actual results:

As you will see on the page, the third-party is able to keep track of other URLs visited by the same user.

Even though the cookies / storage is disabled for a third-party, if the user opens websites, which happen to use same third-party. That third-party can use shared workers to track users across websites.
Same is possible in a private mode too.


Expected results:

Although it's not a very strong tracking vector, but the expectation is when third-party cookies is disabled, there is no way the third-party should be able to track the user, does not matter if it's temporary, session based.

This does not happen on FF57 and above. But FF ESR 52.5.0 , 52.5.1 are affected.
The only other way I could mitigate this attack, was to enable first-party isolation.

Comment 1

[Konark Modi - @konarkmodi]

Versions affected: FF ESR 52.5.0 , 52.5.2

Comment 2

[:Gijs (he/him)]

(In reply to Konark Modi from comment #0)
> This does not happen on FF57 and above. But FF ESR 52.5.0 , 52.5.1 are
> affected.

So this only affects ESR? That makes it sound like something that might have been fixed in the past but we decided not to fix it on ESR (because we limit what gets uplifted to ESR, both based on impact on websites/enterprises etc. and based on how hard it is to create a patch that applies on uplift).

:bkelly, you know about workers, do you happen to know what caused this bug and where it got fixed, and if there was a deliberate decision not to fix ESR?

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

I don't think its fixed in current firefox.  I have bug 1401359 filed to disable SharedWorker from documents without access to storage for exactly what comment 0 suggests.

I think it sometimes appears to isolate correctly in newer firefox because of multi-e10s.  We don't share SharedWorker objects across process boundaries yet.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

I'll see if I can fix and land my patch in bug 1401359.  Should we dupe this?  (Are privacy issues normally marked secure bugs?)

Comment 5

[:Gijs (he/him)]

(In reply to Ben Kelly [:bkelly] from comment #4)
> I'll see if I can fix and land my patch in bug 1401359.  Should we dupe
> this?  (Are privacy issues normally marked secure bugs?)

I'm not sure. Depends how severe they are, see https://wiki.mozilla.org/Security_Severity_Ratings suggests this may be sec-low (" Identification of users by profiling browsing behavior.")

Dan?

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

BroadcastChannel has similar issues.  See bug 1401362.

Comment 7

[Daniel Veditz [:dveditz]]

Sometimes privacy bugs are kept hidden if the risk is severe enough, but given bug 1401359 is public and the fact that 3rd party cookie blocking is not a common setting (most users can be tracked via cookies anyway) we don't need to in this case.