Trackingschutz Firefox 60 ESR

[Highlander4711]

Der unter Debian installierte Firefox 60 ESR hat soweit ich weiß nur einen mangelhaften Trackingschutz an Bord.
Dieses war für mich auch ein Grund, HIER nach der Möglichkeit zur Installation des Firefox 67 nach zu fragen.
Ich habe auf die Installation des selbigen abgesehen, auch wenn ich weiß das dieses grundsätzlich möglich ist.
( anscheinend überwiegen die Nachteile insbesondere etwaiger Updateprobleme der Paketverwaltung )
Es gibt viele Add-Ons zum Trackingschutz, nur welcher taugt was?
Bezüglich des Firefox 60 ESR.....

[MSfree]

Dieses war für mich auch ein Grund, HIER nach der Möglichkeit zur Installation des Firefox 67 nach zu fragen.

Ich habe hier Buster installiert und da gehört Firefox-ESR 68 dazu.

Davon abgesehen, es gibt sowieso keinen Browser mit effektivem Trackingschutz.

[tobo]

Aktuell ist die Firefox-Version ESR 68.8. Den kannst du anreichern mit einer eigenen user.js und/oder den Addons UBlock Origin, UMatrix und NoScript. Nachzulesen und noch vieles mehr z.B. hier
https://privacy-handbuch.de/
unter den Unterpunkten von "Spurenarm Surfen".

[Korodny]

Davon abgesehen, es gibt sowieso keinen Browser mit effektivem Trackingschutz.

Du meinst im Auslieferungszustand? Oder stellst du Trackingschutz prinzipiell in Frage?

[MSfree]

Oder stellst du Trackingschutz prinzipiell in Frage?

Ja, den stelle ich generell infrage.

Eine Webseite, die vom Browser die Do-Not-Track-Mitteilung bekommt, wird dem Benutzer eben ein anderes Mittel schicken, um getrackt zu werden. Ganz beliebt sind hier die ganzen Heartbeat-Dinger, die zu Duzenden von einer Webseite auf den Browser geschickt werden.

Egal, welche Plugins du installierst, du wirst trotzdem getrackt, weil die "Erfinder" dieser Trackingmethoden den Plugins immer einene Schritt voraus sind. Die nutzen diese Plugins nämlich auch, um gezielt Methoden zu entwickeln, die an den Plugins vorbei kommen.

[Ibex]

Eine Webseite, die vom Browser die Do-Not-Track-Mitteilung bekommt, wird dem Benutzer eben ein anderes Mittel schicken, um getrackt zu werden.

Die Do-Not-Track-Mitteilung ist ja auch nur eine höffliche Bitte, das Tracking sein zu lassen. Websites, die dieser Bitte folge leisten, sind vermutlich die, bei denen man am wenigsten Probleme damit hätte getrackt zu werden.

Egal, welche Plugins du installierst, du wirst trotzdem getrackt

Das ist mir ein bisschen zu schwarz/weiß. Viele Tracking Methoden lassen sich effizient unterbinden, grade wenn die entsprechende Skripte von Drittanbietern gar nicht erst geladen werden. Damit ist man dann schon deutlich datensparsamer unterwegs. Einen 100% Schutz gibt es nicht, aber das gilt ja immer im Internet (und überhaupt). Deswegen ganz zu resignieren, ist aber auch falsch.

Und ein positiver Nebeneffekt ist, das man dabei auch gleich 90% der Werbung blockt, auch ohne Werbefilter.

[MSfree]

Einen 100% Schutz gibt es nicht

Das ist eine Binsenweisheit.

Es reicht halt nicht aus, 99 Trackingskripte zu blockieren, wenn es ein einziges dennoch schafft, auf den Browser zu kommen.

Deswegen ganz zu resignieren, ist aber auch falsch.

Ich resigniere nicht, sondern ich versuche sie mit ihren eigenen Mitteln zu schalgen. Ich erlaube so viele Trackingmethoden wie möglich, damit die so viel wie möglich in ihre Datenbanken speichern müssen. Nur, ich lösche den ganzen Kram nach dem Seitenbesuch. Beim nächsten Besuch gibt es neue Cookies, Sktipte etc. mit neuen Kennungen, die mich nicht in der Datenbank wiedererkennen lassen. Ich in praktisch jedesmal das erste Mal auf deren Seite. Das halte ich für sehr viel effizienter als 99 von 100 Methoden zu blockieren, wo die eine übrig gebliebene dich eben doch wiedererekennt. Diese eine ist eben 100%ige Unsicherheit.

[Korodny]

