Is Brave currently susceptible to fingerprinting through extension detection in the stylesheets?

Brave Feature Requests Desktop Requests
, ,
1

I thought I would do what I can to help contribute to Brave Browser keeping ahead of the game in terms of thwarting fingerprinting attempts. There’s recent research from February of 2021 that was presented to the USENIX Security Symposium that details how browser extensions could be detected for inclusion in fingerprinting by looking at the stylesheets and detecting injections to them. If Brave is vulnerable to this kind of attack, it could be worth putting a ticket in your backlog to have a look at this. The link below should take you to the research paper.

https://hal.archives-ouvertes.fr/hal-03152176/document

2

I think you should post this on GitHub.

3

Also cc @pes for this

4

Hi all,

Thank you for posting this. This is an issue that is “rediscovered” every few years; im a bit surprised that it was accepted as a new conference publication. Its slightly counter-intuitive, but the short of it is that attacks like are why stylesheets are considered active content (and have been for a very long time). MDN has more details, for example.

Some quick thoughts though:

  1. The findings here shouldn’t be interpreted as “brave users are more fingerprintable that we though”. Its “browser extensions are very high value fingerprinting vectors”. its why you should (all things being equal) use browsers that provide extremely strong protections in the default configuration, instead of installing extensions to protect your privacy.
  2. “Disabling JavaScript is not a very strong fingerprintint defense.” Its not nothing of course, but disabling scripting is a practical defense, not a fundamental one.
  3. its just as easy to block folks trying to fingerprint your browser through browser extensions, as it its to block folks trying to fingerprint your browser using traditional methods. Brave’s blocking defenses are no less (or more) powerful against blocking stylesheet based fingerprinting as they are against more typical JS based fingerprinting.
  4. The papers idea of removing getComputedStyle is extremely wrong-headed. I’m amazed and shocked they included it to be honest. Theres a long list of reasons why, but the shortest is that there are all sorts of ways (fundamental, cannot be removed from the platform) to infer the style of an element without getComputedStyle); impacts on layout, rendering times, caching, etc.