Diskussion:Kulturflatrate und Datenschutz

Aktive Diskussionen
Version vom 11. Dezember 2010, 16:28 Uhr von imported>Wiskyhotel (→‎Vorschaufunktion: Bugfix)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Moin,

es fehlt der Punkt über die Kritik an der Datenschutztauglichkeit der KFR. Da ich mich mit der Wiki Software nicht gut genug auskenne, möchte ich einen Fähigen bitten, meine nun folgenden Kritikpunkte aufzunehmen. Sonst muß ich mich da irgendwann mal durchbeißen. Danke.

/edit by elcon: habe das selber eben eingebaut und auch eine Gliederung versucht.

cu

elcon

@ArneBab:

Ich dachte, diese Site hier ist zum Diskutieren. Es macht wenig Sinn, wenn jeder im Text des anderen schreibt. Mach einen Absatz zu den Punkten, wobei du meine Sätze so umbauen kannst, daß sie in einzelne Punkte zerlegbar sind und gebe dann die Gegendarstellung an.

Elcon 10:08, 25. Okt 2006 (UTC)


Genau das ist nicht die Art, wie in Wikis diskutiert werden muss. Ein schöner Punkt an Wikis ist, dass hier Punkte direkt widerlegt werden können, statt dass man ewige Tiraden schreiben muss um zu sagen, an welchem Punkt man gerade ansetzt.

Aber da dir das im Hauptartikel anscheinend nicht gefällt, poste ich den gesamten Artikel hier in die Diskussion, dann kannst du nach Herzenslust und ohne schlechtes Gewissen in den Text schreiben, solange deine Kommentare nicht das Format einer vollständigen Gegendarstellung haben.

Übersicht

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 (selbst hinter einem NAT gibt es das Paar pro p2p-App nur einmal) 

Bevor sie jetzt 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 (die Künstler registrieren ihre Werke. Wer es nicht registriert hat auch keine Chance auf Geld). 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).

Es gibt keine Hardwarekomponente.

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

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

Wenn diese Variante auch keine persönlichen Daten über jegliche Nutzer erhebt, so erhebt sie doch die Daten genau der Haushalte, die die Statistiksoftware nutzen, und das auch noch langfristig. Diese Daten sind die IP, Downloadgewohnheiten und die ID der Software.

Über diese Software ID sind die Daten solange dem Haushalt zuzuordnen, der die Statistiksoftware nutzt, 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.

Die Software überträgt die Daten über das Internet und dies darf nur abhörsicher geschehen, was unmöglich ist, da mit konstant ansteigender Hardwareleistung (Stichwort Cluster (das neue Buzzword heißt Grid :) -ArneBab)) 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).

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

Das Problem hast du auch in jeder Bezahlsoftware. Und diese Systeme gibt es bereits und sie funktionieren. -ArneBab 10:06, 25. Okt 2006 (UTC)
Bezahlsoftware kann ich aber vermeiden indem ich sie nicht kaufe. -JollyOrc 11:06, 26. Okt 2006 (UTC)
Ein Statistikprogramm musst du auch nicht nutzen. Das werden nur einige repräsentative Nutzer tun. Die Sicherheit der Daten der anderen Nutzer hängt nicht an der Verschlüsselung. Und ich meine mit Bezahlsoftware beispielsweise Software um eine Banktransaktion zu tätigen. -ArneBab 12:28, 26. 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.


Eine Lösung diverser Kritiken

Dongles und USB-Sticks mit ROM-Software

Aloa5 11:22, 25. Okt 2006 (UTC)

Diskussion über Kritik an dem Modell

folgende Änderungen durchgeführt:

1. bei "Haushalten" darauf nun hingewiesen, daß nur die statistisch ausgesuchten Haushalte gemeint sind. Vielleicht überprüfst du deine ersten Kommentare daraufhin noch einmal.

2. Cluster gegen Grid ausgetauscht. Auch hier bitte deinen entsprechenden Kommentar überprüfen.

Grid ist genauso wie Clustercomputing ein Buzzword, also eigentlich unnötig zu schreiben. Es ist sinnvoller einfach nur von größerer Rechenleistung zu sprechen :)
Der Kommentar war nicht ganz ernst gemeint... -ArneBab

3. Link zu GnuGP gesetzt und Zitat mit Ausführen von Fremdcode gebracht.

Ansonsten:

4. Die IP wird übertragen. Das ist notwendig bei TCP/IP. Also was soll der Kommentar?

"(allerdings als nicht eindeutig zuordnebaren schwachen Hash -ArneBab), "

Das heißt schlicht und einfach das, was im Text dazu geschrieben steht: Es wird ein schwacher Hash über IP:Port (und eventuell: IP:Port/Programm-ID) gejagt, so dass zwar eine Unterscheidung der Programme, aber keine Zuordnung mögl. ist, zumindest über leute, die nicht die Statistiksoftware nutzen (habe ich im Text erklärt). -ArneBab

