Microblog Memes

This makes sense for extensions that respond to and directly process and interact with page elements, such as Flash or Silverlight.

This makes absolutely no sense if the app has no ability to load or interact with anything in the page. If there is no interactivity - and why would there be, with simple blocking? - there is nothing for an external script to “grab”.

Which security add-ins, an external script can tell - at most - that an in-page element was not loaded by the web browser, but then anyone doing the tracking needs to contend with the dozen-plus add-ins that have the capability to block an element like that. The exact add-in is still not identifiable, only the class or type of add-in that has the functionality to block said element.

I have read through a number of white papers that explore this technology, and to a T,

1. This is still largely experimental and proof-of-concept
2. Is still primarily meant to block bots that are trying to mimic humans, and to ensure that the site visitor is actually a salty bag of mostly water
3. Can only identify apps that are explicitly designed to produce a response, as a core aspect of their purpose and design. Which, by default, fails to include almost all security-based add-ins, which behave more as “black holes” that have never been designed nor have any capability to respond to external queries.

So when a website bitches about you having an adblocker installed, the site cannot tell WHICH ad-blocker is installed, only that ads are not loading because it is not getting any telemetry from them.

So the website cannot track you by your installation of uBlock Origin unless it has that mix of ads that uBlock’s particular DEFAULT blocking pattern can be identified with. And since you can add or remove black lists at will, this becomes an infinite game of whack-a-mole for anyone trying to track you. Plus, other adblockers can load the same black lists, giving the exact same pattern for any website not loading ads from many dozens of different sources.