John Richard

NASA has no where that number of employees. How many years of data are we talking about?

Lol, nope. Data centers are built with advanced fire suppression systems.

It’s called MDM. Unfortunately most companies try to limit their MDM solutions to enterprises, but FleetDM is an okay choice.

No, they’re intrinsically less secure.

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.

Not really. UBlock Origin Lite works really well. They even added content scripts recently. From a technical perspective MV3 offers more security by default.