Eine Erweiterung wie LokalCDN die Ressourcen Injektion macht, ist grundsätzlich ist ein Sicherheitsrisiko… Nutzt Du eine ältere Bibliothek mit LocalCDN was bei der Anzahl an Bibliotheken die LocalCDN hat sehr wahrscheinlicht ist, kann es auch mit firefox einen Fingerprint geben und ist zudem ein Sicherheitsrisiko.
Ich habe deinen Beitrag abgetrennt, weil er mit der ursprünglichen Fragestellung nichts zu tun hat.
Das ist nicht korrekt. „Injected“ wird nichts, sondern die Anfrage wird umgeleitet (= onBeforeRedirect
und redirectUrl
), siehe hier und die Mozilla Dokumentation.
Die Webseite nutzt nach wie vor nur die Methoden aus der Bibliothek, die bei einer Anfrage an z.B. Cloudflare genutzt werden. Es wird weder irgendwas am Code der Webseite geändert noch sonst etwas ähnliches gemacht.
Das ist nicht korrekt. Die Bibliotheken in LocalCDN sind aktuell - ganz im Gegensatz zu den Webseiten, die ein Benutzer aufruft. Dort werden häufig völlig veraltete Bibliotheken verwendet. In LocalCDN findet kein Downgrade statt, sondern entweder Upgrades oder es wird eben 1:1 die gleiche Bibliothek ausgeliefert, siehe hier. Das ist übrigens der häufigste Grund, warum Webseiten „kaputt“ sind. Ein Paradebeispiel ist jQuery, siehe hier.
Zwischen den einzelnen Versionen gibt es manchmal sehr viele „breaking changes“, die dann ein Upgrade auf eine neuere Version unmöglich machen. Ein aktives Eingreifen in den Sourcecode der Webseiten wäre zu aufwendig und steht im keinem Verhältnis.
LocalCDN ist aus guten Gründen nicht empfohlen: https://github.com/arkenfox/user.js/wiki/4.1-Extensions#-dont-bother
Die Einschränkungen beziehen sich aber auf Tor (logisch) und auf VPNs. Desweiteren erübrigt sich das Add-on, wenn „Total Cookie Protection (dFPI)“ Verwendung findet (in der Praxis und in der Breite wohl eher seltener in Verwendung). Bei normalen „Feuerfüchsen“ (auch ESR), wovon hier wohl die Rede ist, kann der Einsatz des Add-ons hingegen durchaus sinnvoll sein.
Und das kann ich gar nicht bestätigen:
Replacing some version specific scripts on CDNs with local versions is not a comprehensive solution and is a form of enumerating badness. While it may work with some scripts that are included it doesn’t help with most other third party connections
Ich würde im Gegenteil eher davon ausgehen, dass Nutzer des Forums dFPI im Firefox ohnehin aktiv haben und da dürfte der Nutzen in der Tat eher begrenzt sein.
Decentraleyes wird dort aus guten Gründen nicht empfohlen. LocalCDN wird dort aus schlechten bis falschen Gründen nicht empfohlen.
Die Zielgruppe für LocalCDN ist eigentlich unabhängig von dFPI, denn dFPI verhindert nicht, dass ein Drittanbieter kontaktiert wird. Man könnte es eher vergleichen mit den unnötigen bzw. unerwünschten Kontakten in diversen Androids zu
- connectivitycheck.gstatic.com
- time.android.com
- supl.google.com
Natürlich könnte man alles durch ein VPN oder Tor schicken, aber nicht jeder kann oder möchte das - vor allem wenn Webseiten dann den Zugang komplett unterbinden oder Captchas einbinden. Letzteres ist besonders ärgerlich, wenn man die Webseite häufiger aufrufen muss.
Die Erweiterung ist vor allem dann sinnvoll, wenn man uBlock Origin im Medium oder Hard Mode laufen lässt. Nur so lässt sich dann das Problem mit „enumerating badness“ wirklich lösen und „enumerating goodness“ anwenden. Man muss aber auch sagen, dass die Erweiterung nicht alle Webseiten und alle Ressourcen abdecken kann, denn das ist unmöglich. Bei cdnjs.com gibt es dazu irgendwo eine Übersicht mit den rund 5000 Libraries (zzgl. aller Versionen). Wie auch alle anderen Schutzmaßnahmen, hängt es sehr stark von den besuchten Webseiten ab, ob und wie viele Ressourcen ersetzt werden können.
Das Ziel sollte eigentlich sein, dass es Erweiterungen wie decentraleyes oder LocalCDN gar nicht erst gibt. Der Betreiber einer Webseite kann ohne Probleme den ganzen „Krempel“ an JavaScript, CSS und Fonts einfach selbst hosten. Der ursprüngliche Einsatzzweck von CDN war völlig legitim, aber bei den aktuellen Bandbreiten und der geringen Dateigrößen ist ein CDN (neben dem Privatsphäre-Problem) zum (Sicherheits-)Risiko (siehe Single Point of Failure) mutiert. Erst vor kurzem ist JSDelivr ausgefallen und reist dann natürlich unzählige Webseite mit sich mit, weil dort nichts funktioniert. Diese CDNs sind auch sicherheitstechnisch ein lukratives Ziel, bspw. als im Jahr 2021 der Anbieter CDNJS kompromittiert wurde.
Ganze extreme binden dann diese externen Ressourcen nicht ein mal über eine Versionsnummer ein, sondern mit latest
oder verwenden gar kein SRI - vergleichbar als würde man mit verbundenen Augen mit dem Auto fahren und erwarten, dass nichts passiert.
Als solche habe ich die beiden Add-ons (Decentraleyes, LocalCDN) immer verstanden.
Warum? Genau das nutze ich : ( Was ist an LocalCDN besser?
Hab’ hier und da gelesen, dass Decentraleyes mit veralteten CDN’s arbeitet, z.B. bei den Bewertungen und auch auf gitlab.
Zu LocalCDN hat @nobody ja schon geschrieben…
IP-basiertes Tracking ist ein Problem. Egal ob mit oder ohne LocalCDN. VPN oder Tor sollte man daher so oder so verwenden.
dFPI ist seit über einem Jahr in Firefox standardmäßig für alle Nutzer aktiviert. Andere Privacy-Browser wie Brave und Librewolf haben auch standardmäßig State Partitioning. Selbst Chrome und Edge haben inzwischen viel State Partitioning, außer für Cookies, wenn man also dort Drittanbieter-Cookies verbietet haben selbst diese Nutzer keinen Bedarf an LocalCDN.
Nein. Siehe oben.
Es ist seit einem Jahr standardmäßig aktiviert in FF.
Soso. Welche Formen von Tracking verhindert LocalCDN denn erfolgreich, wenn State Partitioning und VPN/Tor in Verwendung sind?
dFPI, State Partitioning oder irgendeine andere Technologie verhindern nicht, dass ein Drittanbieter kontaktiert wird:
… oder sind neuerdings Endpunkte wie time.grapheneos.org
, connectivitycheck.grapheneos.network
und captiveportal.kuketz.de
unnötig geworden?
Es geht eher um die Anwendung von „enumerating goodness“, wenn Tor oder VPN nicht zur Verfügung stehen. Der Use-Case steht aber eigentlich direkt unter bummelsteins Beitrag
Besteht, @nobody, Hoffnung, dass LocalCDN irgendwann auch in Chromium-basierten Browsern (Google) Fonts ersetzen kann? Änderungen an Chromium/MV3?
a) https://codeberg.org/nobody/LocalCDN/wiki/Home#chromium-incompatibilities-bugs
b) https://gitlab.com/nobody42/localcdn/-/issues/67
Wer hat schon Lust auf Google Fonts? Das Tracking-Potenzial ist auf Grund der Verbreitung immens. Das Fonts-Ersetzen ist mein persönliches LocalCDN-Killer-Feature.
Danke für das tolle Addon.
Vermutlich eher nicht, liegt aber an Chrome, ob u.a. *.woff
ersetzt werden dürfen. Mein letzter Versuch liegt schon einige Monate zurück. Vielleicht hat sich zwischenzeitlich etwas geändert, aber so oder so hat sich die Erweiterung mit MV3 für Chrome erledigt. Die Erweiterung wird dann nicht mehr funktionieren.
Nur zum Verständnis: Google Fonts wie z.B. Roboto werden nicht ersetzt, sondern die Material Icons (technisch identisch).
Sorry, das war unpräzise formuliert.
Das Fehlen von Icons zerschießt das Layout vieler Websites und macht sie unbenutzbar. Deshalb ist LocalCDN hier so wertvoll.
@nobody
Mit der letzten Aktualisierung (v2.6.71) muss sich wohl ein Fehler eingeschlichen haben.
(Firefox Browser 115.14.0esr)
Vielleicht solltest du mal deinen fast 1 Jahr alten Browser aktualisieren oder vermutlich das näherliegende, den Flüchtigkeitsfehler korrigieren
Du meinst vermutlich das. Ist behoben und die neue Version sozusagen schon unterwegs. Die fehlerhafte habe ich für AMO (addons.mozilla.org) deaktiviert, d.h. aktuell ist dort wieder die v2.6.70
Downgrade:
- Am Desktop die XPI-Datei herunterladen (Repository oder AMO) und per Drag & Drop in den Browser ziehen.
- Für Android die Einstellungen in der Erweiterung exportieren, Erweiterung entfernen, neu installieren und Einstellungen importieren.
Schreibfehler: Nicht „4“, sondern „14“. Sorry!
Zur Erläuterung: „ESR“ bedeutet „Extended Support Release“. Das Firefox Extended Support Release „115.14.0esr“ ist das derzeit (noch) aktuelle ESR-Release, welches noch bis „115.15.0esr“ weitergeführt werden wird.
Ja. Danke für die prompte Reaktion sowie die Hilfestellung für die Fehlerbereinigung!
- Nevermind, hab schneller getippt als gelesen -
Moin zusammen,
kurze Frage: Funktioniert bei euch LocalCDN noch korrekt? Seit heute habe ich das Problem, dass fast alle Webseiten, bei denen ich mich einloggen möchte, ewig laden solange LocalCDN aktiv ist. LocalCDN aus - alles gut; LocalCDN an - Login lädt bis in den TimeOut. Mach ich hier was falsch?