Chrome pushes forward with plans to limit ad blockers in the future

The media loves a clash of the titans narrative when it comes to the big tech companies, but the fact that they've all carved out such careful moats for themselves means none of them really compete head-on with one another. That said, the cultural competition is always fascinating to me. For example, while the broad story here is that Google is making ad blocking less accessible to Chrome users despite a pretty obvious perverse incentive to cram display ads down users' gullets, there's a beneath-the-surface contrast with Apple that's just as interesting.

I knew that the v3 manifest limited ad blockers, but I didn't realize it does so by drastically limiting the number of rules extensions can define (and then, favoring dynamic rules over static ones):

Originally, each extension could offer users a choice of 50 static rulesets, and 10 of these rulesets could be enabled simultaneously. This changes to 50 extensions simultaneously and 100 in total… Extensions could add up to 5,000 rules dynamically which encouraged using this functionality sparingly

So going forward, Chrome extension developers will still be able to execute as much JavaScript as they want—potentially invading users' reasonable expectations of privacy and slowing their machines down—but they will be limited in how many ads and trackers they can block.

Compare this to how Apple's Content Blocking API ties the hands of developers to ensure users are protected from nefarious ad blockers that scrape user data or replace all the ads with their own. They do this by forcing every rule to be statically defined—the very thing Chrome is restricting now. As Andy Ibanez puts it:

At the most elemental level, content blockers are rules represented in a JSON file. Everything all the Content Blocker apps in the App Store do is create a JSON file that gets handed to Safari. You could theorically create an extensions that all it does is hand a static JSON file to Safari without writing a line of code.

So on one end, we have Chrome restricting its extension API to protect itself from lost advertising revenue at the expense of users and which will incentivize developers to implement resource-intensive workarounds at best and publish bogus "ad blocking" extensions that do underhanded, skeevy stuff at worst. At the other end, Apple's Content Blocking API protects itself from scandal by preventing most categories of scams outright at the expense of developers having any tools to differentiate their extensions over others and which will result in users having the trade-off of speed (fast) vs effectiveness (middling) decided for them.

It's interesting to think about how the structural incentives of each company leads them to approach problems like this one so differently. For Google, it's always Google first, developers second, users third. For Apple, it's always Apple first, customers second, developers third. (Explaining why so many programmers are happy Apple customers while remaining wholly disinterested in being Apple-ecosystem developers.)