ZensurUeberwachung

Aus Wiki gegen Netzzensur
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Zusammenfassung

Um zu überprüfen, welche Seiten in Deutschland gesperrt/zensiert sind, sind Tests nötig. Da jedoch der Zugriff auf eine gesperrte Seite strafrechtlich verfolgt werden kann, muss die Überprüfung ohne den eigentlichen Zugriff geschehen. Dies ist technisch möglich.

Auf dieser Seite werden nun Ideen und Anregungen gesammelt, um diese Komponente zu implementieren.

Bitte beachtet auch den Vorschlag der Diskussionsseite. --Joachim 21:12, 18. Mai 2009 (UTC)

Vorschlag in Stichpunkten

  • Firefox-Plugin bzw. Proxy als Kinderschutzfilter
    • Kinderschutzfilter? Die Argumentation ist mir nicht klar. -- Patrick
    • Sorry, meine Liebe für Doppeldeutigkeiten. Zum einen läßt sich ein Kinderschutzfilter besser "verkaufen" (GPL!) als ein censor filter. Machen wir einfach zwei Versionen ;-) Der Filter kann so oder so genutzt werden. Aber letztlich soll der Filter dazu führen, dass wirklich gegen Verursacher vorgegangen wird - ironischerweise mit den Mitteln der Zensoren selbst. --Joachim 22:29, 13. Mai 2009 (UTC)
  • Keine Speicherung von URL's und IP's.
  • Hashcodes und Positiv/Negativlisten
  • kein zentraler Server
  • Heuristiken zur Erkennung "verdächtiger" Seiten (ohne Zugriff darauf!),
 die Entscheidung aber behält der Benutzer. Es wird nichts umgangen!
  • p2p Verbindung (Kademlia) der Plugins untereinander
    • udp basiert (weniger Probleme mit Firewalls).
    • vielleicht ein alternativer, p2p basierter DNS-cache
  • Auswertung weiterer DNS-Server oder auch rekursiver dnslookup

Meta-Ideen und mögliche Konsequenzen

Zum Mitdenken:

Benutzer des Plugins bewerten Seiten im Internet. Der Browser kann bei einer negativen Bewertung eine Warnung anzeigen.

Findet der Benutzer versehentlich illegale Inhalte, so könnte das Plugin anbieten einen takedown request zu versenden oder unrechtmäßig gesperrte Seiten anprangern. Letzteres wäre natürlich nur dann möglich, wenn der Benutzer einen alternativen DNS verwendet. Dagegen kann das Plugin aber nichts tun. Immerhin warnt es den Benutzer trotzdem.

Somit könnte der Nachweis erbracht werden, dass die Stoppliste keine Seite unrechtmäßig sperrt.

Falls das doch ausnahmsweise einmal nicht der Fall wäre, dann hätte das BKA die Möglichkeit zu korrigieren oder die Sperrlisten zu entschlacken:

Denn jemand, der die Sperrliste kennt (BKA, Provider) könnte das Plugin mit den gesperrten Seiten füttern und auf die Bewertungen achten. Fehler fallen dann auf. Natürlich bleiben die Einträge der Liste geheim. Keine URL verläßt den prüfenden Rechner!

Um das zu unterstützen gibt das Plugin die Anzahl der nicht negativ bewerteten, aber gesperrten Seiten aus. Es wäre kostengünstig eine BKA-Version des Plugins denkbar.

Dazu müssen keine URLs veröffentlicht oder gespeichert werden.

Das Plugin könnte also legal und ungefährlich helfen "böse" Seiten aus dem Internet verschwinden zu lassen, menschliche Fehler der Mitarbeiter des BKA zu korrigieren und den Nutzer vor zweifelhaften Inhalten transparent schützen.

Ein Missbrauch ist dank der verwendeten Hashcodes nicht möglich.

Dies alles in der Hoffnung, dass so keine illegale Seite im Internet mehr übrig bleibt...

