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!

Being fingerprinted across Tor is different from being deanonymized—it basically just "psuedonomizes" you. You now have an identifier. It is a significant threat, but it is not hard to "psuedonomize" someone based on stylometry and some of the people with the highest threat model—operating an illegal site, will be pseudonymous anyway.

Don't get your opsec advice from HN. Check whonix, qubes, grapheneos, kicksecure forums/wikis. Nihilist opsec, Privacyguides.

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

I learned enough about security years ago that there's basically zero chance you're secure and almost 100% chance someone is watch everything you do online.

Whether they care is entirely separate.

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.

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

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?

> 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?

> ...stored in the global StorageDatabaseNameHashtable. > This mapping: > - Is keyed only by the database name string > ... > - Is shared across all origins

Why is this global keyed only by the database name string in the first place?

The post mentions a generated UUID, why not use that instead, and have a per-origin mapping of database names to UUID somewhere? Or even just have separate hash-tables for each origin? Seems like a cleaner fix to me compared to sorting (imo, though admittedly, more of a complex fix with architectural changes)

Seems to me that having a global hashtable that shares information from all origins is asking for trouble, though I'm sure there is a good explanation for this (performance, historical reasons, some benefits of this architecture I'm not aware of, etc.).

Does Tor Browser still allow JavaScript by default? Because if you block execution of JavaScript, you won't be affected from what I understand.

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.

Why is Firefox DB open-source MPLv2.0 running .cpp indexedDBdatabses() script on the API:

namespace mozilla {

namespace dom::indexedDB {

using namespace mozilla::dom::quota;

using namespace mozilla::ipc;

using mozilla::dom::quota::Client;

"The signal is not just stable. It also has high capacity." stopped reading right there also it's nothing that anybody using tails for example should have to worry about. Nothingburger.

Tor on Chromium, when?

Seriously, I am saddened that Chromium dominates the browser market as much as it does, but at this point the herd-immunity of Chromium is necessary to keep users safe.

https://archive.ph/BbVZo — for those that would rather be fingerprinted by Google than fingerprint-com

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?

Imho, EU should make any fingerprinting illegal in all browsers.

And all browser devs should be required to actively fight against fingerprinting.

There is no legitimate need for fingerprinting in browsers.

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?

What are these databases not scoped to origin of creation like cookies?

There are others that Cloudflare and friends use for fingerprinting.

Tails (without persistent storage) will mitigate this though. I'm not too concerned.

You can also fingerprint browsers profile-wide across sessions without any JS, CSS or even HTML, using the favicon: https://github.com/jonasstrehle/supercookie

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.

[flagged]

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