4 ms·
One way to counter browser fingerprinting could be to add a plugin that simply report random data when queried. This would invalidate the hashing. Of course, i
by Renaud 13y ago
One way to counter browser fingerprinting could be to add a plugin that simply report random data when queried. This would invalidate the hashing.
Of course, if the plugin is well known, it could be removed by the fingerprinting code, unless it can disguise itself as something else -more or less random- when it is installed.
- morpher 13y agoWouldn't a better solution be to simply modify the bowser to report some base set of fonts / plugins (and any other high-information content fields)? How many sites actually legitimately serve different content based on your fonts or plugins? Also, the UA string could be simplified to reveal less.
- fingerprinter 13y agoI just have a couple of personal plugins that will change my reported UA slightly, my fonts collection slightly and some other random bits. Just screws it up enough so I know I'm not tracked.
- ilikepi 13y agoWould you consider releasing these, or are you concerned if they were more common they would become less effective?
- peterwwillis 13y agoNope, already thought of, and not for what you'd expect. Authentication systems using Browser ID create a value based on the browser identification bits and apply a ratio of how close the value is to a given user's fingerprint, so your values may change (like when you resize your screen) but it'll approximate the fingerprint as the user's. In other words, if it's close, it still matches.