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.
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.
Strict
Metadata Update from @polcak: - Issue tagged with: design decision
Login to comment on this ticket.