• 6 Posts
  • 604 Comments
Joined 3 years ago
cake
Cake day: June 22nd, 2023

help-circle
  • Marie Concentration-Camp Perez is supposed to be my representative. I can’t even begin to tell you how disappointing she is, but it’s also Democrats in my district that are the problem. If you ask a Democrat here what is more important, trans women playing in women’s sports or preventing a genocide, they’ll repeat some MSM pro-Israel talking point and say if you don’t unconditionally support trans women playing in women’s then you’re a bigoted racist Nazi that shouldn’t be allowed to vote.

    Then they’ll go on some tangent about how we need to raise taxes for more housing while they give it to the corporate landlords constantly raising rents, all because the landlord agrees to “reduce the rent” on like 5 apartments for minorities using a median income from the overpriced gentrified Portland, OR neighborhoods as the standard rate. They are equally as corrupt if not more than some of the Republicans.

    I honestly think people that actually want change should give up on the Democrat party. They claim everyone is racist, but they definitely hate Middle Eastern people. The media had everyone distracted with El-Sayad and a handful of other elections, for them to notice how big the problem is elsewhere.














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


  • This is extremely funny that you’re trying to insult me, based on your feelings and not facts.

    My only participation in this thread was that UBO Lite creator disagrees with you, which he publicly stated, but you felt… Offended? (No idea) - and decided to insult me rather than to deal with facts.

    There is a word for people like you.

    Troll.

    Citing gorhill’s disclaimer that uBOL isn’t a 1:1 clone of uBO doesn’t prove Chrome is “ad-infested”—it conflates advanced power-user filtering with everyday ad blocking. Many limitation were Firefox-exclusive APIs that Chrome MV2 never supported in the first place.

    Under the hood, standard filter lists compile directly into native C++ evaluation via declarativeNetRequest, while cosmetic element hiding and anti-adblock defusers run through the scripting and userScripts APIs. Furthermore, synchronous webRequestBlocking is still built into the Chromium engine for policy installs. Pointing out the architectural reality of how these APIs actually execute isn’t trolling; it’s addressing technical mechanics rather than hyperbole.