985
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 Aug 2026
985 points (99.5% liked)
Technology
87807 readers
3721 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
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.
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:
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).
Edit: MV3 is a perfect example of inverse tivoization.
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.