Looking at their product, I wonder how many of these kind of vulnerabilities are still open and exploited by them. Wouldn't make much sense for them to burn such a useful vulnerability which is required for their product unless they had something better.
You can get a lot of entropy just by fingerprinting things send over HTTP headers and things freely accessible by JS.
E.g. user agent, screen dimensions, language, web GL, audio api, etc.
Generally wrt. fingerprinting chrome is worse then Firefox as Firefox actively worked to reduce fingerprint-ability if possible, while chrome seems to not care much. Because of this ironically I have a less unique fingerprint on a customized Firefox browser then a "stock" Chrome browser even through much less people use Firefox...
The reason (I think) why they make this public is because this can be used for more then "just" fingerprinting. I.e. this can be used by cyber attacks to find a potential attack vector to then pull of either a direct attack or some social engineering attack.
This is why the torbrowser/firefox "try to make everybody look the same" approach is doomed.
Adding white noise is the only solution: "try to make your fingerprint on each website for each brower-restart look as different as possible (a) from your fingerprint on every other website and (b) from your fingerprint on the same website on a previous browser-restart".
That's the best you can do anyways without rejecting first-party cookies.
Brave does this, and it is the right way. I just wish Firefox would wake up and clue in to this.
> most browsers have safety mechanisms in place designed to prevent such exploits. Weaknesses in these safety mechanisms are what makes this vulnerability possible.
> By specification, extensions need to be able to open custom URLs, such as mailto: links, without confirmation dialogs. The scheme flood protection conflicts with extension policies so there is a loophole that resets this flag every time any extension is triggered
If true, this sounds worse revelation than the exploit itself. Disabling a flag temporarily sounds bad, regardless of whether a vulnerability exists.
Yeah, it gave me quite a list of programs, including xcode and itunes, which is fascinating on a Linux box... they list 20 programs they think I have installed, of which I actually have 2. I'm not sure why it would be so inaccurate, but I feel better...
> I'm not sure why it would be so inaccurate, but I feel better...
I don't think you understood the core of the issue: it's not about identifying which applications you have installed, it's about always getting the same result for the same user. If all your browsers serve the same results, you are trackable, no matter if those results are good or not.
yeah, chrome/chromium on linux not tested at all, mostly because nobody on the team is using linux. We tested it on MacOS Big Sur and a bit of Windows.
Full table of what was tested here: https://github.com/fingerprintjs/external-protocol-flooding#... dathinab
>By opening a popup window with a custom URL scheme and checking if its document is available from JavaScript code, you can detect if the application is installed on the device.
> the basic concept is the same. It works by asking the browser to show a confirmation dialog in a popup window. Then the JavaScript code can detect if a popup has just been opened and detect the presence of an application based on that.
so...we seem to be relying on the honor system with the user? Can anyone clarify?
Basically browsers have the "I open a popup to ask" or "the user has no schema handler for that schema so I don't need to ask" or the "User already confirmed it always should open the link with given application" behaviour and they can detect it "somehow "?
Browsers open pop-ups to ask "Can I run that application?" but only if that application is installed. If that application is not installed, the browser will ignore the custom URL.
It looks like a mitigation might be that in the event you do not have the application installed, to return a "denied" status and send a prompt to the user like "Unknown application protocol".
Something like that could still would be susceptible to a timing attack though.
Yes I believe the proper fix would be to always behave as if a popup is showing, independent of weather or not it actually shows.
Through it's maybe slightly more complex as you might need to behave as if the user clicked cancel in a way where a attacker can not easily differentiate it from an actual user clicking cancel.
I’m the article author, can you please clarify your question?
The demo will not work without a popup window in Chrome, Firefox and Safari. The “Get My Identifier” button is needed in order to have a single user gesture to open an additional window.
However the Tor Browser demo works silently without any additional window.
> It works by asking the browser to show a confirmation dialog in a popup window. Then the JavaScript code can detect if a popup has just been opened and detect the presence of an application based on that.
> ...
> Tor Browser has confirmation dialogs disabled entirely as a privacy feature, which, ironically, exposed a more damaging vulnerability for this particular exploit. Nothing is shown while the exploit runs in the background, contrasting with other browsers that show pop-ups during the process.
Interesting concept. Most fingerprinting I've seen so far has for instance used the GPU to detect small differences in rendering, but also based on browser. First cross-browser I've seen, barring the obvious stuff like IP or so.
Hope this won't be a post where everyone that didn't get the same identifier have to proclaim it, though. We get it, it's not perfect. FWIW I got same in Edge & Fx and it claimed it was a unique combo (different ID in Chrome, though).
- in Firefox, it detected Epic Games Telegram Discord Battle.net Xcode NordVPN Sketch Teamviewer Microsoft Word WhatsApp Postman Adobe Messenger Figma Hotspot Shield ExpressVPN Notion iTunes, none of which I have installed. It didn't detect VSCode though I have VSCodium.
- On Chromium, it warned it would not work well on Chrome on Linux. It incorrectly detected all the apps. It seems that the browser would try to open the links with xdg-open.
Did it on Chrome, Firefox, and Safari and got the same code on all three. In all three it failed to detect some apps, but the same ones failed each time.
When I did it in Safari it actually caused Apple Music to open. When I did it in Chrome it popped up a small square window where I could see it doing it's thing.
Firefox was the only one where it was silent.
But still, that's an interesting hack. Very clever.
I just verified this on my machine and it was able to uniquely identify across Brave browser, Firefox and Epic browser (based on Chromium). I didn't check Safari because that's the browser I use the most and don't want to test on that.
The Epic browser one was interesting. That browser comes with a built in proxy for routing connections through other countries. I use it to get around geolocked content and sometimes for a tiny sense of anonymity. But seeing this able to identify it with same identifier as Brave and Firefox was a bit more troubling. But I guess that comes with the territory of all these browsers using the same Chromium engine.
I "saw" the little square window in Firefox on Windows 10, but only because I was paying attention. It was down in the corner, on (for some reason) my second monitor.
Was silent for me on macOS Big Sur Safari as well, except for the fact that it opened Apple Music without any warning. The author might want to remove the iTunes check, not sure how much entropy it adds anyways given that it is automatically installed on all Macs.
Does this actually work correctly for anyone? Got wrong results for Firefox and Chrome on Linux (it warns that Chrome probably won't work).
I glanced through the source[0] and my about:config and I noticed I have the dom.block_external_protocol_in_iframes setting enabled. Looks like this could be the mechanism they use? I don't remember enabling it manually.
Otherwise, it could be my tiling window manager messing with detection.
Yeah, we tested it on MacOS Big Sur mostly. Nobody on the team had linux so we didn't really test there.
It can be made to work with better timings for the measurements etc.
Any custom settings may affect the result. However default settings will work for the Firefox 88.0.1. Was tested on Windows, Safari and Linux.
Chrome does not work on Ubuntu, since it opens everything with xdg-open and creates confirmation dialog for both installed and not-installed application
Interestingly, custom URL handlers seem to stick around even after the app associated with them has been uninstalled. For example, this detected Messenger's URL handler although I uninstalled it a year ago.
Not the least bit surprised. I use Total Uninstall and almost every app leaves bits behind.
I've complained to many vendors and sent technical details of missed registry keys, files, etc.
Sometimes they even fix it.
But on the whole, Uninstall on Windows is a bit of a myth.
Finding new a fingerprinting mechanism in JavaScript is like finding a new memory corruption bug in the web browser engine.
They are always going to exist for architectural reasons, some are worse than others, and the really bad ones are likely kept nice and secret while they are actively exploited. In other words, I'm not surprised in the slightest, but I'm glad that this is out in the open now.
Windows 10 does some garbage where it installs handlers for URL schemas that take you to the windows store install page for the app. The vulnerability is only testing if you have an handler installed for skype:// not what application is actually handling it.
Worked perfectly on Firefox 88.0.1 on Windows. Great to know despite my efforts to balance privacy and anonymity, there is another metric that I'm unique in. Fingerprinting is just insidious.
Browsing in a VM is really one of the only safe ways to go on the modern web for privacy. So many sites break without JS, and having it enabled is an accident waiting to happen.
When you need privacy, always browse in a VM or a Tails boot.
Even in a VM you have to carefully ensure that memory deduplication is disabled, and/or some form of mitigation against Rowhammer is in place. Else you will be vulnerable to Flip Feng Shui cross-VM attacks.
This won't work against fingerprinting unless you change the underlying hardware and / or external IP too when stating a new VM. If you don't have a unique external IP per VM you might as well not bother. It is like trying to hide from the police by changing clothes and cutting your hair but stil hold the same huge sign with your name and address in your hands.
Since this is about fingerprinting and not hiding your identity I'm not sure this will help. If you use a public VPN you are removing some data points from the fingerprint but adding a huge new one. After all fingerprinting is about blending in and being like the average user. Adding a few privacy extensions and a VPN and you are much easier to recognise.
At least 9 of those programs could be "installed to desktop" on supported Chromium based browsers. That not only lowers your fingerprint in this particular vulnerability, but also saves quite a bit of disk space.
How unique are these ids really? I imagine certain apps will be very commonly installed as well as certain groups of apps? So it's not 32bits of information. Still more information to add to the finger printing pile..
I wish we could find a way to deal with this risk that's not simply disabling all kinds of functionality. Browser APIs seem to be suffering more and more by limitations to prevent finger printing.
> How unique are these ids really? I imagine certain apps will be very commonly installed as well as certain groups of apps?
Probably worse than you think. Zoom, Skype and Slack will be very common on work computers, while game launchers like steam and epic will work quite well on gaming pcs. You can differentiate further by checking the mixing of those groups and their relative music client (Spotify, ITunes...). Of course it won't be full 32 bits, but given the amount of quite common programs with url handler, it will probably deliver quite good results.
Fingerprinting and profiling in general just makes me not want to use the internet sometimes. I stopped using gmail at the very least. Maybe I should start using a VPN.
I appear to be getting false positives with a different identifier each time I run it. It says I have 3-4 different applications installed, none of which actually are on my system. Each subsequent run comes back with a different set of applications, and a different unique identifier. Looks like I may have beaten this method of fingerprinting, although I'm not quite sure how.
212 comments
[ 0.21 ms ] story [ 263 ms ] threadIt's as if they want browser developers to look at the code and break it as much as possible.
E.g. user agent, screen dimensions, language, web GL, audio api, etc.
Generally wrt. fingerprinting chrome is worse then Firefox as Firefox actively worked to reduce fingerprint-ability if possible, while chrome seems to not care much. Because of this ironically I have a less unique fingerprint on a customized Firefox browser then a "stock" Chrome browser even through much less people use Firefox...
The reason (I think) why they make this public is because this can be used for more then "just" fingerprinting. I.e. this can be used by cyber attacks to find a potential attack vector to then pull of either a direct attack or some social engineering attack.
Ironically, many of the settings can make you more unique because they disable a lot of functionality.
[1] https://github.com/pyllyukko/user.js
Adding white noise is the only solution: "try to make your fingerprint on each website for each brower-restart look as different as possible (a) from your fingerprint on every other website and (b) from your fingerprint on the same website on a previous browser-restart".
That's the best you can do anyways without rejecting first-party cookies.
Brave does this, and it is the right way. I just wish Firefox would wake up and clue in to this.
> most browsers have safety mechanisms in place designed to prevent such exploits. Weaknesses in these safety mechanisms are what makes this vulnerability possible.
> By specification, extensions need to be able to open custom URLs, such as mailto: links, without confirmation dialogs. The scheme flood protection conflicts with extension policies so there is a loophole that resets this flag every time any extension is triggered
If true, this sounds worse revelation than the exploit itself. Disabling a flag temporarily sounds bad, regardless of whether a vulnerability exists.
I've updated the demo for Chromium and made it work slower, in order to increase accuracy.
It does do the popup for VSCode asking if I want to open links there, which I do have installed.
I don't think you understood the core of the issue: it's not about identifying which applications you have installed, it's about always getting the same result for the same user. If all your browsers serve the same results, you are trackable, no matter if those results are good or not.
I.e. there are some schemas which lets say XCode handles but which also some other program handles.
On one of the browsers it also didn't detect slack and vscode being installed.
Is it you main browser in which you had used slack url's/ set slack to always handle the links?
Or is it the opposite?
Or maybe something else?
>This is your identifier. It was seen 2 times among 8828 tests so far.
None of these was my run. Still, didn't detect vscode :)
The internet connection may be the issue here, or the custom configuration on Safari.
in FF, unless im mistaken this assumes the user clicks anything except cancel on the popup. bug for reference and comment. https://bugzilla.mozilla.org/show_bug.cgi?id=1711084
further from the github:
> the basic concept is the same. It works by asking the browser to show a confirmation dialog in a popup window. Then the JavaScript code can detect if a popup has just been opened and detect the presence of an application based on that.
so...we seem to be relying on the honor system with the user? Can anyone clarify?
But I still have to look closer into it.
Something like that could still would be susceptible to a timing attack though.
Through it's maybe slightly more complex as you might need to behave as if the user clicked cancel in a way where a attacker can not easily differentiate it from an actual user clicking cancel.
I’m the article author, can you please clarify your question?
The demo will not work without a popup window in Chrome, Firefox and Safari. The “Get My Identifier” button is needed in order to have a single user gesture to open an additional window.
However the Tor Browser demo works silently without any additional window.
> ...
> Tor Browser has confirmation dialogs disabled entirely as a privacy feature, which, ironically, exposed a more damaging vulnerability for this particular exploit. Nothing is shown while the exploit runs in the background, contrasting with other browsers that show pop-ups during the process.
I'm on Firefox and didn't have to click anything. It correctly detected I have Steam installed.
The flashing popup window was quite obvious though.
Hope this won't be a post where everyone that didn't get the same identifier have to proclaim it, though. We get it, it's not perfect. FWIW I got same in Edge & Fx and it claimed it was a unique combo (different ID in Chrome, though).
- in Firefox, it detected Epic Games Telegram Discord Battle.net Xcode NordVPN Sketch Teamviewer Microsoft Word WhatsApp Postman Adobe Messenger Figma Hotspot Shield ExpressVPN Notion iTunes, none of which I have installed. It didn't detect VSCode though I have VSCodium.
- On Chromium, it warned it would not work well on Chrome on Linux. It incorrectly detected all the apps. It seems that the browser would try to open the links with xdg-open.
Clever hack anyway!
Security through obscurity does it again!
Edit: With firefox it is able to correctly detect 3 installed desktop applications.
When I did it in Safari it actually caused Apple Music to open. When I did it in Chrome it popped up a small square window where I could see it doing it's thing.
Firefox was the only one where it was silent.
But still, that's an interesting hack. Very clever.
Interesting. In my case I saw the little pop up window in all three browsers. Otherwise same results though.
The Epic browser one was interesting. That browser comes with a built in proxy for routing connections through other countries. I use it to get around geolocked content and sometimes for a tiny sense of anonymity. But seeing this able to identify it with same identifier as Brave and Firefox was a bit more troubling. But I guess that comes with the territory of all these browsers using the same Chromium engine.
I glanced through the source[0] and my about:config and I noticed I have the dom.block_external_protocol_in_iframes setting enabled. Looks like this could be the mechanism they use? I don't remember enabling it manually.
Otherwise, it could be my tiling window manager messing with detection.
[0]: https://github.com/fingerprintjs/external-protocol-flooding/...
It's not very effective....
Chrome does not work on Ubuntu, since it opens everything with xdg-open and creates confirmation dialog for both installed and not-installed application
I've complained to many vendors and sent technical details of missed registry keys, files, etc. Sometimes they even fix it. But on the whole, Uninstall on Windows is a bit of a myth.
They are always going to exist for architectural reasons, some are worse than others, and the really bad ones are likely kept nice and secret while they are actively exploited. In other words, I'm not surprised in the slightest, but I'm glad that this is out in the open now.
https://jsfiddle.net/ourcodeworld/aqq1w0qm/
[1] https://www.nirsoft.net/utils/url_protocol_view.html
When you need privacy, always browse in a VM or a Tails boot.
https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events...
I wish we could find a way to deal with this risk that's not simply disabling all kinds of functionality. Browser APIs seem to be suffering more and more by limitations to prevent finger printing.
Probably worse than you think. Zoom, Skype and Slack will be very common on work computers, while game launchers like steam and epic will work quite well on gaming pcs. You can differentiate further by checking the mixing of those groups and their relative music client (Spotify, ITunes...). Of course it won't be full 32 bits, but given the amount of quite common programs with url handler, it will probably deliver quite good results.
This is interesting since I didn't really expect Opera to care about this kind of thing.