Testverhalten von FF110 mit uBlock Origin ist mir unverständlich

Hallo zusammen,
ich habe hier einen Pihole-Server, in Verbindung mit einem Unbound Server laufen. Das Ganze läuft jetzt seit fast 2 Jahren ohne für mich erkennbare Probleme.
Google, Facebook und auch einige andere Dienste sind über den Pihole komplett geblockt.
Jetzt aber zu meiner eigentlichen Frage:
Ich nutze den FF110 in Verbindung mit der user.js von Arkenfox und der user-override.js von 12bytes.
Darüber hinaus habe ich uBlockOrigin und JShelter installiert.
Ich habe dann heute mal Test Adblock auf diesem FF-Profil laufen lassen.
Ergebnis: Nur 28% der Tests wurden mit eingeschaltetem uBlockOrigin geblockt (Grün). Nicht geblockt (Rot) wurden viele Google Dienste die über entsprechende RegEx Einträge im Pihole Server geblockt sind, bzw. eigentlich geblockt werden sollten.
Schalte ich jetzt uBlockOrigin auf dieser Testseite aus, dann werden 88% der Tests geblockt (Grün).
Benutze ich jetzt ein FF-Profil ohne user.js und ohne irgendwelche AddOns für diesen Test, ist das Ergebnis identisch mit dem vorgenannten Profil bei ausgeschaltetem uBlockOrigin.
Verstehen tue ich das nicht. Hat hier jemand eine Erklärung für dieses Verhalten und welche Maßnahme(n) sollte ich daraus ableiten? z.B. uBlockOrigin deinstallieren ?

Nachtrag:
Habe noch folgendes versucht. uBlock Origin auf Werkseinstellungen zurückgesetzt. Jetzt werden auf der genannten Webseite wieder 88% geblockt. Allerdings werden auch wieder Twitter Domains als nicht geblockt angezeigt die vom Pihole über RegEx eigentlich geblockt werden müssten.
Erst wenn ich uBlock komplett deaktiviere entspricht das Blockingverhalten der Testseite den Einstellungen im Pihole…

JShelter schadet mehr als es nutzt mit der Arkenfox user.js
https://github.com/arkenfox/user.js/issues/1388#issuecomment-1057542283
https://github.com/arkenfox/user.js/issues/1388#issuecomment-1057959990
https://github.com/arkenfox/user.js/issues/1388#issuecomment-1057989887

das threat model taugt auch nicht um den Browser Fingerprint zu veringern ohne RFP.
Diese Performance, Timings, und Geo APIs auf die jshelter zugreift sollen den Fingerdruck veringern?! Echt? :slight_smile:
Die JS- und DOM-Änderungen sind aber alle auffindbar und liefern selbst zusätzliche Datenpunkte mit hoher Entropie für das Fingerprinting.
https://jshelter.org/threatmodel/
https://github.com/arkenfox/user.js/issues/1388#issuecomment-1059905786

Liegt vermutlich auch, daran, dass dieses Jahrhundert jshelter nicht mehr fertig werden wird.

Die übergeordnete Aufgabe der Initiative „Internet der nächsten Generation“ besteht darin, das Internet für das dritte Jahrtausend und darüber hinaus neu zu konzipieren und umzugestalten.

jshelter kommt von diesen Next Generation PR Heinis
https://www.fsf.org/news/fsf-announces-jshelter-browser-add-on-to-combat-threats-from-nonfree-javascript

Zu deiner eigentlichen Frage. Alle Adblocker Tests sind sinnlos, mit Ublock.
https://nitter.adminforge.de/gorhill/status/1583581072197312512

1 „Gefällt mir“

Danke @ark für Deine interessante Antwort…
JShelter habe ich jetzt erst einmal deinstalliert, da ich bei der Arkenfox user.js bleiben möchte.
Die Empfehlung von JShelter im Privacy Handbuch. Ist diese Empfehlung so zu verstehen, dass sie nur in Verbindung mit den verschiedenen user.js gilt die dort zum Download angeboten werden ?

Ja, im Privacy-Handbuch wird ein Konzept verfolgt, und für die Umsetzung von diesem wird, unter anderem, JShelter verwendet.
Bei Arkenfox hingegen geht die Empfehlung in eine andere Richtung, siehe „Anti-Fingerprinting Extensions“ in deren Wiki unter 4.1: Extensions - Don’t bother - also nur RFP, und ansonsten CanvasBlocker.

