#79 Consider providing more data about FPD actions to experienced users
Opened 6 months ago by polcak. Modified 6 months ago

Taken from Quick Security Evaluation from Radically Open Security.


The review raised issues in the understanding of the FPD functionality, possible applications of stronger anti-fingerprinting measures or similar actions.


  1. Experiment: repeatedly using https://amiunique.org/fp with default level 2 and fingerprinting detection (& blocking) enabled
  2. Observed: the fingerprinting is detected and some action is supposedly taken
  3. the blocked site is not added to a user-visible collection
  4. WebGL Vendor and other information is still obtainable by the site on future visits as "normal" on level 2, no stronger action is observed (e.g. selectively using level 3 protections)

Possible improvements

Some thoughts: the mostly stateless nature of the detection + blocking mechanism certainly has a number of advantages, for example in not leaving a log trail of visited sites where blocking was triggered (e.g., in the extension storage), and as you say configuration management around block decisions gets easier.

The purely reactive nature of the feature has benefits for malicious actors who can continuously tweak the same fingerprinting script resource until it passes detection, or do other unwanted actions from the same context on the next page load.

A potential future tradeoff solution I can think of is to have an optional, temporary and volatile log collection for time duration X or browser restart (whatever comes first) that allows more advanced users to see what resources were blocked during browsing and make informed decisions which domains/subdomains/resources/API endpoints to block using other extensions (such as NoScript or uBlock Origin).

If you want to move away from the stateless system, it would be useful to offer users a way to add the target domain to some permanently blocked list (e.g., always block analytics provider X) if they opt-in to do that, for example with the side effect that blocking of that domain will be less verbose (if notification popups are only shown for sites that aren't already on the blocklist). This is somewhat out of scope and brings new complexity, of course.

Rejected action

  • JSS could apply Strict protection level for future page visits on the site. (See FAQ)

Login to comment on this ticket.