Replacing uMatrix.

Introduction

There used to be this fantastic chrome extension called uMatrix, written by<br>Raymond Hill, the uBlock Origin developer. uMatrix was an intuitive way<br>to control site permissions and subresource requests.

It looked like this:

uMatrix

This isn’t something you’ll care about unless you’re a nerd – but it<br>let you limit what third parties could serve subresource requests, and<br>controlled access to features like frames, scripts, video, fonts and so<br>on. You can do some of that manually with browser settings, but uMatrix<br>made it quick and easy. This meant that what would otherwise be quite a<br>laborious and fiddly way to browse the web became simple. Okay, not<br>simple, but simpler.

Anyway, I enjoyed all the extra knobs to control website<br>permissions.

The features in uMatrix were – more or less – a subset of the<br>features available in uBlock<br>Origin, so rather than maintain both, Hill deprecated uMatrix and<br>users were encouraged to migrate to uBO.

This actually worked okay for me – uBO added some features I quite<br>liked (e.g. cosmetic<br>filters), and if you didn’t mind hand writing the more complex rules<br>and understood selectors, it could do everything uMatrix could do.

The bad news is that uBO is a legacy<br>MV2 extension, and the successor – uBO<br>Lite – removed this feature.

I really don’t want to give that up – is there a solution?

Options

My question is could uMatrix even be possible under mv3?

declarativeNetRequest

The main difference between mv2 and mv3 here is that it is no longer<br>possible to block requests while you execute a callback, a so-called<br>“blocking” web request.

If you want to intercept a request, it now has to be done declaratively.<br>That just means instead of running some javascript on every single<br>request, you have to declare what actions you want applied in<br>advance.

Here is the controversial bit you’ve probably read about: You can’t<br>do everything that was possible in a callback declaratively, so<br>the capabilities have been nerfed. That is technically true, but<br>practically the rules are flexible enough for everything I would ever<br>want.

Policies

The web already has a system to control features and subresources,<br>it’s called Content<br>Security Policy.

The obvious design is to use declarativeNetRequest to<br>add our own Content-Security-Policy, then the browser will<br>do all the work for us. All we need to do is provide a convenient<br>interface to manage it.

Okay, but how will we offer a list of subresources to allow and deny?<br>When you used uMatrix, it would show you a list of subresource types and<br>origins, and let you manually approve or deny them.

This was the core thing uMatrix did well, so it’s essential. Well, I<br>think CSP already provides a solution! There is a report-to<br>directive that instructs the browser to post any security violations to<br>a reporting endpoint.

All we have to do is enable that feature, add another<br>declarativeNetRequest rule to catch those reports, then<br>populate a list from the reports the browser sent. That’s another task<br>successfuly offloaded 😂

Of course, this will take some plumbing, but the pieces are all there<br>and it seems completely viable to me.

Outline

So now that we have a rough outline for how it could work…<br>someone just has to write a proof of concept. Ah fine, I’ll give it a<br>shot.

Here is a first attempt, matrix³.

It is clearly in a prototype state, but it basically works. I thought<br>I’d post about this on my blog and see if there’s any interest!

The code is minimal – no building or dependencies required, just<br>git clone and then “Load Unpacked” in Chrome.

I am not a web developer, and I clearly have zero UX skills 🦎 Please<br>let me know if this is a bad idea, or you know a better solution, or you<br>want to help.