Keine Aktualisierungen für Privacy-Handbuch mehr - Vorschläge für medium strenge Firefox ESR user.js

Das Privacy-Handbuch wird aus gesundheitlichen Gründen nicht mehr fortgeführt.

https://www.privacy-handbuch.de/changelog.htm

Für mich als Laien ist das ein Problem, weil ich mit den aus dem Kuketz Blog angegebenen Alternativen nicht vertraut bin:
Siehe 2.3 user.js-Projekte

Firefox configuration hardening gefällt mir aufgrund der schieren Masse an möglichen Addons nicht, die ich optional hinzufügen kann. Der konservative Ansatz hat mir beim Privacy Handbuch gefallen - so wenig wie möglich, so viel wie absolut nötig an Addons.

Zum Verständnis, mein Profil ist das für hohe Sicherheitsanforderungen mit der user.js medium streng (Firefox ESR 115.x) im PrHdb:
https://www.privacy-handbuch.de/handbuch_21browser-schnell.htm

Ich bin dementsprechend offen für einen technischen Austausch darüber, was als Alternative für mein Sicherheitsprofil eher geeignet ist.

Firefox configuration hardening wirkt auf mich nicht strikt genug, aber belehrt mich gerne eines Besseren.
Arkenfox meint einerseits, dass ublock origin und Skip redirect als Addons okay sei, womit ich einvestanden bin. NoScript sei hingegen überflüssig, was ich für eine provokative Aussage halte. Perspektivisch wird JShelter als 4. und letztes Addon irgendwann obsolet laut Privacy-Handbuch, ich weiß nur nicht wann. Dementsprechend bin ich für jeden technischen Austausch dankbar.

Beste Grüße

Sobald Firefox ESR >120

Firefox 120+ hat einen eingebauten Schutz gegen Fingerprinting, der den Canvas und Fontmetrics Fingerprint randomisiert, das exakte Auslesen der installierten Schriftarten verhindert usw.

Eine zusätzliche Installation von Add-ons ist nicht nötig, wenn man die Fingerprinting Protection (FPP) man unter about:config mit folgender Einstellung aktiviert […]

Quelle

Firefox ESR 128 ist für den 09.07.2024 geplant: Firefox Release Calendar.

2 „Gefällt mir“

JShelter war nie eine gute Idee. Eine Extension mit laut Mozilla Add-On-Store nur 560 Nutzer schadet dem Fingerprint mehr, als dass sie nutzt. D.h. das Fingerprinting-Script muss nur feststellen, dass du JShelter benutzt und schon bist du in der kleinen Gruppe an JShelter-Nutzern. Das Fingerprinting-Script kann dann die manipulierten Werte gleich ignorieren. Kombiniere das mit all der anderen Fingerprinting-Fläche (Extensions, Einstellungen, OS-Gruppe, … ) die dein Browser bietet und du bist ziemlich sicher einzigartig. Extensions sind zudem ziemlich limitiert in dem was sie tun können in Bezug auf Fingerprinting-Mitigations. Gute Mitigations müssen im Browser eingebaut sein. Lass dich nicht von Fingerprinting-Testseiten irritieren, da die nur an der Oberfläche kratzen, von dem was machbar ist.

NoScript und uBlock Origin haben Überschneidungen aber auch Unterschiede. Aber die Hauptaufgage von NoScript, das selektive Blocken von JS, kann uBlock Origin. Um die Nutzung einer Extension zu rechtfertigen, muss der Nutzen ganz klar das Risiko (Fingerprinting, Angriffsfläche, Schwächung der Site-Isolation) überwiegen.

Warum dann Firefox ESR? Die ESR-Variante bekommt nicht alle Sicherheitspatches, nur die die hoch genug eingestuft wurden zurückportiert. Von daher wäre der normale FF-Release-Channel besser, oder gleich auf Chromium-basierte Browser umsteigen für höhere Sicherheit.

Arkenfox ist am besten recherchiert und gepflegt seit vielen Jahren.

1 „Gefällt mir“

Wenn du beim Firefox bleiben möchtest, dann würde ich dir LibreWolf empfehlen. Bei LibreWolf ist es nicht notwendig, Anpassungen über die about:config oder user.js vorzunehmen - einzige Ausnahme ist hier beschrieben.

Siehe auch: Empfehlungsecke - Firefox.

1 „Gefällt mir“

Vermutlich stimmt das. Aber als Laie muss ich ab einem gewissen zeitlichen Aufwand zum Anlesen von Lösungen auch irgendwann Vertrauen entgegenbringen. Ich werde JShelter loswerden, sobald ich auf eine neue Lösung umgestiegen bin.