Moralische Aspekte

  • Der Beigeschmack des "wir verbessern dadurch den Zensur-Mechanismus, da mit diesem Tool fälschlicherweise gesperrte Seiten aufgespürt werden können" ist etwas unangenehm. Es könnte den Anschein erwecken, als hätten wir uns schon mit der Zensur "abgefunden". Außerdem könnte es auch zu "wenn die Nutzer sich ohnehin beschweren, wenn eine falsche Seite drauf ist, ist das ja auch nicht so schlimm" werden. Mir gefällt auf jeden Fall die Überprüfung, ob eine Seite gesperrt ist VOR dessen Aufruf. Weiterhin ist der takedown-request eine gute Idee. (unter der Voraussetzung, dass die Seite dann vom Netz genommen und nicht in die Sperrliste aufgenommen wird.) Wenn Seiten gefunden werden, die dort nicht hingehören, wäre es allerdings am "medienwirksamsten", wenn diese konsequent veröffentlicht werden. Eine öffentliche Liste von unrechtmäßig gesperrten Seiten. Das kollidiert natürlich mit der Anonymität der Nutzer, schon klar. Ein genaues Konzept fehlt mir noch. Eine aktive Hilfe zur Verfeinerung der Sperrliste ist mir nach wie vor unsympathisch. -- Patrick

Hi Patrick, ich denke, wir sind uns letztlich einig :)

Doch es stimmt. Wenn das BKA wie angedeutet reagiert, dann wird das die Liste des BKA verbessern, falls sie ehrlich sind. Wenn nicht, dann wird das Programm es ermöglichen ihnen die Hosen runter zu lassen.

Das Programm ist aber nicht in der Lage, selbst unter Gewaltandrohung nicht, zu sperrende URLs mitzuteilen, denn das könnte missbraucht werden.

Der Plan ist eine mathematische win/win Situation erzeugen - falls genügend Nutzer (einige 100) mitmachen.

Zensoren könnten das Plugin ignorieren. Das Programm wird dann mit Hilfe der Nutzer die Fehler der Zensoren nachweisen. Sie können das verhindern, indem sie das Programm selbst nutzen. Damit füllen Sie die Hashlisten. Sie können ehrlich sein und ihr Möglichstes tun. Dann füllen die Nutzer die Hashlisten, weil die Sperren (fast) alleine durch ihre Existenz erkannt werden. Sie können tun und lassen, was sie wollen, unsere Listen werden sich füllen. Jeder Hasheintrag aber macht die Sperrliste ein wenig mehr absurd und wirkungslos. Nur durch Abschaltung der Sperrungen läßt sich das verhindern. Damit bin ich einverstanden, denn dann müssen sie endlich wirklich gegen die Verursacher vorgehen.

Jede Fehlsperrung zählt das Programm mit und macht die absolute und prozentuale Anzahl jedem bekannt.

Folge: niemand wird mehr auf den Stoppseiten landen und den Zensoren wird das zu zensierende ausgehen. In den Sperrlisten wird nur noch das verbleiben, auf das niemand mehr stößt. Die Sperrlisten werden leer oder unbrauchbar sein. Genau das erkennt das Programm. In diesem Fall muß das Zensursystem abgeschaltet werden, weil es dann keine Rechtfertigung mehr gibt.

Die einzige wirkliche Kritik IMHO ist: es könnte eine Strafverfolgung verhindert werden. Doch das ist bei den Zensurversuchen systemimmanent und nicht die Schuld des Programms. Und Pädophile, die das Programm nutzen, um sich selbst zu schützen werden sich selbst die Quellen entziehen.

Die einzige Möglichkeit ist es das Programm zu verbieten. Es "hackt" aber nicht, es kennt keine illegalen Seiten, es unterstützt genau die Dinge, die unsere Politik fordert. Man beachte die teilweise absurd wirkenden Ideen aus #Meta-Ideen und mögliche Konsequenzen. Jeder Verbotsversuch wäre einfach genau so absurd. Es gibt hunderte solcher Filterprogramme. Dafür, dass die "Quatsch" sind kann ich ja nichts.

Die Zensur wendet sich gegen sich selbst. Und niemand kann dagegen etwas tun. Das ist einfach ein Naturgesetz. (Wenn ich mich nicht irre)

--Joachim 21:36, 13. Mai 2009 (UTC)

  • Ok, alles klar. Ich denke, man muss einfach mal schauen, wie es sich entwickelt. --Patrick 07:20, 14. Mai 2009 (UTC)

Funktionsweise umgangssprachlich

  • Der Zusammenhang "Bewerten" - "Keine URL verlässt den PC" - "Hashcodes" ist mir noch nicht so ganz klar. Die Bewertung wird also auf einem zentralen Server gespeichert, allerdings nicht unter der URL, sondern unter "md5(URL)". Die Prüfsumme wird auf dem PC berechnet. Ist das so in etwa richtig? -- Patrick

