lobsters score: 1 · tags: browsers, security
This seems pretty misguided. People in this forum will know I work for Firefox, so everything I say will be perceived as me doing my job rather than talking objectively, so I will stop here. :)
But if people have questions, I’m happy to share a more specific answer.
score 1 · canonical
https://rknf404.github.io/chromium-hardening-guide/BROWSER_SELECTION/#firefox
I genuinely really want to know what you think of this whole section on Firefox, speaking as a Firefox dev or otherwise. Because I’ve seen all of the points here mentioned many many times. I’ve also read here and there about Firefox improving on some of the points here but I’ve not seen any counter claim to the “Firefox is basically insecure and Chrome(ium) is the gold standard for browser security” (and I do believe this quote to be true - but for the record I do mostly still use Firefox personally)
score 1 · canonical
Can you clarify what you mean by “some points”? Earlier I said I’ll be happy to discuss somethign that is more specific. I don’t think this is? I don’t want to spend more time refuting than it takes to make a bold, incorrect claim. It just gets tiring.
OK, you nerd sniped me. Many of the linked claims are outdated, incorrect or “category error”: A lot of the “Chrome is doing this” security improvements make A LOT of sense for Chrome. But Chrome have a different codebase, a different architecture and different security issues. E.g., we have way less JIT type confusions, but much more “UXSS in the parent process” bugs. So, sure, you could frown upon Firefox for not having a JS heap sandbox. But realistically, I think our time was well spent to implement CSP in the parent process.
Something that’s truly missing: Yes, we do not use the isolatedProcess flag on Android yet. It’s coming soon, though :)
score 2 · canonical
In somewhat related news Gentoo has recently masked (disabled) the Chromium ebuild and it’s currently going through last rites, the process before removal form the Portage tree. I can fully sympathize. I’ve given up on Chromium/Chrome a while ago for similar reasons. The ridiculous build times in particular.
From the package.mask message:
Increasingly challenging to maintain with increased release cadence, upstream toolchain changes, and conflicts between trying to provide a consistent experience for Gentoo users (avoiding bundled where possible) vs. getting updates out in a timely manner. Many unfixed vulnerabilities.
Keeping it in ::gentoo isn’t a matter of just supplying an updated ebuild, but a commitment to keeping it up to date and finding a compromise between users’ expectations (like various USE flags & not forcing all bundled components) and maintainability.
Some more details: https://bugs.gentoo.org/982204#c53
I think LWN might have a take on this too but I don’t currently have a subscription.
score 1 · canonical
Yep, and that LWN story is on the site as well, with a free “subscriber link”! :-)
score 1 · canonical
Content Blocking For starters, extensions are always bad. Especially MV2 extensions, like uBlock Origin. Since MV2 extensions can access any site as well as a great many features without permission. MV3 prevents this, but it isn’t too much better since many extensions just ask for access to all sites anyway to work properly, but at least it offers the user control. With that in mind uBOL (uBlock Origin Lite) in Basic mode is pretty good, since it has no access to sites while still being able to deliver decent content-blocking. It also allows granting access to specific sites, such as Youtube (yes it works), for better filtering if needed. Other extensions and uBOL global modes risk security and weaken site isolation.
Hm? That adblocking extensions can intercept (any) network request on any site is by design. If you ignore the scriptlet injection and the cosmetic filtering, uBO is also a network request filtering engine, which allows you to precisely filter requests (like specific site while visiting certain domain) than DNS blocking could.
You have to put scary warnings on that capability because letting an extension intercept all requests is easily abused in the wrong hands, but that doesn’t make this access bad.
The author goes on to say that filtering engines (not made by the Chromium team) patched into Chromium or Brave’s in-browser blocking is better, but I don’t understand why it matters where the content blocking code lives (outside of the author complaining about attack surface).
score 1 · canonical
Having the blocking engine in the browser with access exposed via declarative rules system means (a) it’s simpler for alternative blockers to exist and provide the same functionality, and (b) you don’t have to audit or trust that the blocker is being sane/safe with your browsing history, because it never has it.
The bizarre history of the various things referred to as “ublock” is a pretty clear indication that people can’t and shouldn’t trust that extension makers are currently or will in the future do what’s right.
score 1 · canonical
(a) it’s simpler for alternative blockers to exist and provide the same functionality
I don’t consider this an upside,
webRequestallows significantly more flexible code (and by extensions more techniques to defeat anti-adblock) than the rulesets made for specifically content blocking extensions do. The only thing this does is ossify content block capability.(b) you don’t have to audit or trust that the blocker is being sane/safe with your browsing history, because it never has it.
This is moot because I don’t think any mortal user is informed adequately enough to give consent for extension permissions. If you give any permission, you’re extending trust to the extension author to not abuse it. Authors don’t even have to give you inline justification for why any specific permission is required.
Mozilla realized this problem and reviews extensions that go through the extension store before signing it, I have my gripes with the system but it’s what we’re left with.
The bizarre history of the various things referred to as “ublock” is a pretty clear indication that people can’t and shouldn’t trust that extension makers are currently or will in the future do what’s right.
Whatever transgressions done, the current status quo is significantly better than whatever ABP and friends are doing with “”“acceptable ads”“”.
It’s also going to be significantly better than trusting yet another Chromium fork to patch in an engine per patchfiles, which is my argument :/
score 1 · canonical
I don’t consider this an upside
Safari has had declarative content blocking for over a decade. There are dozens of competing options that make use of this feature - and you don’t have to trust what the author of the extension says at all. It won’t have access to your browsing history, ever, UNLESS they also provide an extra “regular” javascript extension (which IME is required for YouTube, the odd “Linux ISO” download site, and literally nowhere else).
On the other side of the fence we apparently have a monoculture of Ublock (which is also a bit over a decade old), another half a dozen different incantations of extensions with similar enough names to it that I’d wager I could gaslight most people other than the extension author themselves into believing any of them is the “proper good one” in about 15 minutes, and… who knows what other scammy shit.
This is moot because I don’t think any mortal user can give adequate consent for extensions. If you give any permission, you’re extending trust to the extension author to not abuse it.
Which is exactly why a declarative model works really fucking well. In Safari literally the only “permission” with a content blocker plugin is “Allow in Private Browsing”. That’s fucking it. If the plugin author also ships a separate, regular JS extension for specific sites (I’m side-eying you here Youtube), that’s a separate extension, with separate permissions, and AFAICT they always default to no permissions until you agree.
Whatever transgressions done, the current status quo is significantly better than whatever ABP and friends are doing with “”“acceptable ads”“”.
So you’re saying I can go to https://ublock.org/ and not worry about sneaky practices?
It’s also going to be significantly better than trusting yet another Chromium fork to patch in an engine per patchfiles, which is my argument :/
I mean… the whole concept is laughable. You’re choosing to use a browser/engine developed by a company whose revenue model is essentially entirely ad-based, and then worrying about how best to block those ads.
This would be like finding the best way to crush up diabetes medication so it isn’t noticeable in your McFlurry.
score 1 · canonical