uBlock Origin: Effiziente Benutzung mit Dynamic Filtering und Skript-Blockierung

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.

    grafik

    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“:

uBO Dynamic Filtering Pane1

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:

uBO Dynamic Filtering Pane2

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.

Hard Mode

A. Bei Seiten, die ich nicht regelmäßig besuche und sozusagen im Vorbeigehen schnell lesbar/benutzbar machen will, gehe ich folgendermaßen vor:

  1. 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.
    Ressourcen aus Drittquellen noopen

    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.

  2. Falls das nicht reicht, erlaube ich Scripte über den Per-site-Schalter und lade die Seite neu.
    Javaskript erlauben

    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.

  3. 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).
    Skripte von Drittseiten erlauben

    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.
    Drittseiten noopen

    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!

Speichern von Regeln

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.

18 „Gefällt mir“

Oh meim Gott, endlich eine verständliche, aktuelle Anleitung!
Mit Beschreibung der Bedeutung der Farben.
:smiling_face_with_three_hearts:
Super!
Das muss ich erstmal genau durcharbeiten.
Bisher nutze ich einfach vertrauensselig die Konfiguration aus dem Privacy-Handbuch

2 „Gefällt mir“

Eine kleine Ergänzung: Ich habe geschrieben, dass ich mir für alle Adserver/Tracker eine globale Blockierregel anlege. Man kann sich das allerdings auch etwas einfacher machen, indem man z.B. die bekannte Liste von Peter Lowe als plain text herunterlädt und etwa als yoyo abspeichert. Diese Liste hat per heute 3677 Einträge.

Dann kann man diese mit sed (gibt es das auch für Windows?) in 2 Schritten in eine Liste mit uBO-Blockierregeln umwandeln:

  1. Einfügen von *Leertaste als 1. Spalte:

sed 's/.*/\* &/' < yoyo > yoyo1

  1. Einfügen von Leertaste * Leertaste block am Ende:

sed 's/.*/&\ * block/' < yoyo1 > yoyo2

Den Inhalt von yoyo2 kann man dann kopieren und in uBO unter Einstellungen → Meine Regeln in der ersten Leerzeile unter „Temporäre Regeln“ einfügen und dauerhaft speichern. Das kann ein paar Momente dauern, bis uBO das verarbeitet hat.

Wie im Tutorial gesagt: Diese Domains werden bereits über die Filterlisten blockiert. Der Sinn dieser Übung besteht daher einzig und allein darin, diese Domains mit einer globalen Blockierregel zu versehen, damit sie beim Noopen der Drittdomains von vornherein außen vor bleiben können, so dass die Domains, die genoopt werden müssen, damit die Seite funktioniert, leichter identifiziert werden können.

Super und vielen Dank für das Tutorial! Ich hatte deine Anleitungen schon mühsam aus der alten Forenruine rausgekratzt, aber in dieser kompakten Form ist es noch besser.

… arbeitest Du auch mit allow-rules ( * Set filterAuthorMode to true in [advanced settings]) ???

&&&

… hier bekomme ich kein dunkelgrau hin, nur ein blassrot >>> liegt das vielleicht an meinem Theme ???

2 „Gefällt mir“

Verstehe ich das richtig, dass im Hard Mode der Schalter „Skripte dieser Domain“ keine Funktion hat? Mir war beim ersten Mal der „Hier klicken, um Javascript auf dieser Seite wieder zu aktivieren“ Schalter entgangen und ich war davon ausgegangen, dass „Skripte dieser Domain“ diese Funktion erfüllt.

Ja, weil ich weiß, was ich tue. Allow rules stehen aber mit gutem Grund standardmäßig nicht mehr zur Verfügung, weil früher viele Benutzer diese sehr häufig genutzt haben, wenn eine Seite nicht funktionierte - mit dem Ergebnis, dass auch überhaupt kein Schutz mehr durch die Filterlisten gegeben war. Das sollte man nicht tun!