5. Allerdings nicht in dem vorgestellten Entwurf, ansonsten würde sie in den Hash einbezogen. Die Einzigen, deren Daten zugeordnet werden können sind die Haushalte, die Statistikprogramme haben, und da ist das auch erwünscht, um Manipulationsversuche zu erkennen. -ArneBab 10:06, 25. Okt 2006 (UTC)

Das das gegen Manipulationsversuche eingesetzt wird, gehört in deinen Thread. Das mit den Haushalten habe ich bereits korrigiert.

ist in den Anmerkungen

6. Wie im vorherigen Absatz geschrieben, gibt es diese Daten hier nicht. -ArneBab 10:06, 25. Okt 2006 (UTC)

Im Internet wird _immer_ die IP mitgeliefert, siehe TCP/IP. ebenso erwähnst du selber in deinem Text, daß die Statistiksoftware eine ID hat. Wird bei TCP/IP eine IP übermittelt und enthält deine Statistiksoftware eine ID? Ja oder nein?

Welche Daten machen dir jetzt Kopfschmerzen? Die über die Nutzer einer Statistiksoftware, oder die über andere Nutzer?

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

GnuPG hat seit seiner ersten Version einige Lücken für Angriffe enthalten. Alle bislang öffentlich bekannten gewordenen sind gefixt worden. Siehe dazu auch den Link, den ich angebracht habe. Eine Software gilt solange als "sicher", bis sie gehackt wird.

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

Keine wichtigen Einwände meinerseits, also stehen lassen.

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

Keine wichtigen Einwände meinerseits, also stehen lassen.

10. USB sticks, Dongles etc. : du schreibst, daß keine Hardwar eeingesetzt wird.

Bitte unterscheide die Diskussionsteilnehmer. Modelle können verändert werden, wenn es notwendig ist, um reibungsloses Funktionieren zu ermöglichen. Der einfachste Weg ist, keine Hardware zu nutzen. -ArneBab

Elcon 11:52, 25. Okt 2006 (UTC)


Änderungen am Artikel

Welche Daten machen dir Kopfschmerzen? Die über die Nutzer einer Statistiksoftware, oder die über andere Nutzer?

