Kulturflatrate und Datenschutz

Aus Piratenwiki Mirror
Zur Navigation springen Zur Suche springen

Dieses Text beschäftigt sich mit dem Datenschutzaspekt der Kulturflatrate (kurz KFR).

Gliederung

Technik der Kulturflatrate etwas detaillierter; eine Möglichkeit:

Zur Zählung der Downloads werden Programme ausgegeben wie es bei SetTop-Boxen für Fernseher funktioniert. Etwa 10.000 sollten es sein.

Die Personen, die sie benutzen werden zufällig, aber Personengruppen ausgleichend verteilt. (d.h. repräsentativ. Also sollte zum Beispiel die Zahl allein Erziehende Mütter mit Statistik-Programm im Vergleich zu Familien mit Prog. ihrem Anteil an der Gesellschaft entsprechen)

Die Statistikprogramme zählen alle Up- und Downloads mit, und sie loggen die Nutzung durch denjenigen der es nutzt (um Betrugsversuche zu vermeiden). Illegale Inhalte werden die Leute sich also über andere Programme holen.

Daten, die von den _Programmen_ erhoben werden, sind:

- Dateiname 
- Hash 
- Metadaten (falls vorhanden) 
- IP:Port, durch schwachen Hash verdeckt (selbst hinter einem NAT gibt es das Paar pro p2p-App nur einmal) 

Bevor sie an einen Server geschickt werden, wird ein kryptographisch schwachen Hash über IP:Port gejagt, so dass sie nicht mehr zurückrechenbar sind. Da IP:Port eine riesige Anzahl an Variationen bietet, kann es auch Brute Force nur sehr schwer herausgefunden werden. (Bei IPv4 sind das 270 Billionen Möglichkeiten, weniger wenn du nur auf Deutsche IPs prüfst, aber da der Hash schwach ist, gibt es mehrere Kombinationen, die den gleichen Hash ergeben (aber sehr unwahrscheinlich zur gleichen Zeit auftreten, also auch die Statistik kaum verfälschen, weil ein p2p Programm meist nur einen von 64000 möglichen freien Ports nutzt)).

Jetzt werden die Dateien auf den Server geschickt (mit der ID des Statistikprogrammes) und gegen eine Liste von registrierten Werken geprüft (Künstler können ihre Werke registrieren. Bei der Vergütung werden nur registrierte Werke berücksichtigt). Dafür brauchst du Leute, aber wohl weit weniger als die Gema hat, und sobald du einen Datei-Hash zugeordnet hast, musst du ihn kein zweites Mal zuordnen.

Dann wird eine Statistik über die Künstler erstellt, wieviele Werke des jeweiligen Künstlers in einem Jahr heruntergeladen werden. In diese Statistik kommen dann Schlüssel, die beispielsweise eine komplette Diskographie höher werten als ein einzelnes Lied, und auch die Medientypen können gegeneinander abgewogen werden.

Die Bedingung, wie genau diese Statistik sein muss, ist nun, dass jeder Künstler, dessen Werke genug am Download ausmachen, dass er einen signifikanten Betrag aus dem Topf bekommen würde, eine Sicherheit von 90% haben muss, in einem gegebenen Jahr auch erfasst zu sein. Darunter ist es einfach Glückssache, mittelt sich über die Jahre aber raus.

Meine persönliche Grenze, ab wann ein Künstler diese Sicherheit haben sollte, wäre 200€ im Jahr, was aber auch auf 1000€ hochgebracht werden kann, wenn ansonsten das Erfassen zu schwierig wäre.

Das hieße bei 200€, dass er einen Anteil von einem Zehnmillionstel der Downloads erreicht (bei 2 Milliarden € Gesamttopf). Unter 10 Millionen Downloads sollte also seine Datei einmal dabei sein.

Unter 200€ wird nichts ausgeschüttet, was die Statistik leichter macht.

Sollte ein Nutzer eines Statistikprogrammes (der es freiwilig nutzt und auch weiß, dass sein Programm Statistiken sendet) versuchen zu manipulieren, werden die Daten von seinem Programm sehr signifikant von denen von anderen abweichen, so dass zumindest ein Verdacht vorliegt, dass er manipuliert, und der Verdacht geprüft werden kann.

Es wird pro Internetverbindung gezahlt. 5€ auf eine aktuelle DSL-Flatrate.

Die Verbindung von Statistikprogramm zum Server wird durch einfache GnuPG Verschlüssellung gesichert (Oder andere entsprechend sichere Systeme).

