[lxgr]

To my knowledge, no browser allows any usage of WebUSB without a prompt.

WebAuthN is different, since it does not provide sites low-level peripheral access – WebAuthN and CTAP have been designed for specifically this environment and go to great lengths to make fingerprinting hard.

As long as you don’t actually use an authenticator on a site to store a credential, it won’t be able learn anything about it.

[repelsteeltje]

Not sure about this, but I think from JavaScript you can absolutely probe stuff without explicit user consent. For instance, without accessing any USB device I can try:

  if(!navigator.usb) {
    console.log("learned that browser does not have USB capability");
  } else {
    console.log("learned that browser has USB capability");

    navigator.usb.getDevices().then((devices) => {
      devices.forEach((device) => {
        console.log(device.productName);
        console.log(device.manufacturerName);
      });
    });
  }

(Which is useful for fingerprinting.)

[nolist_policy]

Okay, so you can learn that Chrome supports WebUSB and Firefox doesn't. But you already knew that from the User-Agent header...

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