Das geht ungefähr so: Der Nutzer klickt einen Link an. Der Link wird vom Proxy in einen Hash (nicht md5, doch ähnlich) gewandelt und in einer Sperrlistentabelle und in einer Bewertungstabelle gesucht. Wird er gefunden, so werden die entsprechenden Infos dem Nutzer mitgeteilt.

Wird er nicht gefunden, so wird zunächst eine Plausibilitätskontrolle vorgenommen. Die Ziel-IP wird beim Provider-DNS abgefragt. Ist das eine bekannte Stoppseite, so wird der Hashcode der Sperrlistentabelle hinzugefügt. Es gibt Möglichkeiten festzustellen, ob IP und URL plausibel sind ... und entsprechend reagiert. Notfalls erhält der Benutzer eine private (lokale) Stoppseite.

Der Benutzer hat immer die Möglichkeit die aktuelle Seite zu bewerten. Vermutlich wird es dazu nur ein Punktesystem und keinen freien Text geben. Text könnte gefährlich sein.

Die Hashlisten werden aktiv und anonym im p2p-Netz verteilt. Dank Kademlia gibt es dazu effiziente Algorithmen. Jede Kommunikation zwischen p2p Partnern erfolgt verschlüsselt.

Es gibt also keinen zentralen Server! Allerdings muß es eine Möglichkeit geben dem Netz beizutreten. Entweder werde ich bei diversen p2p-Netzen schnorren. Alternativ könnte ein geschickter Gebrauch von DynDns.org helfen (wenn deren Nutzungsregeln das erlauben). Notfalls wird ein Portalserver eingerichtet, der nur den Zugang bereit stellt und sonst keine Informationen, die nicht auch jeder Client hat, speichert.

Noch Fragen?

  • Erst mal nicht. Die kommen aber sicher später noch :-) --Patrick 07:15, 14. Mai 2009 (UTC)

Technische Ideen DNS-Manipulationen zu erkennen

  • DNS Abfragen werden an 2 bis n DNS-Server geschickt, von denen mindestens einer nicht die Sperrliste führt. Das kann mit der Methode auf der Diskussionsseite geschehen.
  • Die Antworten werden abgeglichen und bei Differenzen eine Warnung ausgegeben, ob der Vorgang wirklich fortgesetzt werden soll.
  • Die DNS-Caches der Pluginrechner könnten ausgetauscht werden.
  • Eine .com URL, die zum lokalen Provider in de führt ist verdächtig.
  • Die IP-Adressen der Stoppseiten werden durch das Plugin bekannt. Damit wird eine Fälschung auch ohne DNS-Abgleich erkannt.

Hört sich gut an. Keine Einwände. --Patrick 07:22, 14. Mai 2009 (UTC)

  • Irgendwann mal: Überprüfung der DNSSEC-Signatur. Da diese Signierung von der darüberliegenden Zone (z.B. .com) durchgeführt wird, kann ein deutscher Provider sie nicht anpassen. Die verdächtigen DNS-Einträge werden also nicht signiert sein - richtig?

Zu DNSSEC: richtig (IMHO). Doch könnte es sein, dass der Provider DNSSEC gar nicht zugänglich macht. Und er könnte den DNS-Port sperren. Damit muss das Plugin zurecht kommen. --Joachim 22:33, 13. Mai 2009 (UTC)

Sich als Provider gegen DNSSEC zu sperren, ist IMHO eine folgenschwere Entscheidung. DNSSEC wird (irgenwann) weltweit eingesetzt, nur wir nutzen es nicht, weil unser total sinnfreies Zensursystem damit kollidiert. --Patrick 07:14, 14. Mai 2009 (UTC)

