Closed Bug 1640574 Opened 4 years ago Closed 4 years ago

Enhanced Tracking Protection standard option does not block all cross-site tracking cookies

Categories

(Core :: Privacy: Anti-Tracking, defect, P2)

76 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1447935

People

(Reporter: gertjan.franken, Assigned: dimi)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36

Steps to reproduce:

The Enhanced Tracking Protection measure in Firefox is supposed to strip all cross-site tracking cookies from requests when its "standard" option is enabled. Since Firefox 69, this is the default setting. However, cross-site requests initiated by several mechanisms are not adequately stripped of their cookies when directed at a known tracking domain.

These are the mechanisms in question, together with example code on how to reproduce the request:

  • Cross-site requests initiated by leveraging a WebSocket

    • var socket = new WebSocket("wss://tracking-domain.com:9030");
  • Cross-site requests initiated through the Fetch API by a Service Worker.

    • var request = new Request("https://tracking-domain.com", { method: 'GET', credentials: 'include'}); fetch(request);
    • var request = new Request("https://tracking-domain.com", { method: 'HEAD', credentials: 'include'}); fetch(request);
    • var request = new Request("https://tracking-domain.com", { method: 'POST', credentials: 'include'}); fetch(request);
  • Cross-site requests initiated through the AppCache API, by including the following line in the AppCache manifest:

CACHE:
https://tracking-domain.com

This has been tested by setting up two locally hosted websites; one with an unimportant domain name, and the other with a domain name that is included in the Disconnect tracking black list (https://github.com/disconnectme/disconnect-tracking-protection). The former will host a webpage leveraging one of the discussed mechanisms to refer to the latter.
First, cookies of the simulated tracking domain are set by simply visiting one of its webpages. Subsequently, when the other domain's web page is visited using Firefox in default configuration, a request (including cookies) will be sent to the simulated tracking domain.

Only requests initiated by the WebSocket mechanism are visible in the network tab of the Developer Tools. For the others, requests can be observed using a proxy or the access logs of the employed local server.

This behavior was observed in Firefox versions 69 throughout 76 for the WebSocket en Service Worker mechanisms. For AppCache mechanism, this was observed in Firefox 71 throughout 76.

Actual results:

While the ETP standard option is not intended to block cross-site requests sent to tracking domains, it is intended to strip all cookies from these requests. This, however, is not the case for the mechanisms described above. All requests initiated by these mechanisms included third-party cookies set by the referred tracking domain.

Expected results:

The cookies set by the tracking domain should have been stripped from the cross-site requests.

Component: Untriaged → Privacy: Anti-Tracking
Product: Firefox → Core

Thanks for the report!

@Dimi: would you mind to check this out and see if we have bugs on file for these?

Blocks: 1207775
Severity: -- → S2
Flags: needinfo?(dlee)
Priority: -- → P2

Byass pass via ServiceWorker is a known issue (Bug 1437626), I intended to work on this recently.
As for WebSocket & AppCache, I'll check what is the root cause.

Assignee: nobody → dlee
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(dlee)

Hi Steven, can you confirm that this is still an S2, and if so are we targeting 79?

Flags: needinfo?(senglehardt)

We are not targeting Firefox 79, but will work to fix these in Q3. I'll bump down the severity.

Severity: S2 → S3
Flags: needinfo?(senglehardt)

This is fixed by the patch in Bug 1447935

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.