Es reicht halt nicht aus, 99 Trackingskripte zu blockieren, wenn es ein einziges dennoch schafft, auf den Browser zu kommen.

Das wäre dann wahr, wenn es immer mindestens ein Skript durch den Schutz schafft und alle Trackingdienste Daten miteinander austauschen. Das vorauszusetzen würde ich auch als "Resignation" beschreiben.

Ich resigniere nicht, sondern ich versuche sie mit ihren eigenen Mitteln zu schalgen. Ich erlaube so viele Trackingmethoden wie möglich, damit die so viel wie möglich in ihre Datenbanken speichern müssen. Nur, ich lösche den ganzen Kram nach dem Seitenbesuch.

Das würde voraussetzen, dass du nicht an deiner Kombination aus Browser, Browser-Version, Betriebssystem, IP, Fenstergröße, installierten Browser-Erweiterungen, verfügbaren Zeichensätzen und ähnlichem Krimskrams halbwegs eindeutig zu identifizieren bist - ganz ohne Cookies o.ä.

Siehe dazu auch: https://panopticlick.eff.org - gerade noch mal ausprobiert: Von den 266.000 in den letzten Monaten getesteten Browsern hatte keiner den gleichen Fingerabdruck wie meiner. Es gab 18 Merkmale, anhand der ich identifiziert werden konnte.

Es ist unglaublich viel schwerer - m.E. unmöglich - mit der Tracking-Industrie Schritt zu halten und ständig deinen Browser gegen neue Identifizierungsmaßnahmen zu immunisieren. Es ist dagegen lediglich (viel) Arbeitsaufwand, erst mal alle Inhalte sperren zu lassen, die nicht von der aktuellen TLD stammen und dann schrittweise das zuzulassen was für ordentliche Darstellung benötigt wird

[tobo]

Von den 266.000 in den letzten Monaten getesteten Browsern hatte keiner den gleichen Fingerabdruck wie meiner.

Nein. Die 266.000 bedeutet, dass deine Fingerabdruck-Signatur im Schnitt alle 266.000 mal genau so (nach deren Testkriterien) vorkommt. Je kleiner desto besser. Insgesamt aber trotzdem relativ bedeutungslos - relevant sind die Bits!

Es gab 18 Merkmale, anhand der ich identifiziert werden konnte.

Es gibt 21 "gelistete" Merkmale und damit hat dein Browser auch 21 Merkmale, für deren Berechnung. Wenn dein Browser 15 dieser 21 Verfahren komplett unterbinden könnte, dann hätte er trotzdem 21 Merkmale!

[willy4711]

Vielleicht interessant:
https://curius.de/blog/13-betriebssyste ... fox-addons

[tobo]

Vielleicht interessant:
https://curius.de/blog/13-betriebssyste ... fox-addons

Eher nicht!? Eine Webseite, die nahezu unkommentiert 3 Addons nennt - da gibt es tausende andere Webseiten, die können das genauso oberflächlich gut/schlecht. Hier ist dann noch der Unterschied, dass mit 2. First Party Isolation ein Addon genannt wird, dass seit 2018 im Firefox nativ bereitsteht und mit einem einzigen about:config-Eintrag funktionstechnisch ersetzt werden kann. Zudem ist der Informationsgehalt bezüglich der bereits genanntern Quellen bestenfalls 0. Was also sollte interessant sein?

[TomL]

So mehr oder wenig langläufig stell ich immer mal wieder meine vorherigen Entscheidungen in Frage.... und im Moment hab ich mal wieder Palemoon auf dem Kieker, der seit längerem bei mir der Default-Browser ist. Die Zündung für die Frage, ob eine Entscheidung geändert werden muss, war der Hinweis (irgendwo gelesen) auf einen mir bisher unbekannten FF-Parameter: privacy.firstparty.isolate ... der im Palemoon unbekannt ist. Der zweite Zündfunke war, dass ich mir eine relativ sichere Referenz-prefs.js (im Vergleich zu den defaults) für den FF-ESR gebastelt habe, die ich mit wenig Aufwand schnell im LAN verteilen kann, was mir das individuell durchzuführende manuelle FF-Customizing auf den Systemen erspart. Und der dritte Zündfunke war, dass mir die derzeit recht häufigen Updates des Palemoons, die ich immer manuell verteilen muss, doch aktuell ziemlich auf die Nerven gehen.

