Nur auf der FB - ausführlicher (länger als gedacht) Hinweis zur allgemeinen Methodik innen
Pi-Hole habe ich nicht. Das war aber auch keine Fritzbox Promotion , andere Boxen bieten ähnliches, sondern ich wollte sehen, wie effizient das DNS Blocking im Router/Pi-Hole ist und ob aus irgendeinem blöden Grund bei Heise die Ladezeiten sogar hoch statt runtergehen, weil z.B. Skripte explizit auf "Zulieferungen" von externen Content warten, der jetzt geblockt ist.
Es war auch als Anregung gedacht, was man mit fast null Aufwand und vorhandenem Gerät bereits erreichen kann.
(Falls das auch im Heise Artikel erklärt ist ab hier alles skippen)
Durch das Erkennen von fehlenden Ad-Inhalten durch Skripte lassen sich rein DNS basierte Blocker leicht aushebeln, das ist der gleiche Mechanismus auf dem auch die Anti-AdBlocker-Hinweise beruhen, die von der angesurfen Originalseite aus getriggert werden.
Um die Anti-AdBlocker-Hinweise und andere Inhalte pfad- oder typweise blocken zu können, braucht man mehr als "simples/dummes" DNS Blocking und muß den Contentstream, was fordert der Browser an und was erhält er zurück, betrachten und filtern.
Durch die HTTPS Auslieferung ist das nur möglich, wenn man die sichere Verbindung zwischen dem Server (Webseite) und Client (Browser) aufbricht. Für den Router und jemand anderen der mitliest sind nur die Doaminnamen lesbar, Pfade und Inhalte sind verschlüsselt.
Von der Anforderung des Macfix Logos
https://www.macfix.de/theme/MacFix/img/forum_logo_inv.png
kann der Router oder jemand der den Traffic mitschneiden will nur noch https://www.macfix.de/ lesen - der Rest ist verschlüsselt und bleibt zwischen der Webseite und Browser "geheim".
Browserextensions wie AdBlock, uBlock etc. sind in der komfortablen Lage, die Requests (Client => Server , Browser => Webseite) nach dem Abschicken durch den User aber vor dem Verschlüsseln bzw. bei der Antwort (Server => Client , Webseite => Browser) nach dem Entschlüsseln aber vor der Darstellung im Browser mitlesen/beeinflussen zu können.
Aus einer kompletten sicheren Strecke Webseite <- sicher -> Browser
Webseite <- sicher -> Internet <- sicher -> Router <- sicher -> Anzeige im Browser
kommt dann ein "unsicheres" Stück, der AdBlocker, hinzu
Webseite <- sicher -> Internet <- sicher -> Router <- sicher -> uBlock -< unsicher -> Anzeige im Browser
So kann man zwar jeglichen Inhalt ob verschlüsselt oder unverschlüsselt blocken und/oder vor dem Absenden oder der Darstellung verändern, offenbart aber dem AdBlocker sämtliche Informationen.
Zusätzlich funktioniert das nur direkt im Browser, d.h. mehrere Browser bedeuten auch mehrere AdBlocker und jedes Mal wieder auch das Festlegen der Blockierregeln.
Die Alternative besteht darin den gesamten Traffic durch einen zentralen AdBlocker zu schicken, wie den Pi-Hole nur eben nicht nur für die Namensauflösung sondern für das Filtern des Inhalts.
Das erfordert bedeutend mehr Rechenleistung als nur DNS Anfragen zu beantworten, da auch komplexe Regeln schnell und ohne merkliche Verzögerung abgearbeitet werden müssen.
Falls hier noch einer liest kurzes Feedback dann folgt später noch Teil 2 zu Proxies mit SSL und im Handy lokale VPN Proxies - sonst spare ich es mir, wenn es eh jeder weiß/verstanden oder die Erklärung nicht verständlich ist.
Es war auch als Anregung gedacht, was man mit fast null Aufwand und vorhandenem Gerät bereits erreichen kann.
(Falls das auch im Heise Artikel erklärt ist ab hier alles skippen)
Durch das Erkennen von fehlenden Ad-Inhalten durch Skripte lassen sich rein DNS basierte Blocker leicht aushebeln, das ist der gleiche Mechanismus auf dem auch die Anti-AdBlocker-Hinweise beruhen, die von der angesurfen Originalseite aus getriggert werden.
Um die Anti-AdBlocker-Hinweise und andere Inhalte pfad- oder typweise blocken zu können, braucht man mehr als "simples/dummes" DNS Blocking und muß den Contentstream, was fordert der Browser an und was erhält er zurück, betrachten und filtern.
Durch die HTTPS Auslieferung ist das nur möglich, wenn man die sichere Verbindung zwischen dem Server (Webseite) und Client (Browser) aufbricht. Für den Router und jemand anderen der mitliest sind nur die Doaminnamen lesbar, Pfade und Inhalte sind verschlüsselt.
Von der Anforderung des Macfix Logos
https://www.macfix.de/theme/MacFix/img/forum_logo_inv.png
kann der Router oder jemand der den Traffic mitschneiden will nur noch https://www.macfix.de/ lesen - der Rest ist verschlüsselt und bleibt zwischen der Webseite und Browser "geheim".
Browserextensions wie AdBlock, uBlock etc. sind in der komfortablen Lage, die Requests (Client => Server , Browser => Webseite) nach dem Abschicken durch den User aber vor dem Verschlüsseln bzw. bei der Antwort (Server => Client , Webseite => Browser) nach dem Entschlüsseln aber vor der Darstellung im Browser mitlesen/beeinflussen zu können.
Aus einer kompletten sicheren Strecke Webseite <- sicher -> Browser
Webseite <- sicher -> Internet <- sicher -> Router <- sicher -> Anzeige im Browser
kommt dann ein "unsicheres" Stück, der AdBlocker, hinzu
Webseite <- sicher -> Internet <- sicher -> Router <- sicher -> uBlock -< unsicher -> Anzeige im Browser
So kann man zwar jeglichen Inhalt ob verschlüsselt oder unverschlüsselt blocken und/oder vor dem Absenden oder der Darstellung verändern, offenbart aber dem AdBlocker sämtliche Informationen.
Zusätzlich funktioniert das nur direkt im Browser, d.h. mehrere Browser bedeuten auch mehrere AdBlocker und jedes Mal wieder auch das Festlegen der Blockierregeln.
Die Alternative besteht darin den gesamten Traffic durch einen zentralen AdBlocker zu schicken, wie den Pi-Hole nur eben nicht nur für die Namensauflösung sondern für das Filtern des Inhalts.
Das erfordert bedeutend mehr Rechenleistung als nur DNS Anfragen zu beantworten, da auch komplexe Regeln schnell und ohne merkliche Verzögerung abgearbeitet werden müssen.
Falls hier noch einer liest kurzes Feedback dann folgt später noch Teil 2 zu Proxies mit SSL und im Handy lokale VPN Proxies - sonst spare ich es mir, wenn es eh jeder weiß/verstanden oder die Erklärung nicht verständlich ist.