Ich möchte bei Aliexpress LiPo-Lade-Platinchen bestellen.
Unter meinem Gentoo-Linux lasse ich Librewolf mit UBlock-Origin, LocalCDN und JShalter laufen.
Wenn die Homepage von www.aliexpress.de besucht, haut einem JShelter geradewegs die Fingerprinting-Versuche um die Ohren. Dagegen ist Google ein weißes Schafe…
Was also tun?
Die Produkte, die auf den Milimeter identisch mit denen von z.B. Amazon sind, kosten bei Amazon das Zwei bis Dreifache…höhere Multiplikatoren habe ich auch schon des öfteren gesehn.
Wenn ich sich tatsächlich um in Europa erzeugte Elektronik handel würde, hätte ich mit einem im Rahmen gebliebenen Preis kein Problem…aber bei haargenau der gleichen Elektronik?
Lasse ich JShelter seinen Dienst machen, meldet Aliexpress nach einer Weile, es hätte „ungewöhnliche Aktionen“ von meiner Seite aus detektiert und bricht ab.
Wer hier einen Tip hat, wie speziell im Falle Aliexpress.de JShelter möglichst „stark“ eingestellt werden kann aber dennoch Aliexpress in der Leitung bleibt …
Wenn das nicht geht - was ich befürchte - was ist hier ein sinnvoller Ansatz, um auf der einen Seite dem Fingerprinting die Stirn zu zeigen aber auf der anderen Seite dennoch erfolgreich eine Bestellung abzusetzen…?
Mir ist bewusst, dass bei Einloggen und Bezahlen meine Identität erkennbar ist.
Nichtsdestotrotz möchte ich „aus Prinzip“ und zur Übung im Umgang mit sowas eine möglichst gute Lösung gegen das Fingerprinting anstreben.
Im ersten Ansatz habe ich mal eine Virtualbox mit Linux Mint installiert…
Schönes und sicheres Wochenende in die Runde!
Tuxic
Da du dich offensichtlich um Fingerprinting sorgst, anbei ein paar Tipps:
LocalCDN ist praktisch nutzlos für Datenschutz. Siehe auch https://github.com/arkenfox/user.js/wiki/4.1-Extensions . Librewolf bewahrt Drittanbietercookies und andere Webseitendaten via state partitioning vor seitenübergreifendem State-Tracking und wenn du das automatische Löschen aller Webseitendaten beim Schließen aktivierst, ist auch Erstanbietertracking via browser state nicht möglich.
Librewolf hat resistFingerprinting aktiviert, was deutlich besseren Schutz als JShelter bietet. Du verwendest einen seltenen Browser, auf einem Nischen-OS, änderst vielleicht noch die ein oder andere Einstellung und fügst selten verwendete Erweiterungen hinzu (JShelter und LocalCDN). Das Setup macht dich mit einiger Wahrscheinlichkeit in Verbindung mit anderen Metriken einzigartig. Siehe Ausführungen im Arkenfox Issue-Tracker zu gravierenden Schwächen von JShelter https://github.com/arkenfox/user.js/issues/1388
Wenn du Librewolf weiterverwenden willst, empfiehlt es sich diesen möglichst unverändert zu lassen und auch keine zusätzlichen Erweiterungen zu installieren. Am Besten verwendest du aber Tor Browser oder Mullvad Browser, wenn du dich um Fingerprinting sorgst.
Fingerprinting ist kein Selbstzweck. Wenn du mit dir verknüpfte Zahlungsdaten und Adresse preisgibst, ist deine Anonymität sowieso dahin. Zudem ist Fingerprinting in der EU nur zu Sicherheitszwecken (Bot- und Betrugsdetektion) und nicht zum Tracking erlaubt, wenn du im Cookie-Banner nur essentielles erlaubst. Ob sich die Firma daran hält ist natürlich schwierig zu ermitteln.
Vielen Dank für Deine Erklärungen und Links, Chief1945!
Viele nicht-Onion-Seiten weisen den Tor-Browser (oder den Kontakt zu einem Exit-Node) ab. Der Tor-Browser ist also zum Browsen im Normie-Net nur bedingt brauchbar.
Gibt es irgendwo im Internet eine Seite, mit der ich prüfen kann, wie ich hinsichtlich FP „nach außen“ dastehe?
Ich stehe momentan vor dem Problem, von verschiedenen Seiten verschiedene sich widersprechende Lösungsansätze für das Problem Privacy-beim-Surfen zu bekommen und habe keine Möglichkeit, diese dann auch stichhaltig zu prüfen. Gerade beim Angebot vieler Lösungen möchte ich gerne als nur einen Lösungsanmsatz „glauben“ oder „vertrauen“ - ich möche es technisch für mich selber nachweisen.
Leider nicht. Die Wahrscheinlichkeit, dass du aus den Ergebnissen die falschen Schlüsse ziehst ist sehr hoch, wenn du kein tiefgehendes Wissen hast über Browser-Fingerprinting und ist sicher einer der häufigsten Fehler bei dem Thema. Fingerprinting-Testseiten bilden nur einen (meist kleinen) Teil der möglichen Fingerprinting-Methoden ab, haben viel zu wenig Besucher und ihr Datensatz ist extrem verzerrt, weil hauptsächlich Privacy-Enthusiasten teilnehmen, die überhaupt nicht repräsentativ für die richtige Welt sind. All das führt aufgrund der statistischen Natur zu massiv verzerrten Aussagen. Ich würde diese Seiten nur als Proof of Concept für einzelne Methoden sehen und mehr nicht. Mir wäre es lieber diese wären überhaupt nicht publik, da sie viel zu oft zu falschen Schlüssen führen und für viel Support-Aufwand in Foren sorgen.
Ja, das ist ein generelles Problem in der Privacy-Community.
Das kannst du nicht. Du hast zwei Möglichkeiten:
Die eine Möglichkeit ist das Thema selbst zu verstehen, was sehr viel Zeit, Interesse und Wissen benötigt. Du musst die statistische Natur davon verstehen (Entropie usw), wie Browser grob funktionieren, welche Dinge von einer Webseite überhaupt abgeleitet werden können, wie sich Systeme im Hinblick auf Fingerprinting unterscheiden und dann dich noch mit konkreten Methoden beschäftigen. Erst dann kannst du Schlüsse ableiten. Hier findest du wissenschaftliche Paper zum Fingerprinting: https://github.com/prescience-data/dark-knowledge . Auch hier gilt: nicht aus einzelnen Papers Schlüsse ziehen (ist auch einiges mit niedriger Qualität dabei), sondern das Große und Ganze betrachten.
Du vertraust dem Urteil von Leuten die professionell mit Browsern und Fingerprinting zu tun haben. Beispielsweise den Fingerprinting-Experten des Tor Browser-Teams, welche auch den Mullvad Browser betreuen, und den GrapheneOS/Vanadium-Entwicklern.
Herzlichen Dank für Deine ausfühlichen Ausführungen (das klingt zwar schräg und ein wenig nach „Zwischentöne“ zwischen den Zeile, IST ABER NICHT SO GEMEINT!
Es steht da buchstäblich das was ich meine! )
Ich benutze ein Pixel 6a mit GrapheneOS.
Wo Du gerade den Vanadium Browser erwähnst:
Was mir - aus dem Bauch eines Newbie heraus - an Vanadium nicht gefällt:
Kontakt zu Google Servern, auch wenn da nun nicht gerade meine Telefonnummer mit 'rübergeht
Es ist ein Chromium-Browser. Mir übt Google mit seinem allgegenwärtigen Chrome/-ium zuviel Einfluss auf die Entwicklung des Web aus.
Darum möchte ich eine zweiteilige Frage hinterherschieben:
Wenn ich völlig auf Chrome-farbende Browser verzichten möchte: Was ist hinsichtlich des Themas diesen Threads der beste Browser (Der Tor-Browser und Obrbot (und SimpleX Chat by the way) sind ohnehin installiert, was würdest Du empfehlen?
Wenn ich keine Rücksicht auf meine Chrome-Allergie nehme: Es Vanadium wirklich so gut wie GrapheneOS oder gibt es eine noch bessere Wahl?
Auf Android bieten nur Chromium-Browser gute Sicherheit an. Gecko-basierte Browser würde ich da nicht verwenden. Meine Empfehlungen bezüglich Fingerprinting bezogen sich auf Desktop-Systeme. Auf Smartphones gibt es ein paar Unterschiede, da es deutlich weniger Individualisierungsmöglichkeiten als auf dem Desktop gibt (z.B. keine Möglichkeit individueller Hardware-Konfiguration). Fingerprinting-Mitigations sind deshalb deutlich weniger wichtig. Die GrapheneOS-Webseite erklärt die Sicherheitsaspekte und den generellen Ansatz ganz gut: https://grapheneos.org/usage#web-browsing
Keiner weiß was in der Praxis tatsächlich eingesetzt wird. Aktuelle Fakten gibt es nur sehr wenige, größtenteils sind es ältere Studien/Fakten oder eben nur Vermutungen. Wie auch in einem anderen Thema geschrieben, ist Fingerprint nicht immer relevant, sondern hängt sehr stark von den Webseiten ab, die man besucht. Nicht jede Webseite berechnet einen Fingerprint ihrer Besucher, und falls doch, geschieht dies eher über Drittanbieter (insbesondere für Werbung), die sich einfach blockieren lassen. Ein Browser den ich mit uBlock Origin nicht konfigurieren kann, ist für mich aus Datenschutzgründen raus.
Wenn Tor- und Mullvad-Browser nicht funktionieren, würde sich evtl. ein temporäres Firefox-Profil lohnen. Mit einem kleinen Skript wird ein Profil für Firefox erstellt und nach dem Schließen vollständig gelöscht:
Bei der Wahl zwischen Firefox oder Chrome, würde ich Firefox bevorzugen, da dort bereits jetzt kritische Komponenten in der Programmiersprache Rust geschrieben wurden. Die Chrome-Sandbox ist in einer unsicheren Programmiersprache geschrieben, um Speicherfehler aus dem gleichen unsicheren Code abzufangen. Der praktische Nutzen hält sich daher in Grenzen (sichtbar an den regelmäßigen kritischen Patches). Sind Komponenten in Rust geschrieben, sind Schwachstellen durch Speicherfehler (die Hauptursache für Schwachstellen) nicht mehr möglich. Firefox bietet daher einen guten Kompromiss zwischen Datenschutz, Sicherheit und Anpassbarkeit.
Die Chromium Sandbox ist deutlich stärker, insbesondere unter Linux. Auf Android sowieso, da FF da intern gar keine Sandbox hat. Zudem beschützt die Sandbox nicht nur gegen Speicherfehler sondern auch gegen logische Fehler. Die zwei Hauptangriffspunkte für Sandboxes sind sowieso IPC und Kernel. In beidem ist Chromium deutlich besser. FF hat mit der Einführung von wenigen Teilen in Rust zudem das Mehrsprachen-Problem, was Exploit-Mitigations schwächen kann. Daniel Micay, Justin Schuh, Madaidan, Demy Obenour und Alex Gaynor sind nur ein paar Sicherheitsforscher die Firefoxs Sicherheit kritisiert haben und mir auf die schnelle einfallen.
Hat im Ausgangszustand kaum Fingerprinting-Mitigations und ist auf so einem seltenen OS deshalb keine gute Idee.
In der Theorie soll eine Sandbox vor bestimmte Dinge schützen, in der Praxis vergehen allerdings selten mehr als 14 Tage, in denen kein kritisches Sicherheitsupdate ausgerollt wird - sehr viele davon sind auf Speicherfehler zurückzuführen. Der Großteil der Malware in freier Wildbahn nutzt immer wieder nur leicht modifizierte Angriffsmethoden, die dann zu Speicherfehlern mit anschließender Rechteausweitung führen. Ein Problem welches von einer Sandbox eigentlich „abgefangen“ werden sollte. Da die zugrundeliegende Ursache die Programmiersprache ist, wird mit anderen Worten unsicherer Code mit noch mehr unsicheren Code abgesichert - keine gute Grundlage. Mehr Codezeilen bedeuten auch immer auch mehr potentielle Risiken (Fehler, Schwachstellen usw.).
Mozilla hat sich sehr früh damit beschäftigt und viel in die Entwicklung von Rust investiert. Google und andere Größen haben die Vorteile von Rust erkannt, unterstützen Rust auf ihren Plattformen und haben bestimmte Bereiche schon von C/C++ nach Rust migriert - Chrome und die Chrome-Sandbox sind allerdings nicht dabei. Wenn man also die Wahl hat zwischen einem Browser der komplett in C++ (=unsicherer Code) geschrieben ist und einem dessen kritischen Komponenten in Rust geschrieben sind, dann würde ich immer die Rust-Variante bevorzugen. Die Anzahl der kritischen Schwachstellen hat sich speziell beim Firefox durch den Einsatz von Rust deutlich reduziert.
Nein, ein „Mehrsprachen-Problem“ per se gibt es nicht. Vieles ist in mehreren Sprachen geschrieben, beispielsweise sind in Android 13 (Stand 2022) 1,5 Millionen Rust-Codezeilen (siehe android.googlesource.com). Wenn Komponenten in Rust geschrieben sind, gibt es an diesen Stellen keine Speicherfehler und die Angriffsfläche wird enorm reduziert. C und C++ sind nun mal sehr alte Sprachen und für einen sehr großen Teil der Schwachstellen verantwortlich. Beide haben ihren Ruhestand verdient und gehören endlich abgelöst.
Doch, gibt es. Vielleicht ist meine Übersetzung schlecht. Bin nur mit den englischen Begriffen vertraut. Der englische Begriff ist Mixed Language Problem und ist z.B. für CFI ein Problem. Soweit ich weiß hat da nur Windows Clang eine Lösung.
Der letzte Satz ist nicht allgemein gültig. Sandboxen reduzieren die Angriffsfläche massiv und verringern die Risiken, obwohl es mehr Code ist. SBX geht heutzutage meist nur über Kernel oder IPC und bei ersterem hat Chromium deutlich striktere Seccomp-Filter, auch letzteres ist in Chromium sicherer.
Das ändert nichts an der massiven Angriffsflächenreduktion durch Sandboxen und daran, dass diese mit die wichtigsten Teile sind.
Übrigens wurde Firefox mit Abstand am härtesten getroffen bei Pwn2own 2024 mit RCE+SBX. Manfred Paul fand auch in den andere Browsern Schwachstellen, aber kein SBX. Er sagt selbst, dass ein SBX am schwierigsten ist. Ohne SBX kann man zwar auch ein wenig Schaden anstellen, aber eben viel weniger gravierend und ist als Angreifer sehr limitiert.
Firefox ist so ziemlich in allem sicherheitstechnisch hinten dran. Sandboxing, Exploit Mitigations, JIT-Sicherheit, Speicherallokator, Site Isolation, Untrusted Font Blocking, … . Das bisschen was in Rust geschrieben ist, kann das nicht mal annähernd ausgleichen. Wie oben geschrieben, bin nicht nur ich der Meinung, sondern mehrere Experten.
Nein, auch innerhalb der Sandbox kann ein gewaltiger Schaden gerichtet werden und ist daher nicht zu unterschätzen. Malware setzt heutzutage auf eine Verkettung von Schwachstellen - viele Schwachstellen wurden eigentlich bereits behoben, aber mit nur leichten Änderungen reist das wieder auf. Im wesentlichen sind es immer die gleichen Komponenten/Probleme.
Eine gute Basis kann nur eine sichere Sprache bilden. Das haben Mozilla, Google, Microsoft, Meta, AWS, Apple und noch viele andere erkannt. Nicht ohne Grund arbeiten sie daran, ihren alten Code nach Rust zu migrieren.
In Firefox sind aktuell 11,5 % aller Codezeilen (u.a. kritische Komponenten) in Rust geschrieben und ca. 40,8 % in C und C++ verfasst. So eine Migration braucht Zeit, die sich aber letztendlich auszahlt. Erkennen kann man das bereits jetzt an den gesunkenen CVEs in Firefox. Lies dir vielleicht mal diesen Blogartikel (01/2023) im Google Security Blog durch, besonders den Abschnitt „Why We Chose to Bring Rust into Chromium“:
Our goal in bringing Rust into Chromium is to provide a simpler (no IPC) and safer (less complex C++ overall, no memory safety bugs in a sandbox either) way to satisfy the rule of two, in order to speed up development (less code to write, less design docs, less security review) and improve the security (increasing the number of lines of code without memory safety bugs, decreasing the bug density of code) of Chrome
Blättere einfach mal durch die letzten CVEs (out of bounds, use after free oder heap buffer overflow sind die häufigsten Ursachen und meistens mit CVSS > 8 bewertet).
Nein, C++ bietet überhaupt keine Sicherheit und ist alleine dadurch extrem fehleranfällig.
Dein einziges Argument für Firefox’s Sicherheit ist also der kleine Anteil Rust-Code. Da Chromium auch vermehrt Rust einsetzt und FF in nahezu allen anderen Sicherheitsbereichen nicht gleichwertig zu Chromium ist, ist das schlicht nicht ausreichend um FF auch nur annähernd auf die gleiche Ebene zu stellen wie Chromium.
Die Verwendung von Rust wird nie eine Sandbox ersetzen, da logische Bugs in so einer komplexen Software immer noch zuhauf zu finden sind und die Kernel-Angriffsfläche (hauptsächlich C-Code) auch noch da ist. Ein gutes Beispiel ist das neue Sudo unter Windows, was fast komplett in Rust geschrieben ist und innerhalb kurzer Zeit von Sicherheitsforschern wie James Forshaw Sicherheitslücken entdeckt wurden. Und man hat immer noch die Kernel-Angriffsfläche, die unter FF größer als bei Chromium ist.
ResistFingerprinting (RFP) arbeitet in der Kombination mit den anderen Einstellungen im Librewolf suboptimal. Die Fingerprinting Protection (FPP) von Firefox funktioniert besser. FPP wird im Librewolf automatisch aktiviert, wenn man RFP abschaltet (was hiermit empfohlen wird).
Ist bekannt, aber ich zweifle stark an deren Expertise im Fingerprinting-Bereich, wenn etwas wie JShelter empfohlen wird oder wurde. Es widerspricht Experten-Meinungen vom Tor Projekt, GrapheneOS und anderen. Bitte das verlinkte GitHub-Issue von Arkenfox dazu lesen.
Und FPP als besser geeignet als RFP zu bezeichnen, wobei letzteres viel mehr Metriken abdeckt, bestätigt meine Meinung zum PHB.
arkenfox hat angekündigt, RFP (resistFingerprinting) ab der nächsten Version zu deaktivieren und statt dessen FPP (FingerprintingProtection) zu nutzen:
„ATTN: arkenfox in v125 or v126 will make RFP-etc inactive and use FPP as default“
Librewolf wird dann ab Version 125 ebenfalls FPP statt RFP standardmäßig aktivieren (wie im PrHdb).
Warum? Weil die alle keine Ahnung von Fingerprinting haben?
Ändert nichts an meiner Aussage. RFP deckt deutlich mehr Metriken als FPP ab, was nach wie vor stimmt. Und dass JShelter keine Lösung ist, hat sich auch nicht geändert.
Arkenfox und Librewolf arbeiten schon seit längerem so eng zusammen, dass das quasi wie eine Stimme ist.
Ach ja? Wie viele wissenschaftliche Paper hast du denn zu dem Thema gelesen? Hast du auch eigene Fingerprinting-Methoden entwickelt. Bitte nicht mit Steinen werfen, wenn man im Glashaus sitzt.
Die Zeitzone wird bei RFP auf UTC gesetzt, was zu einem TimezoneMissmatch führt - kontraproduktiv für den Browserfingerprint in-the-wild (ist nur sinnvoll beim TorBrowser, wo man die Herkunft natürlich geheim halten will).
Der User-Agent-Fake bei RFP führt zu einem UserAgentMissmatch unter Linux und MacOS - ebenfalls kontraproduktiv für den Browserfingerprint in-the-wild.
P.S. Du kannst uns gern deine Referenzen zeigen, also die Fingerprinting Methoden, die du entwickelt hast oder die Paper, die du zu dem Thema geschrieben hast oder zumindest ein paar Paper, die du gelesen (oder überflogen hast)…
Ohh - RFP ist detektierbar - interessante Erkenntnis. Also so detektierbar wie die Installation von JShelter?
Was ist denn dann daran besser als ein Add-on wie JShelter zu installieren, wenn der einzige Vorwurf gegen JShelter war, dass man die Installation des Add-ons erkennen könnte ?
Bei weitem nicht der einzige Vorwurf, bitte nochmals darum den Arkenfox-Link zu lesen. Zudem wird RFP viel öfter verwendet als JShelter, dass im Mozilla Store nur um die 500 Benutzer anzeigt.
Schon interessant, dass du extra einen neuen Foren-Account machen musstest nur um mich anzugreifen.
)