Blassrot? Hm, sollten eigentlich hellgrau sein.

Ich hatte im alten Forum (das ja leider Gottes nicht vernünftig durchsuchbar ist) mal gorhill zitiert, dass der Per-site-Button vorzugsweise benutzt werden sollte. Der bestimmt ja auch, ob Erst- und Drittseiten-Skripte erlaubt sind (und Letztere nur dann, wenn für „Skripte aus Drittquellen“ keine Blockierregel definiert ist). Ich verwende „Skripte dieser Domain“ nicht. Der ist m.E. in Fällen sinnvoll, wenn man für bestimmte Drittseiten Skripte erlauben will, für die Erstseite aber nicht. Man müsste dafür erst mal Skripte mit dem Per-site-Button erlauben und dann für die Erstseite über „Skripte für diese Domain“ wieder verbieten. Ich denke, das ist eher ungewöhnlich, aber nicht undenkbar.

Was „Inline-Skripte“ angeht, so kann ich mich an einige auf reddit diskutierte Fälle erinnern, wo deren Blockieren empfohlen wurde, um irgendwelche Nervigkeiten zu unterbinden.

Danke für die Erklärung. „Skripte dieser Domain“ hat im Hard Mode also nur eine Funktion, wenn Skripte für die Erstseite über den Per-Site Button schon erlaubt wurden.

Vielen Dank seeket für das HowTo. Da es ein Wiki ist, kann es ja auch erweitert/bearbeitet werden. Vorschlag: Ein paar Screenshots ergänzen.

Danke, gute Idee! Werde ich bei Gelegenheit umsetzen, wird aber noch dauern, da ich in nächster Zeit anderweitig beschäftigt bin.

Ich denke, dass es dann auch sinnvoll wäre, die Basics (also etwa den Unterschied zwischen Static Filtering und Dynamic Filtering sowie die grundsätzliche Logik und die Rangordnung) kurz, aber prägnant darzustellen, bevor es ans Eingemachte geht. Aber wie gesagt, kurzfristig habe ich dafür keine Zeit.

Ich hatte übrigens versucht, zu meinem obigen Beitrag die Textdatei yoyo2 hochzuladen. Das war aber nicht zulässig, und ein Reinkopieren der Regeln in den Beitrag als Code ging auch nicht, weil zu groß. Schade :frowning:

Vielen Dank für diese Anleitung.
Wie schon erwähnt wären Screenshots zum besseren Verständnis super!

Tolle Anleitung, vielen Dank!

Unter Windows könnte man die Liste recht einfach mit Notepad++ bearbeiten:

1.) Unter „Search/Replace“ zuerst unten im Kästchen „Search Mode“ „Regular expression“ anhaken.

2.) Dann in „Find what:“ „^“ und unter „Replace with:“* " eingeben. „Replace all“ drücken.

3.) Und schließlich in „Find what:“ „$“ und unter „Replace with:“ * block" eingeben. „Replace all“ drücken.

Leerzeichen nicht vergessen! :slight_smile:
Hoffe, ich konnte auch ein kleines bisschen dazu beitragen…

Nachdem ich jetzt diverse Tage so gesurft bin, will ich zuerst mal sagen, dass ich begeistert bin. Das bedient sich letztendlich viel flotter als uMatrix bzw. uMatrix + uBlock. Leider ist das UI von uBlock nicht ganz so intuitiv wie uMatrix, so dass man sich ein bisschen mehr einarbeiten muss, aber danach flutscht es.

Ich habe allerdings festgestellt, dass ich bei allen Seiten als erstes Javascript wieder aktiviere, weil sonst praktisch nichts mehr funktioniert heutzutage. Das spare ich mir in Zukunft dann lieber und aktiviere Javascript wieder in den Voreinstellungen, oder handele ich mir damit evtl. Nebeneffekte ein (abgesehen davon natürlich, dass Javascript der Domäne ausgeführt wird)?

1 „Gefällt mir“