Dazu muss ich mich belesen. Hast du eine Quelle für mich, wie ich uBlock Origin so einrichten kann (es ist ja durch die PrHdb-Einstellungen voreingestellt), dass es ohne NoScript geht?

Nichts zu ergänzen, hier stimme ich dir zu.

Absolut korrekt. Firefox bekommt Hochrisiko-Secruity-Updates:

Maintenance of each ESR through point releases is limited to high-risk/high-impact security vulnerabilities, and in rare cases may also include off-schedule releases that address live security vulnerabilities. Backports of any functional enhancements and/or stability fixes are not in scope.
Quelle

Insofern bleibt Firefox stabil, enthält hohe Sicherheitsupdates für meine persönlichen Sicherheitsanforderungen und bekommt Updates über die offiziellen Debian Repositories meines Linux Debian 12 eingespielt. Stabilität und Sicherheit in Einklang zu bringen ist nicht leicht für mich. Ich bin in der Hinsicht auf der konservativeren Seite.

Aber du kannst gerne deine Perspektiven einbringen, wieso ich zu Bleeding Edge wechseln sollte, falls mir irgendwo ein Denkfehler unterlaufen ist :slight_smile:

Arkenfox scheint Firefox ESR zu unterstützen, also fällt es in den engeren Kreis der relevanten Lösungen.

Danke für den Tipp! Es ist nur etwas kompliziert bei Debian 12 einzurichten. Und es mag widersinnig klingen, aber ich würde eher mein Firefox ESR über die offiziellen Debian Repositories behalten wollen und zusätzlich einen enormen Aufwand zum Anpassen mittels Arkenfox für ESR Versionen betreiben, als ein zusätzliches Repository für Librewolf einzubinden, um dann alles vorkonfiguriert zu haben.

Zusätzliche Paketquellen können mehr Instabilität in Debian bedeuten.
Weiterhin will ich eine Lösung für Linux und Windows im Dual Boot, sonst habe ich doppelten Weiterbildungsaufwand.
Das Team um Librewolf ist kleiner als das um Mozilla und Debian (Stichwort Langlebigkeit von Projekten) - klingt widersinnig angesichts der Nutzung des Privacy-Handbuchs, aber ich hatte damals keine bessere Lösung als Laie gefunden.

Aber ich nehme gerne weitere Argumente hierzu auf, wieso ich doch Librewolf nutzen sollte :slight_smile:

https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide

Was ist denn an einem normalen Firefox-Release instabil? Die allermeisten Nutzer und Distros verwenden das normale Release.

Der Browser ist einer der wichtigsten Bausteine beim Thema Sicherheit. Warum willst du da nur die Hochrisiko-Vulnerabilitäten gepatcht haben und auf die anderen Sicherheitspatches verzichten?

Einfach ein paar Kommandos kopieren.

Tun sie im Normalfall nicht. Die Paketquellen sind ja extra für Debian kreiert worden.

Habe seit Jahre ein Browser-Profil mit Arkenfox und der Aufwand ist nicht hoch, insbesondere nicht nach einmaliger Einrichtung, da man danach eigentlich nur noch das Update-Skript laufen lässt und gut ist.

Wenn wir gerade bei Firefox sind, welche Erweiterungen sind denn überhaupt noch nötig bzw. empfehlendswert ?

„Besonderheit“

Versteht das jemand bzw. hat das jemand verstanden?
Es gibt kein Verzeichnis „chrome“ im Profilordner.
Darf (muss) das einfach nachträglich manuell erstellt werden?

Bei mir ist das vermutlich …\Browser LibreWolf\Profiles\Default\storage\permanent\chrome

1 „Gefällt mir“

Die userChrome.css muss in den Profilordner (Adresszeile: about:profiles → „Wurzelordner“ → „Ordner öffnen“) in den - immer beim ersten Mal zu erstellenden - Ordner „chrome“.
Der Knopf wird einen Ordner öffnen, der einen Namen im Format von 8 alphanumerischen Zeichen (Buchstaben und Zahlen), einem Punkt, und dem Namen des Profils (siehe about:profiles). Da gehört dann der Ordner rein, und in diesen die css-Datei einfügen/erstellen.
Beispiel Dateipfad: ~/.mozilla/firefox/ch6uougt.default-esr/chrome/userChrome.css
Unter Windows ist die Verzeichnisstruktur ab firefox in einen Unterordner von %AppData%

