| ▲ | Meneth 5 hours ago | ||||||||||||||||
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? | |||||||||||||||||
| ▲ | nneonneo 5 hours ago | parent | next [-] | ||||||||||||||||
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. | |||||||||||||||||
| |||||||||||||||||
| ▲ | lxgr 5 hours ago | parent | prev | next [-] | ||||||||||||||||
The content is obviously scoped to an origin, or IndexedDB would be a trivial evercookie. | |||||||||||||||||
| ▲ | AgentME 5 hours ago | parent | prev [-] | ||||||||||||||||
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. | |||||||||||||||||