Drittanbieter sind bereits mit Total Cookie Protection (dFPI) partitioniert.
Das Ersetzen einiger versionsspezifischer Skripte in CDNs durch lokale Versionen ist keine umfassende Lösung und stellt eine Form der Aufzählung von Schlechtigkeiten dar. Es mag zwar bei einigen Skripten funktionieren, die im Lieferumfang enthalten sind, aber bei den meisten anderen Verbindungen von Drittanbietern hilft es nicht. CDN-Erweiterungen verbessern die Privatsphäre nicht wirklich, wenn es um die Weitergabe der IP-Adresse geht, und die Nutzung ist mit Fingerabdrücken nachweisbar, wie ein Entwickler des Tor-Projekts betont. Sie sind das falsche Werkzeug für den Job und kein Ersatz für ein gutes VPN oder den Tor-Browser. https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22089#note_2639603 https://github.com/arkenfox/user.js/wiki/4.1-Extensions
Es sind ja nicht die Skripte selbst, sondern die (auch offiziellen!) Filterlisten. O-Ton von mir: „Dass die Ressourcen auch in jeden Fall […] umgeleitet werden, kann Ich nicht bestätigen“
Siehe diesen standardmäßigen Ausnahmefall, wo das nicht passiert:
Da habe Ich mich tatsächlich geirrt, Entschuldigung. Ich warf meine Editierung noch im letzten Moment nach, als Ich mit der Netzwerkanalyse nichts vorfand, da Ich erst jetzt wieder Zeit habe. Ich hatte in Erinnerung, dass in einer der letzten Firefox ESR Reihen dort noch drin stand, wenn ein AddOn auf lokale Ressourcen umgeleitet hat. Vielleicht Irre Ich mich damit ja sogar auch, oder das war für uBlock Origin nie der Fall?
Nachtrag: Im übrigen las Ich beim verfassen des vorherigen Beitrages von mir einen Abschnitt hier im uBlock Origin Wiki, was tatsächlich zum Missverständnis von mir beitrug.
„Dynamic filtering rules overrides static filtering.“ - aber: Redirects sind statische Filter.
Das selbe Missverständnis würde auch durch diese Übersicht von uBlocks Netzwerk-Filter-Engine begründet werden können.
Bezüglich LCDN sollte es einen neuen Thread geben, beim nächsten mal kümmere Ich mich (sollte bis dahin keiner existieren) darum, dort dann eine detailreichere Antwort dazu.
Es ging in der Empfehlung ausschließlich um das „fixen“ von Webseiten, durch die ausschließliche (keine „Aufzählung von Schlechtigkeiten“) lokale Bereitstellung von häufig verwendeten Bibliotheken durch verschiedene CDNs, zu denen absolut keine Verbindung gewünscht ist. Im Tor Browser haben eigene Erweiterungen in so ziemlich allen Fällen natürlich überhaupt nichts zu suchen.
Grundsätzlich korrekt, aber um nochmals gorhill zu zitieren:
Here I show that the despite blocking unconditionally all network requests (through dynamic filtering rules), the tool still reports uBO as „85%“.
…
Once you disable all redirections using the filter „@@*$redirect-rule“, you then get „100%“, but at the cost of higher likelihood of website breakage and content blocker detection.
Das heißt, dass auf dieser Testseite trotz vollständigen Blockierens aller Netzwerkanfragen über Dynamic Filtering angeblich nur 85% blockiert wurden und erst mit dem genannten Filter 100% erreicht wurden - weil eben viele Anfragen umgeleitet wurden (was von dieser Testseite nicht erkannt wurde). Mit anderen Worten: diese redirects haben Vorrang auch vor Regeln im Dynamic Filtering. Und das ist auch gut so.
Ja, mit dFPI braucht man das nicht unbedingt (siehe aber auch die Ausführungen des Autors hier). Ich finde allerdings auch, dass die Kritik überzogen ist. Mein Eindruck ist, dass „enumerating badness“ zum Lieblingsstichwort vieler geworden ist, seit Daniel Micay damit vor einigen Jahren in reddit Adblocker kritisiert hat. Mal abgesehen davon, dass er offenbar von Dynamic Filtering (das ja ein Whitelisting-Ansatz ist) noch nichts gehört hatte, läuft diese Kritik im Grunde darauf hinaus, dass ein 95%-iger Schutz schlechter ist als gar keiner, was absurd ist. LocalCDN deckt jedenfalls viele CDNs ab, und sein Autor empfiehlt die Benutzung in Kombination mit uBO im Medium Mode.
Das ist so nicht richtig, weil sich diese Aussage nur auf den Tor-Browser bezieht - und dort gilt dasselbe für jedes andere Add-on genauso, weil dadurch immer der (möglichst) einheitliche Fingerprint verändert wird. Für andere Browser gilt das in dieser Form nicht. Siehe auch dazu die Ausführungen des LocalCDN-Autors.
Ich beziehe mich mit dem Ausnahmefall auf ein Setup ohne dynamisches Filtern.
Wenn man google-analytics per dynamischen Filter blockiert, greift die Umleitung auf das ga.js Ersatzskript tatsächlich in jeden Fall.
Ohne diese Blockierung wird das richtige ga.js Skript heruntergeladen und ausgeführt.
Getestet mit Firefox-ESR 102.5, uBlock Origin 1.45.2, und Standardeinstellungen in beiden (jeweils mit und ohne blockierung von google-analytics durch dynamisches Filtern).
Sowohl in den Logs als auch über den Debugger vom Firefox selbst ist das ersichtlich (welcher bei korrekter Umleitung auch das Ersatzskript anzeigt ).
Das entspricht also meiner Aussage: Ohne google-analytics durch dynamisches Filtern zu blockieren, wird nicht in jeden Fall - nämlich sofern eine Ausnahme festgelegt ist - auf das harmlose Ersatzskript umgeleitet.
Bezüglich LocalCDN brauche Ich nichts mehr zu verfassen, da habe Ich nichts wichtiges beizutragen, was über seekets Post und den Punkten von nobody hinausgeht. Super Beiträge.
Ich surfe seit ca. 10 Jahren mit geblocktem Google Analytics und Googletagmanager. NIE war das ein Grund, dass eine Seite nicht funktionierte.
Dasselbe gilt für sehr, sehr viele Domains bspw. DoubleClick, googlesyndication, google fonts, youtube (natürlich funktionieren dann die dortigen Videos nicht) etc. etc.
Später wird gesagt, Links würden auf durch ein Skript „intern“ umgeleitet, im Sinne von „unschädlich gemacht“, und die Domains würden dennoch „grün“ angezeigt.
Ich halte das, wenn das stimmt, für eine sehr schlechte Lösung: Die sollten keinesfalls grün dastehen, ich denke rot, maximal gelb wäre dafür die korrekte Anzeige.
ps. Oben wird ein IMtranslator genutzt/eingebaut. Deren Internetseite ist schon einmal ekelhaft Google-verseucht, das Addon genießt deshalb ebenfalls mein größtes Misstrauen. Ich empfehle deepl.com …
).