State of Web Browsers on Debian
"this browser project is fixing security issues in chromium and making a hardened browser. it's still work in progress but i see great promise in what these people are doing"
Some of their complaints of ungoogled-chromium were a little bit odd in my opinion, such as it not being updated fast enough, but appears that the last version of available through guix was done fast?
Some command line flags with policies can do some decent configuration in my opinion. https://www.chromium.org/administrators/linux-quick-start
I don't really have any complaints about ungoogled-chromium. I use the Flatpak version and it seems to get timely updates.
I currently use Devuan Ceres (Unstable)
My main browser is Abrowser plus a personal user.js in order to avoid automatic connections, disable Jit, improve fingerprinting and so on.
I hardly ever run ungoogled chromium.
I also have Firefox ESR and Pale Moon for testing purposes, also hardened with a user.js.
Can you share some details of what specifically you've changed in your user.js and why?
Hi!
To be honest, dozen of strings.
I use arkenfox project and I applied several changes, some from Tor Browser, other from Librewolf and a few personal ones.
I could use it on any Firefox-based browser, including abrowser.
-Forcing Tor useragent for enhancing fingerprinting. Librewolf does it too.
-Disabling Jit in order to improve security (but reduces performance) Chromium-based browser will do this in the future. Besides, Microsoft is working on that.
-Disabling WEbRTC (media.peerconnection), dom.webaudio, default fonts (browser.display.use_document_fonts from Tor), media.webspeech, blocking certicates downloading, that's a security feature but also an antiprivacy characteristic(security.OCSP.enabled) and so on.
-Avoiding automatic addons updates. You may do it anyway if you manually check in Add-ons and themes section. I prefer a sort of "demozillation", downloading xpi files from Github/codeberg webs.
With reference to Abrowser, you still can see an automatic connection to shavar.services.mozilla.com when you open the browser if you write about:networking.
It will disappear changing browser.safebrowsing.provider.mozilla.updateURL string with nothing.
>"-Disabling Jit in order to improve security (but reduces performance)"
This looks like it's worth trying to see how bad the performance hit is. Can you share your method for disabling jit on a Firefox-based browser?
According to arkenfox:
"Disable Ion and baseline JIT to harden against JS exploits
* [NOTE] When both Ion and JIT are disabled, and trustedprincipals
* is enabled, then Ion can still be used by extensions"
javascript.options.ion -> false
javascript.options.baselinejit -> false
javascript.options.jit_trustedprincipals -> true [FF75+] [HIDDEN PREF] So you have to create this one.
You'll see in "heavy-javascripted" webs.
OK good, I found the first two settings with a search, and now I've added the trustedprincipals option. I've been reading that there's not much difference in how it runs without jit. I was warned I might see a slowdown on the Odysee video site, but Odysee is actually running better without jit than normal for me for some reason. Maybe Odysee has adjusted their code.
> Forcing Tor useragent for enhancing fingerprinting.
I was wondering, if you are not completely disabling JS, can you still selectively block access to any user info queriable through JS, like user platform for example? I had been using Tor for a while, set on the default 'Safer' mode, when I realized that JS was still leaking my os.platform string, possibly bringing me much closer to being uniquely identifiable since the Tor Browser had been spoofing my useragent line all along.
On abrowser, the Chameleon extension will consistently randomize all of your fingerprinting characteristics. You may show up as a unique user, but you'll never show up as the same unique user twice.
This is the form of anti-fingerprinting that Brave also uses - constant randomization.
Tor Browser's anti-fingerprinting is more in the form of presenting thousands of users who all appear to have the same characteristics. Blending in with the herd.
My personal preference is the constant randomization form of anti-fingerprinting. It's a subject that's open to debate though. There's a lot to be said in favor of Tor's methods.
> You may show up as a unique user, but you'll never show up as the same unique user twice.
That makes sense.
Otherwise you are always dependent on a statistics you cannot control (i.e. how many other users really look like you), in order for there to acually be a herd and not just one lonely potential member of a desirable but non-existing herd. Especially if you are visiting low traffic websites.
Not sure why Tor Browser does not have its security level set at 'Safest' by default. I read "JavaScript is disabled on non-HTTPS sites" as "JavaScript is enabled on all HTTPS sites" in 'Safer' mode, which means always. I thought it would probably make Tor Browser users look more similar if JS was not leaking their platform.
In fact, that useragent is Firefox ESR for any GNU/Linux + privacy.resistFingerprinting.
I also tried to hide OS platform but I think it's not possible, unless disabling JS (javascript.enabled -> false) or randomizing with an addon like Chameleon as @andyprough said.
>"I also tried to hide OS platform but I think it's not possible, unless disabling JS (javascript.enabled -> false) or randomizing with an addon like Chameleon as @andyprough said."
Brave and browsers with Chameleon are both able to randomize the OS platform. Brave sometimes reports the accurate OS but the fingerprint websites think they are being spoofed, so will say the true OS core is "unknown". Kind of funny to see the fingerprinters being fooled by truthful information.
I think it's enough with Firefox/Abrowser/Iceweasel and privacy.resistFingerprinting.
Canvas hash is always randomized.
Anyway, nice to know that about Brave. However, I'm not really keen on Chromium browsers.
"However, there are some glaring flaws with the ungoogled-chromium project. For instance, ungoogled-chromium lags behind upstream Chrome for days every release."
https://qua3k.github.io/ungoogled/
"Fast updates — no more than 4 days lag time ideally."
https://docs.hexavalent.org/
chromium --js-flags=--jitless
"At the cost of reduced performance, you can disable just-in-time compilation of JavaScript to native code, which is responsible for roughtly half of the security vulnerabilities in the JS engine"
https://wiki.archlinux.org/title/Chromium#Disable_JIT
https://www.debian.org/security/2021/dsa-5026
^ looks like firefox-"esr" has been updated for debian stable.
To be honest, I think firefox and chromium are both kind of problematic in many ways.
It would be nice if people started focusing on addons for badwolf, instead of those bloated messes above.
I do have my own reasons, of course, but meh...
Until someone makes a noscript like addon for badwolf, only obviously way better/less bloated, I will probably use hblock for block trackers/ads.
Webkit, the non-google one or qt one, seems to be in my personal opinion, the best way forward. To each their own though, but meh...
That's just me.
I only really use a firefox fork when I am in dire need at this point, but I have a few comps and a vm of some other operating systems, so yeah... I have that luxury...
I understand that some don't have that.
But yeah, if you need something more than persay, badwolf...
Go with a firefox derivative or if need be, a chromium clone that is updated enough to be useful, that is very ungoogled.
;)
On a more related note, I wonder if Debian is doing any better since this thread was formed. :)
> It would be nice if people started focusing on addons for badwolf, instead of those bloated messes above.
Hi, I never heard of Badwolf before. It seems interesting. Is there any friendly documentation on how to write extensions for it?
Well, it supposedly can use webkit2 addons, but for better info, here:
https://hacktivis.me/projects/badwolf/fqa#adblocker
If that isn't enough security, you can also use this in combination with badwolf, I do so... :)
https://github.com/hectorm/hblock
Its up to you.
> Well, it supposedly can use webkit2 addons
I couldn't seem to find much about those. Definitely not a detailed documentation as there is for Firefox/Chromium WebExtensions (and as there used to be for XUL addons).
I saw some "WebKitWebExtension" API description[1]. It makes an impression of not being very easy to use. At the same time, it might be more capable than what mainstream browsers offer in their restricted APIs...
> If that isn't enough security, you can also use this in combination with badwolf, I do so... :)
Actually, I was thinking about the possibility of porting/writing my own extension for it :d
[1] https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebExtension.html
This article looks a bit easier to understand in terms of creating webkit extensions:
https://webkit.org/blog/3476/content-blockers-first-look/
> his article looks a bit easier to understand in terms of creating webkit extensions:
> https://webkit.org/blog/3476/content-blockers-first-look/
Sounds very similar in spirit to the declarativeNetRequest pushed by Chrome family of browsers[1]. It's not a bad idea, *as long as* the "legacy" methods of request inspection&blocking are retained. The problem with such declarative rules is that:
1. Their format must be comprehensive. Otherwise, some specific kinds of functionalities will be impossible to implement. And some will be impossible anyway. It is not without reason that Firefox has its streamFilter API to modify HTTP responses on-the-fly[2][3].
2. Even though those who propose&push such declarative filtering shemas present them as very efficient, the approach taken (i.e. having rules provide regexes for matching URLs) is not necessarily the best.
If curious, read about how much trouble the move to declarative rules causes in Chromium family of browsers[4].
[1] https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/StreamFilter
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1255894
[4] https://github.com/uBlockOrigin/uBlock-issues/issues/338
EDIT: Also, it seems even WebKit-based browsers that support some kind of extensions (e.g. Falcon) lack documentation for their APIs :/