Abo
  1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › DoH-Standard: DNS über HTTPS ist…

RIP DNS-Based Ad Blocking

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. RIP DNS-Based Ad Blocking

    Autor: nikeee13 18.07.19 - 10:04

    Wenn OkHTTP schon DoH kann, wird es nicht lange dauern, bis jedes Android-Werbewidget den DoH-Resolver vom Werbetreibenden nimmt.

    Dann muss man sich neben dem DNS-Server mit Blocklisten noch eine Firewall mit Blocklisten hinstellen.

    War ne schöne Zeit.

  2. Re: RIP DNS-Based Ad Blocking

    Autor: Xar 18.07.19 - 10:43

    nikeee13 schrieb:
    --------------------------------------------------------------------------------
    > Wenn OkHTTP schon DoH kann, wird es nicht lange dauern, bis jedes
    > Android-Werbewidget den DoH-Resolver vom Werbetreibenden nimmt.

    Und wo ist der Unterschied zu jetzt? Jede App könnte einen bestimmten DNS-Resolver hardcoded ansprechen.

  3. Re: RIP DNS-Based Ad Blocking

    Autor: beta 18.07.19 - 11:00

    Xar schrieb:
    --------------------------------------------------------------------------------
    > nikeee13 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wenn OkHTTP schon DoH kann, wird es nicht lange dauern, bis jedes
    > > Android-Werbewidget den DoH-Resolver vom Werbetreibenden nimmt.
    >
    > Und wo ist der Unterschied zu jetzt? Jede App könnte einen bestimmten
    > DNS-Resolver hardcoded ansprechen.

    Jup können sie. Diese werden dann von meiner Firewall geblockt. Mit Ausnahme von pihole wird aller DNS Traffic nach Aussen geblockt. Hardcoded mag ich deshalb besonders, selbst Adressen ausserhalb mein Filterliste werden dadurch einfach geblockt :)



    1 mal bearbeitet, zuletzt am 18.07.19 11:01 durch beta.

  4. Re: RIP DNS-Based Ad Blocking

    Autor: Gole-mAndI 18.07.19 - 11:07

    Das Problem ist eher das dann Android-Blocker wie Blokada nicht mehr funktioniert.

  5. Re: RIP DNS-Based Ad Blocking

    Autor: LASERwalker 18.07.19 - 11:21

    Sie können das auch schon jetzt über HTTPS tunnellen, auch ohne DoH. Also keine Verschlechterung durch DoH.

  6. Re: RIP DNS-Based Ad Blocking

    Autor: Qbit42 18.07.19 - 11:23

    Wieso sollte Blockada nicht mehr funktionieren und wo ist der Unterschied zu jetzt?

  7. Re: RIP DNS-Based Ad Blocking

    Autor: Gole-mAndI 18.07.19 - 11:31

    Die Werbung wird meistens noch von einem Drittanbieter Server heruntergeladen. Die Domain dieses wird per DNS aufgelöst. Blokada sieht die Anfrage un blockiert sie. Bei DoH sieht blokada den Inhalt nicht mehr und kann nichts tun.

  8. Re: RIP DNS-Based Ad Blocking

    Autor: LASERwalker 18.07.19 - 13:30

    Du hast da was nicht verstanden.

    nikeee13 sagt Apps können den voreingestellen DNS-Server ignorieren und die IP-Adressen der Werbeserver per DoH abfragen. Ich habe geantwortet: das können sie auch ohne DoH per HTTPS. Deshalb zieht das Argument von nikeee13 nicht.

  9. Re: RIP DNS-Based Ad Blocking

    Autor: Gole-mAndI 18.07.19 - 13:53

    LASERwalker schrieb:
    --------------------------------------------------------------------------------
    > Du hast da was nicht verstanden.
    >
    > nikeee13 sagt Apps können den voreingestellen DNS-Server ignorieren und die
    > IP-Adressen der Werbeserver per DoH abfragen. Ich habe geantwortet: das
    > können sie auch ohne DoH per HTTPS. Deshalb zieht das Argument von nikeee13
    > nicht.

    Diese Anfrage kann Blokada (theoretisch) noch blockieren. Ohne allgemeines DoH müsste die DNS Anfrage selbst nochmal an einen (DoH) Server des Werbungsdienstleisters geschickt werden. Diese Anfrage kann Blokada blocken. Eine Anfrage an einen allgemeinen DNS Server zu blocken wäre hingegen sinnfrei.

  10. Re: RIP DNS-Based Ad Blocking

    Autor: robinx999 18.07.19 - 13:55

    Die Apps könnten jetzt schon andere DNS Server nutzen, diese könnte man evtl. in der Firewall blockieren. Sie könnten per IP auf ihre Werbenetze zugreifen, sie könnten ein komplett eigene Protokoll verwenden, sie könnten die Werbung die runter geladen wurde zählen und wenn nichts runter geladen wurde ihren Dienst komplett einstellen (wenn es öfters passiert, oder Werbung anzeigen die mit der App mit kommt bzw. die von dem Anbieter übertragen wurde)
    Mittels Zertifikatspinning kann man auch noch das belauschen des Traffics erschweren

    Eigentlich gibt es hier viele Möglichkeiten

  11. Re: RIP DNS-Based Ad Blocking

    Autor: Gole-mAndI 18.07.19 - 14:21

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > Die Apps könnten jetzt schon andere DNS Server nutzen, diese könnte man
    > evtl. in der Firewall blockieren. Sie könnten per IP auf ihre Werbenetze
    > zugreifen, sie könnten ein komplett eigene Protokoll verwenden, sie könnten
    > die Werbung die runter geladen wurde zählen und wenn nichts runter geladen
    > wurde ihren Dienst komplett einstellen (wenn es öfters passiert, oder
    > Werbung anzeigen die mit der App mit kommt bzw. die von dem Anbieter
    > übertragen wurde)
    > Mittels Zertifikatspinning kann man auch noch das belauschen des Traffics
    > erschweren
    >
    > Eigentlich gibt es hier viele Möglichkeiten

    Es ist egal welchen DNS Server sie nutzen. Solange Blokada den Inhalt des Pakets lesen kann, kann es die Anfrage auch blockieren.

    Ich weiß nicht sicher warum die Werbedienstleister nicht direkt die IP nutzen oder warum alle Block-Listen für Werbung DNS und nicht IP basiert sind. Aber offenbar ist es so für beide Seiten einfacher. Wenn DoH wirklich Verwendung finden sollte bleibt nur ein IP basiertes Blacklisting. Was aber beispielsweise Adaway nicht realisieren kann und was auch PiHole vor Probleme stellt.

    Und den Dienst einstellen können die Apps auch nicht so einfach. Die Werbung kann auch aus anderen Gründen nicht funktionieren. Eine nicht funktionierende App würde direkt negativ auf die Entwickler zurückfallen.

    DoH macht es also deutlich schwerer Werbung zu blockieren als jetzt und würde zumindest große Umbauten bei den Werbeblockern erfordern.

  12. Re: RIP DNS-Based Ad Blocking

    Autor: robinx999 18.07.19 - 14:28

    Gole-mAndI schrieb:
    --------------------------------------------------------------------------------
    > robinx999 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Die Apps könnten jetzt schon andere DNS Server nutzen, diese könnte man
    > > evtl. in der Firewall blockieren. Sie könnten per IP auf ihre Werbenetze
    > > zugreifen, sie könnten ein komplett eigene Protokoll verwenden, sie
    > könnten
    > > die Werbung die runter geladen wurde zählen und wenn nichts runter
    > geladen
    > > wurde ihren Dienst komplett einstellen (wenn es öfters passiert, oder
    > > Werbung anzeigen die mit der App mit kommt bzw. die von dem Anbieter
    > > übertragen wurde)
    > > Mittels Zertifikatspinning kann man auch noch das belauschen des
    > Traffics
    > > erschweren
    > >
    > > Eigentlich gibt es hier viele Möglichkeiten
    >
    > Es ist egal welchen DNS Server sie nutzen. Solange Blokada den Inhalt des
    > Pakets lesen kann, kann es die Anfrage auch blockieren.
    >
    > Ich weiß nicht sicher warum die Werbedienstleister nicht direkt die IP
    > nutzen oder warum alle Block-Listen für Werbung DNS und nicht IP basiert
    > sind. Aber offenbar ist es so für beide Seiten einfacher. Wenn DoH wirklich
    > Verwendung finden sollte bleibt nur ein IP basiertes Blacklisting. Was aber
    > beispielsweise Adaway nicht realisieren kann und was auch PiHole vor
    > Probleme stellt.
    >
    Naja DNS ist einfacher wie IP, aber wenn DNS bassiertes Blocking ein hohes Maß an Nutzern erreicht wäre ein Umstellen relativ einfach möglich.
    DNS Abfragen könnten sie auch jetzt schon Tunneln und sei es über SSH oder sonst etwas, dafür braucht es kein DOH

    > Und den Dienst einstellen können die Apps auch nicht so einfach. Die
    > Werbung kann auch aus anderen Gründen nicht funktionieren. Eine nicht
    > funktionierende App würde direkt negativ auf die Entwickler zurückfallen.
    >
    Spricht nicht so viel dagegen dass die App sich beim ersten Start 20 Verschiedene Werbungen runter lädt und diese Anzeigt wenn die Verbindung zu dem Werbeserver nicht klappt
    Wenn die App länger wie sagen wir 48 Stunden keine Verbindung zu dem Werbeserver hin bekommt, dann stellt sie ihren Dienst ein sollte nicht so schwer zu realisieren sein. Und dürfte "normale" Nutzer eigentlich nicht treffen selbst wenn der Werbedienstleister mal Offline sein sollte
    > DoH macht es also deutlich schwerer Werbung zu blockieren als jetzt und
    > würde zumindest große Umbauten bei den Werbeblockern erfordern.

    Man könnte einen eigenen DOH Server in die App einbauen und die anderen blockieren.

  13. Re: RIP DNS-Based Ad Blocking

    Autor: Gole-mAndI 18.07.19 - 14:46

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > Gole-mAndI schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > robinx999 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Die Apps könnten jetzt schon andere DNS Server nutzen, diese könnte
    > man
    > > > evtl. in der Firewall blockieren. Sie könnten per IP auf ihre
    > Werbenetze
    > > > zugreifen, sie könnten ein komplett eigene Protokoll verwenden, sie
    > > könnten
    > > > die Werbung die runter geladen wurde zählen und wenn nichts runter
    > > geladen
    > > > wurde ihren Dienst komplett einstellen (wenn es öfters passiert, oder
    > > > Werbung anzeigen die mit der App mit kommt bzw. die von dem Anbieter
    > > > übertragen wurde)
    > > > Mittels Zertifikatspinning kann man auch noch das belauschen des
    > > Traffics
    > > > erschweren
    > > >
    > > > Eigentlich gibt es hier viele Möglichkeiten
    > >
    > > Es ist egal welchen DNS Server sie nutzen. Solange Blokada den Inhalt
    > des
    > > Pakets lesen kann, kann es die Anfrage auch blockieren.
    > >
    > > Ich weiß nicht sicher warum die Werbedienstleister nicht direkt die IP
    > > nutzen oder warum alle Block-Listen für Werbung DNS und nicht IP basiert
    > > sind. Aber offenbar ist es so für beide Seiten einfacher. Wenn DoH
    > wirklich
    > > Verwendung finden sollte bleibt nur ein IP basiertes Blacklisting. Was
    > aber
    > > beispielsweise Adaway nicht realisieren kann und was auch PiHole vor
    > > Probleme stellt.
    > >
    > Naja DNS ist einfacher wie IP, aber wenn DNS bassiertes Blocking ein hohes
    > Maß an Nutzern erreicht wäre ein Umstellen relativ einfach möglich.
    > DNS Abfragen könnten sie auch jetzt schon Tunneln und sei es über SSH oder
    > sonst etwas, dafür braucht es kein DOH

    Die Anfragen müssen aber von irgendwem beantwortet werden. Dafür müssten die Werbedienstleister einen eigenen Server betreiben. Anfragen an diesen Server können einfach blockiert werden.

    Aber wie willst du wissen ob du eine Anfrage blocken darfst, wenn sie an einen allgemeinen DNS Server geht und du den Inhalt nicht kennst. Richtig gar nicht. Du siehst den Unterschied?

    >
    > > Und den Dienst einstellen können die Apps auch nicht so einfach. Die
    > > Werbung kann auch aus anderen Gründen nicht funktionieren. Eine nicht
    > > funktionierende App würde direkt negativ auf die Entwickler zurückfallen.
    >
    > >
    > Spricht nicht so viel dagegen dass die App sich beim ersten Start 20
    > Verschiedene Werbungen runter lädt und diese Anzeigt wenn die Verbindung zu
    > dem Werbeserver nicht klappt
    > Wenn die App länger wie sagen wir 48 Stunden keine Verbindung zu dem
    > Werbeserver hin bekommt, dann stellt sie ihren Dienst ein sollte nicht so
    > schwer zu realisieren sein. Und dürfte "normale" Nutzer eigentlich nicht
    > treffen selbst wenn der Werbedienstleister mal Offline sein sollte

    Es gibt Werbeblocker schon länger und unabhängig von DoH haben sie diese Möglichkeit offensichtlich nie/kaum genutzt. Warum sollte sich daran jetzt auf einmal (durch DoH) etwas daran ändern? Ich denke das ist auch eine Abrechnungssache. Es wird ja nach Klicks/Views gezahlt. Die müssen irgendwie bewiesen werden. Und die Werbedienstleister trauen ihren Kunden auch nicht.

    > > DoH macht es also deutlich schwerer Werbung zu blockieren als jetzt und
    > > würde zumindest große Umbauten bei den Werbeblockern erfordern.
    >
    > Man könnte einen eigenen DOH Server in die App einbauen und die anderen
    > blockieren.

    Und was soll das bewirken?



    2 mal bearbeitet, zuletzt am 18.07.19 15:04 durch Gole-mAndI.

  14. Re: RIP DNS-Based Ad Blocking

    Autor: robinx999 18.07.19 - 15:43

    Gole-mAndI schrieb:
    --------------------------------------------------------------------------------
    > robinx999 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Gole-mAndI schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > robinx999 schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Die Apps könnten jetzt schon andere DNS Server nutzen, diese könnte
    > > man
    > > > > evtl. in der Firewall blockieren. Sie könnten per IP auf ihre
    > > Werbenetze
    > > > > zugreifen, sie könnten ein komplett eigene Protokoll verwenden, sie
    > > > könnten
    > > > > die Werbung die runter geladen wurde zählen und wenn nichts runter
    > > > geladen
    > > > > wurde ihren Dienst komplett einstellen (wenn es öfters passiert,
    > oder
    > > > > Werbung anzeigen die mit der App mit kommt bzw. die von dem Anbieter
    > > > > übertragen wurde)
    > > > > Mittels Zertifikatspinning kann man auch noch das belauschen des
    > > > Traffics
    > > > > erschweren
    > > > >
    > > > > Eigentlich gibt es hier viele Möglichkeiten
    > > >
    > > > Es ist egal welchen DNS Server sie nutzen. Solange Blokada den Inhalt
    > > des
    > > > Pakets lesen kann, kann es die Anfrage auch blockieren.
    > > >
    > > > Ich weiß nicht sicher warum die Werbedienstleister nicht direkt die IP
    > > > nutzen oder warum alle Block-Listen für Werbung DNS und nicht IP
    > basiert
    > > > sind. Aber offenbar ist es so für beide Seiten einfacher. Wenn DoH
    > > wirklich
    > > > Verwendung finden sollte bleibt nur ein IP basiertes Blacklisting. Was
    > > aber
    > > > beispielsweise Adaway nicht realisieren kann und was auch PiHole vor
    > > > Probleme stellt.
    > > >
    > > Naja DNS ist einfacher wie IP, aber wenn DNS bassiertes Blocking ein
    > hohes
    > > Maß an Nutzern erreicht wäre ein Umstellen relativ einfach möglich.
    > > DNS Abfragen könnten sie auch jetzt schon Tunneln und sei es über SSH
    > oder
    > > sonst etwas, dafür braucht es kein DOH
    >
    > Die Anfragen müssen aber von irgendwem beantwortet werden. Dafür müssten
    > die Werbedienstleister einen eigenen Server betreiben. Anfragen an diesen
    > Server können einfach blockiert werden.
    >
    So etwas müsste nur auf einem Server laufen der wichtig für die App ist und schon könnte man es nicht mehr unterscheiden. Da viele Apps so wieso mit einem Hersteller reden müssen um zu funktionieren spricht nichts dagegen dies zu kombinieren
    > Aber wie willst du wissen ob du eine Anfrage blocken darfst, wenn sie an
    > einen allgemeinen DNS Server geht und du den Inhalt nicht kennst. Richtig
    > gar nicht. Du siehst den Unterschied?
    >
    > >
    > > > Und den Dienst einstellen können die Apps auch nicht so einfach. Die
    > > > Werbung kann auch aus anderen Gründen nicht funktionieren. Eine nicht
    > > > funktionierende App würde direkt negativ auf die Entwickler
    > zurückfallen.
    > >
    > > >
    > > Spricht nicht so viel dagegen dass die App sich beim ersten Start 20
    > > Verschiedene Werbungen runter lädt und diese Anzeigt wenn die Verbindung
    > zu
    > > dem Werbeserver nicht klappt
    > > Wenn die App länger wie sagen wir 48 Stunden keine Verbindung zu dem
    > > Werbeserver hin bekommt, dann stellt sie ihren Dienst ein sollte nicht
    > so
    > > schwer zu realisieren sein. Und dürfte "normale" Nutzer eigentlich nicht
    > > treffen selbst wenn der Werbedienstleister mal Offline sein sollte
    >
    > Es gibt Werbeblocker schon länger und unabhängig von DoH haben sie diese
    > Möglichkeit offensichtlich nie/kaum genutzt. Warum sollte sich daran jetzt
    > auf einmal (durch DoH) etwas daran ändern? Ich denke das ist auch eine
    > Abrechnungssache. Es wird ja nach Klicks/Views gezahlt. Die müssen
    > irgendwie bewiesen werden. Und die Werbedienstleister trauen ihren Kunden
    > auch nicht.
    >
    Werbeblocker gibt es schon länger. Beim Desktop Browser haben sie auch eine Relativ hohe Verbreitung und es gab einige Gegenmaßnahmen und gerade bei Apps kann man noch viel mehr machen wie beim Browser. Aktuell würde ich vermuten ist die Nutzeranzahl noch recht gering
    > > > DoH macht es also deutlich schwerer Werbung zu blockieren als jetzt
    > und
    > > > würde zumindest große Umbauten bei den Werbeblockern erfordern.
    > >
    > > Man könnte einen eigenen DOH Server in die App einbauen und die anderen
    > > blockieren.
    >
    > Und was soll das bewirken?

    Wenn die App nur den eigenen DOH DNS Server zu lässt, dann könnte man Werbung auch filtern

  15. Re: RIP DNS-Based Ad Blocking

    Autor: Gole-mAndI 18.07.19 - 17:33

    robinx999 schrieb:
    -------------------------------------------------------------------------------
    > Werbeblocker gibt es schon länger. Beim Desktop Browser haben sie auch eine
    > Relativ hohe Verbreitung und es gab einige Gegenmaßnahmen und gerade bei
    > Apps kann man noch viel mehr machen wie beim Browser. Aktuell würde ich
    > vermuten ist die Nutzeranzahl noch recht gering

    Tja mein Werbeblocker funktioniert sowohl im Browser als auch in der App und das absolut zufriedenstellend und seit Jahren. Ich weiß nicht wo du da Probleme hast.

    > So etwas müsste nur auf einem Server laufen der wichtig für die App ist und
    > schon könnte man es nicht mehr unterscheiden. Da viele Apps so wieso mit
    > einem Hersteller reden müssen um zu funktionieren spricht nichts dagegen
    > dies zu kombinieren
    Nein. In diesem Fall müsste der App Entwickler sich selbst für das Werben bezahlen. Möchte er Geld dafür macht er das über einen Dienstleister. Dieser liefert die Werbung aus.


    > Wenn die App nur den eigenen DOH DNS Server zu lässt, dann könnte man
    > Werbung auch filtern
    Nein kann man nicht. Unter Android kann man den DNS fürs mobile Netzwerk nicht konfigurieren. Nur weil ein Server existiert heißt es nicht das er genutzt wird.

  16. Re: RIP DNS-Based Ad Blocking

    Autor: nikeee13 18.07.19 - 18:07

    LASERwalker schrieb:
    --------------------------------------------------------------------------------
    > nikeee13 sagt Apps können den voreingestellen DNS-Server ignorieren und die
    > IP-Adressen der Werbeserver per DoH abfragen. Ich habe geantwortet: das
    > können sie auch ohne DoH per HTTPS. Deshalb zieht das Argument von nikeee13
    > nicht.

    Doch. Denn jetzt gibt's einen Standard. Es ist plötzlich echt billig, das zu tun. Die Frameworks können es jetzz. Die Infrastruktur wird sich in ein paar Wochen vermutlich leicht mit fertiger Software und einem Container hochziehen.
    Das war etwas, was man vorher nicht hatte. Selbstverständlich konnte man das Ergebnis vorher auch schon irgendwie erreichen, aber da hat es Geld gekostet und war eine Bastellösung.

    Jetzt braucht man also noch eine Firewall, die eine Blockliste mit Updates hat. Damit würde der gesamte Traffic durch den Pi laufen. Oder man hackt sich was mit anderen Routern zurecht.

    Und das ganze geht auch nur, wenn die IP für den DoH-Server eine andere ist, als die, wo Content liegt, den man haben will. Ich kann mir z.B. gut vorstellen, dass Google bei YT einen DoH-Server einfach auf die selbe IP legt, auf der auch z.B. der Youtube-Inhalt liegt. Da reicht dann schon auch keine simple Firewall mehr. Da braucht man schon DPI. Und das geht auch nur, wenn kein Cert-Pinning gemacht wurde. Und ob ich DPI auf einem Pi machen würde ist noch Mal eine andere Frage.

    Aktuell habe ich es bei mir so, dass 8.8.8.8 als statische Route an den Pihole geht und 53 nach außen geblockt ist (außer es kommt vom Pihole). In Zukunft sehe ich dafür schwarz.



    3 mal bearbeitet, zuletzt am 18.07.19 18:18 durch nikeee13.

  17. Re: RIP DNS-Based Ad Blocking

    Autor: derh0ns 18.07.19 - 20:21

    Xar schrieb:
    --------------------------------------------------------------------------------
    > nikeee13 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wenn OkHTTP schon DoH kann, wird es nicht lange dauern, bis jedes
    > > Android-Werbewidget den DoH-Resolver vom Werbetreibenden nimmt.
    >
    > Und wo ist der Unterschied zu jetzt? Jede App könnte einen bestimmten
    > DNS-Resolver hardcoded ansprechen.

    Momentan kann ich aber über mein VPN alle anfragen an UDP port 53 auf meinen DNS server umleiten ob die app das will oder nicht, wenns verschlüsselt ist geht das nicht mehr.

  18. Re: RIP DNS-Based Ad Blocking

    Autor: Xar 18.07.19 - 20:38

    derh0ns schrieb:
    --------------------------------------------------------------------------------
    > Xar schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > nikeee13 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Wenn OkHTTP schon DoH kann, wird es nicht lange dauern, bis jedes
    > > > Android-Werbewidget den DoH-Resolver vom Werbetreibenden nimmt.
    > >
    > > Und wo ist der Unterschied zu jetzt? Jede App könnte einen bestimmten
    > > DNS-Resolver hardcoded ansprechen.
    >
    > Momentan kann ich aber über mein VPN alle anfragen an UDP port 53 auf
    > meinen DNS server umleiten ob die app das will oder nicht, wenns
    > verschlüsselt ist geht das nicht mehr.

    Und wenn eine App DNS nicht über UDP+Port 53 macht? Hat schließlich nie jemand behauptet, dass es das feste Grenzen gibt, was geht und was nicht.

  19. Re: RIP DNS-Based Ad Blocking

    Autor: Gole-mAndI 18.07.19 - 20:46

    Xar schrieb:
    --------------------------------------------------------------------------------
    > derh0ns schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Xar schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > nikeee13 schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Wenn OkHTTP schon DoH kann, wird es nicht lange dauern, bis jedes
    > > > > Android-Werbewidget den DoH-Resolver vom Werbetreibenden nimmt.
    > > >
    > > > Und wo ist der Unterschied zu jetzt? Jede App könnte einen bestimmten
    > > > DNS-Resolver hardcoded ansprechen.
    > >
    > > Momentan kann ich aber über mein VPN alle anfragen an UDP port 53 auf
    > > meinen DNS server umleiten ob die app das will oder nicht, wenns
    > > verschlüsselt ist geht das nicht mehr.
    >
    > Und wenn eine App DNS nicht über UDP+Port 53 macht? Hat schließlich nie
    > jemand behauptet, dass es das feste Grenzen gibt, was geht und was nicht.

    Da der App Entwickler und der Werbedienstleister normalerweise zwei unterschiedliche Unternehmen sind (außer es ist Google) kann ich den Traffic des Werbemülls trotzdem wegblocken und der App Traffic geht durch.
    Ein DNS konformes Packet lässt sich trotzdem erkennen. (Ohne DoH)

    Und bei den Anwendungen die ich so nutze ist mir das Problem noch nicht untergekommen. Ok die Gmail App Werbung werde ich nicht los...aber die hat mit diesem Problem eher weniger zu tun.



    1 mal bearbeitet, zuletzt am 18.07.19 20:47 durch Gole-mAndI.

  20. Re: RIP DNS-Based Ad Blocking

    Autor: treysis 18.07.19 - 20:49

    nikeee13 schrieb:
    --------------------------------------------------------------------------------
    > Und das ganze geht auch nur, wenn die IP für den DoH-Server eine andere
    > ist, als die, wo Content liegt, den man haben will. Ich kann mir z.B. gut
    > vorstellen, dass Google bei YT einen DoH-Server einfach auf die selbe IP
    > legt, auf der auch z.B. der Youtube-Inhalt liegt. Da reicht dann schon auch
    > keine simple Firewall mehr. Da braucht man schon DPI. Und das geht auch
    > nur, wenn kein Cert-Pinning gemacht wurde. Und ob ich DPI auf einem Pi
    > machen würde ist noch Mal eine andere Frage.

    Das macht YT doch jetzt schon: Werbung kommt von den gleichen Servern, wie die Inhalte. Deswegen kannst du mit PiHole auch keine YT-Werbung mehr blocken.

    Davon abgesehen kann auch jetzt schon jeder App-Anbieter über HTTPS eine Anfrage an seine Server schicken, die ihm eine Adresse in eine IP auflöst. Muss ja nicht das DoH-Protokoll sein.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hong Kong Economic and Trade Office, Berlin
  2. INSYS MICROELECTRONICS GmbH, Regensburg
  3. BWI GmbH, Meckenheim
  4. IGEL Technology GmbH, Augsburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,99€
  2. 4,99€
  3. (-87%) 1,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Smarte Wecker im Test: Unter den Blinden ist der Einäugige König
