I'd imagine that if it's flagged as malware, this is correct procedure; you don't want to let users accidentally side-load malware either (too many real-world examples of people falling for "Go to this dialog, click this option, NOW click the link and it should work" attacks).

> The good thing of course is that it shows that they are afraid of such an extension.

Seriously. I'd figured they'd filter these "clicks" out easily server-side and didn't bother to install this thing, but this ban has hinted otherwise. I'll be installing it everywhere I can now.

Why such "clicks" would be easy to filter on the server side? What distinguishes them so clearly?

Well, tons of them coming from one IP address, on seemingly every site that address visits, for one thing.

"One IP address" as in "the address of the same NAT box"?

With IPv6 it could work, or maybe with the local IP address passed by the script at click time, but the latter would be trivial to forge.

Sure, but most or all ads on every page visited by a given IPV4 address surely throws up red flags, NAT notwithstanding. And all this is assuming that the extension bypasses session tracking and makes resorting to IP address necessary in the first place.

Then again maybe it doesn't, since they bothered to ban this extension. They did seemingly more-or-less give up trying to sort spam search results from low-traffic but high-value sites a few years back, so I guess they can't algorithm their way out of every abuse problem.

[EDIT] all ads on some pages visited by a given IP over some shortish span of time, I should say, in the case of NAT.

Fortunately Chromium is open source. I would hope that linux distros downstream would patch this anti-feature.

Can't you just Firefox with the extension? And then browse Google from there