Open Bug 1711084 Opened 2 years ago Updated 2 months ago

Scheme flooding technique for reliable cross-browser fingerprinting


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

Firefox 88




(Reporter: konstantin.darutkin, Unassigned)


(Depends on 1 open bug)


(Keywords: csectype-disclosure, privacy, sec-low)


(1 file)

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

Steps to reproduce:

We made a scheme flooding exploit that allows identifying people cross-browser.
Windows, Linux, macOS are affected. The exploit was tested on 88.0.1.


Source code:

Actual results:

The basic steps are:

  1. Open an additional window (AW) with the method;
  2. Navigate the AW to the custom protocol URL (such as slack:// or fb://) with the location.replace method;
  3. Check if the same origin policy is enabled for the AW. If the document is accessible, then the application is installed on the computer;
  4. Perform 24 tests (steps 2-3) in order to get a 24-bit cross-browser fingerprint based on the installed application data.

Thanks for reporting this, we'll take a look. :)

Component: Untriaged → Privacy: Anti-Tracking
Flags: needinfo?(jhofmann)
Product: Firefox → Core
Ever confirmed: true

relevant bugzillas?

FYI: Nightly vanilla profile, test id'ed 20 items (from 24) "installed", 19 of those 20 are false positives

(In reply to Simon Mainey from comment #2)

relevant bugzillas?
FYI: Nightly vanilla profile, test id'ed 20 items (from 24) "installed", 19 of those 20 are false positives

Custom browser configuration may affect the demo results, however the default setup should work. I tested it on Ubuntu, macOS and Windows.
Bug 1167856 and Bug 1626068 seems relevant

(In reply to Konstantin Darutkin from comment #3)

Custom browser configuration may affect the demo results, however the default setup should work

False positives and vice versa don't really matter as long as it's stable, but I doesn't seem to be consistent. I stated my quick test was in a vanilla (new) profile, but in reality my nightly was slightly tweaked (with = 0 - more on this below).

new profiles except nightly where I reset the newwindow restriction pref

  • for the record, only 1 of these 24 is on my system
  • nightly90, beta89, release88: detected all 24
  • flip = 0 (as per Tor Browser)
    • this stops the new window trying to hide "offscreen" (although I still see it bottom right tiny window on my secondary monitor)
    • in this mode the fingerprinting attempt becomes very apparent (the new "tab" grabs focus as well) and would scare users away - maybe useful for a targeted attack, but not mainstream IMO
  • sanitize cache/data etc; retest
  • nightly90: 13 found (only 1 is correct), 11 not found <- this differs from my earlier test: hence I said doesn't seem to be consistent
  • beta89: 21 found (only 1 is correct), 3 not found
  • stable88: 9 found (all false positives), 15 not found (1 false negative)

tl;dr: the results don't have to be correct, it's picking up entropy from other settings

although I still see it

that should read, although I still SAW it .. when the pref was default 2

This sounds like a duplicate of bug 1626068, but will mark that as a dependency of this bug for now.

Depends on: 1626068

I’ve made some math based on the database data from the backend script that collects results:

  1. So far we have 32009 results among 24276 sessions.
  2. 2057 sessions (~8%) have more than 1 unique cross-browser identifier. That probably means the demo worked from the 2nd try or result is inconsistent in general.
  3. 2728 results have 0 apps installed and 2221 results have all apps installed. Roughly speaking, the demo does not work in 15.4% of cases.
  4. 8774 unique identifiers among 34024 tests. (in average, 4 browsers gives the same ID)

These results are about all browsers in general.

This issue made it into common news so more users (including me) might be have gotten aware of it. Comment #4 implies that this issue appears to be not significantly threatening so I was curious about the result when I did the testcase from comment #0 on my current production profile (Firefox 89.0.2 on Windows 10; permanent private browsing mode enabled; privacy.resistFingerprinting=true; dFPI with disabled exceptions active; other small tweaks - pretty much one would expect on a profile that cares for strong privacy). The simple answer is: Nearly everything detected and non-detected was false - hardly different from claiming the choices being random. More curiously repeating the test immediately resulted in another random result - rendering this test unable here to possibly track me.

On the other hand Firefox has accumulated until now quite a good amount of unresolved privacy/tracking-related issues and most of them will not see a fix in the near- or mid-future. The highest threat I'm currently aware of is tracking via the network identifier on IPv6 networks - as it gives a high and relative stable amount of entropy; it can not be spoofed by simple means; there are no good reliable workarounds (including current implementations of the privacy extensions) as far as I know; fixing it might be the very opposite of being trivial. And at some point we will be all on IPv6 and suffer ultimate tracking - there is no escape in sight :)

Still, if the issue Konstantin reported here allows for easier tracking it should probably be evaluated/fixed. But he also might need to check their testcase again if it is still working fine as this seems to be currently not the case on a high-threat level.


(In reply to sworddragon2 from comment #9)

network identifier

I meant device identifier as otherwise it would make not much sense. I still wish you could simply edit your posts here so I could also fix my grammar error in my first sentence (and similar uncommon errors in other posts) that even went unnoticed on an audit before sending :)

Depends on: CVE-2021-43542

Quick update that fixing this is on our roadmap, with no ETA yet.

Flags: needinfo?(jhofmann)
Severity: -- → S2
Priority: -- → P2

with bug 1723281 fixed, could you also take this one on, Olli?

Flags: needinfo?(bugs)

I can't reproduce this when following the steps in comment 0. Document is always accessible, whether or not the protocol is supported.
I get "Prevented navigation to “zoommtg2://123213” due to an unknown protocol." in the web console when the protocol isn't supported and
a popup to handle the url if protocol is some supported one.

But obviously does still work, so it is doing something a bit different.

Does anyone have a minimal testcase?

Flags: needinfo?(annevk)

In Tor Browser we solved this problem with the patch I have attached (developed by Matthew Finkel).

Assignee: nobody → pierov
Assignee: pierov → nobody

Lowering severity to S3 as there are multiple other fingerprinting issues as it doesn't fit for a S2.

Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.