Hot Take 3P-Matrix-lite version 2 available in the webstore (easy to use uMatrix like security using Mv3 DNR rules)

Add-on/Extension Page
https://chromewebstore.google.com/detail/3p-matrix-lite/oljiiikeojepiiaoaicpddpgpfiloejj?pli=1
Jan Willy said:
About uBol-stripped:
Version 3.8.2 deliciously lean.
So far one issue. Block device fingerprinting (WebGL & WebGPU) doesn't work. Tested on browserleaks.com and https://get.webgl.org/.
Click to expand...
Thanks for reporting. I will have a look at it.

I have put 3.9 on github, but it also does not block WebGl & WebGPU.

I removed the need to allow user scripts (but .... told you still learning, some scriptlets need user script permissions). Played with it this morning, but ran in two dead ends solving it. I recall AI had changed color of two check marks in Security & Privacy (greyed them),

I have to check whether only debug access to WebGL/WebGPU is blocked (this leaves WebGL.WebGPU fully functional, but only blocks teh easies way to fingerprint using debug, in stead of drawing an image). I did something simular with changing *##+js(noeval), in stead of hard block, block only known compression and obfuscation.
 
Last edited:
  • Like
Reactions: Gandalf_The_Grey, Khushal and Jan Willy
Jan Willy said:
About uBol-stripped:
Version 4.1.0
Block device fingerprinting (WebGL & WebGPU) now o.k.
Didn't look at other components.
Click to expand...

I'm just curious.
Does the test look like this?

3.png
 
  • Like
Reactions: Jan Willy
@Jan Willy I just uploaded 4.1.2 this one is without bug/trace logs (every millisecond is squeezed out of it for max performance).

It found out about EsLint (a tool to check JavaScript code and got carried away)

I am done improving and optimizing stuff, no idea what I could improve next, the code is completely refactored (except one big monolithic JS-module).

I tried to refactor the monolithic JS-module, but that caused all sorts of problems, so yeah Mr Hill certainly knows all the dark corners of JavaScript extension development and I finally found out why and how it is better to do it the uBO-lite way than the AdGuard way, but ... AG-team also did some things smarter than mr Hill. That is why I kept pushing to find a middle ground and the big monolith is now cleaner and partition into 4 sub modules which fire sequentially when needed (I knicked that idea shamelessly from the AG-team :-) also because it fits the best practices of structured programming better)

In layman's terms we (Claude AI and me) used the strong bones of uBO-lite and stripped it (removed less well programmed features to keep up with AdGuard Mv3). Next we added some open source AdGuard skills (it is open source so why not use what is available in stead of competing as a one man band with a team of developers). Next I added some features which in my opinion were missing in uBO-lite (the ABP-import is from AG and I added a new easy create your own custom DNR picker tool and some extra security & privacy options). To make the code easy to understand, extend and debug I refactored the strong uBO-lite bones using four (old structured programming) principles (nerd alert):

  1. SEPARATION OF CONCERNS — HTML, CSS AND JAVASCRIPT Every file has exactly one job. HTML describes the structure of the page. CSS handles all visual styling. JavaScript handles all behaviour. No styling is written inside JavaScript. No logic is embedded in HTML. This means you can change how something looks without touching the code that makes it work, and vice versa. Each dashboard tab, each popup panel and each background module is its own isolated file.
  2. FIVE-TIER FOLDER STRUCTURE The codebase is organised into five layers, and code is only allowed to call downward — never upward or sideways. This means a bug in the UI can never corrupt the filter logic, and the filter logic can never accidentally write to the UI. Every dependency is explicit and traceable (ui — what the user sees and clicks, workflow — the service worker that coordinates everything, core — the actual blocking and filtering logic, util — small shared helper functions, data — storage, configuration and external API calls)
  3. STATE VECTORS AND SWIMMING LANES Every multi-step process owns a single named state object — called a state vector — that holds all its data and a phase field describing exactly where in its lifecycle it currently is. For example the monitor session can only be in one of four states: idle, starting, running or paused. A guard function checks the phase at the start of every operation and logs a warning if something tries to happen out of order. This means bugs that used to be silent — a session that got stuck halfway, a timer that never fired — are now immediately visible in the browser console with the exact step that failed. The service worker startup sequence follows the same pattern: it tracks whether it is booting, starting, ready or in error, and records which sub-step it was on if something goes wrong. If the extension ever fails to start, the error message tells you exactly where.
  4. MAINTAINABILITY AND BOUNDARY GUARDS Every capacity limit — the maximum number of custom DNR rules, the maximum number of cosmetic rules, the ID ranges for each rule type — is defined in a single file (dnr-budgets.js) and imported everywhere else. Changing a limit means editing one number in one place. Every module that manages a resource also owns the cleanup of that resource. Timers live inside the state vector they belong to, not scattered across the module. Every future scaling limitation is marked with a comment explaining what the ceiling is and what a future developer would need to change to raise it.
 
Last edited:
  • Like
