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.

Demo:
https://schemeflood.com/

Source code:
https://github.com/fingerprintjs/external-protocol-flooding

Actual results:

The basic steps are:

1. Open an additional window (AW) with the window.open 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. :)

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 browser.link.open_newwindow.restriction = 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 browser.link.open_newwindow.restriction = 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.

I’ve made some math based on the database data from the backend script that collects results:
https://github.com/fingerprintjs/external-protocol-flooding/blob/master/packages/backend/src/index.ts

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.