Reimagining uMatrix: Bringing Granular Request Control to Manifest V3

For power users and privacy enthusiasts, the deprecated uMatrix extension was more than just a tool; it was a command center for the browser. Created by Raymond Hill (the developer of uBlock Origin), uMatrix provided an intuitive, matrix-style interface to control site permissions and subresource requests. It allowed users to precisely limit what third parties could serve—scripts, frames, fonts, and videos—turning a laborious manual process into a manageable workflow.

While uBlock Origin (uBO) absorbed many of these features, the transition to Chrome's Manifest V3 (MV3) has created a gap. uBO Lite, the MV3-compliant successor, lacks the granular control that made uMatrix indispensable. This has led Tavis Ormandy to investigate whether a uMatrix-like experience is even possible under the constraints of the new extension architecture.

The Technical Challenge: MV2 vs. MV3

The primary hurdle in replicating uMatrix is the shift from Manifest V2 to Manifest V3. In MV2, extensions could use "blocking" web requests, executing JavaScript callbacks to decide whether to allow or block a request in real-time.

MV3 removes this capability. Instead, extensions must use the declarativeNetRequest API. This means the extension cannot run logic on every single request; instead, it must declare a set of rules in advance that the browser then executes. While critics argue that this "nerfs" the capabilities of ad-blockers and privacy tools, Ormandy suggests that for the specific use case of a uMatrix replacement, these rules are flexible enough to be practical.

A Proposed Architecture for matrix³

To bring back the granular control of uMatrix, Ormandy proposes a design that leverages existing web standards rather than fighting the browser's new limitations. The strategy involves two main components:

1. Leveraging Content Security Policy (CSP)

Rather than trying to manage every single request via declarativeNetRequest rules, the proposed solution is to use the API to inject a custom Content-Security-Policy (CSP) header. CSP is a native browser mechanism designed to control which resources can be loaded and from where. By offloading the actual blocking to the browser's own CSP engine, the extension simply becomes a management interface for these policies.

2. Automating Discovery via report-to

One of uMatrix's best features was its ability to show users exactly which subresources a site was attempting to load, allowing them to approve or deny them on the fly. To replicate this in MV3, Ormandy suggests using the report-to directive in CSP.

When a CSP violation occurs, the browser can be instructed to post a report to a specific endpoint. By using declarativeNetRequest to intercept these reports, the extension can populate a list of blocked resources in real-time. This creates a feedback loop: the browser blocks the request, reports the violation, and the extension presents that violation to the user for a potential "allow" rule.

The Current State: matrix³

This conceptual framework has resulted in a proof-of-concept called matrix³. While currently in a prototype state with minimal UX, it demonstrates that the core loop of "block $\rightarrow$ report $\rightarrow$ user decision $\rightarrow$ allow" is viable under Manifest V3.

Community Perspectives and Alternatives

The discussion surrounding this project highlights a deeper tension in the browser ecosystem. Many users argue that the need for such workarounds is a direct result of Google's push toward MV3 to limit the effectiveness of ad-blockers.

Alternative Paths

Several community members pointed toward alternatives for those unwilling to compromise on functionality:

• Firefox: Since Firefox has not adopted the same restrictive approach to MV3 as Chrome, uBlock Origin remains fully functional there. Others suggested nuMatrix as a modern alternative for Firefox users.
• Brave: Some users noted that Brave has explicitly announced support for uMatrix-like functionality.
• Chrome Flags: For those determined to stay on Chrome, some suggested using command-line flags (e.g., --disable-features=ExtensionManifestV2Unsupported) to temporarily keep MV2 extensions alive, though this is a fragile solution.

The "User Agent" Philosophy

Beyond the technical implementation, the conversation touched on the philosophy of the browser as a "user agent." Critics argue that the lack of native, granular request control in modern browsers is a systemic failure. As one commenter noted:

"Something like uMatrix should be built right into the browser... it's the one extension that's absolutely essential... being able to see at the click of a button what kind of crap most sites want to load is really eye opening."

By moving these controls into an extension—and then restricting those extensions via MV3—the browser ceases to act as an agent for the user and instead acts as a gatekeeper for the web's advertising ecosystem.