Anmerkungen:

  • Es gibt in diesem Entwurf keine Hardwarekomponente.
  • Zur Erstellung der Statistik und um Manipulationsversuche erkennen zu können, werden Daten über die repräsentativ ausgewählten Nutzer der Statistiksoftware gespeichert, die der Erhebung und Speicherung dieser Daten zustimmen, bevor sie die Statistiksoftware erhalten (ansonsten wird einfach jemand anderes gewählt). Sie sind die einzigen Nutzer, deren Daten zuordnebar sind. Die Nutzung dieser Daten wird zweckgebunden sein, also nur für die Statistik und die Entdeckung von Betrugsversuchen genutzt werden dürfen.

ArneBab 00:16, 25. Okt 2006 (UTC)

Mögl. Kritik an der KFR bzgl. Datenschutz:

Wenn diese Variante auch keine persönlichen Daten erhebt, so erhält der Server die Daten eines Haushaltes, der zu statistischen Zwecken auserwählt wurde und das auch noch langfristig. Die Daten, die gespeichert werden können sind die IP der TCP/IP Verbindung des Clients mit dem Server in Klartext und nicht gehasht, Downloadgewohnheiten und die ID der Software.

Über diese Software ID, die dazu dient, Manipulationen zu verhindern/ aufzuspüren, sind die Daten solange den statistisch ausgewählten Haushalten zuzuordnen, wie es Unterlagen (digitale Daten oder in Papierform) darüber gibt, welcher Haushalt welche Software mit entsprechender ID bekam. Diese Daten fallen an und es hängt von den entsprechenden Stellen ab, wann diese unterschiedlichen Daten gelöscht werden.

Diese Nutzer sind die einzigen, über die es zuordnebare Daten gibt, und es werden nur Nutzer sein, die in voller Kenntnis der Sachlage ihre Erlaubnis dazu geben. -ArneBab 12:14, 25. Okt 2006 (UTC)

Die Software überträgt die Daten über das Internet und dies darf nur abhörsicher geschehen, was unmöglich ist, da mit konstant ansteigender Rechenleistung und Know How in der Wissenschaft nur jeweils aktuelle Methoden nicht gehackt werden können.

GnuPG kann seit Jahren nicht in irgendeiner annehmbaren Geschwindigkeit gehackt werden. -ArneBab 10:06, 25. Okt 2006 (UTC)

Demzufolge müsste diese Software modular aufgebaut sein und über einen eigenständigen Updater aktualisiert werden können, was eine neue Sicherheitslückenmöglichkeit auf Softwareebene anbietet oder falls die Software von einem Supporter vor Ort aufgespielt wird, eine menschliche Sicherheitslücke implementiert. Abgesehen davon müssen ebenfalls hacksichere Lösungen gefunden werden, den Updater zu aktualisieren, ohne neue Angriffsflächen zu bieten, falls ein Updater oder eine Updatefunktion implementiert wird.

Das Problem hast du auch in jeder Bezahlsoftware. Und diese Systeme gibt es bereits und sie funktionieren. -ArneBab 10:06, 25. Okt 2006 (UTC)

Die Software muss auf allen Rechnerplattformen und internetfähigen Geräten sicher laufen, was gleichzeitig bedingt, dass es keinerlei Fehler in der Hardware gibt, die über Softwareangriffe ausgenutzt werden können. Dazu gab es in der Vergangenheit genug Beispiele, das dies nicht möglich ist (Stichwort Intel Pentium Gleitkommafehler 1994).

Siehe vorheriger Absatz. -ArneBab 10:15, 25. Okt 2006 (UTC)

Die jeweiligen Betriebssysteme und Anwendungsprogramme, die nichts mit der KFR zu tun haben, müssen unhackbar sein. Die KFR Supporter müssen also auch z.B. eine installierte Windowsversion unhackbar bekommen. Siehe dazu vor allem Windows Vista, wo es explizit verboten ist, Workarounds zu implementieren. Dies ist nur die Clientseite. Entsprechende Probleme liegen ebenfalls auf Serverseite vor.

Siehe vorheriger Absatz. -ArneBab 10:15, 25. Okt 2006 (UTC)

Intel Pentium Rechenfehler:

http://www.uni-lueneburg.de/infu/pdf/24_04.pdf

Windows Vista:

http://download.microsoft.com/documents/useterms/Windows%20Vista_Home%20Basic_English_6d3e0409-7a2c-4239-b850-d41210b71b13.pdf

     SCOPE OF LICENSE: - work around any technical limitations in the software.

Fehleranfälligkeit von GnuPG exemplarisch:

http://lists.gnupg.org/pipermail/gnupg-announce/2006q3/000229.html

     * Fixed 2 more possible memory allocation attacks.  They are
     similar to the problem we fixed with 1.4.4.  This bug can easily
     be be exploited for a DoS; remote code execution is not entirely
     impossible.