Reactions: Jan Willy and Gandalf_The_Grey
@Sampei.Nihira

WebGL and WebGPU tests are both on browserleaks

When I get reports of website breakage, I will tune the protections down to only blocking access to debug WebGL/GPU. Debug is more used than the drawing of graphics what all the "WHHHOOEEE you are in trouble because your fingerprint is unique" websites do.

I was in marketing & sales and believe me: you can always be tracked. Only tracking has impact on website rendering speed and by combining some data points you also can track users (so full featured fingerprinting is not much used, only IKEA did that when I recall corectly).

Same as with noeval protection, blocking noeval increases website breakage risk (my last knowledge it was 8% increase), but I changed the noeval to only look for suspicious code obfuscation, this lowers breakage risk to below 1%)
 
Last edited:
  • Like
Reactions: Jan Willy
Feature comparison

1784547121781.png


I have suggested both in uBO and AG to drop the useless malware blacklist, because
1. they are tiny compared to DNS & Antivirus company URL blacklists
2. they are stale (on average 6 hours old), better use MBAM Browser Guard, BD Traffic Light or Osprey browser protection or DOH with malware filters
 
  • Like
Reactions: Jan Willy, Sampei.Nihira and Gandalf_The_Grey
LinuxFan58 said:
@Sampei.Nihira

WebGL and WebGPU tests are both on browserleaks

When I get reports of website breakage, I will tune the protections down to only blocking access to debug WebGL/GPU. Debug is more used than the drawing of graphics what all the "WHHHOOEEE you are in trouble because your fingerprint is unique" websites do.

I was in marketing & sales and believe me: you can always be tracked. Only tracking has impact on website rendering speed and by combining some data points you also can track users (so full featured fingerprinting is not much used, only IKEA did that when I recall corectly).

Same as with noeval protection, blocking noeval increases website breakage risk (my last knowledge it was 8% increase), but I changed the noeval to only look for suspicious code obfuscation, this lowers breakage risk to below 1%)
Click to expand...

That's interesting.
Is it possible to boil this down to a simple rule using uBo/AG syntax?
 
  • Like
Reactions: Jan Willy
Sampei.Nihira said:
That's interesting.
Is it possible to boil this down to a simple rule using uBo/AG syntax?
Click to expand...
No it is a custom scriptlet :-) not in uBO or AG, that is the fun of Vibe coding. Ask AI to disect existing software, discuss components and alternative application opportunities, propose a change, assess feasibilty and write a prompt for AI using my old IT-knowledge to make it. Block unathorized access to Mic & Camera is also adopted to reduce website breakage. When existing WebGL/GPU scriptlet causes issues I change the existing scriptlet to only block debug access to WebGL/GPU :cool: (block 80% of WebGL/GPU fingerprinting without causing issues).

But I started with a uBO-scriptlet, I digg into it for you and PM you (but that will be tonight).
 
Last edited:
  • Like
  • Thanks
Reactions: Sampei.Nihira and Jan Willy
Jan Willy said:
This morning I didn't have a lot of time, so I didn't test WebGPU.
Now I did with version 4.1.2 and nothing was blocked.
If I understand correctly, Kees considers to change the scriptlet. It's not clear to me how the test on browserleaks will react on that.
Click to expand...

I use a script in Brave that, of course, should produce the same result in the test as you get in Firefox via about:config:

As you can see, it blocks the same content:

0.png

Although I've found on several occasions that Firefox's blocking is less problematic for certain websites.
 
  • Like
Reactions: Jan Willy
Guys, when I was playing with the professional check tool, it found something called "empty catch"

An empty catch block usually looks like someone caught an error and just... forgot to do anything about it, which is a real, common mistake. But your coding standards require to init, monitor, pas and exit gracefull, something that's allowed to fail quietly — like checking "is this text a valid pattern?" where "no" isn't an error, it's just an answer (explanation of Claude in layman's terms).

So I documented it in the code that it was intentional and I made a typo, causing the Security & Privacy scriptlets to fail.

I updated from 4.12 to 4.13 and the WebGL/GPU blocks work again. @Jan Willy yes I posted that I will tune WebGL/GPU down when people are complaining about website breakage (WebGPU is relatively new)

4.1.3 is availabe on Github and resubmitted for review
 
  • Like
Reactions: Jan Willy
@Jan Willy

Let's keep new 3P-Matrix-lite clean, until uBol-stripped not is published I pollute this thread, yes I am learning in uBol=stripped 4.2.3 also more whitelist rules for Security & Privacy exyta's

Have you seen the new Create custom DNR dialog ? Now uBol-stripped has the Custom cosmetic rule creator of uBol and the Adguard follow up in the Custom DNR rule creator

1784662826917.png
1784662902970.png
1784662972033.png
Domain rules are a bit faster than URL filter rules, so when you don´t need the URL use the simpler domain block rule (to squeze every inch of performance out of uBol-stripped) :-)
 
  • Like
Reactions: Jan Willy

You may also like...