Es ergibt wenig Sinn, Empfehlungen aus beiden Quellen zu kreuzen, da sie unterschiedliche Empfehlungen geben (das Privacy-Handbuch ratet bspw. von RFP ab, Arkenfox hingegen rät zu dieser Option).

Zusätzlich ist die Arkenfox user.js „nur eine Vorlage“, dadurch gibt es vermutlich viele Unterschiede zwischen den Nutzern, während die user.js Varianten vom Privacy-Handbuch idealerweise so genutzt werden sollten, wie sie sind, und die Addons entsprechend konfiguriert.
Da die PrHdb user.js, und die Addons, samt Ihrer Konfigurationen, aufeinander abgestimmt sind, und hoffentlich vom Großteil der Nutzer ebenjener Kombination verwendet werden, ist es wohl aus Sicht der Autoren eine akzeptable Lösung.
Für die Arkenfox user.js gilt das nicht, da dort davon abgeraten wird, und sich die Nutzer hoffentlich daran halten.

Angeregt durch Deine beiden Antworten habe ich mal spaßeshalber folgendes gemacht:

  • Neues FF Profil mit der user.js (sehr streng) aus dem PrHdb und den dort empfohlenen
    Addons (uBlock Origin, Canvasblocker und JShelter mit den empfohlenen jeweiligen
    Einstellungen) eingerichtet.
  • Mein vorhandenes Profil mir der user.js von Arkenfox und der user-override.js von 12bytes
    mit uBlock Origin, Canvasblocker und deinstalliertem JShelter.

Dann jeweils diese Testseite aufgerufen.

Und hier die beiden Ergebnisse:

Die vorstehenden Ergebnisse sind nur jeweils eine Zusammenfassung. Da ich nun wirklich kein Experte bin habe ich mir die jeweiligen Details nur oberflächlich angesehen. Die Zusammenfassungen zeigen jedoch keine nennenswerten Unterschiede.

Deutlich unterschiedlich aber ist das Browserverhalten wenn ich diese Testseite aufrufe:

  • mit Arkenfox
    Sowohl beim Neuaufuf dieser Testseite, als auch bei jedem Reload ändert sich der Wert für
    „Signature“ und der PNG Hash.

  • PrHdb
    Die Werte für „Signature“ und PNG Hash bleiben bei jedem Reload unverändert.

Wird dieses Verhalten auf dieser Testseite nur durch die Einstellungen des CamvasBlockers
beeinflusst oder spielt hier auch die jeweilige user.js mit hinein ?

Das beobachtete Verhalten bei den PrHdb Einstellungen wird durch die CanvasBlocker Einstellungen erreicht.

Ein wichtiger Faktor noch:
Sobald der Browser geschlossen wurde, oder wenn der gleiche Code auf einer anderen Webseite verwendet wird, um einen Canvas Fingerprint zu erstellen, gibt es einen anderen Fingerprint.
Das liegt daran, dass pro Webseite ein Seed generiert wird, und dieser für die Modifizierung des Canvas genutzt wird. Sofern diese Einstellung hier, im Handbuch, unter „CanvasBlocker Preset Settings“, dem letzten Teil unter Punkt 2 der Auflistung, genutzt wird, oder die empfohlenen Einstellungen importiert wurden, werden diese Seeds beim schließen des Browsers gelöscht, und beim nächsten Besuch neue generiert, und damit auch andere Fingerprints.

Das Ergebnis ist also „irrelevant“, da man auch einfach in Cookies eine zufällige ID speichern kann, die ebenso die Browser-Session über, für die gleiche Seite, hält. Dafür kann eine Webseite nicht ganz einfach anhand sich ständig ändernder Fingerprints in gleicher Session feststellen, dass diese modifiziert werden (auf andere Weise sicherlich schon).

PS: Es sind nicht beides meine Antworten. :grin:

Danke für diese Hinweise…
Mein Verständnis des von Dir beschriebenen Sachverhaltes fasse ich mal so zusammen:

  • Bei der Nutzung der bzw. einer der anderen user.js empfiehlt das PrHdb
    zunächst einmal den ergänzenden Einsatz von uBlock Origin, Canvasblocker und
    JShelter.

  • Mit JShelter in Verbindung mit dem Canvasblocker wird der Einsatz einer ebenfalls
    zum Download angebotenen CanvasBlocker-settings.json empfohlen.

  • Ohne JShelter kann man unter 3 verschiedene Setups auswählen. Wobei ich für
    einen weiteren Test den von Dir erwähnten „Expert Modus“ gewählt habe.

