Arkenfox user.js - Unsicher im Umgang mit Section 8001

matar · 12. Mai 2023 um 13:49

Hallo zusammen,
auch in der aktuellen user.js von Arkenfox findet sich in Section 8001 folgender Eintrag:

8001: prefsCleaner: reset items useless for anti-fingerprinting ***/
// user_pref(„browser.display.use_document_fonts“, „“);
// user_pref(„browser.zoom.siteSpecific“, „“);
// user_pref(„device.sensors.enabled“, „“);
// user_pref(„dom.enable_performance“, „“);
// user_pref(„dom.enable_resource_timing“, „“);
// user_pref(„dom.gamepad.enabled“, „“);
// user_pref(„dom.maxHardwareConcurrency“, „“);
// user_pref(„dom.w3c_touch_events.enabled“, „“);
// user_pref(„dom.webaudio.enabled“, „“);
// user_pref(„font.system.whitelist“, „“);
// user_pref(„general.appname.override“, „“);
// user_pref(„general.appversion.override“, „“);
// user_pref(„general.buildID.override“, „“);
// user_pref(„general.oscpu.override“, „“);
// user_pref(„general.platform.override“, „“);
// user_pref(„general.useragent.override“, „“);
// user_pref(„media.navigator.enabled“, „“);
// user_pref(„media.ondevicechange.enabled“, „“);
// user_pref(„media.video_stats.enabled“, „“);
// user_pref(„media.webspeech.synth.enabled“, „“);
// user_pref(„ui.use_standins_for_native_colors“, „“);
// user_pref(„webgl.enable-debug-renderer-info“, „“);

Alle prefs in dieser Section sind auskommentiert und ich weiß nicht ob ich diese prefs aktivieren muss oder ob der erwähnte prefsCleaner das automatisch macht ?
Ist vielleicht eine dumme Frage aber ich weiß wirklich nicht ob bzw was damit zu tun ist…

nudel · 12. Mai 2023 um 15:06

Ich verstehe das so:
Arkenfox setzt privacy.resistFingerprinting auf TRUE, Abschnitt 4501 in der user.js.
Arkenfox sagt, wenn RFP = TRUE ist, dann sind alle die in Abschnitt 8001 aufgeführten Parameter unnütz, z.T. sogar schädlich. Daher sind sie auskommentiert. Um sie also aus der prefs.js rauszukriegen, lass das Skript prefsCleaner laufen.

Ark · 12. Mai 2023 um 15:37

Was Nudel sagt, stimmt zum Teil, allerdings sind diese prefs generell für jede Config nutzlos.
Auch mit RFP = False

Entweder werden diese prefs über RFP oder den Canvas Blocker geregelt oder sind generell nutzlos fürs anti-fingerprinting

/*** [SECTION 8000]: DON’T BOTHER: FINGERPRINTING
[WHY] They are insufficient to help anti-fingerprinting and do more harm than good

matar · 12. Mai 2023 um 21:12

Der prefsCleaner entfernt aus der prefs.js nur prefs die auch in der user.js vorhanden und dort aktiv sind…

Ich hab dann mal ein bisschen rumexperimentiert um zu sehen was passiert wenn:

ich die unter 8001 erwähnten prefs in einer ganz normalen FF-Standardinstallation abfrage…
ich ein neues Arkenfox-Profil anlege, die auskommentierten 8001-pref aktiviere, d.h die führenden
Backslashs „//“ einfach entferne und dann prefsCleaner laufen lasse…
ich ein neues Arkenfox-Profil anlege, die auskommentierten 8001-pref auskommentiert stehen
lasse und dann den prefsCleaner laufen lasse.

Das Ergebnis dieser 3 Versuche habe ich dann mal in einer kleiner Tabelle zusammengefasst:

Da alle 3 Versuche das gleiche Ergebnis zeigen interpretiere ich jetzt die Aussage/Feststellung in der Section 8001 jetzt so:

„Führe keine Veränderungen an den (ohnehin vorhandenen) und nachfolgend aufgeführten prefs durch. Diese Auflistung dient nur Deiner Information.“

nudel · 13. Mai 2023 um 09:19

Hmm, also ich beobachte da etwas anderes:
in meinem ghacks-Profil gibt es in der user.js z.B. den Parameter user_pref("browser.newtab.preload", false);
Diesen Parameter hab ich mal willkürlich ins Visier genommen.
Wenn ich das Profil starte, zeigt mir about:config den Parameter als modifiziert auf false an und der Parameter findet sich so auch in der prefs.js. So weit, so wie erwartet.
Nun kommentiere ich diesen Parameter in der user.js aus (// davor).
Ich starte das Profil erneut, der Parameter ist nach wie vor modifiziert auf false und nach wie vor in der prefs.js.
Ich schließe den Browser und lasse das Skript prefscleaner.sh laufen.
Anschließend ist der Parameter aus der prefs.js verschwunden und about:config zeigt den default-Wert true an. Das Skript hat den in der user.js auskommentierten Parameter aus der prefs.js entfernt.

Danke für diese Arbeit.
Das Ergebnis erstaunt mich nicht. Das ist die Intension von prefscleaner.sh: den Default-Wert wieder herstellen.

Mir fällt noch folgendes auf:
im Abschnitt 8001 der ghacks user.js haben alle auskommentierten Parameter als Wert einen leeren String und zwar unabhängig davon, von welchem Typ der Parameter ist (Boolean, String, numerisch, …)
Was passiert nun, wenn man diese Parameter so unverändert aktiviert und also z.B. einen boolean Wert auf einen leeren String setzt? Ich weiß es nicht, aber ich habe einen Verdacht: er wird auf default gesetzt. Wenn ich Firefox wäre, würde ich das so machen. Auch das würde dein beobachtetes Ergebnis erklären.

matar · 13. Mai 2023 um 09:40

Da hab ich mich vielleicht nicht klar genug ausgedrückt aber das was Du beobachtest ist der von mir gemeinte Sollzustand…

Hat mich auch interessiert da das ja meine ursprüngliche Fragestellung war. Ich habe das mal mit
// user_pref(„dom.w3c_touch_events.enabled“, „“);
ausprobiert. Zuerst eine Zeile VOR der auskommentierten (//) pref eingefügt und den Wert von 0 auf 1 gesetzt, dann prefsCleaner laufen lassen. Erwartungsgemäß zeigt about:config jetzt den Wert 1 an.
Dann habe ich die Auskommentierung (//) vor der pref mit dem leeren String entfernt und wieder prefsCleaner laufen lassen. Ergebnis => immer noch 1. Es erfolgt also keine Rücksetzung auf den Default-Wert.

nudel · 13. Mai 2023 um 15:58

Ich kann dir jetzt nicht mehr folgen. Warum lässt du da wieder den prefscleaner laufen? Einfach den Firefox starten.
Mit der von dir zitierten Frage meinte ich nicht, was macht der prefscleaner sondern was macht der Firefox, wenn er beim Start in der user.js einen boolean Parameter mit Wert " " vorfindet.

matar · 13. Mai 2023 um 16:35

In der Arkenfox steht explizit:
/* 8001: prefsCleaner: reset items useless for anti-fingerprinting ***/
Ich bin davon ausgegangen das die explizite Erwähnung des prefsCleaners sicherlich einen Grund hat bzw doch haben sollte. Was aber anscheinend nicht der Fall ist.

Das habe ich jetzt auch noch einmal ausprobiert und da passiert ebenfalls nichts.