• 1 Post
  • 213 Comments
Joined 3 years ago
cake
Cake day: June 22nd, 2023

help-circle
















  • KeePass honestly sucks for the most part. I love local vault and hope something better comes along, but KeePass UI constantly gives me issues. I’ve tried KeePassXC and that is what I use still, but being limited to opening a single entry at a time. Additional properties are a pain. It’s author not even understanding the need for using the desktop session for the CLI (requires passing password via the terminal to or having separate key file). KeeShare not working on Android. So many things that Bitwarden/Vaultwarden solves much better and quicker. Sad that Bitwarden/Vaultwarden didn’t make a local SQLite client that doesn’t rely on a server.



  • 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.


  • You can’t claim to be “semi-technical” while simultaneously refusing to look at technical facts and dismissing platform mechanics as “empty yapping.” How a browser engine executes extensions is inherently technical. Claiming you want facts while ignoring the architecture just means you’d rather stick with an emotional narrative than understand how the software actually works.

    Chrome MV2 never supported some features people claim were lost: Features like in-flight response body rewriting and pre-socket IP filtering were Firefox-exclusive APIs (filterResponseData). Chrome MV2 never had them, so MV3 did not take them away.

    webRequestBlocking is not dead in MV3. Google did not delete the synchronous blocking engine from Chromium. It requires installing via policy now. If an extension is provisioned via local policy, full programmatic webRequestBlocking runs in MV3 just as it did in MV2.

    Everyday ad blocking works normally. For standard Web Store installs, uBlock Origin Lite compiles the standard filter lists (EasyList, EasyPrivacy, uBO filters) into native browser rules. Banners, trackers, and video ads are blocked.

    The original claim was that “Chrome users don’t know what an ad-free web looks like.” That is provably false. If you want to understand the issue as a “semi-technical” user, you have to separate actual browser engine mechanics from internet hyperbole.