Das Ergebnis, zumindest beim Testen auf Browserleaks ist jedoch unterschiedlich.
Mit JShelter und entsprechender Konfiguration des CanvasBlockers bleibt die Signature und der PNG Hash immer gleich bzw. wird erst nach Neustart verändert.

Ohne JShelter und mit CancasBlocker im Expert Modus ändern sich die beiden vorgenannten Werte bei jedem Relaod der Testseite.

Ich werde also dieses Firefox Profil ohne JShelter und mit dem CanvasBlocker im Expert Modus weiter nutzen. Oder mache ich das etwas falsch ?

Wenn der Wert „privacy.resistFingerprinting“ unter about:config auf true steht, keines der beiden Addons zu nutzen. Steht er auf false ist best practice nur canvas blocker zu nutzen.

Wir empfehlen CanvasBlocker bereits als Alternative zu RFP - das ist alles, was Sie brauchen und alles, was Sie tun können - naive Skripte täuschen.
Fast jedes Skript enthält Canvas, also ist fast jedes naive Skript abgedeckt. Man muss NICHT mit dem Timing herumspielen, mit Plugins herumspielen, mit Audio herumspielen, Web-Worker kaputt machen (es tut dies, weil es weiß, dass Worker es aufdecken)
https://github.com/arkenfox/user.js/issues/1388#issuecomment-1057959990

Ich gehe mal davon aus, dass Dein Beitrag sich auf die Verwendung der user.js von Arkenfox bezieht…?
Diese user.js beschreibt in [SECTION 4500] insgesamt 10 prev´s die zur Aktivierung von RFP gesetzt werden müssen bzw. von den Autoren schon gesetzt sind …Zitat: „It is an all-or-nothing buy in: you cannot pick and choose what parts you want“…
Sofern man also diese user.js so nutzt wie Arkenfox sie „ausliefert“ gilt dann aber auch die Aussage im Arkenfox Wiki, wo der CanvasBlocker zumindest als optional gelistet ist.

Der von Dir verlinkte Thread stammt aus März 2022; ist also 1 Jahr alt. Offensichtlich hat sich mittlerweile die Einschätzung des Autors der Arkenfox user.js zum CanvasBlocker geändert.
Wie auch immer. JShelter und da hast Du recht wird dort nicht gelistet und sollte demzufolge auch nicht verwendet werden.
Ich habe in meinem Profil uBlockOrigin und Redirect (beide als recommended gelistet) installiert. Ich verlass mich da absolut auf den/die Autoren von Arkenfox.

Entschuldige den langen Text, auch weil es streng genommen alles Off-Topic ist… (Thread-Titel) - aber es fällt mir in diesen Fall ansonsten ziemlich schwer, richtig zu antworten, ohne die Länge noch schlimmer zu machen. Auch bin Ich mir nicht ganz sicher, wie viel Erfahrung du, oder ein anderer Leser, in diesem Bereich hast.

Im Grunde hast du, aus meiner Sicht, 2 interessante Presets/Voreinstellungen im CanvasBlocker, „Stealth“/„Schwer zu detektieren“ und „Maximum Protection“/ „Maximaler Schutz“.
Davon hält der Autor vom PrHdb das „Stealth“ Preset zumindest dann für Ideal, wenn du den Expertenmodus aktivierst, und daraufhin auf selbiger Seite, unter „Vortäuschen“, den Haken bei „Persistente Daten speichern“ entfernst.
Ob es zwingend aus Sicht des Autoren nötig ist, weiß Ich nicht, der Punkt kam dazu, als ein Nutzer den/die Autoren kontaktierte, davor wurde das Preset trotzdem empfohlen - möglicherweise wurde die Option dabei auch übersehen, oder war anfangs noch nicht vorhanden.

Es soll mit dem Stealth Preset vermieden werden, dass es heraussticht, dass die Canvas (etc.) Funktionen manipuliert werden.
Wenn die Option zum speichern aber nicht deaktiviert wird, würde sich dein manipulierter Canvas Fingerprint für eine Seite über unterschiedliche „Browsersitzungen“ nicht ändern (wäre jedoch zwischen unterschiedlichen Domains weiterhin unterschiedlich), obwohl er durch die Modifizierungen vermutlich wirklich einzigartig wurde, wurde ja auch so erläutert.