Smarte Wecker im Test
Unter den Blinden ist der Einäugige König

Einen guten smarten Wecker zu bauen, ist offenbar gar nicht so einfach. Bei Amazons Echo Show 5 und Lenovos Smart Clock fehlen uns viele Basisfunktionen. Dafür ist einer der beiden ein besonders preisgünstiges und leistungsfähiges smartes Display.
Ein Test von Ingo Pakalski

  1. Nest Hub im Test Google vermasselt es 1A

OKR statt Mitarbeitergespräch: Wir müssen reden
OKR statt Mitarbeitergespräch
Wir müssen reden

Das jährliche Mitarbeitergespräch ist eines der wichtigsten Instrumente für Führungskräfte, doch es ist gerade in der IT-Branche nicht mehr unbedingt zeitgemäß. Aus dem Silicon Valley kommt eine andere Methode: OKR. Sie erfüllt die veränderten Anforderungen an Agilität und Veränderungsbereitschaft.
Von Markus Kammermeier

  1. Arbeit Hilfe für frustrierte ITler
  2. IT-Arbeitsmarkt Jobgarantie gibt es nie
  3. IT-Fachkräftemangel Freie sind gefragt

Hyundai Kona Elektro: Der Ausdauerläufer
Hyundai Kona Elektro
Der Ausdauerläufer

