Vorweg:
Ich stelle dieses Tutorial ein, weil in uBlock Origin (uBO) m.E. Dynamic Filtering immer noch zu wenig bekannt ist. Zudem wird häufig beklagt, dass die Entwicklung von uMatrix eingestellt wurde, und es wird behauptet, dass die Benutzung von uBO in Kombination mit Noscript notwendig wäre, um die Funktionalität von uMatrix zu erreichen. Ich zeige unten, dass dem nicht so ist.
Weiterhin wird beklagt, dass das Blockieren von Objekttypen nicht so feingranular wie bei uMatrix sei. Aber: Mit Dynamic URL Filtering über den Logger lassen sich sogar einzelne Skripte, Bilder usw. blockieren bzw. erlauben - das ist etwas, was in uMatrix überhaupt nicht möglich ist. Zugegeben, das ist etwas umständlicher und erfordert nach dem Öffnen des Loggers ein Neuladen der Seite.
Aber m.E. ist das auch wenig relevant. Diese Unterscheidung nach Typen spielt bei den Adservern/Trackern/Malware-Seiten von vornherein keine Rolle, weil die eh komplett über die Filterlisten blockiert werden (und dadurch keine Skripte ausführen und z.B. auch keine Cookies setzen können). Und für die anderen in einer Webseite eingebundenen nicht blockierten Dritt-Domains müssen in uMatrix in der Regel auch XHR (Fetch) erlaubt werden, damit die Seite funktioniert.
Andererseits kann man in uBO sehr wohl steuern, was erlaubt ist: Im Medium Mode werden für die Dritt-Domains nur CSS Stylesheets geladen, aber Skripte und Frames werden weiter blockiert. Die erlaubst du erst, wenn du für eine Domain eine noop-Regel erstellst. Und auch dann werden viele mögliche Tracking-Skripte und dergleichen von den Filterlisten blockiert. Zur Erinnerung: Diese sind wesentlich mächtiger als die hosts-basierten Listen in uMatrix, die nur (Sub-)Domains blockieren können. Mit den Filterlisten in uBO werden auch einzelne Skripte, Webbugs usw. blockiert.
Grundsätzliches:
In uBO gibt es drei Arten der Filterung:
-
Static Filtering: das beinhaltet die Filter aus den aktivierten Filterlisten und ggfs. eigene Filter (enthalten im uBO Dashboard → Meine Filter)
-
Dynamic Filtering: verfügbar in den uBO Einstellungen nach dem Anklicken von „Ich bin technisch versiert“. Mit Dynamic Filtering lassen sich leicht bestimmte Anfrage-Typen sowie Hostnamen bzw. (Sub-)Domains blockieren/filtern. Die erzeugten Regeln sind dann enthalten im uBO Dashboard → Meine Regeln.
-
Dynamic URL Filtering: Erläuterungen dazu weiter unten.
Um sich mit dem Thema vertraut zu machen, empfehle ich, sich mit der grundsätzlichen Logik von Dynamic Filtering zu beschäftigen und dann mit der für die Regeln geltenden Rangordnung. Dabei gilt u.a.:
-
Im Dynamic Filtering stehen standardmäßig block Regeln (-> rot) und noop (=no operation) Regeln (-> grau) zur Verfügung.
-
block Regeln (und allow Regeln - dazu später mehr) haben Vorrang vor dem Static Filtering. D.h.: Egal, was die Filterlisten oder eigene Filter beinhalten - wenn eine entsprechende block Regel existiert, gilt diese. Punkt!
-
noop Regeln bedeuten im Gegensatz dazu, dass hier Dynamic Filtering außer Kraft gesetzt wird und stattdessen die Filterlisten (und ggfs. eigene Filter) zum Tragen kommen.
-
Zu unterscheiden sind globale Regeln, die auf allen Seiten gelten, und lokale Regeln, die nur auf der jeweiligen Seite gelten.
Eine globale (block oder noop) Regel erzeugt immer zunächst auch eine entsprechende lokale (block oder noop) Regel - bis Letztere modifiziert wird. Dann gilt:
-
Lokale Regeln haben Vorrang vor globalen Regeln. Man kann damit z.B. Facebook über eine globale block Regel auf allen Seiten blockieren, durch eine lokale noop Regel aber auf facebook.com - und nur da! - zulassen (wobei dann immer noch die Filter aus den Filterlisten angewendet werden - siehe oben!).
-
Weiterhin gilt grundsätzlich: spezifischere Regeln haben Vorrang vor breiteren oder allgemeineren Regeln.
Eine Regel für „Skripte aus Drittquellen“ oder „Frames aus Drittquellen“ hat daher Vorrang vor den breiter gefassten „Ressourcen aus Drittquellen“ - eine block Regel für „Skripte aus Drittquellen“ gilt also auch dann noch, wenn für „Ressourcen aus Drittquellen“ eine noop Regel angelegt wird.
Und eine block (bzw. noop) Regel für eine bestimmte Drittseite (also eine Domain-spezifische Regel) hat Vorrang vor einer breiter gefassten noop (bzw. block) Regel für „Ressourcen aus Drittquellen“ und „Skripte bzw. Frames aus Drittquellen“.
-
Neben block und noop Regeln gibt es auch noch allow Regeln, die jedoch standardmäßig nicht mehr zur Verfügung stehen, da sie in der Vergangenheit zu oft missbracht wurden, wenn eine Seite nicht „funktionierte“ - mit dem Ergebnis, dass überhaupt kein Schutz mehr durch die Filterlisten bestand, da auch allow Regeln Vorrang vor Static Filtering haben und die Filterlisten daher außer Kraft setzen. Man sollte sie daher tunlichst meiden!
Schließlich sollte man sich mit den verschiedenen Blocking Modes und dem Zusammenspiel der verschiedenen Modi vertraut machen.
Die Blockier-Modi in uBlock Origin
im uBO-Wiki werden die folgenden grundsätzlichen Blockier-Modi unterschieden:
-
Easy Mode: Das ist der Auslieferungsmodus von uBO. Hier sind die Standard-Filterlisten aktiviert, Dynamic Filtering ist dagegen deaktiviert. D.h., es wird ausschließlich das Static Filtering angewandt, ähnlich wie das in anderen Blockern wie z.B. AdBlock Plus gehandhabt wird.
-
Medium Mode: Hier sind im Dynamic Filtering durch globale block Regeln Drittseiten-Skripte und -Frames blockiert. Dieser Modus wird im Wiki als „optimaler Modus für fortgeschrittene Benutzer“ bezeichnet. Durch lokale noop-Regeln für „Skripte aus Drittquellen“ und „Frames aus Drittquellen“ erfolgt für die betreffende Webseite ein Rückfall in den Easy Mode. (Durch eine entsprechende globale noop-Regel würde grundsätzlich für alle Seiten ein Rückfall in den Easy Mode erfolgen.)
-
Hard Mode: Hier werden zusätzlich zu den Drittseiten-Skripten und -Frames durch eine globale block Regel alle Ressourcen aus Drittquellen blockiert. Dadurch wird sogar mehr blockiert als mit den Standardregeln in uMatrix. Durch eine lokale noop-Regel für „Ressourcen aus Drittquellen“ erfolgt für die betreffende Webseite ein Rückfall in den Medium Mode. (Durch eine entsprechende globale noop-Regel würde grundsätzlich für alle Seiten ein Rückfall in den Medium Mode erfolgen.)
Für welche Blockier-Modus man sich entscheidet, ist letztlich jedem selbst überlassen. Klar ist, dass ein strikterer Modus mehr blockiert, damit Seiten häufiger „kaputt“ macht und es daher mehr Mühe bereitet, diese wieder zu „heilen“.
Bei dieser Abwägung sei auch auf diese Diskussion hingewiesen, in der sich ein Nutzer darüber beklagt, dass das Blockieren von Drittseiten-Skripten im Medium Mode über XHR Requests unterlaufen werden kann. gorhills Antwort:
A site can pull data however it wants from 3rd parties (xhr, images, css, whatever), and extract „secret“ javascript from it, and execute it as 1st party. The only way to prevent this is to block 1st-party javascript (this includes inline-script), or as you found out, to block all 3rd-parties network requests.
Und dieses Blockieren aller Drittseiten-Anfragen wird tatsächlich nur im Hard Mode erreicht. Die Frage ist, wie relevant das ist. Wie bereits eingangs erwähnt, werden praktisch alle Adserver/Tracker/Malware-Seiten schon durch die Filterlisten blockiert, so dass diese Problematik hier kaum eine Rolle spielt, während für legitime Anfragen an Drittseiten auch in uMatrix XHR in der Regel erlaubt werden müsste. Dennoch stellt der Hard Mode einen umfassenderen Schutz dar, v.a. gegenüber Drittseiten, die (noch) nicht in den Filterlisten gelandet sind, oder etwa gegen Zählpixel, sofern nicht bereits ebenfalls über die Filterlisten blockiert.
Wichtig: In allen diesen Modi werden standardmäßig Erstseiten-Skripte nicht blockiert (mit Ausnahme von Skripten, die bereits durch die Filterlisten blockiert werden, z.B. Tracking-Skripte). Dies kann vielmehr umgesetzt werden entweder grundsätzlich über Einstellungen → Standardverhalten → JavaScript deaktivieren oder für bestimmte Seiten über den Per-site-Schalter, mit dem auch das Deaktivieren von Javascript für die jeweilige Seite wieder aufgehoben, also erlaubt wird. Allerdings sind auch dann im Medium Mode oder Hard Mode alle Skripte aus Drittquellen weiterhin blockiert!
Die im Dynamic Filtering-Fenster verfügbaren Zeilen Bilder, Inline-Skripte und Skripte dieser Domain sowie Alle Ressourcen (Nightmare Mode) spielen in der Praxis keine große Rolle.
Noch einige Hinweise zum Dynamic Filtering-Fenster: Standardmäßig sind die Zeilen für Sub-Domains „eingeklappt“:
Klickt man jedoch auf das Plus-Zeichen vor Alle Ressourcen, werden die Sub-Domains angezeigt, wodurch auch Sub-Domain-spezifische Regeln angelegt werden können:
Zusätzlich ist es möglich, auf das Trichter-Symbol links oben zu klicken:
Dort hat man die Möglichkeit, sich z.B. nur die (nicht) blockierten Drittdomains anzeigen zu lassen oder/und diejenigen, die (nicht) Skripte enthalten. Dadurch kann das Ganze übersichtlicher und gezielter angezeigt werden. Wichtig: Die gewählte Ansicht bleibt erhalten, bis man sie wieder rückgängig macht! Um daran zu erinnern, dass eine selektive Ansicht gewählt wurde, sind die Zeilen für die Drittdomains, die nicht den Selektionskriterien entsprechen, nicht ganz ausgeblendet, sondern vielmehr dünn eingeschoben.
Konkrete Umsetzung:
Ich benutze uBO im Hard Mode und mit deaktiviertem Javascript. Wichtig zu wissen: Dieser Schalter hat Blockier-Vorrang - d.h., wenn er aktiviert ist, sind Erst- und Drittseiten-Skripte grundsätzlich verboten, sofern nicht über den entsprechenden Per-site-Schalter explizit erlaubt.
A. Bei Seiten, die ich nicht regelmäßig besuche und sozusagen im Vorbeigehen schnell lesbar/benutzbar machen will, gehe ich folgendermaßen vor:
-
Ich noope im 1. Schritt die lokale Zelle für „Ressourcen von Drittseiten“, wodurch seit v. 1.32 blockierte Stylesheets automatisch neu geladen werden, falls möglich. Dies erben die Drittseiten-Domains (rot → hellgrau), wodurch diese Drittseiten nicht mehr komplett blockiert werden, sondern die Statischen Filter (d.h. die Filter aus den Filterlisten und ggfs. selbst erstellte Filter) zur Anwendung kommen. Adserver/Tracker/Malware-Seiten werden natürlich weiter durch diese Filterlisten blockiert.
Wichtig: Erstseiten- und Drittseiten-Skripte (und Frames) sind in diesem 1. Schritt nach wie vor komplett blockiert, weil diese über den Per-site-Schalter (und darüber hinaus über die Blockier-Regeln für „Skripte von Drittseiten“ und „Frames von Drittseiten“) weiterhin verboten sind! Oft reicht das, um eine Seite lesbar zu machen.
-
Falls das nicht reicht, erlaube ich Scripte über den Per-site-Schalter und lade die Seite neu.
Wichtig: Dadurch werden Erstseiten-Skripte erlaubt (sofern nicht von den Filterlisten blockiert!), aber alle Drittseiten-Skripte (und Frames) sind weiter blockiert, da die entsprechenden Blockier-Regeln für „Skripte von Drittseiten“ und „Frames von Drittseiten“ nach wie vor Vorrang haben. Letztlich ist dieser Schritt in Kombination mit Schritt 1 ein Rückfall vom Hard Mode in den Medium Mode. Wer also den Medium Mode statt des Hard Mode als seine Strategie wählt, kann den Punkt 1 oben auslassen.
-
Wenn auch das nicht reicht, um eine Seite lesbar/benutzbar zu machen, gibt es folgende Alternativen:
3.1 Man kann sich die Sache einfach machen und die lokale Zelle für „Skripte von Drittseiten“ (und ggfs. „Frames von Drittseiten“) noopen (rot → dunkelgrau). Dies gilt dann für alle Drittseiten, sofern für diese keine globale oder lokale Blockierregel existiert. Dieser Schritt deaktiviert Dynamic Filtering weitgehend (Domain-spezifische block Regeln gelten weiterhin, da sie Vorrang haben) und ist letztlich ein Rückfall vom Medium Mode in den Easy Mode (mit der eben erwähnten Ausnahme).
Wichtig aber: Adserver/Tracker/Malware-Seiten werden selbstverständlich weiter durch die Filterlisten blockiert. Auch bei den nicht blockierten Seiten greifen natürlich die Filter und blockieren z.B. Tracking-Skripte und anderes unerwünschtes Zeug.
3.2 Alternativ kann man die Blockierregeln für „Skripte von Drittseiten“ und „Frames von Drittseiten“ belassen (rot) und stattdessen einzelne Domains noopen (hellgrau → dunkelgrau), um z.B. notwendige Skripte zu erlauben.
Auch hier gilt natürlich das eben Gesagte: Die Filterlisten werden ggfs. Unerwünschtes blockieren.
Die Schwierigkeit bei dieser 2. Alternative ist, zu entscheiden, welche Domains genoopt werden müssen. Um mir das Leben ein bisschen einfacher zu machen, habe ich mir daher seit langen angewöhnt, für alle Adserver/Tracker, die mir über den Weg laufen, globale Blockierregeln (knallrot) zu erzeugen - nicht um diese Domains zu blockieren (das werden sie ja schon durch die Filterlisten), sondern einfach, um die Liste an Drittdomains, die für ein Noopen überhaupt infrage kommen, kürzer und übersichtlicher zu halten, da man diese roten Domains erst gar nicht in Erwägung ziehen muss.
Für nicht regelmäßig besuchte Seiten ist aber die Alternative 3.1 (das Noopen von „Skripte von Drittseiten“ und ggfs. „Frames von Drittseiten“) wohl die schnellere Methode - wobei auch hier das eben Gesagte gilt: Die Domains mit globalen Blockierregeln werden vollständig blockiert, unabhängig von den Filterlisten. Und solche Domain-spezifischen Blockierregeln haben Vorrang vor weniger spezifischen. Damit lassen sich auch Seiten, die auf keinen Fall geladen werden sollen, wie z.B. facebook.com oder google.com, sehr einfach blockieren. Falls notwendig, kann man die dann im Einzelfall durch eine lokale Noop-Regel immer noch erlauben.
Beispiel:
Auf diese Weise mache ich eine Webseite mit wenigen Klicks lesbar und unterbinde das Tracking trotzdem weitgehend, insbesondere in Kombination mit (d)FPI und Network Partitioning.
B. Bei Seiten, die ich regelmäßig besuche, gebe ich mir ein bisschen mehr Mühe, die notwendigen Regeln/Filter zu definieren. Schritt 1. (das Noopen der „Ressourcen von Drittseiten“) überspringe ich, gehe zu 2. und dann 3.2. Die dann gefundenen Regeln speichere ich mir durch Klick auf das Schloss-Symbol ab (Das Radiergummi-Symbol darunter macht alle Änderungen rückgängig, die noch nicht abgespeichert wurden.).
WICHTIG: Ohne ein solches Speichern wendet uBO die gewählten Regeln nur temporär an, „vergisst“ sie also wieder!!! Das gilt auch für alle oben unter A. beschriebenen Schritte!
Falls notwendig, ergänze ich diese Regeln im Logger um sehr spezifische Regeln über das Dynamic URL Filtering, die dann Vorrang haben vor dem oben dargestellten Dynamic Filtering, oder um Filter, die sich über den Logger sehr komfortabel erzeugen lassen.
Ergänzende Bemerkungen zum Dynamic URL Filtering
Oben wurde bereits erwähnt, dass neben Static Filtering und Dynamic Filtering auch noch Dynamic URL Filtering zur Verfügung steht. Wichtig ist, dass die darin erzeugten Regeln - die besonders komfortabel über den Logger angelegt werden können - Vorrang vor dem Static Filtering und sogar dem Dynamic Filtering haben. Besonders nützlich sind sie, um spezielle Anfragen zu erlauben, obwohl die entsprechende Domain durch eine block Regel im Dynamic Filtering blockiert wird.
Beispiel: Im Dynamic Filtering lassen sich z.B. alle Anfragen zu Google leicht blockieren - entweder im Rahmen des oben diskutierten Hard Mode oder grundsätzlich durch spezifische block Regeln für die Google Domains:
* google-analytics.com * block
* google-pagerank.net * block
* google-rank.org * block
* google.com * block
* adservice.google.com.mt * block
* google.de * block
* google.ru * block
* googleadservices.com * block
* googleanalytics.com * block
* googleoptimize.com * block
* googlesyndication.com * block
* googletagmanager.com * block
* googletagservices.com * block
... usw ...
Das Problem dabei ist, dass dadurch auch die Benutzung der Google reCAPTCHA nicht mehr möglich ist, was leider bei einigen Seiten aber notwendig ist. Einen Ausnahmefilter dafür anzulegen, bringt nichts - wie wir wissen, hat die block Regel im Dynamic Filtering Vorrang vor dem (Ausnahme-)Filter im Static Filtering. Die Lösung daher: das Erzeugen spezieller Dynamic URL Filter:
* https://www.google.com/recaptcha/api * noop
* https://www.google.com/recaptcha/enterprise * noop
* https://www.gstatic.com/recaptcha/api * noop
* https://www.gstatic.com/recaptcha/releases/ * noop
* https://www.recaptcha.net/recaptcha/api script noop
* https://www.recaptcha.net/recaptcha/enterprise script noop
* https://www.google.com/js/bg/ script noop
Dadurch werden nur Anfragen zu diesen spezifische URLs erlaubt, alle anderen Anfragen zu den Google (Sub-)Domains bleiben weiterhin blockiert.
Fazit:
Wenn man sich in diese Logik mal hineingedacht hat und das Ganze ein paar Mal durchgespielt hat, wird man feststellen, dass man auf uMatrix gut verzichten kann. Ebenso kann man auf Noscript verzichten, da auch mit uBO Skripte zuverlässig blockiert werden können. Man kann allerdings in Noscript alle Einschränkungen global deaktivieren und nur den XSS-Schutz eingeschaltet lassen, obwohl das nach meiner Erfahrung kaum etwas bringt, wenn man uBO in der oben dargestellten Weise benutzt.
