Posted by danpinto 21 hours ago
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.
Or just open dev tools
namespace mozilla {
namespace dom::indexedDB {
using namespace mozilla::dom::quota;
using namespace mozilla::ipc;
using mozilla::dom::quota::Client;
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.
Because it's an isolated remote browser, you also get a lot of flexibility. You can run BrowserBox itself as an onion hidden service connected to the clearnet, or connect BrowserBox to browse over Tor, or even do both at the same time. Since this Firefox IndexedDB vulnerability relies on persisting state, you can completely avoid it by running BrowserBox (based on Chromium), and doing it ephemerally. There's actually a new GitHub action [0] that makes spinning up a purely ephemeral, disposable session incredibly easy and would be immune to this kind of process-level state tracking.
The action runs BrowserBox on a GitHub Action Runner, you can specify whether you want a CloudFlare tunnel, or a tor tunnel (which comes with torweb access). And there's a conveneince script you can use to run from the command-line - which does the setup then spits out your login link.
All you need is a BrowserBox license (not free), but then you can use it.
I would consider this a lightweight Tor-proxied Browser, not a replacement for Tor Browser, at this time as there are likely edges and leaks that the official Tor Browser has long patched. However, as cases liek this IDB bug demonstrate - no security is perfect. If you simply want a way to access tor, and add an extra "ephemeral" hop on a runner, itself over Tor, and not trying to do anything especially sensitive or life-threatening - it's probably good.
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 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.
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.
And all browser devs should be required to actively fight against fingerprinting.
There is no legitimate need for fingerprinting in browsers.