Der Hyundai Kona Elektro begeistert mit Energieeffizienz, Genauigkeit bei der Reichweitenberechnung und umfangreicher technischer Ausstattung. Nur in Sachen Emotionalität und Temperament könnte er etwas nachlegen.
Ein Praxistest von Dirk Kunde

  1. Elektroauto Neuer Chevrolet Bolt fährt 34 km weiter
  2. Elektroauto Porsches Elektroauto Taycan im 24-Stunden-Dauertest
  3. Be emobil Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt

  1. UMTS: 3G-Abschaltung kein Thema für die Bundesregierung
    UMTS
    3G-Abschaltung kein Thema für die Bundesregierung

    Nutzer, die kein LTE in ihren Verträgen festgeschrieben haben, sollten wechseln, da 3G zunehmend abgeschaltet werde. Das erklärte das Bundesverkehrsministerium und sieht keinen Grund zum Eingreifen.

  2. P3 Group: Wo die Mobilfunkqualität in Deutschland am niedrigsten ist
    P3 Group
    Wo die Mobilfunkqualität in Deutschland am niedrigsten ist

    Die Qualität des Mobilfunks in Deutschland ist in den einzelnen Bundesländern sehr unterschiedlich. Dort, wo Funklöcher gerade ein wichtiges Thema sind, ist die Versorgung gar nicht so schlecht.

  3. Mecklenburg-Vorpommern: Funkmastenprogramm verzögert sich
    Mecklenburg-Vorpommern
    Funkmastenprogramm verzögert sich

    Wegen fehlender Zustimmung der EU ist das Geld für ein Mobilfunkprogramm in Mecklenburg-Vorpommern noch nicht verfügbar. Dabei hat das Bundesland laut einer P3-Messung große Probleme.


  1. 18:00

  2. 18:00

  3. 17:41

  4. 16:34

  5. 15:44

  6. 14:42

  7. 14:10

  8. 12:59