Mögliche Komponenten einer Software

  • GUI. XUL - wer kennt sich da aus?
  • Proxy - code exemplarisch vorhanden.
  • Erkennungsheuristik für Sperren - wir sammeln hier die Ideen
    • Differenzen zwischen Zoneneinträgen in verschiedenen DNS-Servern
    • .com-Zone bei lokalem Provider (Aber: Was ist, wenn der Provider-DNS "cached" und z.B. die IP von google.com direkt - ohne Rückfrage - zurückgibt?)
      • verstehe ich nicht. Ein DNS cached immer. Meinst Du einen Provier-Proxy? Der gibt die Seite für die echte Seiten-URL zurück. Der Client benötigt keinen DNS mehr (oder?) --Joachim 12:07, 14. Mai 2009 (UTC)
      • Mmh...war etwas schlecht formuliert. Letztlich ist nur der Vergleich der Antworten der versch. DNS-Server das richtige Mittel, um eine Sperrung aufzudecken. --Patrick 18:00, 14. Mai 2009 (UTC)
    • Die vom Provider-DNS gelieferte IP ist eine bereits aufgedeckte Stopp-Seite (wird nicht lange dauern)
  • Benutzergesteuertes Bewertungssystem - Ideen?
    • Zwei "Teile": 1) Eine Seite ist gesperrt. Korrekt oder nicht? 2) Eine Seite ist nicht gesperrt. Korrekt oder nicht?
    • Zwei Teile reichen nicht, wenn möglichst viele das Plugin nutzen sollen(!?!). Es sollte möglich sein für alle Seiten gestaffelte Bewertungen abzugeben. Vielleicht: geeignet für Kinder, Jugendliche, Erwachsene, eine Note (1-6), lehrreich, spaßig, gefährlich, Viren und Trojaner, kommerziell, illegal, gesperrt. Aber: keep it super simple.
    • Ok, dein Rahmen ist etwas größer :-). --Patrick 18:00, 14. Mai 2009 (UTC)
    • IMHO bewertet Google Seiten auch und gibt Listen an Firefox. Kann man sich da rein hängen um eine Basisbewertung zu haben?
  • verteilter DNS-Server - wer kennt sich aus?
    • kann der tor-DNS sinnvoll mitverwendet werden?
    • Das Plugin muß keinen DNS zur Verfügung stellen. Aber es kann trotzdem Adressen cachen und mit p2p-Partnern abgleichen. Alternativ könnte man sich z.B. Dnsmasq einmal ansehen.
  • Lowlevel p2p Code,
    • [Kademlia] (existent), Einstieg in das Netz (Ideen vorhanden), Firewallumgehungscode (vorhanden, doch von einigen Entscheidungen abh.),
  • Hashcodes - SHA-xxx vorhanden
  • Hashlistenverwaltung - ist relativ einfach / nope siehe #Hash und Tabellen
  • Protokolle zum Abgleich der Listen und Bewertungen - nur Arbeit, doch sehr wichtig!
  • Verschüsselung der p2p Kommunikation - AES ist vorhanden.

Programmiersprache

Wie sieht das bei der Software mit der Programmiersprache aus? (XUL für die GUI - was für den Rest?)

Javascript auf der Firefoxseite (natürlich). C(++) wegen vorhandemen Code (wie Proxy usw) und wegen der Effizienz. Ist mein Vorschlag. --Joachim 11:48, 14. Mai 2009 (UTC)

Ja, ist ok. --Patrick 18:00, 14. Mai 2009 (UTC)

Nachdem ich mir nun Adblock Plus einmal angeschaut habe, halte ich es für möglich einen sehr einfachen Blocker dort zu integtegrieren. Sprache javascript. Vielleicht sollte das Version 0.1 sein. --Joachim 11:52, 16. Mai 2009 (UTC)

Hash und Tabellen

  • Bereits in der Mailingliste angesprochen: Wie werden die Seiten gehasht?
    • URL ohne Parametern? Bei TinyUrl z.B. 1 Hash für n Seiten.
    • URL mit Parametern? SessionID als Parameter verfälscht den Hash => n Hashs für die gleiche Seite.
    • mit www / ohne www etc. verfälschen ebenfalls den Hash => n Hashs für die gleiche Seite.
    • FQDN => 1 Hash für n Seiten.

Benötigte Tabellen

Hashcodes sind AES-256 (oder AES-512)?

Hashcodes von URLs
Parameter werden immer angeschnitten => Hash der FQDN
Hostname => hash des Hostname
Tabellen
Stopp-IPs
Stopseiten-IP
Mastertable
hostname
FQDN
Bewertungstabelle
hostname
FQDN
rating
date
Stopptable
hostname
Stopp-IP

(wird noch erklärt werden) --Joachim 22:45, 14. Mai 2009 (UTC)

Meine Werkzeuge
Namensräume
Varianten
Aktionen
Navigation
Werkzeuge