Potential Threat to Brave Browser Fingerprint Protection?

Support and Troubleshooting
, ,
#1

Fingerprint protection built into Brave browser’s nightly build in part relies on randomized API values that are imperceivable to humans, but distinguishing to computers / fingerprinters.

I am wondering whether this strategy for fingerprint protection could be defeated by a process that works something long the lines shown in the image below:

image
image1735×653 78.8 KB

Since randomization of API parameters is limited to ranges beyond human perception, could a fingerprinter map values within ranges to just one value within the range, the same value regardless of browser, session etc?

I guess this strategy could be described as making the random values look the same, by, in effect, rounding the api values.

It is sort of as if 10.472095739571 is randomized by picking random numbers between
10.465000000000 and
10.474999999999

In this scenario, Brave fingerprint protection relies on the fingerprinter calculating 50,000,000 different fingerprints depending on which value comes in from the browser between 10.465000000000 and 10.474999999999. For sake of discussion, imagine humans can perceive differences in this parameter only to two decimal places. That would imply the random value sent by Brave to the fingerprinter will be a random number between 9.465000000000 and 10.474999999999 inclusive. If the webserver knows that parameter is perceptible to two decimal places, could the web server translate all values received from within that range to one value of the web server’s choosing. Randomness gone?

#2

That’s an excellent question. A fingerprinter could definitely try to normalize values in this way and then end up with a more stable fingerprint for Brave users.

That said, the value of a fingerprint is based on two components:

  1. it is as stable as possible
  2. it is as unique as possible

If a fingerprinter implemented the technique you describe, they would be trading uniqueness for more stability and so the fingerprint would not be as useful.

In fact, in some cases the fingerprint uniqueness relies on very small imperceptible differences specific to hardware devices, and so normalizing the values would make it impossible to get a distinct fingerprint in that case.

1 Like
#3

Is it possible for you to provide an example of this?

Are the differences you are referring to unique to every device or every model? In other words, is there a difference present in two devices that are exactly the same make/model?

Fingerprinters already cannot fingerprint when Brave is the browser. They could add a routine to their fingerprinting that says if the fingerprint is one they had not seen before, they could recompute the fingerprint with the normalized values we are talking about. At that point, if they find a fingerprint match, this would be the risk of non-uniqueness comes into play. This seems like a fun game of cat and mouse.

I am trying to figure out the motivation for fingerprints over cookies for uniquely identifying browser installations. The main things that come to mind is fingerprints cannot be deleted from a browser and webservers want to know when multiple online accounts belong to the same person.

I just tried fingerprintjs.com/demo/ with Safari and Firefox, both produced different fingerprints.

Fingerprinter should be able to put the same fingerprint on those two browsers on the same device. Until they can do that, they won’t stand a chance at the seeing through the variation introduced by browsers as a defense against fingerprinting.

1 Like
#4

Here’s one which relies on the sound card:

1 Like
#5

Thank you for taking time to respond.

I am very pleased to see my Brave browser could not be fingerprinted at the demo linked from that article.

I have one additional comment: browser privacy is a complicated issue.