[repelsteeltje]

Hahah, so you think. But now you have additional telemetry to show that this wasn't cURL forging a Chrome (or Firefox) user-agent header.

Finger printing sounds sophisticated, but it's just collecting the bits and pieces into something that (mostly, probabilistically) identifies you. And then tracking you, surveilling you till you're somewhere where they can identify you.

From there: profit!

[lxgr]

> this wasn't cURL forging a Chrome (or Firefox) user-agent header.

There must be a million different ways to establish that, though.

I get the general idea, but this particular data point seems highly correlated with just the family of browser, as GP suggests.

It's also very easy to fix – just make your non-WebUSB-supporting browser expose that object, but always behave as if the user had declined that particular prompt.

[repelsteeltje]

That still allows website to distinguish between webUSB-aware clients and older browsers. The point being, that it would be great if extentions like WebUSB were developed such that nothing about capabilities could be learned without the users' awareness and explicit consent.

Unfortunately, instead, new capabilities are added to browsers constantly and the interfaces commonly are silently made available as part of a regular software upgrade. Sure, thought is given to security and the user is prompted just before something horrible is about to happen (access camera, mic).

But don't underestimate the shitload of "niceties" in the grabbag of APIs that in aggregate reveal more or less a supercookie of your browser instance.

[pipo234]

Yes, enumerating available capabilities helps fingerprinting. And this is not good, and APIs should be designed better.

But there are easier avenues that are harder to mitigate. Hashing an image that relies on the browsers rendering of (default) fonts. Highly instance specific, lots of entropy.

[lxgr]

> more or less a supercookie of your browser instance.

That's really not what it is though, is it?

These capabilities will be rolled out for all users of a given browser, or even for a given rendering engine, and I'd assume that your browser family is already easily fingerprintable. In other words, they are all highly correlated.

Things like installed fonts, window sizes, your clock drift etc. are a different story. These lower-correlation measurable properties are the real supercookie problem.

[hedora]

It lets you enumerate all the USB crap on the bus.

My desktop has 12 things on the bus. 8 are soldered on to the motherboard, and 4 are plugged in. There are at least 32 choices for each of the things, so that’s 5 bits of entropy per device — 7 bits, ignoring the motherboard.

[nolist_policy]

But only if you allow WebUSB access, which the browser will ask you first.

If you allow Camera access you get a metric ton of bits.

[hedora]

The author of the sample code implies it will run without prompting.

[lxgr]

I mean, if you grant USB access to an untrustworthy web site, it's game over – you can probably just read the serial number of at least one of these devices over USB.