Da du nach dem Konzept vom Privacy-Handbuch zum beseitigen von „Identitätseigenschaften“ aber den Browser beendest (löschen des Caches, der Cookies, … möglichst allem) ist das löschen der persistenten Daten zum Ende der Session eben nötig und sinnvoll, und liefert keine Auffälligkeiten (du siehst wie ein frischer Browser aus, da du ja auch keine Seitendaten behältst).
Dass das „Maximum Protection“-Preset immer einen anderen Fingerprint liefert, bringt dir keinen Vorteil im Konzept des PrHdb.
Wenn eine Webseite einfach eine UUID in ein Cookie o.Ä. packt, bist du für diese trotzdem in dieser Sitzung wiedererkennbar, egal welches Preset du nutzt, bis dieses gelöscht wird (und möglichst alles gelöscht/verändert wird, was eine Verbindung ermöglicht/vereinfacht - Fingerprinting, IP-Adresse, …).
Das „Maximum Protection“ Preset erleichtert es zu erkennen, dass du die Canvas (u.A.) Funktionen manipulierst, da sich deren Ausgaben, bei gleichen Operationen, ständig unterscheiden - und dadurch ggf. auch nicht für die Berechnung eines Fingerprints verwendet werden, anstatt dass dieser gefälschte, sich verändernde Informationen nutzt.

Der Unterschied in diesen beiden Profilen liegt also hauptsächlich darin, dass das Stealth Preset möglichst vermeiden soll, dass Manipulationen (leicht) auffallen, während das „Maximum Protection“ Preset möglichst verhindern soll, reale/nützliche Daten zu erhalten, auch wenn es dadurch auffliegt.

Damit es keine Missverständnisse gibt: Der Expertenmodus zeigt dir nur ein paar Optionen mehr zum verändern an, durch bloße Aktivierung alleine tut dieser nichts.

Du nutzt nicht die „Stealth“ Voreinstellungen, sondern die „Maximum Protection“, oder etwaige Standardeinstellungen, oder?
Dann brauchst du keinen Expertenmodus aktivieren.

Wenn du in diesem FF Profil aber der Gruppe der vermutlich meisten Nutzer des PrHdb angehören möchtest, solltest du dich natürlich vollständig an die Empfehlungen halten. Ich denke, das wäre das „richtige“, ein Teil des Konzeptes ist nämlich auch eine gewisse Gleichheit der Konfigurationen.

Vermutlich wäre die Empfehlung, wenn du kein JShelter nutzt, wohl weiterhin die „Schwer zu detektieren“ Voreinstellung, mit der Option „Persistente Daten speichern“ deaktiviert.
Vielleicht auch die Aktivierung der „Minimale Bildschirmgröße vortäuschen“ Option, Links in der Seitenleiste unter „APIs“, ganz unten bei der Screen-API.
Aber afaik. lässt sich die Aktivierung der Option leicht feststellen.

Kleine Anmerkung: wenn die Option zum „speichern persistenter Daten“ durch das „Stealth“ Preset aktiviert wurde, wird sie nicht durch den Wechsel zu einen anderen Preset deaktiviert. Man sollte vorher also die Einstellungen von CanvasBlocker zurücksetzen, wenn man das Preset wechseln möchte.

1 „Gefällt mir“

Also zunächst einmal vielen Dank für die Zeit die Du Dir genommen und die Mühe die Du Dir gemacht hast mir zu helfen.
Ich hatte bei der Einstellung meines FF Profils nach PrHdb den JShelter tatsächlich nicht genutzt weil beim Test auf Browserleaks die Signature und der PNG Hash während einer FF Sitzung und einem Reload dieser Testseite unverändert blieb.
Dieses Verhalten kannte ich bei der Nutzung der user.js von Arkenfox (ohne Canvasblocker und JShelter) eben nicht und daran habe mich eben auch bei der Nutzung der user.js in Verbindung mit den beiden vorgenannten Addons orientiert.

Dank deines langen Textes :slight_smile: habe ich das jetzt wieder geändert und den JShelter wieder - mit dem Preset aus dem PrHdB - aktiviert und die von Dir als Bestandteil des PrHdb Konzeptes beschriebene gewisse Gleichheit wieder hergestellt.

