Covering is not as good as not loading.

Loading brings all the malware, the tracking, and the bandwidth/load times.

"Not loading" doesn't make sense in the case where the ad is inline in the response body (i.e. "part of the site", like Facebook's ads are.) Which is the case where this ad-blocker uniquely shines.

Besides which, the algorithm involved is a computer-vision one, so the ad needs to be rendered before the algorithm can recognize it as an ad.

The best solution here, if you want maximum privacy, would be to use a traditional ad-blocker as a first-line defence, and this algorithm as a second-line, for the ads which make it past regular ad-blocking (and which are therefore probably inline-content ads anyway.)

> where the ad is inline in the response body

That only applies to the HTML, which generally is fairly lightweight. They still load additional images, videos, do XHRs for tracking etc.

You could feed back the visually blocked ads to a system that profiles their HTML/etc and then generates new rules for the first line blocking (which is usually itself a combination of not loading and not rendering).

There's a big chance that the AD blocking AI would consume much more power than the AD scripts and make browsing slower.

I agree, it's a limitation of the perceptual blocker, as it needs to `see` the ads to detect them. However, combined with a regular ad blocker to catch the ads that the regular ad blocker missed, it seems like a reasonable solution.

But the whole point of this approach (as I understand it) is that companies may be able to deliver the ads in the same HTTP response as the content, they may render the whole page as a <canvas>, they may go to crazy lengths, but by sitting on top of all of that, this software can still block pixels that look like an ad.

Hey—I wrote this article ... if anyone forks this and makes it real please let me know. @jason_koebler on twitter or [email protected]

Anyone know if it interferes with uBlock? I'm on mobile and can't test now.

This is probably obvious, but where is that file?

The chrome extension file (.crx) is a zip file (with meta data). Just unzip it and you'll find the files, including the 'utils.js'.

I made a repo for the patched extension: https://github.com/byrnehollander/perceptual-adblocker-edite...