Google today reached the final milestone in a browser-extension transition that has been years in the making, all remaining Manifest V2 extensions were removed from the Chrome Web Store.
Some forks of Firefox are ok, but if you actually dig and look inside about:config you’ll see with who it communicates, what telemetry it collects. What organisations fund it.
Care to elaborate? It’s actually not like chrome at all. The engine is different, it’s not Google, they haven’t blocked manifest v2 plugins… Other than being a web browser, how would you classify it as Chrome?
I don’t have to. Yea, it shares some backend Google services, but the rest of the browser, like the other 90% isn’t Chrome. It’s like comparing Windows and Mac OS and saying that they’re the same because they both connect to the same Internet and that their operating systems. Just like Chrome v Firefox, they are two distinctly different products.
I guess they could be referring to how much money Google throws at Mozilla to keep Google Search as standard in Firefox? Still, it’s a tenuous link at best
Not really. UBlock Origin Lite works really well. They even added content scripts recently. From a technical perspective MV3 offers more security by default.
They generate memory issues (use-after-free, dangling pointers, double free(), zombie processes, uncomplete teardown, GC failures or abrupt stops, race conditions, etc.) because of their shitty isolation, and their poor service-workers and IPC architecture.
What’s worse, they greatly limit the network APIs needed to active defense (DNR instead of webRequest).
I agree however that Chromium has some issues still. I have personally managed to crash my browser when calling the Mojo APIs via JavaScript. However, it wasn’t related to security. As GrapheneOS notes, no other browser engine provides the same levels of sandboxing. Recognizing the effectiveness of Chrome’s sandbox, Microsoft began evolving Windows kernel access control to formalize and harden these techniques at the OS level. The upcoming Windows Updates implements this in its new ProcessContainer support.
Blaming process isolation and IPC for memory bugs like Use-After-Free and dangling pointers fundamentally confuses language-level C++ problems with OS containment architecture. Memory corruption exists across all C++ engines (Gecko, WebKit, Blink); isolation is what prevents those bugs from compromising the host OS.
Handing third-party extensions blanket permissions to inspect and modify live plaintext traffic across all tabs creates a massive MITM exfiltration surface. Moving rule matching to declarativeNetRequest enforces least privilege by executing filters in the native engine without exposing sensitive network payloads to extension code.
webRequestBlocking is not deleted in MV3. The synchronous blocking engine still exists in Chromium. If an extension is installed via local policy or the Windows Registry (ExtensionInstallForcelist), full programmatic webRequestBlocking executes in Manifest V3 just as it did in MV2.
Blaming process isolation and IPC for memory bugs like Use-After-Free and dangling pointers fundamentally confuses language-level C++ problems with OS containment architecture. Memory corruption exists across all C++ engines (Gecko, WebKit, Blink); isolation is what prevents those bugs from compromising the host OS.
Yeah, but they instead greatly compromise the browser, and the problem is that these are not as likely to happen in MV2 (i.e., Firefox).
Why? Simple:
You have a long operation running inside an extension.
Your system (or the browser itselfs) suspends or even kills the associated Service Worker.
A new one has to be created.
If the previous memory chunk goes unreferenced, then you have a double free and/or an UAF.
If the previous memory chunk doesn’t get unreferenced, then you get a dangling pointer.
Either way you get a race condition if it’s something concurrent.
The problem is, if an attacker and/or a malicious process do compromise that unreferenced or unallocated memory, then any and all sandboxing will be esentially irrelevant and thus vulnerated, vulnerating not only the browser (something that itself can compromise sensible information), but even the OS.
Then you have the zombie processes because the current memory model in V8 causes SWs to forcedly stop before they can do any cleanup.
MV3 is not about security at all, is about more control over your own computer and about more control over the network (that way they can let more trackers, zero-days, ads, malvertisers and even malware to pass because browser-level blockers and firewalls won’t be able to block them).
Handing third-party extensions blanket permissions to inspect and modify live plaintext traffic across all tabs creates a massive MITM exfiltration surface. Moving rule matching to declarativeNetRequest enforces least privilege by executing filters in the native engine without exposing sensitive network payloads to extension code.
You’re doing a false equivalence here.
It’s not about blanket permission vs. almost no permissions.
You can have granular ACLs (which are being hindered by MV3), or OCap/CapSec, or even other security and permissions approaches.
They’re or incompetent or malevolous, these are the only two options left when you think a bit about it.
webRequestBlocking is not deleted in MV3. The synchronous blocking engine still exists in Chromium. If an extension is installed via local policy or the Windows Registry (ExtensionInstallForcelist), full programmatic webRequestBlocking executes in Manifest V3 just as it did in MV2.
It is in practice.
Not all users are able to do that (local policy install), as not all users are (or have to be) that tech savvy. That’s an exclusionary barrier towards inclusion and accesibility of security and sovereignity features.
The following filter options can’t be translated into DNR rules:
strict1p, strict3p: whether a network request is same-origin as its initiator
Entity-based values for domain= filter option (webextensions #394)
redirect-rule=: the DNR API does not support redirect-if-blocked concept (webextensions #493)
Click-to-load embedded contexts through redirect=click2load.html filter option
Regex-based removeparam= modifier filter options
Exceptions for all modifier filter options are not possible
Workarounds exist for removeparam= and csp= by carefully tuning the priority property.
Many very useful regex-based filters used in uBO are not allowed, or are rejected by the DNR API (webextensions #344)
replace=, can't modify the response body (full support is only possible with Firefox MV2)
ipaddress=, can't use IP address as a condition to block/unblock (full support is only possible with Firefox MV2)
urlskip=, this requires programmatic steps to extract a URL from another URL (partial support, for strict-blocked pages only)
aside from that it is somewhat better than default ublock but that’s a pretty big list of issues.
There’s also pretty restrictive length limits on filter lists iirc, so ubo lite would have to select top filters at some point. This getting worse as websites add more ads or obfuscate more requiring more rules.
Some of those limitations were never supported in Chrome to begin with. MV3 still supports webRequestBlocking at the engine level but it is gated behind enterprise policy (ExtensionInstallForcelist in the Windows Registry, macOS MDM, or Linux managed policy JSON). If an extension with webRequestBlocking is installed via policy, it restores programmatic interception.
Not all users are able to do that, as not all users are (or have to be) that tech savvy. That’s an exclusionary barrier towards inclusion and accesibility of security and sovereignity features.
In practice, I found it breaks sites more, lets some things through, triggers more adblock detectors, and doesn’t work as well with the annoyance list.
It doesn’t work on YouTube. And the maximum number of entries to block is limited.
Its not catastrophic though.
So UBO Lite is not wholly ineffective, no. It works great, mostly. Buts its definitely more of a nuisance to use, which is exactly what Google wants.
Big win for Firefox.
Firefox is Chrome with extra steps
I’ve never seen a more downvoted comment. This is true for every single other mainstream browser except Firefox.
Some forks of Firefox are ok, but if you actually dig and look inside about:config you’ll see with who it communicates, what telemetry it collects. What organisations fund it.
Care to elaborate? It’s actually not like chrome at all. The engine is different, it’s not Google, they haven’t blocked manifest v2 plugins… Other than being a web browser, how would you classify it as Chrome?
Not only are they different, Gecko is like 12 years older than Chromium.
In about:config check with what google services, urls, relays, vpns browser communicates. What organizations donate most money.
Hardly makes it “Chrome with extra steps”.
Did you actually look inside?
I don’t have to. Yea, it shares some backend Google services, but the rest of the browser, like the other 90% isn’t Chrome. It’s like comparing Windows and Mac OS and saying that they’re the same because they both connect to the same Internet and that their operating systems. Just like Chrome v Firefox, they are two distinctly different products.
I guess they could be referring to how much money Google throws at Mozilla to keep Google Search as standard in Firefox? Still, it’s a tenuous link at best
You can say that about almost every browser, but not Firefox.
That doesn’t even make sense. You bots need better prompts
Probably just young
Maybe used Chrome for years before ever hearing about Firefox
Huh, do we have engagement bots in Lemmy already?
We’re thriving guys!
Thanks for the laugh!
Lol no
Still time to delete this
Not really. UBlock Origin Lite works really well. They even added content scripts recently. From a technical perspective MV3 offers more security by default.
That’s a whole truckload of copium you’re consuming there, fella. Watch out for the side effects.
Clearly you’re the one struggling with coping.here
Keep telling yourself that.
No, they’re intrinsically less secure.
They generate memory issues (
use-after-free, dangling pointers,double free(), zombie processes, uncomplete teardown, GC failures or abrupt stops, race conditions, etc.) because of their shitty isolation, and their poor service-workers and IPC architecture.What’s worse, they greatly limit the network APIs needed to active defense (DNR instead of
webRequest).GrapheneOS disagrees with you:
https://grapheneos.org/usage#web-browsing
I agree however that Chromium has some issues still. I have personally managed to crash my browser when calling the Mojo APIs via JavaScript. However, it wasn’t related to security. As GrapheneOS notes, no other browser engine provides the same levels of sandboxing. Recognizing the effectiveness of Chrome’s sandbox, Microsoft began evolving Windows kernel access control to formalize and harden these techniques at the OS level. The upcoming Windows Updates implements this in its new ProcessContainer support.
Blaming process isolation and IPC for memory bugs like Use-After-Free and dangling pointers fundamentally confuses language-level C++ problems with OS containment architecture. Memory corruption exists across all C++ engines (Gecko, WebKit, Blink); isolation is what prevents those bugs from compromising the host OS.
Handing third-party extensions blanket permissions to inspect and modify live plaintext traffic across all tabs creates a massive MITM exfiltration surface. Moving rule matching to declarativeNetRequest enforces least privilege by executing filters in the native engine without exposing sensitive network payloads to extension code.
webRequestBlocking is not deleted in MV3. The synchronous blocking engine still exists in Chromium. If an extension is installed via local policy or the Windows Registry (ExtensionInstallForcelist), full programmatic webRequestBlocking executes in Manifest V3 just as it did in MV2.
The problem is, if an attacker and/or a malicious process do compromise that unreferenced or unallocated memory, then any and all sandboxing will be esentially irrelevant and thus vulnerated, vulnerating not only the browser (something that itself can compromise sensible information), but even the OS.
Then you have the zombie processes because the current memory model in V8 causes SWs to forcedly stop before they can do any cleanup.
MV3 is not about security at all, is about more control over your own computer and about more control over the network (that way they can let more trackers, zero-days, ads, malvertisers and even malware to pass because browser-level blockers and firewalls won’t be able to block them).
You’re doing a false equivalence here.
It’s not about blanket permission vs. almost no permissions.
You can have granular ACLs (which are being hindered by MV3), or OCap/CapSec, or even other security and permissions approaches.
They’re or incompetent or malevolous, these are the only two options left when you think a bit about it.
It is in practice. Not all users are able to do that (local policy install), as not all users are (or have to be) that tech savvy. That’s an exclusionary barrier towards inclusion and accesibility of security and sovereignity features.
The following filter options can’t be translated into DNR rules:
aside from that it is somewhat better than default ublock but that’s a pretty big list of issues.
There’s also pretty restrictive length limits on filter lists iirc, so ubo lite would have to select top filters at some point. This getting worse as websites add more ads or obfuscate more requiring more rules.
Like FB putting every character in every [w][o][r][d] on the site into a unique code block
Some of those limitations were never supported in Chrome to begin with. MV3 still supports webRequestBlocking at the engine level but it is gated behind enterprise policy (ExtensionInstallForcelist in the Windows Registry, macOS MDM, or Linux managed policy JSON). If an extension with webRequestBlocking is installed via policy, it restores programmatic interception.
Not all users are able to do that, as not all users are (or have to be) that tech savvy. That’s an exclusionary barrier towards inclusion and accesibility of security and sovereignity features.
In practice, I found it breaks sites more, lets some things through, triggers more adblock detectors, and doesn’t work as well with the annoyance list.
It doesn’t work on YouTube. And the maximum number of entries to block is limited.
Its not catastrophic though.
So UBO Lite is not wholly ineffective, no. It works great, mostly. Buts its definitely more of a nuisance to use, which is exactly what Google wants.
Thanks for the laugh! Keep telling yourself that.