Also kurz gesagt, Palemoon steht auf dem Prüfstand, weil zu Arbeitsintensiv, weil er -so scheints mir- den technischen Anschluß verliert, weils mir bisher nicht gelingt, den Download via Keys zu verifzieren. Meine Frage ist nun, wie bedeutsam ist eigentlich dieser Parameter firstparty.isolate? Und es gibt da auch noch ein AddOn "First Party Isolation". Sind das zwei verschiedene Tätigkeitsgebiete? Oder hat der FF-ESR die Funktion des AddOn nun selber implementiert?

Wenn dieser Parameter tatsächlich was wichtiges/sinnvolles und gegen Tracking wirksames ist, dann wirds wohl eine neue Entscheidung geben.

[willy4711]

Mein Link oben sollte ja auch nur eine Anregung für genau dieses Feature sein, sowie auf das
Add-on Decentraleyes hinweisen.
Genauer Beschrieben bei:
https://www.kuketz-blog.de/firefox-dece ... ium-teil3/
Das Add-on finde ich auch interessant und hab es aufgrund dieses Artikels installiert.
Ob es wirklich das versprochene bewirkt ? Mal sehen. Jedenfalls musst ich erstmal rumprobieren,
um meinen PW- Manager wieder funktionsfähig zu bekommen. (ließ sich nicht mehr aus dem Browser heraus starten)

Natürlich ist mir der Schlüssel privacy.firstparty.isolate schon lange bekannt und ist bei mir schon immer auf "true"
Hier werden einige zusätzliche Einstellung zu diesem Thema genannt.
https://www.privacy-handbuch.de/handbuch_21z.htm

Ein Add-on, was wohl dasselbe bewirkt und abschaltbar ist, finde ich aber nicht verkehrt.

[irgendwas]

Also ich bin inzwischen von mehreren Browsern zu nur noch einem Browser (Firefox) mit mehreren Profilen (mit about:profile) übergegangen. Ein Profil hat so ziemlich gar keine Anpassungen/Addons. Alle anderen sind durch diverse Tipps (privacy-handbuch.de) angepasst. Decentraleyes hab ich inzwischen entfernt und gegen LocalCDN getauscht (bietet mehr CDN und unterstützt Bootstrap, Font Awesome usw.). Ansonsten nutze ich in allen Profilen Temporary Containers.

[tobo]

Der zweite Zündfunke war, dass ich mir eine relativ sichere Referenz-prefs.js (im Vergleich zu den defaults) für den FF-ESR gebastelt habe, die ich mit wenig Aufwand schnell im LAN verteilen kann, was mir das individuell durchzuführende manuelle FF-Customizing auf den Systemen erspart.

Bin mir nicht sicher, aber ich glaube, dass ich das mit der prefs.js schon mal bei dir gelesen habe. Jetzt, da es dann also offensichtlich kein Versehen ist: prefs.js als (verteilbare) Konfigurationsdatei ist falsch. Richtig ist user.js. Denn diese (user.js) wird nicht überschrieben und wird bei jedem Firefox-Start eingelesen. Und das sind dann auch schon die beiden Unterschiede, die prefs.js als mögliche Konfigurationsdatei unbrauchbar machen.

[willy4711]

Ansonsten nutze ich in allen Profilen Temporary Containers.

Interessant.
Was ist deiner Meinung nach der Unterschied / Vorteil zur Aktivierung privacy.firstparty.isolate

[TomL]

@tobo
Nee, hab ich noch nie gemacht... eben weil ich den FF eigentlich nicht nutze. Und eine user.js gibts es hier in den FF-Profilen nicht.

Was ich gemacht habe...?... einfach ein vollständig neues FF-Profil angelegt und alle Settings so durchgeführt, wie das nach meiner Vorstellung sein sollte. Dann habe ich diese prefs.js weggesichert... um sie nun auf anderen Systemen bei ebenfalls neuen (!) Profilen nach dem ersten Start zu kopieren. Spricht was gegen dieses Vorgehen?

Was ist deiner Meinung nach der Unterschied / Vorteil zur Aktivierung privacy.firstparty.isolate

Du kannst Dich in einem Portal gleichzeitig isoliert mit mehreren Accounts anmelden. Containerisierung ist wohl was anderes als Isolierung zwischen First und Third-Party-Verbindungen, wo es wohl um Cross-Site-Tracking geht.

[irgendwas]

Und eine user.js gibts es hier in den FF-Profilen nicht.

Ja, die kann/muss man anlegen.

Spricht was gegen dieses Vorgehen?

Du kannst auch den kompletten Profilordner kopieren. In der Config gibts du dann nur noch an, dass es dieses Profil gibt.

Du kannst Dich in einem Portal gleichzeitig isoliert mit mehreren Accounts anmelden. Containerisierung ist wohl was anderes als Isolierung zwischen First und Third-Party-Verbindungen, wo es wohl um Cross-Site-Tracking geht.