Vielen Dank nachmals und ein schönes Wochenende…

1 „Gefällt mir“

Korrekt, wenn man nicht richtig liest gilt diese Aussage :slight_smile:

CanvasBlocker
non-RFP users only -
https://github.com/arkenfox/user.js/wiki/4.1-Extensions#-optional

Der Browserleaks test ist übrigens genauso sinnlos wie der Adblocker test, erst recht bei der Arkenfox.

1 „Gefällt mir“

Asche über mein Haupt. Hast natürlich recht …

Nachtrag:

Gibt es denn überhaupt irgendeinen Test der Auskunft darüber gibt wie gut das benutzte Profil im Hinblick auf die Wahrung der Privatsphäre abgesichert ist ?

Nein, aber wenn dich interessiert, kannst gerne die neuste Messstudie hierzu lesen bzw. im Stream anhören, warum die alle nicht taugen :slight_smile:

Browser-Fingerabdrücke sind dynamisch und entwickeln sich mit den im Laufe der Zeit veränderten Merkmalswerten weiter. Bisherige Fingerprinting-Datensätze sind entweder klein, mit nur Tausenden von Browserinstanzen oder ohne Berücksichtigung der Fingerprint-Dynamik. Daher bleibt unklar, wie sich ein evolutionsbewusstes Fingerprinting-Tool in einer realen Umgebung verhält, z. B. auf einer Website mit Millionen von Browserinstanzen, geschweige denn, wie die Dynamik der Fingerabdrücke den Datenschutz und die Sicherheit beeinflusst.

In diesem Papier führen wir die erste groß angelegte Studie mit Millionen von Fingerabdrücken durch, um die Dynamik von Fingerabdrücken auf einer realen Website zu analysieren. Unsere Messstudie beantwortet die Frage, wie und warum sich Fingerabdrücke im Laufe der Zeit verändern, indem wir die Dynamik der Fingerabdrücke auf der Grundlage ihrer Ursachen in drei Kategorien einteilen.

https://dl.acm.org/doi/10.1145/3419394.3423614

Interesse habe ich ja. Aber nach dem ersten Stream musste ich einfach zur Kenntnis nehmen, dass mir die technischen Grundlagen zum Verständnis einfach fehlen.

Bleibe also weiterhin ein interessierte User und vertraue hier auf das Expertenwissen.

Danke Dir nochmals…und ein schönes Wochenende

Darf ich ich hier kurz etwas fragen?

Wenn man per Empfehlungsecke von Mike benutzt mit Arkenfox user.js:
Ublock
Skip Redirect
Clear Urls
LocalCDN
Canvas Blocker

Wie sollte Canvas Blocker eingestellt sein?
Gibt es ein fertiges Setting zum herunter laden?
Oder benutzt man einfach eines der Presets,

Wenn Du die user.js von Arkenfox benutzt, dann lies Dir bitte mal das Wiki zu den Extensions durch.
Jede einzelne Deiner Fragen wird dort beantwortet. Auch eine Anleitung zur Konfiguration von uBlock wird dort beschrieben.

Um die Arkenfox user.js mit dem Addon Setup vom Mike kompatibel zu machen,
zuerst ein neues Profil und eine user-overrides.js anlegen, wie es im Wiki beschrieben ist.
https://github.com/arkenfox/user.js/wiki/3.1-Overrides

in die overrides diese prefs kopieren.

/* override recipe: RFP is not for me ***/
user_pref(„privacy.resistFingerprinting“, false); // 4501
user_pref(„privacy.resistFingerprinting.letterboxing“, false); // 4504 [pointless if not using RFP]
user_pref(„webgl.disabled“, false); // 4520 [mostly pointless if not using RFP]

https://github.com/arkenfox/user.js/issues/1080

updater + prefs cleaner ausführen.
https://github.com/arkenfox/user.js/wiki/3.4-Apply-&-Update-&-Maintain
https://github.com/arkenfox/user.js/wiki/3.5-prefsCleaner

Bei den Presets vom Canvas Blocker „schwer zu detektieren“ wählen und zusätzlich noch
„Allow window.name in frames“ danach den Expert Mode aktivieren und
die persistente Speicherung von Daten deaktivieren.