Die Konfigurationen auf der Seite entsprechen Mikes persönlichen Einstellungen, die eben auch seinen Bedürfnissen/Vorlieben entsprechen.
Die userChrome.css bringt hier weder Sicherheits noch Datenschutztechnisch etwas.
Sie versteckt den blauen Punkt der an einen Tab angezeigt wird, wenn im Hintergrund sich etwas im Tab verändert hat. Es hat keine weiteren Effekte, außer optische.
Während die userChrome.css standardmäßig deaktiviert ist, da man damit auch Unfug treiben könnte, und sich immer wieder etwas verändern kann im Browser.

uBlock Origin.

Optional: Skip Redirect, wobei das auch Dinge kaputt machen kann.
Da muss man dann regelmäßig whitelisten, und gerade bei Zahlungsvorgängen das Addon besser gleich deaktivieren, oder dessen Modus auf „Aus“ stellen, bis man damit durch ist. Vielleicht auch einfach ein eigenes Browserprofil für Shopping verwenden.

Sonst gibt es keine wirklichen „pflicht“ Addons, der Rest lässt sich hauptsächlich mit Browserinternen Einstellungen gerade biegen. Eventuell bietet sich ein referer-Addon an, das die Übertragung von diesen HTTP-Header feiner Regeln kann als die network.http.referer.XOriginPolicy & network.http.referer.XOriginTrimmingPolicy Einstellungen, falls man das für Webseiten wie Pixiv o.Ä. freigeben möchte/muss, die das nachladen von Bildern oder anderer Ressourcen ohne Referer von ihren Servern unterbinden.

Das Privacy-Handbuch hat sein eigenes Konzept mit den AddOns CanvasBlocker und JShelter verfolgt, und nicht auf resistFingerprinting und co. gesetzt. Dafür gibt es valide Gründe.

Im Grunde kann uBlock Origin alles, was NoScript auch kann. Da muss man sich dann in den dynamischen Filter Modus einarbeiten. Deswegen ist NoScript „überflüssig“.
Ich vermisse immernoch die Matrix von uMatrix, da man die Sachen dort einfacher so fein, aber zugleich nicht zu fein einstellen kann/konnte…
Aber NoScript hatte nie wirklich ein gutes Interface. Wenn du dort alle einzelnen Felder für eine Domain - also einen Custom Regelsatz - festlegst, wirst du vielleicht nicht ganz glücklich mit dynamischen Filtern, da es da etwas nerviger ist, und nicht alles möglich ist, da dort keine Wildcards o.Ä. funktionieren, wenn man nur bestimmte Dinge (z.B. Bilder/Medien) freigeben will.
Ansonsten kannst du genauso Domains global oder per Seite mit dynamischen Filtern freigeben, wie das mit NoScript möglich ist, und meist getan wird - „Vertrauenswürdig“ „Nicht Vertrauenswürdig“ - dabei werden die normalen Filter von uBlock nicht angerührt, solange du keine allow (Grün) Regeln, sondern noop (Hellgrau) setzt. Die Schnittstelle in der GUI dafür wurde aber so verändert, dass das nicht mehr versehentlich passieren sollte.

Der XSS Filter von NoScript ist meiner Meinung nach überflüssig, und rechtfertigt für mich kein AddOn. Wenn dir der wichtig ist: uBlock hat keinen, könntest du dir dafür also installieren. Ist aber eigentlich nicht dein Verantwortungsbereich, sondern der des Webseitenbetreibers.

2 „Gefällt mir“

Sehr gute Seite. Dazu belese ich mich die nächsten Tage :+1:

Ich habe mir die Unterteilung der Sicherheitsstufen mal angeschaut, von denen ESR nur die obersten zwei gefixt bekommt:

Critical - Vulnerability can be used to run attacker code and install software, requiring no user interaction beyond normal browsing.
High - Vulnerability can be used to gather sensitive data from sites in other windows or inject data or code into those sites, requiring no more than normal browsing actions.
Moderate - Vulnerabilities that would otherwise be High or Critical except they only work in uncommon non-default configurations or require the user to perform complicated and/or unlikely steps.
Low - Minor security vulnerabilities such as Denial of Service attacks, minor data leaks, or spoofs. (Undetectable spoofs of SSL indicia would have „High“ impact because those are generally used to steal sensitive data intended for other sites.)
Quelle

Dann habe ich mal in die ESR Fixes geklickt und musste feststellen, dass es vorwiegend, aber nicht nur Critical & High Vulnerabilities Fixes sind: https://www.mozilla.org/en-US/security/advisories/mfsa2024-19/