Ja und sobald der Tab zu ist, ist alles weg.

[tobo]

Was ich gemacht habe...?... einfach ein vollständig neues FF-Profil angelegt und alle Settings so durchgeführt, wie das nach meiner Vorstellung sein sollte. Dann habe ich diese prefs.js weggesichert... um sie nun auf anderen Systemen bei ebenfalls neuen (!) Profilen nach dem ersten Start zu kopieren. Spricht was gegen dieses Vorgehen?

Zunächst mal sagt Mozilla, dass man diese Datei prefs.js überhaupt nicht anfassen soll. Dann eignet sich diese Datei aber auch gar nicht zur Initialisierung der Werte, da sie ja andauernd beschrieben wird. Sobald du (oder Firefox) etwas an den Einstellungen änderst, also über about:config oder im Einstellungsidalog, dann wird dieser geänderte Wert in die prefs.js geschrieben und überschreibt möglicherweise deine Standardvorgaben. Ich/Du z.B. lösche ab und an während des Surfens die History, hake dann aber manchmal die "Aktiven Logins" weg. Das schreibt er dann bei dir und bei mir in die prefs.js rein. Beim nächsten Firefox-Start fehlt bei dir der Haken immer noch, bei mir - wegen entsprechendem Wert in der user.js - ist er wieder, als Standardwert, gesetzt. Die user.js wird als letztes vom Firefox eingelesen und überschreibt alles!
Wo man allerdings aufpassen muss ist, dass da kein Syntaxfehler drin ist (z.B. "fasle" statt "false"). Firefox liest bis zu einem möglichen Fehler und hört dann auf. Kann man aber z.B. überprüfen, in dem man im about:config den Wert der letzten user.js-Zeile ändert und dann schaut, ob durch die user.js beim nächsten Start zurückgeändert wurde.
EDIT: Wie irgendwas ja schon schrieb, die user.js muss man selbst anlegen (ins Verzeichnis der prefs.js).

[irgendwas]

EDIT: Wie irgendwas ja schon schrieb, die user.js muss man selbst anlegen (ins Verzeichnis der prefs.js).

In musste den Satz zweimal lesen, bevor ich ihn verstanden habe

[TomL]

Zunächst mal sagt Mozilla, dass man diese Datei prefs.js überhaupt nicht anfassen soll.

Vielleicht war das missverständlich von mir beschrieben... ich fasse diese Datei nicht manuell und direkt an, ich manipuliere da nix zwischendurch.

Zur Klarstellung:

a. Ich starte auf meinem Desktop erstmalig den FF
b. Ein frisches jungfräuliches Profil sowie eine neue prefs.js wird maschinell angelegt.
c Ich mache meine Settings (legal über Preferences und weitere in about:config, NICHT mit einem Editor Filebasiert)
d. Ich schließe den FF
e. Ich kopiere die prefs.js weg
f. Ab dem nächsten Start arbeite ich mit der produktiven prefs.js ganz normal, die Kopie verbleibt untouched außerhalb des Homedirs

g. Eine (als Beispiel) Surf-VM wird gestartet
h. Der FF wird erstmals mit einem frischen jungfäulichen Profil gestartet, die prefs.js wird maschinell angelegt.
i. Ich beende den FF sofort, ohne (!) irgend etwas gemacht zu haben.
j. Ich überschreibe die prefs.js mit der unter e. gesicherten Kopie
k. Ich starte den Browser erneut und arbeite ganz normal, wie gewünscht, habe aber ab sofort die wichtigen Settings aktiviert.
l. Weitere individuelle Settings werden dann 'legal' über die Browser-Dialoge vorgenommen.

Also, mir gehts eigentlich um ein Paket von Initial-Settings, die bei der Erst-Inbetriebnahme des FF für alle Systeme gelten sollen. Auf keinem der Rechner läuft derzeit der FF... wie gesagt, momentan isses noch der Palemoon. Ich will mir lediglich beim ersten Setup auf den Maschinen die ständigen Wiederholungen der vielen Einstellungen sparen.

EDIT: Wie irgendwas ja schon schrieb, die user.js muss man selbst anlegen (ins Verzeichnis der prefs.js).

Das habe ich mittlerweile selber nachlesen können. Und ja, das wäre auch eine alternative... mit Blick auf Versionswechsel wäre das vielleicht sogar die langfristig arbeitssparendere Variante. Das Verhalten, was Du weiterhin erklärt hast, war mir völlig unbekannt und da werde ich mich auf jeden Fall mit befassen.