In the wake of a certain ad-funded browser company bundling adtech into its browser yet again, some people have been recommending Ungoogled-Chromium (UGC). I think it’s fine to recommend UGC with caveats, such as the fact that it disables component updates that include:
- Certificate revocation. Chromium uses downloaded CRLSets for revocation; it does not support OCSP.
- Out of band security patches. When browser components have exploits in the wild, they need to be patched ASAP; updating billions of installations within time-frames measured in hours often means restartless out-of-band updates.
- Out of band certificate bundle updates.
If you assume Google uses its component update server logs maliciously, you may wish to consider a fork that still offers component updates provided by a different party’s servers.
UGC disabled mDNS at one point. This exposed local IP addresses over WebRTC for years, but they seem to have shipped a fix in May 2023 to disable non-proxied UDP.
UGC also disables the Chrome Web Store in favor of installing extensions out of band. Make sure you regularly update your extensions installed out-of-band, since UGC won’t do it on its own. Some scripts and a special extension re-implement some of this functionality.
Overall, UGC is still safer than QtWebEngine despite making heavy compromises to security for privacy (though I can’t see how either benefited from disabling mDNS: I’m not aware of threat models under which revealing a local IP to every application is preferable to revealing it to just Google). Running UGC is fine if you understand these trade-offs and have accounted for them. I use it in headless mode to run accessibility and performance tests.
Originally posted on seirdy.one: See Original (POSSE). #Chromium #Chrome
Seirdy’s Home
My personal IndieWeb site. I write about and develop software to promote user autonomy. Topics include accessibility, security, privacy, and software freedom.Seirdy’s Home
Seirdy reshared this.
Seirdy
in reply to Seirdy • • •Seirdy
in reply to Seirdy • • •oh and I never recommend QtWebEngine-based browsers. No component updates and extremely behind on regular updates, almost never built with Chromium’s LLVM toolchain hardening, extra fingerprintable…the list goes on. QtWebEngine is great for rendering mostly-trusted webpages but is definitely not ready to be a fully capable browser.
Re. toolchain hardening: to be fair, distros often don’t build Chromium itself with its toolchain hardening and most replace vendored hardened dependencies with system libraries. Fedora and Arch do it well enough (they still make it use system libraries without LLVM hardening but otherwise build it right); older Fedora versions patched Chromium to build with GCC!
Seirdy
in reply to Seirdy • • •You’ve probably seen me salivating over alternative engines like Servo and Weasyprint, but I’m years away from recommending switching to them.
It takes a lot to handle untrusted content, especially untrusted applications!
LisPi
in reply to Seirdy • • •Seirdy
in reply to LisPi • • •Seirdy
in reply to Seirdy • • •Targeting secure browser profiles
Seirdy’s HomeLisPi
in reply to Seirdy • • •I think part of the issue though is that some browsers will disagree on what minimum/basic security a secure profile involves.
Tor Browser gets rid of all the JIT features from "safer" and just disables all Javascript as safest. The others don't do nearly as well.
LisPi
in reply to Seirdy • • •Oh that was real? Browsers don't honor revocation? I was hoping that was some weird nightmare I was half-remembering...
niconiconi
in reply to LisPi • • •GRC's | SSL/TLS Certificate Revocation Awareness – The case for OCSP Must-Staple
www.grc.comSeirdy
in reply to niconiconi • • •@niconiconi @lispi314 Google is pushing for lower lifetimes instead. Lifetimes under 10 days make OCSP obsolete; if enough certs do this revocation becomes a lot easier to manage.
Must-Staple is essentially a short-lived certificate that only certain clients benefit from. Hell, even curl doesn’t check revocation status by default.
I use and recommend must-staple but I also recognize that only a small minority of sites will adopt it, and the right solution is to gradually reduce cert lifetimes to reduce the amount of revoked certs in circulation and make CRLSets/CRLite/Let’s-Revoke easier to pull off.
Seirdy
in reply to Seirdy • • •LisPi
in reply to Seirdy • • •Seirdy
in reply to LisPi • • •@lispi314 @niconiconi Incremental improvements reduce the odds of exploitation. Not all sites need to make this transition, and every little reduction reduces the odds of a bad cert being in circulation. At scale, this translates to a reduction in incidents.
Domains that can’t do short lifetimes can benefit from the now-less-crowded revocation lists.
Seirdy
in reply to Seirdy • • •R. L. Dane
in reply to Seirdy • • •Seirdy
in reply to R. L. Dane • • •R. L. Dane
in reply to Seirdy • • •KHTML itself hasn't changed, though, has it? It's still pure KHTML under the hood, and not just a nasty Blink hook like what's in the Qt libs, right?
Not that much of anything actually *uses* #KTHML (afaik)
Seirdy likes this.
Lady Strawberries
in reply to R. L. Dane • • •R. L. Dane
in reply to Lady Strawberries • • •Ah, that's a bummer. But Konqueror is still around.. it's it just hooked into blink now? :(
Lady Strawberries
in reply to R. L. Dane • • •Seirdy
in reply to Lady Strawberries • • •Seirdy
in reply to Seirdy • • •Tanith the Gay
in reply to Seirdy • • •Seirdy
in reply to Tanith the Gay • • •Simon I Groove musically
in reply to Seirdy • • •Sensitive content
Seirdy
in reply to Simon I Groove musically • • •G
in reply to Seirdy • • •Seirdy
in reply to G • • •G
in reply to Seirdy • • •1544770 - [meta] Add mDNS support to webrtc signaling
bugzilla.mozilla.orgSeirdy
in reply to G • • •