Live data from Hacker News

We found a stable Firefox identifier linking all your private Tor identities

fingerprint.com

31–40 of 306 posts

Re: We found a stable Firefox identifier linking all your private Tor identities

#31
post #19
post #15

Earlier quoted context omitted.

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.

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!).

Re: We found a stable Firefox identifier linking all your private Tor identities

#32
post #25

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?

The content is obviously scoped to an origin, or IndexedDB would be a trivial evercookie.

Re: We found a stable Firefox identifier linking all your private Tor identities

#33
post #28

Earlier quoted context omitted.

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.

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.

Re: We found a stable Firefox identifier linking all your private Tor identities

#35
post #4

It seems Qubes OS and Qubes-Whonix are not affected.

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.

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.

Re: We found a stable Firefox identifier linking all your private Tor identities

#36
post #19

Earlier quoted context omitted.

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.

Uhh okay, so they do exploit vulnerabilities, they just try to target victims who can be served ads? What a weird distinction.

Re: We found a stable Firefox identifier linking all your private Tor identities

#38

Earlier quoted context omitted.

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.

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.

Re: We found a stable Firefox identifier linking all your private Tor identities

#39
post #15

Earlier quoted context omitted.

We don't use vulnerabilities in our products.

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.

Re: We found a stable Firefox identifier linking all your private Tor identities

#40
post #25

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.

Post reply on HN