FF48 blocklist against fingerprinting?

[Skrell]

Will this feature be added to PM ?
http://www.ghacks.net/2016/07/18/firefo ... rprinting/

[Moonchild]

No, because it's pointless to take on additional workload to try and index "bad" swf files based on usage on the top 10k Alexa sites and then simply blocking them by URL/filename.
What do you think deployers of these "bad" flash files will do? They will respond by renaming or rehosting, or even dynamically naming the files upon request (which takes pretty much 0 overhead to do). So at most what it will do is temporarily lower the practice results for small-time trackers, and create a good bit of PR to be forgotten about in 2 months time again.

[dark_moon]

And this blocklist is only against flash fingerprinting.
Uninstall flash and you have a much better protection.

[Moonchild]

I don't think yanking out Flash is a solution. As you said it's only a small part of what trackers use and denying yourself the added functionality of flash for it is an overreaction, IMHO.

Seriously though, this whole "let's add another blocklist" and its added complexity (and potential abuse) for what's likely going to be a passing, short-lived and feeble attempt at stopping trackers is the kind of busy-work I'd rather avoid.

[LimboSlam]

I don't think yanking out Flash is a solution. As you said it's only a small part of what trackers use and denying yourself the added functionality of flash for it is an overreaction, IMHO.

Seriously though, this whole "let's add another blocklist" and its added complexity (and potential abuse) for what's likely going to be a passing, short-lived and feeble attempt at stopping trackers is the kind of busy-work I'd rather avoid.

Aw, I thought these prefs would have been beneficial to privacy/security oriented users.

[Moonchild]

Aw, I thought these prefs would have been beneficial to privacy/security oriented users.

They aren't just prefs. It's controlling an arbitrary list of URIs compiled from running a script over a number of websites to look for specific sizes and types of flash content.
This list won't be anywhere near complete, has a chance of false positives, but even more so, has to be loaded in memory and a lookup done in it for networking requests made from the browser to see if the requested URI is present in the list. Not only is it pointless because the trackers will respond to being blocked as stated, it will also slow down your browsing and add needless complexity to browsing networking behavior.

Security considerations aren't there, unless you're worried that Flash content is insecure, period.
Privacy considerations are IMHO disproportional in this case, since flash "pixel trackers" won't be deterred by this kind of measure. If I'd put myself in the tracking company's shoes, seeing this static blacklisting going on, then it'd be half an hour of work (if that) to circumvent it in an automated fashion, indefinitely, from that point forward.