I'm going to close a website as soon as I get an unprompted popup that says "Firefox is trying to open Slack."
It's clever but somewhat obvious (in both a to-the-user-that-its-happening and a "well of course it's possible" sense).
So it's cute, but not practical, and I won't lose sleep over it. I'll probably be more inconvenienced by the mitigations that will surely result that make it that much more painful to actually launch a URL scheme, sadly.
I've actually never checked the "Always open Slack for slack:// links" or similar checkboxes, precisely out of predicting shenanigans like this would happen eventually :)
I wouldn't be too offended if browsers changed the way they handle schemes: always open a "how would you like to handle this link" dialog for any protocol (even if unhandled - like how Windows shows the "how would you like to open this file" dialog), to disguise whether the protocol is handled or not. Not sure I have the answer for user convenience though if someone is used to things automatically opening. That's the "inconvenience" aspect of any potential mitigation, we probably have to get rid of that "remember this choice" checkbox (well, my point is that "have to" is debatable here).
Note: I just tried the demo [0], and no obvious prompt showed up, instead it was a tiny window [1] on the bottom right of my screen, which only showed up for a couple seconds and is easy to miss.
Yeah, that was the popup I was referencing - although it's much smaller for you than it was for me - maybe my low res laptop screen is a benefit there. It was noticable enough to clue me that something weird was afoot, but I'm sure it could be disguised further.
I think a fix could be: always show a select-program prompt even for unknown schemes (perhaps with a built-in link to the add-ons store a la Windows to find a program to open the "file" ;) ), never fail to a different page context than a successful launch would go to, and make the don't-ask-again checkbox domain specific to prevent random domains doing drive-by automatic launch detection. That seems to solve it without being too disruptive to existing convenience.
Every time I run the demo, it gives me a different result? This is just on the same browser (Firefox), it generates a different code every time and claims I have random applications installed that I don't (the only one I have on that list is steam, which it does seems to consistently report at least). Not sure if one of my extensions is interfering with it.
I do this too. It's also a massive usability win for those annoying websites (usually banking or government) that insist upon a full screen pop-up window to hide the navigation controls and URL bar.
I'm using a tiling window manager and it's very hard to miss: each attempt opens a new window that resizes the browser and takes up half the screen.
On the other hand, I guess they could automatically measure the window size in the popups and use this to detect tiling window managers, which gives them another (albeit noisy) bit for fingerprinting...
On Chrome MacOS Big Sur, it doesn't require accepting the prompt, and the demo shows you can accomplish this in a small pop-under or pop-up, which a lot of inexperienced users might simply ignore.
Browser devs definitely still need to patch this vulnerability by making it an instant-return no-feedback prompt to open an application.
I think my initial reaction was too harsh; after thinking through it some more I agree and think there's an easy enough fix I posted in a sibling comment.
As an aside, It's actually surprising the built-in popup blocker let so many popups come from just one user action - I would have thought the heuristic was 1 click = 1 allowed popup before Firefox started denying them.
Remember the time of early ActiveX, when you could execute an antivirus in the browser that would scan your entire hard drive. It was exactly the same tech that happened for Windows Update executing in-browser. It feels like we’re doing the same mistake over and over.
It didn't work between firefox and chromium on my linux desktop, even trying the chromium branch. But my linux desktop already puts me into a pretty small bucket of users to begin with, so someone who's doing this may not see any joy in trying to fix that.
It appears to just detect the presence of an installed scheme handler, not the application itself. This does tell you that the application was at one point installed and the uninstaller for it lies and doesn't completely uninstall, but none of the applications it thinks I have are applications I still have (just Spotify and Skype, but still).
Good to know who the offenders are, Spotify and Skype. Everything else I uninstalled was actually uninstalled.
For what it's worth, I went to the Registry Editor, deleted the entries in HKEY_CLASSES_ROOT for Skype and Spotify completely, and these are still showing up as installed.
Makes me wonder if Windows is somehow pre-installing custom scheme handlers for these, whether you have them or not. As far as I know, Skype comes with Windows, so there is no way to test a fresh installation that never had it at all, but Spotify? Is there anyone using a completely clean fresh Windows installation that can test if this demo thinks it is installed even though it isn't?
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 "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.
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.
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.
Lots of comments about whether or not the demo works consistently between browsers, but regardless, it's a cool attack vector, major props to the authors. Honestly surprised the Tor browser didn't just disable protocol handlers outright beforehand, seems like a vulnerability waiting to happen when you're that paranoid.
I'm a bit confused about why so many applications have bothered to create custom protocol handlers. I can see the benefit for something like Spotify, you click a link in your browser and it takes you to the song you want in the Spotify application. But is the NordVPN application really so complex that they can't just say, "hey, open Nord and click this"? Just seems like an unnecessary UX decision. Unless there's something I'm not seeing?
This is connected to a significant usability problem with `tel:` links: you have no way of knowing whether they’ll work, and if they don’t work, it could be in one of a few different ways. Maybe it’ll open a dialer app. Maybe it’ll do nothing at all. Maybe it’ll open an “unknown scheme” browser error page. Maybe it’ll prompt you to open it in an external app (I seem to have both Skype and Zoom willing to handle tel: links; neither is going to succeed). You largely can’t detect whether it has done something, might have done something, or has done nothing. Well, this article shows ways that you can detect likely results for some cases after trying it, but it’s not reliable and is depending on implementation details that are liable to change (especially since they’re a fingerprinting vector).
If it’s not going to work, I’d strongly prefer to not make the phone number a link—and perhaps even to present a different flow to the user (e.g. provide a form or mark an email address as the primary option). But if it is going to work, I definitely want it to be a link. It’s common to just guess from the user agent string or screen size whether it’s a mobile device, but that’s extremely flawed too—some tablets will and some won’t be able to dial, and even desktop platforms may well have some VoIP app.
Fingerprinting and usability are so often so significantly at odds. :-(
Lynx is functioning correctly (although I would prefer treating user-entered URLs as relative). However, I think that in new versions of Lynx you can turn that feature off if you want to. However, I think that they really should add a NNTP server so that you can access NNTP, too.
Right, but if you're not on a device with a built in phone connection then it's reasonable to open skype and similar apps that can do phone calls (even if they cost money).
How do I disable this? I don't have any need to open Skype, or any other application, from my browser. Is it a browser setting (I use Firefox) or is it an OS setting (Windows)?
Edit2: After thinking about this more, I'm afraid that removing URI schemes from the registry may break those programs. I'd much rather have a browser level setting that will only open external http:/https: resources and other URI schemes that are configured from the browser like mailto:.
You can remove any settings you persisted in Firefox regarding whether to open a uri scheme in an external application or not by going to your profile folder and deleting the handlers.json file. Do this when Firefox is not open. This will clear any history if you've ever selected "always open links of this type with <blah>" in the popup.
But unfortunately, this exploit is just depending on the popup to happen at all, which I don't think you can configure from Firefox. If a uri scheme handler is registered with Windows, Firefox will ask you if you want to use it. Deleting the registered scheme handler from Windows is a matter of finding an entry in HKEY_CLASSES_ROOT in the registry with a name that matches the scheme and deleting that entry. For instance, in regedit, if you find HKEY_CLASSES_ROOT\spotify, you can delete it and no more handler for spotify://.
Whether or not this breaks the program probably depends on the program. If buttons and links in the application itself use this scheme, then it probably will. If they're handled directly without delegating to the OS, then maybe not. Worst that happens is you can always just reinstall the application if it stops working.
I'm looking around through Firefox docs about whether it's possible to block specific uri schemes from being handled at all but not finding anything. They do block data:// and have a strict origin policy for file://, but those are already on by default and I can't find anything related to blocking (or allowing) arbitrary uri schemes. That would be one obvious fix, though, and the researchers here did report this as a bug, so maybe an upcoming Firefox will offer this.
Should add the obvious ultimate way to prevent fingerprinting of this type is to just run Firefox in its own VM or container with a totally clean OS you otherwise don't touch. You could choose to share the Downloads folder between guest and host so you can still save files, but it then wouldn't be able to see what you do and don't have installed on your real host system.
Of course, if you do anything to allow hardware acceleration in your browser so you're not streaming media like it's 1999, it'll still be able to fingerprint you based on the hardware, but at least it won't see what applications you have.
The Local Group Policy setting in the link only affects Windows Store apps:
"This policy setting lets you control whether Windows Store apps can open URIs using the default desktop app for a URI scheme. Because desktop apps run at a higher integrity level than Windows Store apps, there is a risk that a URI scheme launched by a Windows Store app might compromise the system by launching a desktop app."
I haven't tried the registry setting, maybe that will also block normal desktop applications? Edit: it looks like the BlockProtocolElevation setting also only affects Windows Store apps.
Windows Settings lets me choose an app, but not choose no app/remove an app. So that's not entirely useful (the obvious "just use notepad for everything" is also an obvious tell)
I'm not wildly keep on manually editing the registry, at least without someone else doing it first and reporting that it didn't break their computer :)
For MacOS, I was able to fix this by editing the info.plist inside each application which was detected. This lets me still keep the app but no longer get detected.
WARNING: Do it at your own risk. I am fairly certain when I restart my computer, the Spotify app will no longer work as deleting the entry from the info.plist file most likely changes the signature of the app binary and it will no longer be valid.
Simply uninstalling the app won't be enough. Rebuild LaunchServices is required to get rid of the registered URL scheme.
The info.plist for Spotify for example is located at:
/Applications/Spotify.app/Contents/Info.plist
You can either do it through terminal or navigate to /Applications in finder, then right click the app and use "Show Package Content" option > Contents > Info.plist.
Open the Info.plist in Xcode, look for CFBundleURLSchemes:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
Without the above command, the URL scheme wasn't getting unregistered and the site was still picking it up.
- 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.
>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?
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.
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 tried it in Firefox and Tor, and got the same identifier for both, but in both cases it said, "This is your identifier. It is unique among [####] tests so far."
But.. it wasn't unique for the second browser I tried. And they'd be coming from different IPs, so it wouldn't have any way to know both were coming from the same person, aside from the fingerprinting itself...
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.
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.
But speaking of, does the website know if you do have MetaMask installed right away (without prompting you for anything)? Because that would be a real concern if it did.
Yeah it does. Browsing the Web with MetaMask is like walking around with a bag of $10,000 cash openly exposed in a crowded public street of a society with no police officers or law enforcement.
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).
Wow, it didn't work at all on my desktop. It thinks I have 23 apps from its list installed, on both Firefox and Chrome. Pretty funny seeing that on a Linux box running CentOS 7. Even better, it detects a different app on each as the only one missing: on Firefox it says I don't have Skype installed, while on Chrome it says I don't have Hotspot Shield installed.
Interesting to see that browsers are still vulnerable to this; I know iOS had a very similar problem a while back (apps would check for the existence of hundreds of other applications by checking whether they could open those URL schemes) and Apple clamped down on it quickly by restricting the number of queries that could be made.
Results differ wildly between browsers and even between runs within the same browser. It detects application I do not have installed and does not detect applications I do have installed. For instance it detects iTunes, XCode and Sketch, but they are Mac-only application and I am on Windows.
Thanks for testing it on Windows. We mostly tested it on MacOS Big Sur because all devs on the team have that OS.
With Windows different timings might be needed, we'll check into it tomorrow.
Seriously, it maintains (among other things, yes) the mapping from filename extensions to the path of the binary that should be used to open them.
It's a map : extension -> path.
WhyTF does MIME have to get dragged into this? Why can't I just say "*.foo is opened with /usr/bin/foobalize"? Why must I suffer the agony of trawling the interwebs to find out that blartz.foo is actually a z-content-flavor/foobalized_v3?
(Yes, I understand why browsers need to start the lookup using a MIME type. I'm talking about everything else -- the galaxy of things that don't use HTTP).
And even once I've found the Magic MIME type, xdg-open still does whatever it wants, and there appears to be no way to troubleshoot it when it's being invoked by another application. Setting XDG_UTILS_DEBUG_LEVEL=999 simply prints out a list of which files its reading (I can get that from strace, thanks), with no step-by-step rundown of its decision process:
$ XDG_UTILS_DEBUG_LEVEL=999 xdg-open ftp://foo.com
Selected DE generic
Checking /home/user/.config/mimeapps.list
Checking /home/user/.local/share/applications/defaults.list and /home/user/.local/share/applications/mimeinfo.cache
Checking /home/user/.local/share/applications/defaults.list and /home/user/.local/share/applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and /usr/local/share//applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and /usr/local/share//applications/mimeinfo.cache
Checking /usr/share//applications/defaults.list and /usr/share//applications/mimeinfo.cache
Checking /usr/share//applications/defaults.list and /usr/share//applications/mimeinfo.cache
Okay, y'all can downvote me now, ranty time is over.
No, xdg-utils are absolutely terrible. They're a mess of untested, undebuggable, underdocumented and extremely user unfriendly shell scripts that need to die and be replaced with something that actually had some serious design thought put into it.
I've once had xdg-open be absolutely broken on my machine, scanning all of my $HOME because of a file with a space character in it [1]. Any attempt to use xdg-open would pin a CPU core for 100% while bash/find recursively traversed millions of files because of missing quote characters in a shell script. Truly the pinnacle of software engineering.
I wouldn't be surprised if serious security bugs lurked somewhere in it, exploitable by web pages attempting to open maliciously crafted protocol URLs.
- Document scripts are restricted, and can be customized and spoofed (or fully disabled) by the user.
- Whether or not a link can be opened, and whether or not it is asked, depends on user settings. If it is configured to ask, it does so for both known and unknown URI schemes.
- Known and unknown schemes are both considered different origins; they do not redirect to about:blank (unless it is a scheme which is handled by rendering a document, which happens to redirect to about:blank, but it does not normally do this).
- Scripts cannot detect such prompts, and only one can be displayed at a time. One key combination can be used to prevent further prompts; even if a way is found, only one will work anyways.
And many other improvements, because existing web browsers are bad in a lot of ways.
This seems wildly inaccurate for me. On firefox with resistfingerprinting it says I have 23 of the 24 applications installed (I don't, that's more incorrect than correct), and on tor browser it says 0 applications installed (also incorrect, I have a few installed).
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
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.
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.
Super clever to make this exploit work on Chrome by opening a PDF file prior to launching the custom app scheme, in order to activate the Chrome PDF viewer extension, which resets the global flag requiring a user gesture before any custom scheme launch. It didn't track me across Firefox, and Chrome on Windows 10, but it was still cool.
Weird that when I tried running it in chrome headless[0], it opened the popup window, and tried the first scheme, but then stopped, and hung.
> 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.
You are likely relatively unique because you only have Skype installed, whereas a lot of visitors will have more applications out of the list. Someone who has no applications on the list installed may be even more unique, for example.
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 started a little project to mitigate risk like this - run firefox from unprivileged podman container (it will work with docker too). https://github.com/grzegorzk/ff_in_podman
I always get the same ID on the demo because 0 apps are detected :) and this makes the browser unique because not many people run browser on system with 0 apps installed.
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.
Aside from profiling, can these custom URL handlers also be used as an attack vector on other installed applications?
That is, assuming any of those happens to be installed and have a (input sanitation related) vulnerability.
Maybe I'm just seeing ghosts here. But the idea of a web site pushing malicious links to whatever software may also be installed on the same machine, isn't a very comforting thought.
For example, Safari opens the Apple Music without any user prompt. The app itself is designed to handle deep links (such as opening an album or starting the song).
That means you can perform a deep link forgery, in order to force the app to perform unwilling action without user confirmation.
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.
> In a quick search of the web, we couldn’t find any website actively exploiting it but we still felt the need to report it as soon as possible.
I've seen popup-based exploits on less-legal websites (e.g. torrents, keygens, illegal streaming of live sports and/or movies) a few times over the years. I'm unsure if they're executing this specific exploit though.
Firefox on Android has a setting "Open links in apps" and works similar to the way you describe but it's global, either enabled for all websites or disabled for all. I agree that something similar on desktop would be useful.
On Firefox on Windows (same results on Edge) it detected three programs I do have installed, and one I do not, and failed to detect one I do have installed. There was a moderately noticeable small window in the bottom right of the screen in both.
That said, at least for tracking consistency is more important than accuracy.
It seem that Vivaldi have better protection against this than the rest. Running in Vivaldi will cause the demo down to crawl because I think it was trying to find the apps. It detected all of the apps but it failed to appear in the detected list. MacOS Big Sur Apple Silicon if you are wondering
> Safari: Despite privacy being a main development focus for the Safari browser, it turned out to be the easiest browser of the four to exploit. Safari doesn’t have scheme flood protection which allows the exploit to easily enumerate all installed applications. The same-origin policy trick as used for the Firefox browser was used here as well.
On iOS (and MacOS too I believe), when developing apps and requesting URL scheme, the developer has to declare every URL scheme they want their app to query in the `LSApplicationQueriesSchemes` array in info.plist of the app. This was added in iOS 9 as part of a similar vulnerability where apps and advertisement SDKs would simply query a list of URL schemes and then identify based on that across multiple apps. Something similar can be done by browsers for websites. MacOS could simply show you a popup with a checkbox list of all URL schemes the site tries to query for with options for "Allow", "Deny" or "Randomize".
My searching is failing, but I believe a similar scheme was uncovered in a popular app using a 'strings' equivalent. It would run through intents on iOS and Android to figure out what was installed. Interesting to see if on the web too!
Why does this page declare Safari to be the easiest browser to exploit, when it also says it uses the same technique as it does in Firefox (and does not describe any scheme flooding protection in Firefox)?
Mostly because it took hours to make an exploit on Safari compared to days on Firefox, however the final approach ended up the same. Only Chromium has a built-in scheme anti-flooding protection.
Seems like this submission is a bit undercooked. It probably should have been submitted once they had some real world samples or at least gated it to their specific use case
This appears to depend on user interactivity. How would you silently (and accurately) use this technique to fingerprint a system for cross-browser tracking?
It would be trickier, but it's not as hard as one might want to get a user to click in such a way that the protections in place against automated behaviors can be side-stepped.
I'd bet good money that this trick would be useful for anyone running either a meme generator website or a file host, for example. It'd be pretty solid in the file host in particular, because you could hide some of the obvious weird behavior behind the "We're downloading your file" delay.
Clever indeed; I only suspected this the second go-round, after I noticed the reload button flicker as I typed. I also noticed you don't have to press Enter or even type the correct phrase to get past the fake prompt. In hindsight, the easy to guess text should have been a dead give-away, but it wasn't.
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.
As a note, this doesn't seem to work with Brave. It only got one of the applications my machine has installed, and I don't have a slow machine nor a slow internet where I am.
I'm a bit surprised it got even one of them though. I will need to review my Brave privacy settings and see if anything can be done.
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.
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.
Visiting the demo website in Tor Browser (using the 'Safest' setting), the demo site displays this notice:
> If you're seeing this message, that means JavaScript has been disabled on your browser, please enable JS to make this app work.
Does this mean that the vulnerability does not work in Tor Browser in Safest mode? Or are there non-JS implementations of this vulnerability that would work in a browser with JS disabled?
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.
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
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.
It's clever but somewhat obvious (in both a to-the-user-that-its-happening and a "well of course it's possible" sense).
So it's cute, but not practical, and I won't lose sleep over it. I'll probably be more inconvenienced by the mitigations that will surely result that make it that much more painful to actually launch a URL scheme, sadly.
I've actually never checked the "Always open Slack for slack:// links" or similar checkboxes, precisely out of predicting shenanigans like this would happen eventually :)
I wouldn't be too offended if browsers changed the way they handle schemes: always open a "how would you like to handle this link" dialog for any protocol (even if unhandled - like how Windows shows the "how would you like to open this file" dialog), to disguise whether the protocol is handled or not. Not sure I have the answer for user convenience though if someone is used to things automatically opening. That's the "inconvenience" aspect of any potential mitigation, we probably have to get rid of that "remember this choice" checkbox (well, my point is that "have to" is debatable here).