Weiterhin habe ich mir veranschaulicht, dass Firefox ESR vom Tor Browser verwendet wird - wäre widersinnig, wenn das einen Nachteil darstellen sollte. Außerdem ist Firefox ESR für große Ogranisationen gedacht wie Universitäten, Schulen, Stadtverwaltungen und Unternehmen (Quelle). Wenn meine Uni ESR verwendet und diese erfolgreich Angriffe abwehren kann, wieso soll ich als Low Target Ziel mich diesen schnellebigen Release Zyklen beugen?
Für mich zählt zu Stabilität auch, nicht ständig mit den neuesten Features „beglückt“ zu werden, sondern einen stabilen Workflow beibehalten zu können. Ich bin mir nicht sicher, ob es deutlich geworden ist, aber ich bevorzuge LTS und deswegen nutze ich Debian und passend dazu Firefox ESR :slight_smile:

Weil wie oben beschrieben Unternehmen, Unis etc. auch keinen größeren Aufwand darum machen, da die Sicherheitsupdates hinreichend gut die wichtigsten Angriffsvektoren abdecken. Es muss ein ziemlich raffinierter, auf meine Person abgestimmter Angriff sein, damit mein System kompromittiert wäre.

Für ja, aber nicht von Debian. Ich wünsche mir von den Debian Devs gesichtete Paketquellen :slight_smile:

Das klingt gut, danke für deine Eindrücke! Mit Arkenfox + Firefox ESR werde ich mich in den nächsten Tagen weiter beschäftigen.

1 „Gefällt mir“

Tor Browser hängt immer wieder selbst Firefox ESR hinterher. Die haben einfach nicht die Mittel den schnelleren Updates des normalen Release-Channels mitzuhalten. Das ist der Hauptgrund. Nur weil das Tor Projekt etwas macht, heißt es nicht, dass das die sicherste Lösung ist, sondern Anonymität und Machbarkeit bei begrenzten Mitteln sind dort höher bewertet. Siehe z.B. Tor Browser unter Android, der, genau wie FF unter Android, nicht einmal eine Sandbox hat und auch in nahezu jedem anderen Sicherheitsbereich Chromium um viele Jahre hinterher hinkt.

Habe schon mit vielen Organisationen und Unternehmen zu tun gehabt, aber noch nie irgendwo Firefox ESR in Verwendung gesehen. Die verwenden meist Chrome oder Edge. Wenn der Desktop mit Linux läuft, dann war es meistens Chrome oder normales Firefox. Universitäten bilden da eher die Ausnahme, da teilweise Linux-lastig, aber auch da war hauptsächlich normales Firefox.

Du traust also Mozillas eigenen Repos nicht?

Dem Debian Package-Maintainer von Firefox traust du zu auch nur ansatzweise eine dermaßen komplizierte Software wie ein Browser mit >10 Millionen Code-Zeilen bei jedem Update zu auditieren? Das ist vollkommen illusorisch, selbst für deutlich unkompliziertere Software. Das Gegenteil ist der Fall. Du bringst weitere Trusted Parties ins Spiel, die keinen Vorteil für die Sicherheit bringen, aber ein zusätzliches Risiko. In diesem Fall ist das zusätzliche Risiko natürlich sehr gering, da es von Mike Hommey und anderen mit sehr guter Reputation maintaint wird, aber ich will dir das Prinzip nahebringen, da es auch für alle andere Packages gilt.

Package-Maintainers und Kontributoren zu Linux-Distros unterliegen keinen strengen Kontrollen. Linux-distros haben ein Supply-Chain-Problem. Siehe Kommentar eines Fedora-QA-Verantwortlichen als Beispiel (betrifft aber alle Distros ähnlich): we are a project that allows 1,601 minimally-vetted people to deliver arbitrary code executed as root on hundreds of thousands of systems .

Bei mir gibts mit Debian 12 von Anfang an null Probleme mit zusätzlichen Paketquellen. Aber wenn du nix zusätzlich installieren willst, den Librewolf gibts auch als AppImage: https://gitlab.com/librewolf-community/browser/appimage/-/releases

1 „Gefällt mir“

In Verbindung mit uBlock Origin noch LocalCDN (Dankeschön nobody, sofern nobody „der“ nobody ist), was eine durchaus sinnvolle Kombination darstellt.

1 „Gefällt mir“

4 Beiträge wurden in ein existierendes Thema verschoben: Browser Addon LocalCDN

Ich habe mir die Mühe gemacht, Arkenfox und Librewolf genauer unter jenen Gesichtspunkten zu betrachten, die mir beim PrivacyHandbuch wichtig sind. Zu meiner konservativen Long-Term-Support-Philosophie, gepaart mit dem Wunsch nach hinreichender Sicherheit und vor allem Datenschutz gehört auch, das meine User-Experience nicht ständig über den Haufen geworfen wird, wie es bei Release Firefox der Fall sein kann. Ich bin nicht interessiert daran, immer den neuesten Sch…nickschnack von Mozilla zu erhalten, der vielleicht doch nochmal überdacht werden sollte.

