The Browser Extension Ecosystem

Abstract

The browser was the gateway to the web, but whose browser? The history of the extension ecosystem is the history of a power struggle: users who wanted to shape the web to their own ideas; developers who built features browser vendors would never ship; and finally companies that realized an installed extension with millions of users is a powerful instrument, for good and for evil.

Greasemonkey: The User as Developer

In late 2004, Aaron Boodman released Greasemonkey, a Firefox extension with a simple idea: users should be able to apply JavaScript scripts to any web page after the page had loaded.

That sounds technical. The implication was radical: the web was no longer what a server delivered. It was what the user made of it.

Userscripts sprang up everywhere. Someone wrote a script comparing Amazon’s prices with eBay’s. Someone else built keyboard shortcuts for Gmail before Google added them. YouTube got download buttons. Reddit got inline image previews. Facebook got a chronological feed long before Facebook itself offered one.

The userscripts ecosystem demonstrated something important: users had concrete ideas about how the web should work, and the ability to implement those ideas themselves. UserScripts.org (succeeded today by Greasy Fork) became the collective memory of these modifications.

Mozilla later built the concept more deeply into its add-on platform. Greasemonkey was the proof of concept. What followed was an industry.

AdBlock: The First Mass Protest

In 2002, Henrik Aasted Sørensen wrote Adblock for Mozilla’s browser. The idea: filter advertisements out of the page with user-defined rules. Its successors went further and never sent the network requests to ad servers in the first place.

The numbers quickly became uncomfortable for the advertising industry. Tens of millions of installations. Then hundreds of millions. In 2015, PageFair estimated that 198 million users worldwide were running an ad blocker, 41% more than the year before.

Adblock Plus (Wladimir Palant, 2006) dominated the market early, then monetized it: the “Acceptable Ads” program allowed advertisers to pay their way onto a whitelist. For critics, this was protection money in extension form. For Palant, it was a compromise between user needs and publisher survival.

uBlock Origin (Raymond Hill, 2014) positioned itself as the reaction: no Acceptable Ads program, no monetization, pure blocking with minimal system resources. uBlock Origin became the preferred choice of technically sophisticated users and privacy advocates.

The advertising industry responded with countermeasures: anti-adblocker scripts, paywalls behind adblocker detectors, first-party advertising that extensions could not recognize. The arms race continues to this day.

Warning

The power paradox of the extension platform:

Extensions that legitimately block advertising use the same API privileges as extensions that steal passwords. The browser vendor gives extensions privileged access to all page loads, all form data, all network requests. That is necessary for useful extensions, and it is exactly what makes malicious extensions so dangerous.

A legitimate ad-blocking extension and a credential stealer are identical from the API’s perspective: both intercept network requests, both can modify page content. The difference lies in the developer’s intent, and the browser cannot see intent.

Chrome and Centralization

Google’s Chrome (2008) launched without extension support. That changed in 2010 with the Chrome Web Store: centralized, curated, with Google’s review process.

Centralization had advantages: quality control, automatic updates, easy installation. It also had risks that only showed later.

Chrome grew into the dominant browser engine. The Chrome extension ecosystem grew with it. The Chrome Web Store grew to well over a hundred thousand extensions.

With market power came potential for abuse. Malware extensions became a systematic problem:

Extensions that rolled out malware updates after being taken over by new owners
Extensions that injected affiliate links into every e-commerce page
Extensions that sold browsing data to data brokers, legally, because the privacy policy allowed it
Supply chain attacks: developers were approached with fake acquisition offers; after the sale, new owners shipped malicious updates

Google responded with manual reviews, automated detection, and repeated purges of the Web Store. The fundamental conflict remained: every extension with millions of users is a valuable target.

Manifest V3: The Conflict over Extension Power

In 2018, Google announced Manifest V3 (MV3), a new extension API; after repeated delays, Chrome began disabling the old Manifest V2 extensions in 2024. The technical change: the webRequestBlocking API, which allowed extensions to block network requests in real time, was replaced by declarativeNetRequest.

declarativeNetRequest is rule-based: extensions define in advance which requests should be blocked. The browser applies the rules without running extension code on every request.

Google’s argument: security and performance. Extensions that execute code on every network request can slow down the browser and have deep access to all communication.

The adblocker community’s counterargument: declarativeNetRequest caps the number of rules (initially 30,000 static and 5,000 dynamic rules) and prevents dynamic, context-dependent blocking decisions. uBlock Origin’s advanced functionality (cosmetic filters, script injection, dynamic filtering) was constrained under MV3.

Raymond Hill (uBlock Origin) released uBlock Origin Lite as an MV3 version, functionally reduced, without all the features of the original.

Mozilla adopted MV3 in its core but kept webRequestBlocking as an optional API. Firefox thereby remained more powerful for extension developers, which Mozilla communicated as a differentiator.

The suspicion of many observers: MV3 was not a pure security decision. Google is the world’s largest advertising vendor. Extensions that block advertising cost Google revenue. MV3 weakens ad blockers. Whether that was the intent cannot be proven, but the alignment of interests is evident.

Dead End: Firefox XUL Extensions

Info

Mozilla’s powerful extension model, and why it had to die:

Firefox’s original extension architecture was based on XUL (XML User Interface Language) and gave extensions deep access to Firefox internals. That was powerful: extensions could completely rebuild the Firefox interface, use internal APIs, interact with the operating system.

The price: every major Firefox release could break extensions. Updates required extension changes. Developers had to know Firefox internals, not just standard web APIs. That drastically limited the developer pool.

In 2017, with version 57 (“Quantum”), Firefox switched to the WebExtensions API, the same foundation as Chrome. Overnight, thousands of XUL extensions became incompatible. Developers who did not port their tools lost their user base. Users who depended on XUL extensions lost their tools.

The switch was necessary: Firefox Quantum was dramatically faster, and WebExtensions compatibility made porting Chrome extensions easy. But the transition destroyed a living ecosystem of highly specialized tools that had been written against Firefox internals and had no WebExtensions equivalent.

Legacy

Extensions changed the web in ways browser vendors never intended. They showed that the web has no final form; it is a medium every user can help shape.

Ad blockers fundamentally challenged the internet’s advertising-funded business model. Userscripts showed that users make better product decisions than product teams, if you let them. Password managers as extensions spread security practices that would have remained fringe phenomena without extensions.

The unsolved core problem remains: an ecosystem powerful enough to be useful is powerful enough to be dangerous. The browser is the window onto one’s entire digital life. Who controls the window (users, developers, browser vendors, or attackers) is the central power question of the modern web.