Das generelle Aktivieren von Javascript halte ich für keine gute Idee.

Ich habe sowohl UBlock (und UMatrix) als auch NoScript im Einsatz.
Die Konfiguration beider AddOns habe ich von Privacy-Handbuch heruntergeladen.

Damit mache ich sehr gute Erfahrungen. Es werden nur wirklich sinnvolle Skripts geblockt. Bei Tagesschau.de habe ich z.B. keinerlei Probleme, obwohl auch dort Skripte geblockt werden.
Vielleicht probiertst Du das mal aus.

Warum?

Und das ist technisch besser als nur uBlock im Hard Mode weil?

Gerade ausprobiert, mal abgesehen davon, dass tagesschau.de mich eigentlich nicht interessiert. IMHO ist das unbenutzbar, solange Javascript auf der Erstseite deaktiviert ist. Selbst mit aktiviertem Javascript muss man in uBlock erst Akamai zulassen, bevor das nutzbar wird.

@elfchen du wurdest so verstanden, also ob Du alles JS freigegeben hättest. Das ist tatsächlich keine gute Idee, schon weil unnötig. Ich verstehe Dich aber so, dass Du Javascripte des Zielservers freigegeben hast, obwohl Deine Formulierung aunklar ist.

Tatsächlich, danke, das war sehr missverständlich formuliert. Und eigentlich hatte ich in dem vorigen Beitrag gefragt, weil mir unklar ist, was die Dokumentation aussagt:
https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-scripting

Die Checkbox heißt „Javascript deaktivieren“. Wenn ich jetzt also Javascript aktiviere in dieser Einstellung, wirkt das dann sowohl für die Erstdomäne als auch alle externen Domänen? Gibt es eine Möglichkeit, Javascript in den Voreinstellungen nur für die Erstdomäne zu aktivieren aber nicht für externe Domänen?

Die Checkbox bezieht sich auf eine separate Option, JavaScript allgemein aus/einzuschalten. Das betrifft dann JavaScript für das Dokument der Seite („Inline“), Domain und Drittdomains.
Nachtrag: Der Vollständigkeit halber: „noscript“-HTML-Elemente (nicht das Add-On) werden durch diese Option auch interpretiert. Theoretisch kann das helfen, bisher sind mir jedoch nur Seiten untergekommen, die damit nichts sinnvolles anstellen, oder auch ohne „funktionieren“. Im Falle dessen, dass man Erstanbieter Skripte generell ausführen möchte, ist die Option meines Wissens nach nutzlos.


Vom „Dynamic Filtering“ ist das aber unabhängig, wenn du also „Skripte aus Drittquellen“ im uBlock Origin Panel deaktivierst, bleibt JavaScript auch für diese deaktiviert, wenn du JavaScript über den „Per-site-switch“ wieder aktivierst (was es auch wäre, wenn du es in den Voreinstellungen nicht anwählst).

Ja, ich hatte ja geschrieben, dass dieser Schalter bzw. der Per-site-Button Blockier-Vorrang hat. Wenn er aktiviert ist, sind alle Skripte grundsätzlich verboten. Wenn er deaktiviert ist, sind aber durch die Blockierregel für „Skripte für Drittseiten“ diese nach wie vor verboten, Erstseiten-Skripte aber erlaubt.

Ich dachte, ich hätte das in A2. so beschrieben. Ist das nicht verständlich genug? Ich kann das ja nochmal umformulieren, falls nötig.

Edit: ich sehe gerade, dass für das Tutorial der Editier-Button jetzt weg ist. Kann ich den Beitrag also doch nicht mehr editieren? :woozy_face:

3 „Gefällt mir“

Danke, nicht nötig das umzuformulieren. Als Einsteiger wird man leicht durch die diversen Konfigurationsebenen verwirrt, vor allem wenn man von uMatrix kommt, wo die Einstellungen über die Matrix sehr intuitiv sind.

1 „Gefällt mir“