There are malicious extensions found in the chrome web store pretty frequently, and if I was making one, I would definitely use the API that lets me man-in-the-middle all network requests. So google’s statement that 40% or whatever of malicious extensions use that API seems plausible to me.
You could definitely make the argument that Google should just do a better job of reviewing extensions, but that alone also wouldn’t be a 100% solution. Google definitely messed up with the original rule limits, though. If chrome is more optimized then surely it must be able to handle just as many (if not more) rules than uBO.
This article is really wrong, wow. There is already a Manifest V3-compliant version of uBlock Origin, it’s discussed in this thread: https://github.com/uBlockOrigin/uBlock-issues/issues/338
I don’t know if it’s stated definitively anywhere, but I’m pretty sure the plan is to roll out that different version to Chrome users as an update to the existing extension. It’s going to be slightly worse because MV3 is still missing some API features.
There are some useful APIs that Firefox is missing compared to Chromium, like Web Share or Web Bluetooth: https://caniuse.com/?compare=chrome+117,firefox+117&compareCats=CSS,HTML5,JS,JS API
If I’m thinking about projects that could benefit the most from an exponential increase in active developers:
- Wine/Proton (could have a fantastic windows runtime on every *nix platform)
- ReactOS (lot of potential for a windows 7/10 upgrade path)
- Mozilla Firefox (would help with API parity with chromium)
- GIMP (but only if they agree to change the stupid name)
The rest goes to package managers and other lower-level projects that don’t get enough of a spotlight, maybe Brew or Curl or something.
I did say the element zapper was missing. uBO Lite is using the same default filterlists as uBO, which includes some trackers: https://github.com/uBlockOrigin/uAssets