Ich habe eine (technisch tiefere) Frage zum Zusammenspiel zwischen LocalCDN und Ad-Blocker(n). Der Thread Browser Addon LocalCDN erschien mir nicht ganz passend, da zu allgemein, daher ein neues Thema.
LocalCDN lenkt (vereinfacht gesprochen) Requests auf Web-Ressourcen auf lokale um. Falls ich einen Ad-Blocker verwende konfiguriere ich diesen mit den „Regelsätze für deinen Adblocker generieren“. Der Ad-Blocker lässt also Requests durch, und (immer noch vereinfacht gesprochen) LocalCDN ersetzt diese durch lokale Ressource oder, falls nicht vorhanden, blockiert oder leitet sie zum urspünglichen Server weiter - abhängig von „Anfordern fehlender Inhalte blockieren“.
Nach AdBlock Plus oder uBlock Origin gibt es verschiedene Typen von Web-Ressourcen (siehe ABP und uBO). Ich verwende zwar uMatrix nicht mehr als Ad-Blocker, aber so wie ich die LocalCDN generierten Regelsätze verstehe, sind nur Ressourcen der Typen script und css relevant. Nur diese Typen würde uMatrix selbst nicht mehr blockieren.
In uBlock Origin kann ich die dynamischen Regelsätze nicht so feingranular angeben. Sie geben die gesamte FQDN für alle Typen frei (auch image, media, font, object, …) .
Werden diese dann von LocalCDN blockiert? Wenn ja, was muss ich dazu konfigurieren?
Ausprobieren kann ich das leider nicht, dazu sind meine Kenntnisse Web-Programmierung zu oberflächlich. Danke.
Wenn die Option „Anfordern fehlender Inhalte blockieren“ deaktiviert ist, werden alle „Typen“ geladen. Je nach Bibliothek werden unterschiedliche benötigt, z.B. Grafiken für TinyMCE oder Schriftarten für MathJax.
Danke für die schnelle Antwort. Ich bin eigentlich daran interessiert, ob LocalCDN mit „Anfordern fehlender Inhalte blockieren“ alle sonstigen beliebigen Requests an die in uBlock Origin freigegeben FQDNs immer noch blockiert.
Ohne die Freigaben in uBO hat uBO nämlich alles blockiert. Übernimmt dann LocalCDN diese vollständige Blockierung?
Da uBO noch nach Web-Ressourcen-Typen differenziert, nahm ich an, das LocalCDN das auch macht. Vielleicht bin ich da ja aber auf dem Holzweg.
Sind die Web-Ressourcen-Typen für LocalCDN überhaupt noch relevant?
Oder werden einfach die URLs und die darin enthaltenen FQDNs in GET und POST Anfragen zugrundegelegt?
Daraus ergibt sich für mich allerdings die Anschlussfrage:
Welche Möglichkeiten habe ich nun unter diesen Randbedingungen (uBO + LocalCDN) POST, PUT, HEAD und DELETE Requests wieder zu blockieren?
uMatrix und NoScript kommen nicht in Frage. uMatrix wird nicht weiterentwickelt, NoScript verwende ich bereits mit nicht passenden Default und Trusted Einstellungen.
Zusätzliche statische Regeln? Andere Add-Ons?
Und ja, Decentraleyes/LocalCDN (fork) - Firefox Kompendium 3 aus dem alten Forum habe ich bereits erfolglos durchwühlt. Ich glaube mich außerdem noch an eine Diskussion zu erinnern, da ging es aber um einen nicht vergleichbaren anderen Fall, nämlich die dynamischen noop Regeln durch statische zu ersetzen.
Ich denke nicht, dass das notwendig ist. PUT und DELETE sind für das Hochladen oder Löschen einer Datei - was (hoffentlich ) auf einem CDN nicht möglich ist und daher auch keinen Sinn macht.
HEAD ist die Aufforderung das Ziel nochmal vom Server abzuholen, allerdings nur den Header und ohne Body (Inhalt). Ursprünglich mal für das Caching gedacht, allerdings in der Realität bisher noch nie gesehen.
Mit POST schickt man Daten an einen Webserver, die dann dort weiter verarbeitet werden sollen.
Aus technischer Sicht ist es möglich solche Anfragen an ein CDN zu schicken, allerdings (abgesehen von HEAD) nicht logisch. Bei den vielen Webseiten die ich bisher getestet habe, sind mir bisher immer nur GET Requests untergekommen. Die Ressourcen, die direkt per Script oder Link-Tags im DOM sind, gehen grundsätzlich immer als GET-Request raus. Wenn, dann müsste eine Bibliothek sowas von sich aus tun und eine Anfrage als POST, HEAD, PUT oder DELETE versenden.
Am ehesten würde es Sinn machen die HEAD Anfragen zu blockieren. Ich denke das sollte LocalCDN machen, da dort die Anfragen verarbeitet werden. Hab das mal eingebaut. Wenn du das testen möchtest, findest du hier eine kurze Anleitung.
Ich denke, alle diese Anfragen sollten blockiert werden. Wo auch immer. Gerade, weil es nicht logisch ist. Nur weil es nicht beabsichtigt ist, eine bestimmte Anfrage zu benutzen, heißt es noch nicht, dass es (falschlicherweise?) einmal gemacht wird.
Man kann mit POST aber auch Web-Ressourcen herunterladen.
Hey, und nochmals danke - das ist ja ein Service.
Habe es mal in einem neuen Profil installiert. Leider weiß ich nicht, wie ich es jetzt testen könnte - außer dass Firefox weiterhin normal funktioniert. Kann ich mit Firefox bestimmte Requests von Hand erstellen? Ich lasse es jetzt mal die Protokollierung mitlaufen. Auf was besonderes sollte ich achten?
In dem verlinkten Issue und dort dem referenzierten commit sieht man, dass aktuell alle Nicht-GET-Anfragen blockiert werden.
Externe Ressourcen werden über Link und Script Tags im HTML Dokument eingebunden. Diese werden immer per GET aufgerufen. Etwas anderes ist an dieser Stelle nicht möglich. Es bleibt nur die Möglichkeit, dass eine Bibliothek oder der Entwickler das manuell per JavaScript abholt.
Es macht deswegen wenig Sinn, weil viele CDNs mit 404 oder 405 antworten, wenn man etwas anderes als GET verwendet um Ressourcen abzuholen. Beispielsweise antwortet Google bei allem was nicht GET ist, mit einem 404 Not found und JSDelivr mit 405 Method not allowed. Ich bezweifel stark, dass man eine halbwegs seriöse Seite findet, die etwas anderes als GET verwendet.
Im Grunde genügt schon eine lokale HTML-Datei - mit etwas JavaScript (Fetch API) - die man im Browser öffnet.
Ich bin hier leider noch nicht weiter gekommen. Firefox mit minimal/user.js und LocalCDN (erst mal aus den Firefox Browser ADD-ONS mit zusätzlich Anfordern fehlender Inhalte blockieren, Protokollierung aktivieren und Fehlende Ressourcen im Symbol kennzeichnen). Danach Neustart.
In freier Wildbahn wird man solche POST requests an CDNs vermutlich gar nicht finden. Zum testen kann man kurz einen lokalen Webserver (z.B. XAMPP oder ähnlich) installieren. Die HTML könnte so aussehen:
Kann jetzt endlich auch selbst (spät) Erfolg melden. Sorry, dass nicht schon eher.
Daran hing es - und verfügbarer Zeit. Habe bei mir zufällig python3 -m http.server <port> entdeckt. Hat zwar noch ein CORS Problem, ist hier aber nicht relevant.
Und in diese Richtung habe ebenfalls gedacht, aber bevor ich was sage, wollte ich erst selbst ausprobieren können.
POST Anfragen gehen jetzt nicht mehr an LocalCDN vorbei und werden geblockt. Und ja, Antwort war 4xx. Trotzdem gutes Gefühl zu wissen, dass durch die uBO Regelsätze kein Loch geschlagen wird.
) auf einem CDN nicht möglich ist und daher auch keinen Sinn macht.
Gerade, weil es nicht logisch ist. Nur weil es nicht beabsichtigt ist, eine bestimmte Anfrage zu benutzen, heißt es noch nicht, dass es (falschlicherweise?) einmal gemacht wird.