Aus diesem Grund habe ich mich hieran orientiert: https://privacy-handbuch.de/handbuch_21n.htm

Gleichzeitig musste ich feststellen, dass ich bei Librewolf wohl nicht drum herum käme, veränderte UX in Kauf zu nehmen (es gibt offenbar keine ESR Versionen) - die Einrichtung wäre aber einfacher als bei Arkenfox. Insofern habe ich Arkenfox mit der aktuellen ESR Version (FF115), Release Arkenfox (FF122) (vorweg gesagt, sie sind hier identisch von den geprüften Einstellungen), Release Librewolf und - ja, ihr lest richtig - Brave miteinander verglichen und geschaut, inwiefern sie mit der kritischen Haltung des PrivacyHandbuchs mitgehen. Hier das (subjektive) Ergebnis beim Vergleich ausgewählter Modifizierungen des Handbuchs:

extensions.pocket.enabled = false

Arkenfox FF115/122 : Uncheck*
Librewolf_126: Check
Brave: Uncheck

Pocket ist überflüssig und politisch. Librewolf versteht das, Arkenfox nicht - egal, ob Version 115 oder F122. Ich brauche niemanden, der mir ausgewählte Artikel unterschieben will. Brave-News und ‚neuer Tab=leere Seite‘ lassen sich wenigstens problemlos per Klick abstellen (Mikes Einstellungen https://www.kuketz-blog.de/einstellungen/#brave-desktop).
*es werden nur gesponsorte Pocket Artikel deaktiviert, aber politisch bleibt es somit trotzdem

extensions.screenshots.disabled = true

Arkenfox FF115/122 : Uncheck
Librewolf_126: Uncheck
Brave: Check

Da schießen beide Browser den Vogel ab:

Wenn man einen Screenshot haben möchte, dann gibt es genügend Tools, die Screenshots erstellen können ohne irgendwelche webbasierten Komponenten mit Datensammlung

Mehr muss ich dazu nicht sagen. Brave hat Screenshots Opt-In (Tastaturkürzel ist einzutippen).

identity.fxaccounts.enabled = false

Arkenfox FF115/122 : Uncheck
Librewolf_126: Check
Brave: Check(?)

Verleitet zu der gefährlichen Annahme, dass Mozilla Cloud (oder irgendeine Cloud) sicher sei. Librewolf zeigt hier Vernunft, Arkenfox ist mir zu nachlässig.
Brave erlaubt auch eine Sync-Einrichtung, aber nicht unbedingt über Cloud (sehe ich zumindest nicht).

browser.formfill.enable = false

Arkenfox FF115/122 : Check
Librewolf_126: Check
Brave: k.A.

[Es] ist […] nicht auszuschließen, dass raffinierte Angreifer Wege finden werden, um unsichtbare Formulare automatisch ausfüllen zu lassen und die Daten auslesen.

Hier zeigen die beiden Browser Einsicht.

extensions.blocklist.enabled = false

Arkenfox FF115/122 : Uncheck
Librewolf_126: Uncheck
Brave: ~Check

Hier sind Arkenfox und Librewolf geradezu blauäugig gegenüber Mozilla:

Die Extension blocklist kann Mozilla nutzen, um einzelne Add-ons im Browser zu deaktivieren. Es ist praktisch ein kill switch für Firefox Add-ons und Plug-ins. Beim Aktualisieren der Blockliste werden detaillierte Informationen zum realen Browser und Betriebssystem an Mozilla übertragen.
[…]
Ich mag es nicht, wenn jemand remote irgendetwas auf meinem Rechner deaktiviert oder deaktivieren könnte.

Mehr habe ich nicht zu ergänzen. Librewolf bekommt so die ersten Kratzer in meiner Wahrnehmung.
Bei Brave habe ich nicht viel gefunden - nur, dass deaktiviertes Safe-Browsing nicht mehr vor „gefährlichen“ Erweiterungen schützt (manuell, aber simpel über Mikes Empfehlungen einzustellen).

extensions.getAddons.cache.enabled = false

Arkenfox FF115/122 : Uncheck
Librewolf_126: Uncheck
Brave: Uncheck

Seit Firefox 4.0 kontaktiert der Browser täglich den AMO-Server von Mozilla und sendet eine genaue Liste der installierten Add-ons und die Zeit, die Firefox zum Start braucht. Als Antwort sendet der Server Statusupdates für die installierten Add-ons. Diese Funktion ist unabhägig vom Update Check für Add-ons, es ist nur eine zusätzliche Datensammlung von Mozilla.

Da ich keine Lust auf so etwas habe, gibt es für Arkenfox und Librewolf Minuspunkte.
Fairerweise sei gesagt, dass beim Brave-Browser auch alle Telemetriedaten deaktiviert werden müssen, aber das ist wenigstens übersichtlich deaktiverbar per Klick (siehe Mikes Einstellungen).

browser.tabs.crashReporting.sendReport=false
datareporting.policy.dataSubmissionEnabled=false
datareporting.healthreport.uploadEnabled=false

Arkenfox FF115/122 : Check
Librewolf_126: Check
Brave: Uncheck

Wenigstens hier werden Telemetriedaten unterbunden. Beim Brave-Browser ist das manuell, aber einfach einzustellen (siehe Mikes Einstellungen):
Erlaubt Produktanalyse, die den Datenschutz respektiert (P3A): Uncheck;
Ping der täglichen Nutzung automatisch an Brave senden: Uncheck;
Automatisch Diagnoseberichte senden: Uncheck

toolkit.coverage.endpoint.base = „“
toolkit.coverage.opt-out = true
toolkit.telemetry.coverage.opt-out = true

Arkenfox FF115/122 : Check
Librewolf_126: Check
Brave: k.A.

Auch das Add-on von Mozilla, das die Einstellungen zur Telemetrie ignoriert und die Firefox Version, Update Channel, Betriebs­system und -version sowie die Information, ob die Über­tragung von Telemetriedaten deaktiviert wurde, sendet, wurde hier löblicherweise von Arkenfox und Librewolf deaktiviert.
Solche Spielereien/Katz-und-Maus-Spiele konnte ich bei Brave nicht finden.

browser.region.update.enabled = false
browser.region.network.url = „“

Arkenfox FF115/122 : Uncheck
Librewolf_126: Check
Brave: ~Uncheck

Laut Dokumentation verwendet Mozilla diese Daten, um irgendwelchen „relevanten“ Content auszuwählen und die Standardsuchmaschine zu definieren (in Abhängigkeit von den Verträgen, die Mozilla mit unterschiedlichen Suchdiensten abgeschlossen hat).

Arkenfox nervt mich spätestens hier gewaltig, Librewolf zeigt Vernunft. Bei Brave lässt sich die Standortabfrage simpel deaktivieren (Mikes Einstellungen: Standort:Websites dürfen meinen Standort nicht sehen).

browser.pagethumbnails.capturing_disabled = true (neue Variable)

Arkenfox FF115/122 : Uncheck
Librewolf_126: Uncheck
Brave: k.A.

Firefox speichert Screenshots von jeder besuchten Webseite auf der Festplatte, um sie später als Thumbnails auf der New Tab Page einzublenden. Diese Speicherung gefällt mir nicht, da ich mein Surfverhalten nicht protokollieren möchte, auch nicht auf dem eigene Rechner.

Beide Browser scheinen es nicht zu wissen, was mir übel aufstößt. Ob Brave diese Funktion besitzt, ist nicht ersichtlich.

browser.newtabpage.activity-stream.asrouter.userprefs.cfr.addons = false
browser.newtabpage.activity-stream.asrouter.userprefs.cfr.features = false

Arkenfox FF115/122 : Check
Librewolf_126: Check
Brave: k.A.

CFR ist ein Werbesystem für Firefox Add-ons und Features. Es ist unklar, nach welchen Richtlinien Mozilla die Empfehlungen auswählt. Mit der Empfehlung für Add-ons hat Mozilla schon einmal öfter daneben gegriffen und ein Tracking Add-on als Tracking­schutz empfohlen (Bugzilla #1483995) oder ein angebliches Security Add-on beworben, dass massenweise Daten gesammelt hat.

Löblich, dass beide Browser es ebenso deaktivieren. Soweit ich das sehe, bewirbt Brave selbst keine Add-Ons, Google tut das im Chrome Web Store.

extensions.htmlaboutaddons.recommendations.enabled = false

Außerdem werden in der Add-on Verwaltung von Firefox Empfehlungen angezeigt, die den Nutzer zur Installation verführen sollen. Die Empfehlungen werden als iFrame von einem Mozilla Server geladen und als erstes beim Aufruf der Add-on Verwaltung angezeigt.

Beide Browser deaktivieren das. Zu etwas Ähnlichem in Brave kann ich nichts sagen oder finden.

browser.vpn_promo.enabled

Arkenfox FF115/122 : Uncheck
Librewolf_126: Check
Brave: Check(?)

Wenn Firefox im Private Browsing Mode erkennt, dass man einen öffentlichen Wi-Fi Accesspoint verwendet, wird man mit Werbung für das Mozilla VPN belästigt.

Arkenfox findet Mozilla Werbung toll, Librewolf nicht so. Es gibt offenbar Brave VPN, aber ich finde nur Einträge bei den Tastenkombinationen (Feld ist leer) und im Private Browsing Mode ist mir nichts aufgefallen.

extensions.webextensions.restrictedDomains = „“

Arkenfox FF115/122 : Uncheck
Librewolf_126: Check
Brave: k.A.

Standardmäßig werden Add-ons auf Webseiten von Mozilla deaktiviert, um die Funktionalität der Dienste sicherzustellen, die auch für interne Funktionen von Firefox genutzt werden
[…]
Damit gibt es auf diese Webseiten zum Beispiel praktisch keinen Trackingschutz mehr, obwohl die Webseiten teilweise Trackingcode einbinden, den uBlock blockieren würde.

Wieso wundert es mich nicht, dass Arkenfox nicht das Problem sieht, aber Librewolf schon? Zu Brave kann ich nichts sagen.

ui.use_standins_for_native_colors = true
ui.systemUsesDarkTheme = 0

Arkenfox FF115/122 : Uncheck
Librewolf_126: Uncheck
Brave: Uncheck(?)

CSS Attribute für Farbe und Hintergrund von HTML Elementen können die Systemfarben der Desktop Umgebung verwenden. Damit sieht die Webseite einer nativen Desktop Anwendung ähnlich. Diese individuellen Farben können via Javascript ausgelesen werden und für das Fingerprinting des Browsers verwendet werden. Gleiches gilt für den Darkmode.

Da Arkenfox nicht an „erweiterte“ Anti-Fingerprinting-Maßnahmen glaubt (https://github.com/arkenfox/user.js/wiki/3.3-Overrides-[To-RFP-or-Not]#-fingerprinting) (und offenbar gehören obige Einstellungen zu „erweitert“), sondern RFP (privacy.resistFingerprinting) mit allen dazugehörigen Problemen empfiehlt, wohingegen das PrivacyHandbuch lieber gleich FPP (privacy.fingerprintingProtection) nahelegt, sind die Einstellungen konsequent, aber vllt verstehe ich auch RFP nicht richtig. Jedenfalls will es mir nicht in den Sinn, wieso mehr Anti-Fingerprinting-Maßnahmen laut Arkenfox nutzlos seien.
Arkenfox und Librewolf scheinen in dieser Hinsicht konsequent zu sein, aber viel Verständnis hatte ich bis jetzt dafür nicht.

Der Brave verfolgt offenbar einen anderen Weg:

Fingerprinting-Testseiten suggerieren oft, dass man eindeutig erkennbar ist. Das ist allerdings nicht entscheidend, sondern ob man über Surf-Sessions hinweg wiedererkennbar/verfolgbar ist. Und genau hier schneidet der Brave-Browser mit seiner Fingerprinting-Protection wie der Site Data Isolation und den Anpassungen gegenüber Chromium hervorragend ab. Mikes Quelle

  • Heißt das nun, dass die RFP oder FPP in Firefox(-forks) in 2024 nocht nicht so ausgreift sind?

  • Und sind die Fingerprinting Maßnahmen aus dem Privacy Handbuch nicht so relevant, sodass sich das Thema Fingerprinting für Arkenfox/Librewolf und Brave relativiert?

network.connectivity-service.enabled = false

Arkenfox FF115/122 : Check
Librewolf_126: Check
Brave: Uncheck(?)

Bei jedem Start und bei einem Wechseln der Netzwerkverbindung kontaktiert Firefox den Server detectportal.firefox.com außerdem, um die IPv4 und IPv6 Verbindungen zu testen.

Hier sind Arkenfox und Librewolf willens, einzugreifen. Für Brave habe ich an anderer Stelle in /ect/hosts IPs blockiert (Mikes Einstellung), aber das nur zur Erwähnung.

Fazit:

Insgesamt macht Arkenfox auf mich einen sehr unsympatischen Eindruck, Librewolf wirkt auf mich einfacher zu bedienen, aber auch etwas naiv in manchen Belangen. Beide Browser haben eine für meinen Geschmack zu unkritische Haltung gegenüber Mozilla, wobei Librewolf wesentlich besser, aber nicht perfekt abschneidet. Mein Vertrauen ist deshalb nicht gefestigt.

Sogar das Privacy Handbuch betrachtet das Projekt Librewolf wohlwollend (mit FPP) (https://privacy-handbuch.de/handbuch_21_librewolf.htm?q=fingerprinting), aber nach einigen obigen Negativ-Beispielen bin ich nicht bereit, dieses für meinen täglichen Bedarf zu verwenden.

Ironischerweise habe ich mich deshalb dem Brave Browser genähert, was niemals meine Intention war. Mit Mikes Einstellungen (https://www.kuketz-blog.de/einstellungen/#brave-desktop) konnte ich das Wichtigste händisch einstellen (eine Export-Datei wäre mir lieber…).
Zusätzlich habe ich ublock Origin installiert, allerdings in Hard Mode (https://github.com/gorhill/uBlock/wiki/Blocking-mode:-hard-mode), damit er mir (als Ersatz für NoScript) zunächst alle 3rd Party Elemente rigide blockiert. Weiterhin habe ich Mikes Einstellungen soweit übernommen. Der Hard Mode ist unter „Meine Filter“ allerdings ergänzt um Filter aus dem PrivacyHandbuch:
‚uBlock filters – Annoyances‘
‚AdGuard – Social Widgets‘
‚Phishing URL Blocklist‘
‚Block Outsider Intrusion into LAN‘
‚AdGuard URL Tracking Protection‘
‚AdGuard – Ads‘.

Eine weitere Modifizierung des Hard Mode steht in „Meine Regeln“, wo ich aus dem Privacy Handbuch

* facebook.com * block
* facebook.net * block
* fbcdn.net * block
* fonts.googleapis.com * block
* fonts.gstatic.com * block
facebook.com facebook.com * noop
facebook.com facebook.net * noop
facebook.com fbcdn.net * noop

das hier zusätzlich in die dauerhafte Liste übernommen habe.

Kurzum, ich bin durch den Kompromiss, Librewolf evtl. zu nutzen, soweit über meinen Schatten gesprungen, dass ich zu eigenem Erstauen bereit bin, externe Quellen einzubinden (Brave für Debian 12), Release Versionen zu akzeptieren und einem Browser mit Chromium- (also Google-)Unterbau das Vertrauen zu schenken, weil Mikes Argumente (https://www.kuketz-blog.de/brave-browser-warum-ich-ihn-gecko-basierten-browsern-firefox-vorziehe/), aber in erster Lnie das maue Ergebnis von Arkenfox und Librewolf mich überzeugt haben.

Ganz wohl fühle ich mich nicht damit, aber noch habe ich mich nicht final entschieden.

Meine Fragen (neben den Zwischenfragen weiter oben) wären also:

  • Brauche ich noch Skip Redirect für Brave?
  • Fallen euch Fehler beim Customizing von Brave auf?
  • Ist es für euch nachvollziehbar, strengere Bewertungskriterien bei Mozilla anzusetzen oder seht ihr Arkenfox oder Librewolf entspannter? Wenn Letzteres, was ist daran besser als an Brave?
1 „Gefällt mir“

Vielen Dank für diese Analyse!

Für mich in jedem Fall JA.

Ich hatte mal viel Zeit in einen Vergleich von arkenfox- und PrHdb-Konfiguration gesteckt und fand bei PrHdB größere Übereinstimmung mit meinen Präferenzen.

Arkenfox ist für mich ein super gut dokumentiertes Template für die Konfigurationsparameter, in dem ich aber sehr viel ändern muss.
Aber ich habe viel aus der arkenfox-user.js gelernt.

1 „Gefällt mir“

Kannst Du hier bitte einmal ausführen wie Dein persönlicher Weg war?

Brave bietet leider kein komfortables hard-coden von Einstellungen über Betriebssysteme hinweg. (Was es für mich im Einsatz auf Rechnern von Verwandten und Freunden, die sich auf Presets von mir verlassen wollen, ausschließt.) Außerdem ist es nicht annähernd so granular konfigurierbar.

Bei Brave muss man erst einmal eine Unmenge an unerwünschten Funktionen händisch in Untermenüs deaktivieren. Anschließend sind die Einstellungsmöglichkeiten, abseits von Cryptowallets, Rewards, Videocalls, VPN und Chatbots, sparsam vorhanden. Weniger Autonomie hat ja auch seine angenehme Seiten und macht Firmen wie Apple erfolgreich.

Ich versuche den Hype um Brave zu verstehen. Als langjähriger Firefox-Nutzer ohne fanboyism fremdle ich allerdings noch mit den geschilderten Umständen. Trotzdem bin ich, wie so viele in der Bubble, aber immer interessiert.

Eine ausfürliche Antwort gibt’s u.a. im Microblog von Mike Kuketz:
Brave-Browser: Warum ich ihn Gecko-basierten Browsern (Firefox) vorziehe

Danke, @Musti, den kenne ich. Wie auch die Mastodon-Posts von Mike dazu.
Mich hatte interessiert wie es @smallville persönlich ging. Er hat (spekulative Unterstellung) keine Fanbase, die applaudiert und/oder ausrastet.