I was expecting an ad for their product somewhere towards the end, but it wasn't there!
I do wonder though: why would this company report this vulnerability to Mozilla if their product is fingeprinting?
Isn't it better for the business (albeit unethical) to keep the vulnerability private, to differentiate from the competitors? For example, I don't see many threat actors burning their zero days through responsible disclosure!
I don't understand what you mean. What separates this from other fingerprinting techniques your company monetizes?
No software wants to be fingerprinted. If it did, it would offer an API with a stable identifier. All fingerprinting is exploiting unintended behavior of the target software or hardware.
It makes sense to me, they're likely not trying to actually fingerprint Tor users. Those users will likely ignore ads, have JS disabled, etc. the real audience is people on the web using normal tooling.
They can just flag all Tor users as high risk. They don't strictly need to fingerprint them when it's generally fine for websites to just block signups for Tor users or require further identification via phone number or something.
You want fingerprinting to identify low risk users to skip the inconvenient security checks.
Most users seem to not care about ad tech/tracking as much as technical users. Even further, most seem to want to enable more tracking to [protect the children or whatever the reason is] pretty regularly (at least in opinion polls about various legislation). ToR users are not at all like that + could be harmed in a very different way... so I think it's fair to frame them differently even if I'd personally say people should be wanting to treat both as similar offenses because neither should be seen as okay in my eyes.
In my experience those users express a mix of surprise and irritation when they get ads about something they did minutes or hours before, but they accept that's the way things are.
I joke that I'm a no-app person, because I install very few apps and I use anti tracking tech on my phone that's even hard to explain or recommend to non technical friends. I use Firefox with uMatrix and uBlock Origin and Blockada. uMatrix is effective but breaks so many sites unless one invests time in playing with the matrix. Blockada breaks many important apps (banking) less one understands whitelisting.
Instead of trying convince-by-assertion, maybe you could try offering an actual objection to the argument raised up-thread?
On what basis do you claim that software developers, who did not establish a means of for third parties to get a stable identifier, nevertheless intended that fingerprinting techniques should work?
1) wanting functionality that isn't provided and working around that
and
2) restoring such functionality in the face of countermeasures
The absence of functionality isn't a clear signal of intent, while countermeasures against said functionality is.
And then there is the distinction between the intent of the software publisher and the intent of the user. There is a big ethical difference between "Mozilla doesn't want advertisers tracking their users" and "those users don't want to be tracked". If these guys want to draw the line at "if there is a signal from the user that they want privacy, we won't track them", I think that's reasonable.
The presence of the "Do Not Track" header was a pretty clear indicator of the intent of the user. Fingerprinting persisted exactly in the face of such countermeasures.
Side channels that enable intended behavior, versus a flat-out bug like the above, though the line can often be muddied by perspective.
An example that comes to mind that I've seen is an anonymous app that allows for blocking users; you can programmatically block users, query all posts, and diff the sets to identify stable identities. However, the ability to block users is desired by the app developers; they just may not have intended this behavior, but there's no immediate solution to this. This is different than 'user_id' simply being returned in the API for no reason, which is a vulnerability. Then there's maybe a case of the user_id being returned in the API for some reason that MIGHT be important too, but that could be implemented another way more sensibly; this leans more towards vulnerability.
Ultimately most fingerprinting technologies use features that are intended behavior; Canvas/font rendering is useful for some web features (and the web target means you have to support a LOT of use cases), IP address/cookies/useragent obviously are useful, etc (though there's some case to be made about Google's pushing for these features as an advertising company!).
A vulnerability is distinct from unintended behavior.
Unintended identification is less than ideal but frankly is just the nature of doing business and any number of niceties are lost by aggressively avoiding fingerprinting.
In software intentionally optimized to avoid any fingerprinting however it is a vulnerability.
The distinction being that fingerprinting in general is a less than ideal side effect that gives you a minor loss in privacy but in something like Tor Browser that fingerprinting can be life or death for a whistleblower, etc. It's the distinction between an annoyance and an execution.
The real reason is that fingerprint.com's selling point is tracking over longer periods (months, their website claims), and this doesn't help them with that.
It means they are suspect. I think its right to be wary of motives if they are involved in the very thing they aim to bring awareness too. Questions arise in my mind as to why they would do something like this in the first place.
Its been my experience that the general public doesn't seem to follow patterns and instead focus on which switch is toggled at any given moment for a company's ethical practices. This is the main reason why we are constantly gamed by orgs that have a big picture view of crowd psychology.
I don't trust them more because of this and maybe they've disclosed it for the wrong reasons, like not allowing a competitor to use it when they don't, but at the end of the day they did disclose a serious issue, and that's good for users.
I understand where you're coming from, by the way, but sometimes the worst person you know does the right thing and it's not fair to criticize them for doing it (you could say nothing, don't have to change your opinion about them, etc). We also don't want someone to go "if I'm bad no matter what I do, then might as well make some money with this" and sell the exploit.
What are you even saying? It's like getting upset at somebody who criticizes a criminal because they once helped some grandma across the street. I'm not upset at the criminal because they helped a grandma across the street obviously that's not the fucking point.
I'm not upset, I just don't think we should criticize someone for doing something good. Maybe they're a terrible org, maybe they deserve criticism most of the time, but not in this instance.
It's not like you can't point out that they did a good deed, but that they're still in the shitty business of fingerprinting users.
Also, if people only get the stick no matter what they do, then eventually some will embrace the dark side and at least make money out of it. And that's not good for you.
It's more like criticising a criminal when they are helping some grandma across the street, thereby treating them more harshly than the criminals that don't do that.
Do you seriously not see the contradiction? I consider all methods that enable fingerprinting, as vulnerabilities that browsers should fix, if we did that it would destroy their business. On top of that a company like that shouldn't be allowed to exist in the first place as a legal entity and it very likely is already operating in a legal grey area in a lot of places. It's the difference between a security company that provides IDS signatures as a service that does responsible disclosure vs. a malware company that offers 0click exploits. Would you praise the NSO group if they did responsible disclosure?
If you take their claim that they don’t use vulnerabilities in their products as true, then I don’t see a contradiction. If it isn’t true, then obviously there is a contradiction.
But your considering of all methods that enable fingerprinting as vulnerabilities is your own opinion. There are definitely measurable signals that are based on a user’s behavior, rather than data exposed by the browser itself.
The OP's link is timing out over Tor for me, but the Wayback[1] version loaded without issue.
Also, does anyone know of any researchers in the academic world focusing on this issue? We are aware that EFF has a project that used to be named after a pedophile on this subject, but we are more looking for professors at universities or pure research labs ala MSR or PARC than activists working for NGOs, however pure their praxis :-)
As privacy geeks, we have become fascinated with the topic -- it seems that while we can achieve security through extensions like noscript or ublock origin or firefox containers (our personal "holy trinity"), anonymity slips through our fingers due to fingerprinting issues. (Especially if we lump stylometry in the big bucket of "fingerprinting".)
> Because the behavior is process-scoped rather than origin-scoped
Hmm, I'm a little confused, since in 2021 Mozilla released experimental one-process-per-site:
> This fundamental redesign of Firefox’s Security architecture extends current security mechanisms by creating operating system process-level boundaries for all sites loaded in Firefox for Desktop
I fantasize having a browser that I can use only for viewing content.
No applications. No mail. No need for cookies.
I can use a "regular" browser for more enhanced stuff. But for simple content consumption, we can just have a "dumb" browser that can't do much.
> A user agent that says the browser's version? Reasonable enough.
No user agent. I'm guessing it will need it for JavaScript or HTML features, and dynamically update if using an old browser, but let's just not supply a user agent and let it be the reader's burden to have a reasonably decent browser.
> Being able to ask for fonts, if the system has them? Difficult to have font support without that.
What's the fallback if the system doesn't have them?
> Getting the user's timezone, language and keyboard layout? Reasonable.
Keyboard layout is irrelevant for viewing content. For timezone and language: Yeah, I can see the use cases, but these are in a small minority. Let there be a popup when requested, and the user can specify the timezone/language as requested.
> The size of the screen, and the size of the browser window? Difficult to lay things out without that.
Let's let this new browser return only from a (small) discrete set of sizes. It will pick the size closest to the actual browser window size and send that.
> Of course a video or audio player needs to know which video formats your browser supports - how else to provide the right video?
Same answer as user agent. Either let the user pick from a selection of video formats, or just hard code a reasonable one and put the onus on the user to have a browser that supports it.
> Obviously javascript can get the time, and it's trivial to figure out the system's clock error by comparing that to the time on a server.
This hypothetical browser could just not send the time :-) For 99% of content consumption, this function is not needed.
What I'm describing should be part of "Private mode". Or browsers should have an "Ultra-private" mode that is the above. If it's too complex/risky maintaining it all in one codebase ... fine. Just have a separate browser.
Right now, if I built such a browser, I'm sure a lot of sites meant for content would break. But in my fantasy world, using "Ultra-private" would be the default, and people who make sites will target them first.
I think much of the complexity in making a web browser is all the "other" stuff. Being able to run apps, cookie/privacy management, etc.
The tor project seeks this bypass this by keeping such things standardized across users, even down to reported screen size. And there is nothing stopping the browser from fibbing as most settings dong matter all that much (ie UK v Canadian v American English).
The most popular browser is made by an ad company. They also provide the majority of funding for their biggest competitor. Why would you expect anything different?
Most stock android phones don't either. You usually get to control precise location, notifications, some background activity, SMS, Calls, Mic, Camera, SD Card, etc.
But most ROMs don't allow controls for WiFi, Cell data, Phone ID, Phone number, User ID, local storage, etc...
It's a fine line between making the web usable, fingerprinting, and peppering the user with dozens or hundreds of permissions.
And since browsers rival OSes for complexity (they are basically OSes in their own right already), any part of the system can be inadvertently exposed and exploited.
This excerpt from the article describes the risk well.
> In Firefox Private Browsing mode, the identifier can also persist after all private windows are closed, as long as the Firefox process remains running. In Tor Browser, the stable identifier persists even through the "New Identity" feature, which is designed to be a full reset that clears cookies and browser history and uses new Tor circuits.
Would it though? I guess state agencies already know all nodes or may know all nodes. When you have a ton of meta-information all cross-linked, they can probably identify people quite accurately; may not even need 100% accuracy at all times and could do with less. I was thinking about that when they used information from any surrounding area or even sniffing through walls (I think? I don't quite recall the article but wasn't there an article like that in the last 3-5 years? The idea is to amass as much information as possible, even if it may not primarily have to do with solely the target user alone; e. g. I would call it "identify via proxy information").
Honestly it seems that most of Web Standards are used mostly for fingerprinting - I think a small number of websites uses IndexedDB (who even needs it) for actually storing data rather than fingerprinting.
That's why expansion of web standards is wrong. Browser should provide minimal APIs for interacting with device and features like IndexedDB can be implemented as WebAssembly library, leaking no valuable data.
For example, if canvas provided only access to picture buffer, and no drawing routines calling into platform-specific libraries, it would become useless for fingerprinting.
You can use a browser extension like "Local Storage Editor" to see the contents of the Local Storage of a website. So far, I've seen it used for caching long-life images (like on gmail), or used as another way to do logins instead of cookies.
There's an instructive example on the page. Suppose a page creates the databases `a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p`, then queries their order. They might get, for example `g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k`, based on the global mapping of database names to UUIDs.
The key vulnerability here is that, for the lifetime of that Firefox process, any website that makes that set of databases is going to see the exact same output ordering, no matter what the contents of those databases are. That makes this a fingerprint: it's a stable, high-entropy identifier that persists across time, even if the contents of those databases are not preserved. It is shared even across origins (where the contents would not be), and preserved after website data is deleted -- all a website has to do to re-acquire the fingerprint is recreate the databases with the same names and observe their ordering.
As I understood not ANY website can see it. But the same website can see it regardless if you reset your identity in Tor Browser.
So it persists between anonymous sessions.
So you could connect User A that logged out and reset the identity to User B who believed was using a fresh anonymous session and logged in afterwards.
No, it does allow identification across different websites (the article says "both cross-origin and same-origin tracking"). Both websites just need to create some databases with the same names. Since the databases are origin-scoped, these aren't the same databases, so you can't just write some data into one and read it on another website. But it turns out that if two websites use the same names for all these databases, the order the list of databases is returned in is random-per-user but the same regardless of website.
It's the mapping of UUIDs to databases that is shared across origins in the browser. Only the subset of databases associated with an origin are exposed to that origin.
Disabling JavaScript actually greatly increases your fingerprint as not many users turn it off, so that instantly puts you in a much smaller bucket that you need to be unique in. Yes, not having JS means it limits your options for gathering other details, but it also requires much less effort to be unique now without JS.
Tor Browser also doesn't spoof navigator.platform at all for some reason, so sites can still see when you use Linux, even if the User-Agent is spoofing Windows.
> Disabling JavaScript actually greatly increases your fingerprint as not many users turn it off, so that instantly puts you in a much smaller bucket that you need to be unique in.
I've heard a handful of people say this but are there examples of what I would imagine would have to be server-side fingerprinting and the granularity? Since most fingerprinting I'm aware of is client-side, running via JS. While I expect server-side checks to be limited to things like which resources haven't be loaded by a particular user and anything else normally available via server logs either way, which could limit the pool but I wonder how effective in terms of tracking uniqueness across sites.
In addition to server-side bits like IP address, request headers and TLS/TCP fingerprints, there are some client-side things you can do such as with media queries, either via CSS styles or elements that support them directly like <picture>. You can get things like the installed fonts, screen size/type or platform/browser-specific identifiers.
I have my problems with that argument. Yes, less identifying bits means a smaller bucket but for the trackers, it also means more uncertainty, doesnt it? So when just a few others without JS join your bucket eg. via a VPN, profiling should become harder.
> increases your fingerprint as not many users turn it off
We're talking about users of the Tor browser, and I'd be very surprised if this was the case (that a majority keep JS turned on)
Basically every Tor guide (heh) tells you to turn it off because it's a huge vector for all types of attacks. Most onion sites have captcha systems that work without JS too which would indicate that they expect a majority to have it disabled.
I would imagine most users of Tor are using Tor Browser. I am reading there was a responsible disclosure to Mozilla but is it me or did that section leave out when the Tor Project planned to respond or release a fixed Tor Browser? Do they like keep very close or is there a large lag?
The best for Tor would just be Links2/Links+ with the socks4a proxy set to 127.0.0.1:9050, enforcing all connection thru a proxy in the settings (mark the checkbox) and disabling cookies altogether.
> It seems Qubes OS and Qubes-Whonix are not affected.
This is dangerously incomplete and bad advice.
Qubes OS does not work the way you seem to think it does.
Creating a new identity in the Tor Browser inside a disposable VM does not automatically stop that VM and start a new disposable VM. That initial disposable VM launches the new identity from the existing process and therefore remains vulnerable, the same as any bare metal computer running Tor Browser would.
Virtualization is not magic.
A Qubes OS user needs to spin up a new disposable Whonix VM to sidestep this attack. Creating a new identity alone is ineffective in this threat model.
If you care about these projects as much as you say you do, please stop giving harmful advice. You do it in various places on the Internet and in every thread which gives you half a chance to do so, and these projects would be better off if you either took any of the extensive well-reasoned correction many people offer you, or opted to stop engaging. The former would be ideal, the latter lamentably preferable to the existing state of affairs.
I believe you are correct, and that this poses a significant risk for people who don't properly understand the underlying concepts.
A Qubes OS user needs to spawn a new disposable Whonix workstation VM to sidestep this attack, NOT create a new identity in the same disposable VM's browser, which is exactly what this attack targets.
On Qubes, you do not create a new identity in the same VM. This would go against the Qubes approach to security/privacy. Using separate VMs for independent tasks is the whole point of using Qubes.
> On Qubes, you do not create a new identity in the same VM. This would go against the Qubes approach to security/privacy. Using separate VMs for independent tasks is the whole point of using Qubes.
This is technically incorrect information and could get people in trouble if followed literally.
On Qubes OS, if a user creates a new identity inside a Whonix workstation disposable VM via the browser's new identity functionality, the new identity spawns within the same disposable VM. I just tested this on Qubes OS 4.3.
That, I assume would expose one to OP's vulnerability, as its still running in the same VM. I would be glad to learn that I'm incorrect in my unverified assumption.
Even Qubes OS users still need to be mindful to launch new disposable VM when keeping identities separate to sidestep this attack.
In the last ten years has qubes moved on to support more hardware? Every 4 years I would try to use it only to find it didn't support any of my hardware.
Qubes OS hardware support, while still far from perfect, is vastly better than it was ten years ago.
Joanna Rutkowska's understandable preference for older kernels had its advantages, but the current team is much more likely to ship somewhat newer kernels and I've been surprised by what hardware 4.3 has worked well on.
Beyond that, I'm currently running a kernel from late Feb/early Mar (6.19.5).
Driver support can still be an issue, and a Wi-Fi card that doesn't play nice with Linux in general is doing to be no different on Qubes OS.
We buy off the shelf laptops, not sure anyone ever checked that it can run Qubes specifically before trying to install it (I'm sure of at least one person: myself). Doesn't just about any x64 machine with hardware where drivers are available in standard kernels also work with Qubes? What have you bought that's not supported?
Most hardware (especially GPUs) is hard to virtualize in a secure manner, which is the entire point of Qubes. People who use it typically buy compatible hardware.
Tested hardware can be found here https://qubes-os.org/hcl. New hardware is being constantly added. If you plan to switch to Qubes, consider buying something from that list or, better, certified, or community-recommended hardware linked there.
> For developers, this is a useful reminder that privacy bugs do not always come from direct access to identifying data. Sometimes they come from deterministic exposure of internal implementation details.
> For security and product stakeholders, the key point is simple: even an API that appears harmless can become a cross-site tracking vector if it leaks stable process-level state.
This reads almost LLM-ish. The article on the whole does not appear so, but parts of it do.
Well that sucks. I guess in the long run we need a new engine and different approach. Someone should call the OpenBSD guys to come up with working ideas here.
> Mozilla has quickly released the fix in Firefox 150 and ESR 140.10.0, and the patch is tracked in Mozilla Bug 2024220.
Did you even read the article at all? Ah my children did bad in school, time to replace them with new children and a different spouse. This is what you're suggesting essentially. A browser is not just something you simply make out of thin air. There's decades of nuance to browser engines, and I'm only thinking of the HTML nuances, not the CSS or JS nuances.
Given the dangers of JS and WASM they could just fork Netsurf and enhance the CSS3 support. If you are a journalist, running Tor with JS and tons of modern web tech enable makes you a bright white spot in a sea of darkness.
You should note that improperly using Qubes OS, creating a New Identity inside of Tor Browser, even in a disposable Whonix workstation VM, would leave one vulnerable to this.
A user would have to manually spawn a new disposable VM for each identity.
>Physical isolation is a given safeguard that the digital world lacks
…
>In our digital lives, the situation is quite different: All of our activities typically happen on a single device. This causes us to worry about whether it’s safe to click on a link or install an app, since being hacked imperils our entire digital existence.
>Qubes eliminates this concern by allowing us to divide a device into many compartments, much as we divide a physical building into many rooms. …
Qubes OS is a great solution for this threat model. By my (admittedly cursory) understanding of this attack, one would have to chain the attack to escalate to dom0 to get around it.
Having said that, fsflover exhibits a poor grasp of how this stuff works and all should be aware that even in Qubes OS, one would need to spawn new disposable VMs for each identity; relying on the Tor Browser's new identity creation within the same disposable VM would be little different from running Tor Browser on a traditional OS.
Stil, nobody should feel great browsing the web in dom0.
Very cool research and wonderfully written.
I was expecting an ad for their product somewhere towards the end, but it wasn't there!
I do wonder though: why would this company report this vulnerability to Mozilla if their product is fingeprinting?
Isn't it better for the business (albeit unethical) to keep the vulnerability private, to differentiate from the competitors? For example, I don't see many threat actors burning their zero days through responsible disclosure!
We don't use vulnerabilities in our products.
I don't understand what you mean. What separates this from other fingerprinting techniques your company monetizes?
No software wants to be fingerprinted. If it did, it would offer an API with a stable identifier. All fingerprinting is exploiting unintended behavior of the target software or hardware.
It makes sense to me, they're likely not trying to actually fingerprint Tor users. Those users will likely ignore ads, have JS disabled, etc. the real audience is people on the web using normal tooling.
They can just flag all Tor users as high risk. They don't strictly need to fingerprint them when it's generally fine for websites to just block signups for Tor users or require further identification via phone number or something.
You want fingerprinting to identify low risk users to skip the inconvenient security checks.
Uhh okay, so they do exploit vulnerabilities, they just try to target victims who can be served ads? What a weird distinction.
Most users seem to not care about ad tech/tracking as much as technical users. Even further, most seem to want to enable more tracking to [protect the children or whatever the reason is] pretty regularly (at least in opinion polls about various legislation). ToR users are not at all like that + could be harmed in a very different way... so I think it's fair to frame them differently even if I'd personally say people should be wanting to treat both as similar offenses because neither should be seen as okay in my eyes.
In my experience those users express a mix of surprise and irritation when they get ads about something they did minutes or hours before, but they accept that's the way things are.
I joke that I'm a no-app person, because I install very few apps and I use anti tracking tech on my phone that's even hard to explain or recommend to non technical friends. I use Firefox with uMatrix and uBlock Origin and Blockada. uMatrix is effective but breaks so many sites unless one invests time in playing with the matrix. Blockada breaks many important apps (banking) less one understands whitelisting.
Well presumably they want to make money.
Painting fingerprinting as vulnerability exploit is your own very biased and very out-of-norm framing.
Instead of trying convince-by-assertion, maybe you could try offering an actual objection to the argument raised up-thread?
On what basis do you claim that software developers, who did not establish a means of for third parties to get a stable identifier, nevertheless intended that fingerprinting techniques should work?
There's a pretty big difference between:
1) wanting functionality that isn't provided and working around that
and
2) restoring such functionality in the face of countermeasures
The absence of functionality isn't a clear signal of intent, while countermeasures against said functionality is.
And then there is the distinction between the intent of the software publisher and the intent of the user. There is a big ethical difference between "Mozilla doesn't want advertisers tracking their users" and "those users don't want to be tracked". If these guys want to draw the line at "if there is a signal from the user that they want privacy, we won't track them", I think that's reasonable.
The presence of the "Do Not Track" header was a pretty clear indicator of the intent of the user. Fingerprinting persisted exactly in the face of such countermeasures.
How would you frame it?
Side channels that enable intended behavior, versus a flat-out bug like the above, though the line can often be muddied by perspective.
An example that comes to mind that I've seen is an anonymous app that allows for blocking users; you can programmatically block users, query all posts, and diff the sets to identify stable identities. However, the ability to block users is desired by the app developers; they just may not have intended this behavior, but there's no immediate solution to this. This is different than 'user_id' simply being returned in the API for no reason, which is a vulnerability. Then there's maybe a case of the user_id being returned in the API for some reason that MIGHT be important too, but that could be implemented another way more sensibly; this leans more towards vulnerability.
Ultimately most fingerprinting technologies use features that are intended behavior; Canvas/font rendering is useful for some web features (and the web target means you have to support a LOT of use cases), IP address/cookies/useragent obviously are useful, etc (though there's some case to be made about Google's pushing for these features as an advertising company!).
Iffy vs grossly unethical.
A vulnerability is distinct from unintended behavior.
Unintended identification is less than ideal but frankly is just the nature of doing business and any number of niceties are lost by aggressively avoiding fingerprinting.
In software intentionally optimized to avoid any fingerprinting however it is a vulnerability.
The distinction being that fingerprinting in general is a less than ideal side effect that gives you a minor loss in privacy but in something like Tor Browser that fingerprinting can be life or death for a whistleblower, etc. It's the distinction between an annoyance and an execution.
The real reason is that fingerprint.com's selling point is tracking over longer periods (months, their website claims), and this doesn't help them with that.
All fingerprinting is a vulnerability, unless the client opts-in.
So it's the criminal that convinced themselves they are the good guys, I didn't expect that one. You are a malware company get a grip.
Would you prefer that they kept this for themselves instead of disclosing it?
I get criticizing their business and what they do wrong, but doesn't seem right to criticizing them for doing the right thing.
It means they are suspect. I think its right to be wary of motives if they are involved in the very thing they aim to bring awareness too. Questions arise in my mind as to why they would do something like this in the first place.
Its been my experience that the general public doesn't seem to follow patterns and instead focus on which switch is toggled at any given moment for a company's ethical practices. This is the main reason why we are constantly gamed by orgs that have a big picture view of crowd psychology.
I don't trust them more because of this and maybe they've disclosed it for the wrong reasons, like not allowing a competitor to use it when they don't, but at the end of the day they did disclose a serious issue, and that's good for users.
I understand where you're coming from, by the way, but sometimes the worst person you know does the right thing and it's not fair to criticize them for doing it (you could say nothing, don't have to change your opinion about them, etc). We also don't want someone to go "if I'm bad no matter what I do, then might as well make some money with this" and sell the exploit.
What are you even saying? It's like getting upset at somebody who criticizes a criminal because they once helped some grandma across the street. I'm not upset at the criminal because they helped a grandma across the street obviously that's not the fucking point.
I'm not upset, I just don't think we should criticize someone for doing something good. Maybe they're a terrible org, maybe they deserve criticism most of the time, but not in this instance.
It's not like you can't point out that they did a good deed, but that they're still in the shitty business of fingerprinting users.
Also, if people only get the stick no matter what they do, then eventually some will embrace the dark side and at least make money out of it. And that's not good for you.
It's more like criticising a criminal when they are helping some grandma across the street, thereby treating them more harshly than the criminals that don't do that.
(Also known as the "Copenhagen Interpretation of Ethics": https://gwern.net/doc/philosophy/ethics/2015-06-24-jai-theco... )
Responsible disclosure and commercial fingerprinting aren't contradictory.
Do you seriously not see the contradiction? I consider all methods that enable fingerprinting, as vulnerabilities that browsers should fix, if we did that it would destroy their business. On top of that a company like that shouldn't be allowed to exist in the first place as a legal entity and it very likely is already operating in a legal grey area in a lot of places. It's the difference between a security company that provides IDS signatures as a service that does responsible disclosure vs. a malware company that offers 0click exploits. Would you praise the NSO group if they did responsible disclosure?
Fucking HN sheep
If you take their claim that they don’t use vulnerabilities in their products as true, then I don’t see a contradiction. If it isn’t true, then obviously there is a contradiction.
But your considering of all methods that enable fingerprinting as vulnerabilities is your own opinion. There are definitely measurable signals that are based on a user’s behavior, rather than data exposed by the browser itself.
It's a little bit disingenuous to call intentional wont-fix features "vulnerabilities".
They probably are not relying on it and disclosure means others can't either.
> the identifier can also persist [...] as long as the Firefox process remains running
Make sure to exit Tor Browser at the end of a session. Make sure not to mix two uses in one session.
The OP's link is timing out over Tor for me, but the Wayback[1] version loaded without issue.
Also, does anyone know of any researchers in the academic world focusing on this issue? We are aware that EFF has a project that used to be named after a pedophile on this subject, but we are more looking for professors at universities or pure research labs ala MSR or PARC than activists working for NGOs, however pure their praxis :-)
As privacy geeks, we have become fascinated with the topic -- it seems that while we can achieve security through extensions like noscript or ublock origin or firefox containers (our personal "holy trinity"), anonymity slips through our fingers due to fingerprinting issues. (Especially if we lump stylometry in the big bucket of "fingerprinting".)
[1] https://web.archive.org/web/20260422190706/https://fingerpri...
yes, there’s an active area of research on web fingerprint, both attacks and defences. Look at conferences like PETS for instance
> Because the behavior is process-scoped rather than origin-scoped
Hmm, I'm a little confused, since in 2021 Mozilla released experimental one-process-per-site:
> This fundamental redesign of Firefox’s Security architecture extends current security mechanisms by creating operating system process-level boundaries for all sites loaded in Firefox for Desktop
https://blog.mozilla.org/security/2021/05/18/introducing-sit...
Perhaps that is not fully released?
Or perhaps it is, but IndexedDB happens to live outside of that isolation?
https://news.ycombinator.com/item?id=47868736 helps me understand that there's a sliver of behaviour that happens to be global, and this thus allows fingerprinting.
If so, cool!
I question why websites can even access all this info without asking or notifying the user.
Why don't browsers make it like phones where the server (app) has to be granted permission to access stuff?
Browser fingerprinting is an unintended side-effect of things it's sorta-kinda reasonable for browsers to provide.
A user agent that says the browser's version? Reasonable enough.
Being able to ask for fonts, if the system has them? Difficult to have font support without that.
Getting the user's timezone, language and keyboard layout? Reasonable.
The size of the screen, and the size of the browser window? Difficult to lay things out without that.
Of course a video or audio player needs to know which video formats your browser supports - how else to provide the right video?
Obviously javascript can get the time, and it's trivial to figure out the system's clock error by comparing that to the time on a server.
Before you know it, almost every browser is uniquely identifiable.
I fantasize having a browser that I can use only for viewing content.
No applications. No mail. No need for cookies.
I can use a "regular" browser for more enhanced stuff. But for simple content consumption, we can just have a "dumb" browser that can't do much.
> A user agent that says the browser's version? Reasonable enough.
No user agent. I'm guessing it will need it for JavaScript or HTML features, and dynamically update if using an old browser, but let's just not supply a user agent and let it be the reader's burden to have a reasonably decent browser.
> Being able to ask for fonts, if the system has them? Difficult to have font support without that.
What's the fallback if the system doesn't have them?
> Getting the user's timezone, language and keyboard layout? Reasonable.
Keyboard layout is irrelevant for viewing content. For timezone and language: Yeah, I can see the use cases, but these are in a small minority. Let there be a popup when requested, and the user can specify the timezone/language as requested.
> The size of the screen, and the size of the browser window? Difficult to lay things out without that.
Let's let this new browser return only from a (small) discrete set of sizes. It will pick the size closest to the actual browser window size and send that.
> Of course a video or audio player needs to know which video formats your browser supports - how else to provide the right video?
Same answer as user agent. Either let the user pick from a selection of video formats, or just hard code a reasonable one and put the onus on the user to have a browser that supports it.
> Obviously javascript can get the time, and it's trivial to figure out the system's clock error by comparing that to the time on a server.
This hypothetical browser could just not send the time :-) For 99% of content consumption, this function is not needed.
What I'm describing should be part of "Private mode". Or browsers should have an "Ultra-private" mode that is the above. If it's too complex/risky maintaining it all in one codebase ... fine. Just have a separate browser.
Right now, if I built such a browser, I'm sure a lot of sites meant for content would break. But in my fantasy world, using "Ultra-private" would be the default, and people who make sites will target them first.
I think much of the complexity in making a web browser is all the "other" stuff. Being able to run apps, cookie/privacy management, etc.
The tor project seeks this bypass this by keeping such things standardized across users, even down to reported screen size. And there is nothing stopping the browser from fibbing as most settings dong matter all that much (ie UK v Canadian v American English).
The most popular browser is made by an ad company. They also provide the majority of funding for their biggest competitor. Why would you expect anything different?
most people would expect something different from tor, surely.
The purpose of a system is what it does.
Hah. It's still better than apps.
Apps have access to inconceivable amounts of identifiers and device characteristics, even on the well protected systems without Google Play services.
>Why don't browsers make it like phones where the server (app) has to be granted permission to access stuff?
Like Android phones perhaps? Unfortunate Apple gives very little granular control.
Most stock android phones don't either. You usually get to control precise location, notifications, some background activity, SMS, Calls, Mic, Camera, SD Card, etc.
But most ROMs don't allow controls for WiFi, Cell data, Phone ID, Phone number, User ID, local storage, etc...
all these permission you have to accept?
It's a fine line between making the web usable, fingerprinting, and peppering the user with dozens or hundreds of permissions.
And since browsers rival OSes for complexity (they are basically OSes in their own right already), any part of the system can be inadvertently exposed and exploited.
I mean Google ain't paying for Chromium development just for the fun of it...
From the sounds of this it sounds like it doesn't persist past browser restart? I think that would significantly reduce the usefulness to attackers.
This excerpt from the article describes the risk well.
> In Firefox Private Browsing mode, the identifier can also persist after all private windows are closed, as long as the Firefox process remains running. In Tor Browser, the stable identifier persists even through the "New Identity" feature, which is designed to be a full reset that clears cookies and browser history and uses new Tor circuits.
This is where you use id bridging.
1. Website fingerprints the browser, stores a cookie with an ID and a fingerprint.
2. During the next session, it fingerprints again and compares with the cookie. If fingerprint changed, notify server about old and new fingerprint.
Many users leave their browsers open for months.
Privacy and security conscious Tor users don’t.
Would it though? I guess state agencies already know all nodes or may know all nodes. When you have a ton of meta-information all cross-linked, they can probably identify people quite accurately; may not even need 100% accuracy at all times and could do with less. I was thinking about that when they used information from any surrounding area or even sniffing through walls (I think? I don't quite recall the article but wasn't there an article like that in the last 3-5 years? The idea is to amass as much information as possible, even if it may not primarily have to do with solely the target user alone; e. g. I would call it "identify via proxy information").
> I guess state agencies already know all nodes or may know all nodes.
Assume the same.
>The idea is to amass as much information as possible
Reminded, from 2012: https://www.wired.com/2012/03/ff-nsadatacenter/
Honestly it seems that most of Web Standards are used mostly for fingerprinting - I think a small number of websites uses IndexedDB (who even needs it) for actually storing data rather than fingerprinting.
That's why expansion of web standards is wrong. Browser should provide minimal APIs for interacting with device and features like IndexedDB can be implemented as WebAssembly library, leaking no valuable data.
For example, if canvas provided only access to picture buffer, and no drawing routines calling into platform-specific libraries, it would become useless for fingerprinting.
You can use a browser extension like "Local Storage Editor" to see the contents of the Local Storage of a website. So far, I've seen it used for caching long-life images (like on gmail), or used as another way to do logins instead of cookies.
> You can use a browser extension like "Local Storage Editor" to see the contents of the Local Storage of a website.
Or just open dev tools
I'm confused.
The IndexedDB UUID is "shared across all origins", so why not use the contents of the database to identify browers, rather than the ordering?
There's an instructive example on the page. Suppose a page creates the databases `a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p`, then queries their order. They might get, for example `g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k`, based on the global mapping of database names to UUIDs.
The key vulnerability here is that, for the lifetime of that Firefox process, any website that makes that set of databases is going to see the exact same output ordering, no matter what the contents of those databases are. That makes this a fingerprint: it's a stable, high-entropy identifier that persists across time, even if the contents of those databases are not preserved. It is shared even across origins (where the contents would not be), and preserved after website data is deleted -- all a website has to do to re-acquire the fingerprint is recreate the databases with the same names and observe their ordering.
As I understood not ANY website can see it. But the same website can see it regardless if you reset your identity in Tor Browser.
So it persists between anonymous sessions. So you could connect User A that logged out and reset the identity to User B who believed was using a fresh anonymous session and logged in afterwards.
No, it does allow identification across different websites (the article says "both cross-origin and same-origin tracking"). Both websites just need to create some databases with the same names. Since the databases are origin-scoped, these aren't the same databases, so you can't just write some data into one and read it on another website. But it turns out that if two websites use the same names for all these databases, the order the list of databases is returned in is random-per-user but the same regardless of website.
The content is obviously scoped to an origin, or IndexedDB would be a trivial evercookie.
It's the mapping of UUIDs to databases that is shared across origins in the browser. Only the subset of databases associated with an origin are exposed to that origin.
Does Tor Browser still allow JavaScript by default? Because if you block execution of JavaScript, you won't be affected from what I understand.
Disabling JavaScript actually greatly increases your fingerprint as not many users turn it off, so that instantly puts you in a much smaller bucket that you need to be unique in. Yes, not having JS means it limits your options for gathering other details, but it also requires much less effort to be unique now without JS.
Tor Browser also doesn't spoof navigator.platform at all for some reason, so sites can still see when you use Linux, even if the User-Agent is spoofing Windows.
> Disabling JavaScript actually greatly increases your fingerprint as not many users turn it off, so that instantly puts you in a much smaller bucket that you need to be unique in.
I've heard a handful of people say this but are there examples of what I would imagine would have to be server-side fingerprinting and the granularity? Since most fingerprinting I'm aware of is client-side, running via JS. While I expect server-side checks to be limited to things like which resources haven't be loaded by a particular user and anything else normally available via server logs either way, which could limit the pool but I wonder how effective in terms of tracking uniqueness across sites.
In addition to server-side bits like IP address, request headers and TLS/TCP fingerprints, there are some client-side things you can do such as with media queries, either via CSS styles or elements that support them directly like <picture>. You can get things like the installed fonts, screen size/type or platform/browser-specific identifiers.
https://fingerprint.com/blog/disabling-javascript-wont-stop-...
There is also a method of fingerprinting using the favicon: https://github.com/jonasstrehle/supercookie
I have my problems with that argument. Yes, less identifying bits means a smaller bucket but for the trackers, it also means more uncertainty, doesnt it? So when just a few others without JS join your bucket eg. via a VPN, profiling should become harder.
> increases your fingerprint as not many users turn it off
We're talking about users of the Tor browser, and I'd be very surprised if this was the case (that a majority keep JS turned on)
Basically every Tor guide (heh) tells you to turn it off because it's a huge vector for all types of attacks. Most onion sites have captcha systems that work without JS too which would indicate that they expect a majority to have it disabled.
Tails (without persistent storage) will mitigate this though. I'm not too concerned.
I'm not sure it will. The problem in Tor here is that the ordering persists beyond "New Identity". It does not persist between browser restarts.
I would imagine most users of Tor are using Tor Browser. I am reading there was a responsible disclosure to Mozilla but is it me or did that section leave out when the Tor Project planned to respond or release a fixed Tor Browser? Do they like keep very close or is there a large lag?
Tor Browser is always quick to rebase on the latest Firefox ESR. They released an update the next day:
https://blog.torproject.org/new-release-tor-browser-15010/
The best for Tor would just be Links2/Links+ with the socks4a proxy set to 127.0.0.1:9050, enforcing all connection thru a proxy in the settings (mark the checkbox) and disabling cookies altogether.
Would whonix fit that bill?
It seems Qubes OS and Qubes-Whonix are not affected.
> It seems Qubes OS and Qubes-Whonix are not affected.
This is dangerously incomplete and bad advice.
Qubes OS does not work the way you seem to think it does.
Creating a new identity in the Tor Browser inside a disposable VM does not automatically stop that VM and start a new disposable VM. That initial disposable VM launches the new identity from the existing process and therefore remains vulnerable, the same as any bare metal computer running Tor Browser would.
Virtualization is not magic.
A Qubes OS user needs to spin up a new disposable Whonix VM to sidestep this attack. Creating a new identity alone is ineffective in this threat model.
If you care about these projects as much as you say you do, please stop giving harmful advice. You do it in various places on the Internet and in every thread which gives you half a chance to do so, and these projects would be better off if you either took any of the extensive well-reasoned correction many people offer you, or opted to stop engaging. The former would be ideal, the latter lamentably preferable to the existing state of affairs.
How so? If you kept a disposable VM open and just created new identities in tor browser, how does Qubes mitigate the threat here?
I believe you are correct, and that this poses a significant risk for people who don't properly understand the underlying concepts.
A Qubes OS user needs to spawn a new disposable Whonix workstation VM to sidestep this attack, NOT create a new identity in the same disposable VM's browser, which is exactly what this attack targets.
On Qubes, you do not create a new identity in the same VM. This would go against the Qubes approach to security/privacy. Using separate VMs for independent tasks is the whole point of using Qubes.
> On Qubes, you do not create a new identity in the same VM. This would go against the Qubes approach to security/privacy. Using separate VMs for independent tasks is the whole point of using Qubes.
This is technically incorrect information and could get people in trouble if followed literally.
On Qubes OS, if a user creates a new identity inside a Whonix workstation disposable VM via the browser's new identity functionality, the new identity spawns within the same disposable VM. I just tested this on Qubes OS 4.3.
That, I assume would expose one to OP's vulnerability, as its still running in the same VM. I would be glad to learn that I'm incorrect in my unverified assumption.
Even Qubes OS users still need to be mindful to launch new disposable VM when keeping identities separate to sidestep this attack.
In the last ten years has qubes moved on to support more hardware? Every 4 years I would try to use it only to find it didn't support any of my hardware.
Qubes OS hardware support, while still far from perfect, is vastly better than it was ten years ago.
Joanna Rutkowska's understandable preference for older kernels had its advantages, but the current team is much more likely to ship somewhat newer kernels and I've been surprised by what hardware 4.3 has worked well on.
Beyond that, I'm currently running a kernel from late Feb/early Mar (6.19.5).
Driver support can still be an issue, and a Wi-Fi card that doesn't play nice with Linux in general is doing to be no different on Qubes OS.
We buy off the shelf laptops, not sure anyone ever checked that it can run Qubes specifically before trying to install it (I'm sure of at least one person: myself). Doesn't just about any x64 machine with hardware where drivers are available in standard kernels also work with Qubes? What have you bought that's not supported?
Actually, it should work indeed, unless it lacks some Linux drivers or VT-d.
No problems on framework laptop that I've run into at least.
Most hardware (especially GPUs) is hard to virtualize in a secure manner, which is the entire point of Qubes. People who use it typically buy compatible hardware.
I would expect that most Qubes users (including myself) do not virtualize GPUs and use the CPU to render graphics outside of dom0.
Tested hardware can be found here https://qubes-os.org/hcl. New hardware is being constantly added. If you plan to switch to Qubes, consider buying something from that list or, better, certified, or community-recommended hardware linked there.
Source?
Different VMs result in different identifiers.
Creating a new identity in the browser in a disposable VM does not spawn a new disposable VM.
> For developers, this is a useful reminder that privacy bugs do not always come from direct access to identifying data. Sometimes they come from deterministic exposure of internal implementation details.
> For security and product stakeholders, the key point is simple: even an API that appears harmless can become a cross-site tracking vector if it leaks stable process-level state.
This reads almost LLM-ish. The article on the whole does not appear so, but parts of it do.
Well that sucks. I guess in the long run we need a new engine and different approach. Someone should call the OpenBSD guys to come up with working ideas here.
> Mozilla has quickly released the fix in Firefox 150 and ESR 140.10.0, and the patch is tracked in Mozilla Bug 2024220.
Did you even read the article at all? Ah my children did bad in school, time to replace them with new children and a different spouse. This is what you're suggesting essentially. A browser is not just something you simply make out of thin air. There's decades of nuance to browser engines, and I'm only thinking of the HTML nuances, not the CSS or JS nuances.
Given the dangers of JS and WASM they could just fork Netsurf and enhance the CSS3 support. If you are a journalist, running Tor with JS and tons of modern web tech enable makes you a bright white spot in a sea of darkness.
Here you go: https://qubes-os.org.
You should note that improperly using Qubes OS, creating a New Identity inside of Tor Browser, even in a disposable Whonix workstation VM, would leave one vulnerable to this.
A user would have to manually spawn a new disposable VM for each identity.
>Why Qubes OS?
>Physical isolation is a given safeguard that the digital world lacks
…
>In our digital lives, the situation is quite different: All of our activities typically happen on a single device. This causes us to worry about whether it’s safe to click on a link or install an app, since being hacked imperils our entire digital existence.
>Qubes eliminates this concern by allowing us to divide a device into many compartments, much as we divide a physical building into many rooms. …
Sold
https://doc.qubes-os.org/en/latest/introduction/intro.html
Qubes OS is a great solution for this threat model. By my (admittedly cursory) understanding of this attack, one would have to chain the attack to escalate to dom0 to get around it.
Having said that, fsflover exhibits a poor grasp of how this stuff works and all should be aware that even in Qubes OS, one would need to spawn new disposable VMs for each identity; relying on the Tor Browser's new identity creation within the same disposable VM would be little different from running Tor Browser on a traditional OS.
Stil, nobody should feel great browsing the web in dom0.