How do ad blockers work? At the very core of any ad blocker lie filter lists (also called 'filters') — literally lists of rules written in a special syntax. If we were to compress ad blockers' job into a few words, we'd say "ad blockers interpret filtering rules". They understand this complex syntax and perform actions with web traffic based on what these rules tell them to do: block specific elements, change web pages in certain ways, etc.
There is a rich variety of filter lists. Thousands of volunteers continuously work on keeping them up-to-date, making sure they block ads and don't break anything important.
You may have heard of the upcoming changes in Chrome browser, also known as Manifest v3. And these changes threaten to end the filters ecosystem as we know it. This article is aimed at Google Chrome developers: we want to believe that they don't have a goal of hurting this ecosystem, but rather simply lack a proper understanding of it. That's why we find it absolutely necessary to describe in detail how it functions and what's wrong with the current implementation of Manifest v3.
And perhaps some of our readers would like to know how it all works, too.
As it's been mentioned before, ad blockers are 'translators' that interpret filtering rules. First, an ad blocker download filter lists. It can be any filter lists, downloaded from multiple different places, it doesn't really matter. What matters is that now the ad blocker will start checking web pages' code against all these filtering rules.
This is how ad blocking works
Let's dive a tiny little bit into technicalities, since there are probably some people who'd like to know how things work on a deeper level. There are several different ways:
Ads on web pages don't appear magically out of thin air. They have to be fetched somehow, i.e. downloaded from a server. To do so, browser needs to send a web request. Filtering rules tell ad blockers which requests are trying to fetch an ad and not useful content and should be blocked.
Every web page has a DOM ("document object model"), basically an HTML document that contains the page's structure and all its elements. Of course, ads on the page are also elements and are reflected in the DOM. Ad blockers can remove parts of the DOM, and filtering rules help them understand which parts are ads and should be removed, and which shouldn't be messed with.
Of course, in reality it's much more complicated than that, but you can see the general picture. If you'd like to know more about the technical side, check out our ad blocking syntax guide.
There are hundreds, if not thousands of filter lists: AdGuard Filters, EasyList, etc. It takes daily work of thousands of volunteers and professionals to keep these filters updated, so that they are always relevant and don't mess up anything.
Filters can do more than just block ads, and different people choose different combinations of filters to match their personal preferences. Here are some examples of popular filter lists that illustrate just how diverse they can be:
Feel free to check out this website that has a huge filter lists database.
And here's the problem: the planned Google Chrome changes imply that there will be only one default filter list (so-called 'static' rules). You'd be able to modify it with a set of 'dynamic' rules, but the limit on those is ridiculously small, only 5,000. Many filter lists we mentioned above don't fit this limit alone, imagine if you want to add multiple filter lists.
As we said, filter lists have to be constantly updated. There are two main reasons for that:
Of course, filter lists' maintainers can't monitor millions of websites themselves. They rely heavily on user feedback. To put it in perspective:
Many ad blockers have tools to help users easily report any filter-related issues they face. For example, AdGuard users have access to a special web reporting tool. Based on such complaints, filter developers correct their filter lists. Ad blockers update the filters, and — boom! — the ad is gone.
Filters are constantly being updated
This gets us to another problem: dynamic rules in Chrome are going to have a different priority compared to static ones. It only brings more chaos and makes filter lists maintainers' work so much harder.
One of the cornerstones of today's ad blocking is the users' ability to add any custom filter lists by URL (as opposed to choosing from the default list, however large it can be). This is vital for health of the filter lists ecosystem.
Another face of the same problem is that under the existing dynamic rules limitation it would be impossible for all of this to happen. This would lead to slow but sure decline of the filter development community.
If nothing is done and all changes planned for Chrome become reality, the future will be grim for all of us:
At the time, we have spoken a lot of harsh words about Safari content blocking, and rightfully so. At least, thanks to countless tricks and 'duct taping' we managed to arrive at a satisfactory solution. With Google Chrome's case, there's honestly no light at the end of the tunnel.
Yes, in fact, all these problems can be addressed and solved, and even without deviating too much from the general direction Google wants to take with Chrome. What we think should be done for that:
From the developers' point of view, it would be much simpler to have only dynamic rules. To developer community dividing rules into static and dynamic categories seems not necessary and even chaos-inducing. At the same time, we are ready to have a dialogue with Google Chrome devs and find a compromise that will satisfy everyone, and most importantly — Chrome users.
PS:
If you feel like you have what it takes to become a filter maintainer, we always welcome any help! Check out this page to learn how you can help us improve AdGuard Filters and what you'll get in return for your efforts.