• 0 Posts
  • 45 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.


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



  • First, I don’t care if they agree with me or not. It is an open source project. They said from they never intended to try to make a 1:1 extension with UBO. They clearly lay out the positives of MV3 as well, and the scripts permission feature is a relatively new addition. You or anyone can contribute or fork it you want to add something.

    I have spent enough time working on MV3 to know Chromium has solved a lot of the challenges. If you want to have a technical discussion about the APIs and differences or how you might do something with MV3, then let’s have the discussion. I never tried to claim MV3 is perfect.

    I just have little patience for essentially non-technical cultists who go around spreading misinformation while acting like they know way more than they do. Prove it then… 99% of people like you never actually want to have a real technical discussion, because you spread your opinions based on feelings and not facts.




  • Three are so many things wrong with this article I don’t even know where to start. In terms of danger from physical bodily injury, I have no reason to doubt this report while traveling on public transport. Though it is also highly dependent on the city and routes you take. It also doesn’t necessarily take into account total commute, which also includes travel on foot to and from transportation hubs. But a majority of crimes and incidents that happen on public transportation are often nuisance and property crimes, and other non-violent offenses. There are also quite a bit of unreported incidents that occur.

    What that translates to is that many people still encounter a higher level of incidents on public transportation that make them feel unsafe. In terms of actual physical safety though, if you summarize mass data like they’ve done here then public transportation is still much safer overall. However, that shouldn’t be used like done here to discredit people’s experiences and concerns with public transportation. The goal should be to still work on aggressively on improving people’s actual experience.

    The data doesn’t really matter in changing perspectives if people still significantly experience significantly more anxiety and fear by witnessing or experiencing intimidation, verbal hostilities and altercations, property crime and theft, public indecency, drug abuse, and other things that are legitimate reasons for increased anxiety and paranoia.