Da ich vermute, dass du Nutzer von Statistiksoftware meinst, habe ich den Teil entsprechend abgeändert (Grund:

elcon: 1. bei "Haushalten" darauf nun hingewiesen, daß nur die statistisch ausgesuchten Haushalte gemeint sind. Vielleicht überprüfst du deine ersten Kommentare daraufhin noch einmal.

- ArneBab 12:07, 25. Okt 2006 (UTC)

Was mir Kopfschmerzen bereitet

Ich versuche mal in eigenen Worten wiederzugeben, wie ich es verstanden habe und bringe gleichzeitig mit ein, was ich meine:

Wenn sich irgendwer am Server anmeldet, liegen seine (TCP) IP im Klartext (und IP + Port verschlüsselt) und die Software ID verschlüsselt vor, letzteres, um den Haushalt zu identifizieren, ob er überhaupt teilnimmt. Durch die Vorratsdatenspeicherung bleibt die IP eines Users über Monate beim Provider geloggt. Über die digitale oder Papierform der Zuordnung Statistikhaushalt <-> Software ID bei der KFR zentrale ist für den Zeitraum der Erhebung der Haushalt identifizierbar. Also sowohl die (TCP) IP als auch die Software ID <-> Haushalt bleiben einige/viele Monate erhalten. Dies unabhängig davon, was mit den Daten auf dem Server selber passiert, der kann IP + ID gleich wieder verwerfen und die Daten unter einer Prozeß ID in die DB speichern, also anonym. Je länger Daten rumliegen, desto wahrscheinlicher werden sie mißbraucht. Es geht hier vermutlich um die Dauer von Monaten. Was brauchst du, wenn du Manipulieren willst? Die Software ID. Wenn du wissen willst, was so alles gesaugt wird, brauchst du nur den Datenstrom zum Server (Lauschangriff von Privatpersonen/ Firmen), die Liste mit Haushalten <-> ID und hast dann einige Monate Zeit, die Verschlüsselung zu knacken. Danach weißt du, welcher Haushalt was saugte. Und noch weitere Mißbrauchfälle denkbar.

Genau das passiert nicht, weil auch die Firmen daran scheitern würden, dass IP:Port der anderen Rechner schwach gehasht sind. Um diese Daten zu kriegen, müssten sie wissen unter welcher IP welcher Port wann aktiv war, und wenn sie das schon wissen, brauchen sie die Daten nicht mehr, weil sie dann eh schon in der Iillegalität sind und auch gleich mitschneiden können (die meisten p2p-Progs identifizieren sich über genau diese Header, sagen also offen, wer sie sind. Übrigens ist auch hier das Manipulationsproblem eins, das auch jedes bereits eingesetzte Bezahlprogramm hat.

Elcon 13:30, 25. Okt 2006 (UTC)

Angriffszenario: Klub der neureichen Musikliebhaber

Folgendes Szenario nutzt keine technische Lücke des Systems aus. Es setzt vorraus das eine relativ hohe Zahl von "Meßgeräten" (wie auch immer die aussehen) existieren. Es müssen genügend sein, das Kommunikation zwischen den Inhabern der Geräte möglich ist (weil sie sich irgendwie kennen gelernt haben).

Ablauf: Treffen sich X Menschen, die alle KFR-registrierte Werke haben. Sie tauschen eine Liste dieser aus. Ggf. noch per Software modifiziert, um natürliche Zugriffsschemen zu erzeugen. Jeder läd' dann die Dateien, welche auf seiner persönlichen Liste stehen herunter. Diese Nutzergruppe puscht sich selbst und sieht dabei nicht anders aus als Vielkonsumenten. Und selbst wenn das Muster erkennbar ist: wie soll der Nachweis gerichtlich erfolgen ? Jegliche öffentliche Aktion eines solchen Musikliebhaberverreins ist legal. Nur die Gesinnung der Handlung ist sehr negativ.

  • Der Angriff ist um so effektiver, je mehr Teilnehmer der Klub hat
  • Die Vorraussetzung relativ vieler Meßgeräte ist eine weiche. Je weniger Boxen desto schwerer wird es die Kontakte zu finden,die für einen solchen Klub notwendig sind
  • Der Angriff ist besonders kritisch, wenn nur abhängig von der Zahl der Downloads und nicht nach einem System, bei dem jeder Mensch gleiches Stimmrecht hat, gewichtet werden.

Verhinderung

Bewusste Manipulationsversuche durch die Nutzer der Statistikprogramme können und sollten gesetzlich verboten werden (genau wie Nutzer von SetTop-Boxen ihren Fernseher soweit ich weiß nicht einfach Tag und NAcht anlassen dürfen).

Und falls ein gerichtlicher Nachweis nötig wird, kann wie in jedem anderen Betrugsverfahren ermittelt werden.

Falls sie eine Software nutzen, deren einziger Zweck es ist, das Abrechnungssystem zu täuschen, wäre das für ein Gericht schon ein sehr deutliches Indiz.

Schwieriger wird es. wenn das Normalnutzer machen.

Jeder Betrugsversuch muss dabei überprüft werden, ob er bei 10 Millionen Nutzern effektiv ist (bzw. hoffentlich irgendwann 40 Millionen).

Gegenargument: der Klub ist völlig legal

Das ganze ist wahrscheinlich in obiger Argumentation unter gegangen. Dem Klub der Musikliebhaber ist mit keiner Gesetz beizukommen, das nicht auch die Freiheit des Musikkonsum drastisch beschneidet. Offiziell tauschen sich die Leute nur über ihre Lieblingslieder aus. Die Intention macht das ganze Ding zum Missbrauch. Diese Intention ist aber ein innerer Wert, auf den man gerichtlich nicht schließen kann ... wenn man nicht auf die Unschuldsvermutung verzichtet.

Es sind keinerlei spezielle Programme nötig, um diese Form des Betruges durchzuführen.

Datenpreisgabe durch IP-Adressen

Die Piratenpartei ist dazu da zu verhindern das Menschen gezwungermaßen Information preis geben, die nur ihnen gehört. Dazu zählt die Auflistung ihres Medienkonsums. Eine Tabelle in der steht wer (wann?) was gelesen hat ist nicht tragbar. Existiert diese Tabelle auf einem Server 24h, so sind das 24h Zeit für jeden der mächtig genug ist, die Tabelle zu kopieren. Ein solch wertvolle Konzentration an sensiblen Daten darf garnicht erst entstehen.

Daher dürfen die Statistikprogramme IPs nur gehasht weitergeben. -ArneBab 04:56, 27. Okt 2006 (UTC)

Hash der IP-Adresse

Im Idealfall existieren 2^32, also 4 Milliarden verschiedenen IP-Adressen. Aufgrund der Aufteilung der Adressen in unterschiedlich große Blöcke und der zu größzügigen Verteilung in der Anfangszeit des Internets sind real aber weniger Adressen besetzt. Im Folgenden wird davon ausgegangen, das Deutschland 1/10 dieser IP-Adressen besitzt. Zur Identifizierung von Personen muss man praktisch wohl sehr viel weniger mögliche Adressen in einer Datenbank haben.

Bleiben 400 Millionen mögliche Hashs, zu denen man die IP nachschlagen müsste. Eine IP braucht 4 Byte. Für den Hash muss man also auch nicht mehr als 4 Byte ausgeben (sollte der Hash länger sein, dann kann man ihn ja wieder hashen um auf 4 Byte zu kommen). Wegen Memory Alignment und für Kontrollinformation veranschlage ich weitere 4 Byte. Macht 12 Byte pro Datensatz. Mit ein bisschen Kompression braucht das ganze 4 GB Ram. Da der Hash relativ gleichverteilt ist, ist die Adressierung dessen in O(1) möglich. Viele Hashs sind so gut gleichverteilt, dass man die IP-Adresse mit einem einzigen Speicherabruf heraus gefunden hat.

On-the-fly den Hash wieder in eine IP verwandeln braucht bedeutend weniger Aufwand als pro Datensatz in den KFR-Zählmaschinen betrieben werden muss und ist sogar durch einen schwachen Angreifer leicht möglich.

Einen Hash von IP+Port kann man für die meisten KFR-Messanwendungen nicht gebrauchen, weil dann ein böswilliger Nutzer einfach mehrere Ports auf einem System nutzt, um mittels Hash als mehrere Systeme erkannt zu werden. Selbst wenn der Port verwendet werden könnte, ist er in der Regel fest oder in einem sehr kleinen Sepktrum. Die Anforderung wird damit nicht wesentlich größer.

Der erste Punkt stimmt.
Der zweite Punkt allerdings nicht überall. Inzwischen verwenden z.B. die meisten Gnutella Programme einen Zufallsport.
Alternativ wäre auch ein Hash über IP+Netzwerk+Programmname+Programmversion möglich (Nutzer müssen nicht über ewige Zeit, sondern nur über einen kurzen Zeitraum unterscheidbar sein).
Da der Hash schwach ist, kommt es zwar zu ein paar fälschlicherweise als gleich gewerteten Nutzern, aber das sollte für die Statistik nicht relevant sein. -ArneBab 04:56, 27. Okt 2006 (UTC)
Spätestens ab diesem Punkt hat der Hash keinerlei Nutzen mehr, da er beliebig gefakt werden könnte. Genauer gesagt: ich sehe keinerlei identifizierenden Nutzen mehr. --Jh 20:30, 27. Okt 2006 (UTC)

Vorschaufunktion

Hallo, mir ist aufgefallen, dass Du kurz hintereinander mehrere kleine Bearbeitungen am gleichen Artikel vorgenommen hast. Es wäre schön, wenn Du in Zukunft die Vorschaufunktion benutzen würdest (siehe Bild), da bei jeder Speicherung der komplette Artikel einzeln in der Datenbank gespeichert wird. So bleibt die Versionsgeschichte für die Artikel übersichtlich und die Server werden in punkto Speicherplatz und Zugriffszahl entlastet.

Vielen Dank. greetz greetz klml 22:01, 27. Okt 2006 (UTC)
PS: natürlich finde ich es toll das ihr hier so angestrengt diskutiert und am schluss ein toller Artikel herauskommt, aber die Vorschau hilft die history übersichtlich zu halten.

Club der Musikliebhaber

Das Szenario gefällt mir und ich sehe Paralellen zu Foren.

Nehmen wir 10 verschiedene Musik-Foren, in denen sich Leute über Hard Rock austauschen. Wenn ich ein Künstler bzgl. Hard Rock wäre, wäre ich in allen 10 Foren angemeldet, um zu wissen, was meine Zielgruppe hört. Ich würde dabei natürlich in meiner Signatur einen Link zu dem Verzeichnis auf einem Count Server setzen, der meine Musik enthält. Ich würde ebenfalls meine Musik in Diskussionen beispielhaft bringen. Ich würde auch in eigenen Threads ein Musikstück von mir zur Diskussion stellen. Jeder, der mitdiskutieren will und dazu sind ja alle da, würde sich das Musikstück downloaden.

Ich wäre zudem in allen entsprechenden Newsgroups drin und Chaträumen etc. PR Arbeit nennt man sowas und ist nicht verboten.

Ich erreiche registrierte Downloader nicht gezielt, aber je mehr Menschen im Internet ich erreiche, desto höher steigt das Downloadaufkommen meiner Songs.

Bannertausch, Werbebanner etc.

Ebenso kann ich illegale Zombifarmen mieten, in der Hoffnung, das darunter ein paar registrierte Haushalte sind.

Kurzum: Es ist kein Club notwendig. Die bisherigen Möglichkeiten reichen aus und werden auch bereits genutzt. Erst im Falle einer KFR werden die bisherigen Möglichkeiten viel besser zum Geldverdienen nutzbar sein.

Elcon 09:55, 31. Okt 2006 (UTC)

Zurück zur Seite „Kulturflatrate und Datenschutz“.