TechTok #9. How do browser extensions work, and what is a firewall?

When we launched the TechTok series last December, we had imagined it as a way to directly answer the questions that you, our readers, may have about technologies surrounding ad blocking and privacy protection. Simple formula — you ask, we answer. And it’s been like that for eight issues, thanks to your questions that you all have been sending through our special online form. However, today we’re taking a small sidestep.

Both of today’s questions come from AdGuard’s CTO and Co-Founder Andrey Meshkov, who’s noticed that some common tech terms get thrown around a lot but are rarely explained clearly. So, let's keep it simple and get to the first one:

How do browser extensions work?

First, let’s define what browser extensions are. To put it very simply, they are mini-programs that run within your browser and modify your web experience in one way or another. Those small icons next to the address bar? That’s browser extensions. They can do all sorts of things — from small tweaks to major upgrades. Some just change how links open or copy text automatically, while others go much further — blocking ads and trackers, working as VPNs, or even using AI to help you write or summarize content. Normally you don’t need to know much more than how to add them to your browser. But how do all these extensions actually work? Let’s get to the bottom of this.

The main thing about browser extensions is in their very name. Unlike standalone software, they can’t work without their browser. At the core of the browser-extension interaction lie APIs (Application Programming Interfaces) — collections of methods and properties provided by browsers that allow extensions limited, permission-based access to some of the browser’s features and data. For example, if an API allows to create new tabs or close the existing ones, an extension can do it by accessing that API, provided the extension has the necessary permissions. The more features and data the extension wants to access, the more permissions it requires, so pay close attention to permission requests when installing a new toy into your browser. But more on that later.

Generally speaking, each browser developer creates their own APIs suited specifically for that browser. This is why it is not uncommon to find an extension for, say, Chrome, that won’t work on Safari, or vice versa. This isn’t ideal, of course, so there has been an effort to standardize and unify these APIs under a common framework, one of the examples is the WebExtensions API. Thanks to it, most major browsers like Chrome, Firefox, and Safari offer largely compatible extension APIs. It allows developers to create extensions that work across multiple browsers with potentially very few changes. This isn’t a given, however. In many cases making your extension work smoothly across different browsers requires a lot of work, and not every developer has resources and desire to walk that extra mile.

Circling back to the matters of security, let’s talk about the confinements that browsers impose on extensions. Browser extensions work in so-called sandboxes — enclosed environments that allow each extension to only access browser APIs and limit its interaction with the operating system and other applications. Every extension has a manifest where it declares the permissions it needs to perform its functions (for example, permissions to modify the page’s contents or to initiate and cancel downloads). The browser then enforces these permissions and won’t allow the extension to do anything that goes beyond their scope. This way, even if the extension is compromised, it won’t have the means to inflict damage to processes and files outside its reach, at least in theory.

You often hear warnings against installing browser extensions from outside the official stores. That’s because these stores add an additional layer of defense. Whenever a developer submits their extension to the store, they undergo a review process. During this process, they need to explain why their extension needs all the permissions it asks for. If upon inspecting the code the reviewer decides that the requested permissions are excessive for the functionality that the extension offers, it may be rejected from the store. The review process is not error-proof, though. There are plenty of examples when extensions admitted into popular stores, like Chrome Store, have gone rogue and stolen users’ data, or worse. This is why it is very important to always review the extension’s permissions before installing it.

Finally, when talking about extensions and security, it is impossible not to mention Chrome's transition to the new version of its extension platform, Manifest V3. We have written plenty about it, and even gave various talks on this at the Ad-Filtering Dev Summit,since its effect on browser extensions is severe, and on ad-blocking extensions is doubly so. It gave our devs a lot of headache, but credit where credit is due: it should improve the security in regard to Chrome browser extensions. It removes the ability for extensions to execute remotely hosted or arbitrary code, so all code will have to be reviewed. And this should if not eliminate, then significantly reduce the security risks.

Now to the next question...

What is a firewall?

This is one of those questions that, if we wanted to cover every angle, could easily take up ten pages. But instead of going down that rabbit hole, let’s zoom in on the key stuff. First, let’s tackle the most obvious question: why is it even called a firewall?

The word firewall wasn’t originally a tech term at all — it came way before the Internet. In its original meaning, a firewall was literally a wall that protected against fire. You’d find it inside buildings, where it was designed to stop flames from spreading from one part of the structure to another. Unlike regular walls, it was thicker, made purely of foundation materials, and usually didn’t have windows or anything else that could let fire pass through.

In the world of computer networks, firewalls first appeared in the late 1980s. Much like their physical namesake, they were designed to stop the spread of something, in this case, unwanted or potentially harmful network traffic.

The first generation of firewalls were known as packet filters. These operated at the network layer, inspecting traffic by analyzing individual packets — the small chunks data is broken into when it travels across the Internet. Packet filters made decisions based on things like the source and destination IP addresses, port numbers, and transport protocols. At their core, these firewalls relied on a predefined set of rules that would allow or block traffic based on those properties.

Then, in the early 1990s, came the second generation of firewalls. Unlike the first gen, these were more complex firewalls known as “stateful firewalls”. They didn’t just look at one packet in isolation — instead, they could keep track of traffic over time. This meant they could remember the “state” of a connection, like whether a packet was part of an existing, approved session or just a random incoming request.

Firewalls kept evolving as the Internet kept evolving. The rise of web applications led to the development of application-layer firewalls, which operate at the application layer, hence the name. These firewalls are capable of understanding and filtering traffic based on specific protocols that support applications or services, like HTTP (used by web browsers to load websites) or DNS (used to resolve domain names into IP addresses), rather than just IP addresses and ports. Then, around 2008, firewalls started to include deep packet inspection (DPI) — a technique that allows them to analyze the actual contents of the data packets, not just their headers.

When it comes to how a firewall is implemented, there are different forms. It can be a hardware firewall, where a physical device is placed at a network boundary to filter traffic (like a home router). It can be a software firewall — think of an app running on your device that filters traffic to and from that device (Windows Defender Firewall and the like). Or it can even be virtual or cloud-based, running remotely and protecting networks or devices without being tied to a specific piece of hardware.

Now, let’s answer a question that you might be curious about. Is AdGuard ad blocker a firewall? The short answer will be no, at least not in the traditional sense of the word. But our apps do have firewall features. Specifically, AdGuard for Android has a Firewall module that allows users to manage internet access for apps on their device. This module enables users to control which apps can access the internet, blocking or allowing access as needed.

This feature becomes especially useful when apps behave suspiciously — like sending data even when you're not using them. With AdGuard for Android’s firewall module, you can block internet access for specific apps, disable background traffic when your screen is off, or even cut off mobile data while roaming. It gives you full control over how and when your apps connect online without needing to root your phone or dig through complex system settings.

While firewalls can be helpful tools that you can use to protect your home network or your privacy and security on-device, more often than not the word ‘firewall’ is now associated with censorship. This is in large part due to the notoriety that the Great Firewall of China has gained over the years. And we cannot wrap this up without at least saying at least a few words about it.
The GFC is a massive, state-run censorship system aimed at restricting access to foreign internet content from within China — including services like Google, Facebook, Twitter, and YouTube. It uses a mix of techniques like DNS spoofing, keyword-based URL filtering, deep packet inspection (DPI) and even packet forging to block or disrupt traffic. There are more GFC-like state-controlled systems in the world that primarily function as censorship tools at the guise of security, but that’s a topic worthy of its own article.