Zitat von Ansgar

Und da haben wir ihn wieder, den Allwissenden

------ Troll -----!

Werbung

@Ansgar

Wenn ich eine Suchmachine meiner Wahl mit dem Begriff "eKad" füttere finde ich leider nichts über böse P2P-Netze.

Zitat von Krecki

Wenn ich eine Suchmachine meiner Wahl mit dem Begriff "eKad" füttere finde ich leider nichts über böse P2P-Netze.

für Leute mit der langen Suchleitung können wir auch eMule Kademlia verwenden

Zitat von Burn256

für Leute mit der langen Suchleitung können wir auch eMule Kademlia verwenden

Deswegen werden mit Kademlia immer noch keine Dateien übertragen. Dafür wird immernoch das Protokoll eDOnkey2000 verwendet.

Zitat von Krecki

Deswegen werden mit Kademlia immer noch keine Dateien übertragen...

Hat auch nie jemand behauptet, was ja auch in diesem Bild deutlich zu sehen ist.
Bei dieser Gelegenheit kannst du ja gleich mal den vielen Unwissenden hier im Forum, den Inhalt des o.g. Bildes technisch verständlich erläutern.
Ich hab im Moment nämlich dafür keine Zeit.

-CityLight-

Günni ist tot.
Der Bericht im Stern schildert ausführlich das Leben und Wirken dieses "Anwalts"

Günter Freiherr von Gravenreuth: "Abmahn-Anwalt" begeht Selbstmord - Digital | STERN.DE

Kurzer Ausschnitt, der es eigentlich auf den Punkt bringt:

Zu dieser Selbstzerstörung hat womöglich der heftige Streit mit der "taz" entscheidend beigetragen. Im Gespräch mit stern.de erinnert sich "taz"-Anwalt Eisenberg an den Prozess und einen "bedauernswerten, jammervollen, armseligen kleinen Mann, der sich grottig verteidigt hat". Von Gravenreuth, sagt Eisenberg, sei eine "groteske Figur" gewesen und habe nichts Furchterregendes an sich gehabt. "Er war ein ********, er hatte keine ethischen Grundsätze und hat sich immer nur mit Schwächeren angelegt, die er ausgenommen hat." Kurzum, so folgert Eisenberg: "Ich habe ihn als Schande für den Anwaltsberuf wahrgenommen." Dennoch sei er vom Schicksal seines einstigen Kontrahenten "menschlich sehr berührt".

....

Zitat von Demon

Günni ist tot.

Man oh man, der steht bald schon wieder auf ! Für heute reicht es, oder ich erschieße mich auch ...

Ich lasse nicht die Korken knallen, dafür ist das zu tragisch, jedoch kann ich keinerlei Trauer empfinden, ich sehe das nur als Nachricht.
Leider gibt es keine Statistik wieviele Existenzen dieser Anwalt vernichtet hat. Seine Jünger halten sein Erbe am laufen und verschicken fleissig Abmahnungen.

So...das war mein letztes Wort zu Günni.

take a good look in your heart, tell me what do you see?
it's black and it's dark, now is that how you want it to be?
it's up to you, what you do will decide your own fate
make your choice now for tomorrow may be far too late

Textpassage aus "burn in hell" von Twisted Sister

An alle Abgemahnte


Der Münchner Rechtsanwalt Günter Freiherr von Gravenreuth ist tot. Er hat sich in der letzten Nacht in seiner Wohnung erschossen. Das geht aus aktuellen Meldungen hervor, die die bayerische Polizei bestätigte.

Seinen Selbstmord soll er zuvor telefonisch angekündigt haben. Verschiedene Kontakte erhielten auch einen Abschiedsbrief via E-Mail. Zwar wurde umgehend die Polizei alarmiert, diese kam jedoch zu spät. Unmittelbar bei ihrem Eintreffen soll sich Gravenreuth erschossen haben.

Der Hintergrund ist offenbar seine Verurteilung zu einer Haftstrafe wegen Betrugs. Laut dem Urteil von Anfang 2009 sollte er 14 Monate hinter Gitter. Das Gericht gewährte ihm allerdings einen Aufschub, damit er Zeit hat, seine Kanzlei aufzulösen. Der Haftantritt stand aber nun unmittelbar bevor.

Gravenreuth war in der Internet-Comunity bekannt und umstritten. Sein anwaltlicher Schwerpunkt lag unter anderem in den Bereichen Urheberrecht und gewerblicher Rechtsschutz, was ihn als Absender einer Reihe von Abmahnungen gegen Betreiber von Webseiten und Foren auftreten ließ.

Schlag einen Kopf ab - und es erscheinen 10 neue - das Geschäft ist einfach zu lukrativ für die Abmahner!!!

Zitat von Demon

Ich lasse nicht die Korken knallen, dafür ist das zu tragisch, jedoch kann ich keinerlei Trauer empfinden, ich sehe das nur als Nachricht.

Ist ja auch OK, soll ja keine Schelte sein. Nur gibt es diese Meldung bestimmt schon zwanzig mal im Forum.
Und ich habe sie zum einundzwanzigstenmal gepostet.

Es sollte auch nur eine Nachricht sein!!!

hallo,

ich wüsste gerne wie lange es dauern kann bis ich den bettelbrief erhalte und wer was dannach gehört hat sprich der Zeitraum nach dem Bettelbiref bis zum nächsten brief

thx

n

Zitat von nemesis19

ich wüsste gerne wie lange es dauern kann bis ich den bettelbrief erhalte und wer was dannach gehört hat sprich der Zeitraum nach dem Bettelbiref bis zum nächsten brief

Diese Information findest du, wenn du in den Foren der Anwälte suchst, von denen du abgemahnt wurdest... und nicht nur die letzten 2 Seiten

Wir sind immer noch nicht deine Vorleser hatte ich dir gestern schon gesagt...
...oder willst du hier der Quizmaster werden?

Hier ist der angekündigte Testbericht Teil-2.

Zur besseren Übersicht noch einmal die Form-Links der vorherigen Berichte.

* Warnhinweis, Änderung User-Hash (GUID)
* Testbericht Teil-1 Teil-A
* Testbericht Teil-1 Teil-B
* Testbericht Teil-1 Teil-C

###############################################
Beginn zum Forum-Bericht: Teil-2
###############################################


2.) der ed2k-Logging-Client im Praxistest
Dieser Teil des Testberichtes wird folgende Punkte erläutern:
- 2.1 Dateien mit nur einem Part (kleiner/gleich 9.28 MByte)
- 2.2 Feststellung der maximalen Downloads im Testlauf Tag-2
- 2.3 Download-Wiederholung und Idendifikation über mehrere Tage per User-Hash (GUID)
- 2.4 Snapshot des Part-HashSet, wird evtl. nur dieses geloggt ?
- 2.5 Zusammenfassung und Fazit
- 2.6 Sonderbeitrag: unsichere Zuordnung der IP-Adresse

<a>
Bevor ich zum eigentlichen Teil des Testberichtes komme, müssen noch einige Dinge grundsätzlich erwähnt werden. Es wird in diesem Teil keine endlosen Zahlenreihen oder Statistiken geben, bei wievielen P2P-ed2k-Nutzern wir einen Download (Upload der Gegenstelle) nachweisen konnten, wieviele Nutzer wir über den User-Hash "wiedergefunden" haben, oder wieviele IP-Adressen wir abgreifen konnten. Es wird vorwiegend in dieser Richtung erläutert, warum es schlichtweg nicht möglich ist, innerhalb einer Woche bei so derart vielen IP-Adressen (siehe auch Abmahnstatistik von @princess15114) einen sog. beweisgesicherten?? Upload der Gegenstelle zu unterstellen. Und ich werde auch dahingehend einige Behauptungen aufstellen, was offenbar tatsächlich als Grundlage für die Abmahnungen herangezogen wird, und warum genau "das" an Hand unserer Testergebnisse die einzig logische Erklärung ist.
<b>
Ich bin mir auch im Klaren darüber, dass "die Behauptungen" einigen IT-Dienstleistern (Loggerbuden) als vorerst unverdaulicher Brocken im Hals stecken bleiben wird. Allerdings haben wir bisher "von denen" auch nichts weiter gehört als Behauptungen, noch nicht einmal einen technisch nachvollziehbaren Vortrag, wie bestimmte beweissichere? Log-Vorgänge überhaupt funktionieren sollen. Es soll ja sogar Abmahner geben, denen mittlerweile das Wort "Gutachter" in der Abmahnung "zu heiß" geworden ist.
Wenn also die Loggerbuden der Meinung sind, ihre Spezial-Software funktioniere grundsätzlich anders, dann steht ihnen das Recht frei sich doch mal grundlegend dazu zu äußern. Dazu darf es auch mal eine technisch tiefgründige Erläuterung sein. Denn entgegen der weitläufigen Meinung auch einiger Richter sind im "P2P-Netz" eben nicht nur wild saugende, und bunt klickende Nutzer unterwegs, die keinen Plan von der "technischen Materie" haben.
<c>
Vor den eigentlichen Erläuterungen noch einige Details zum Testablauf.
Der finale Test wurde ausgelegt auf einen Zeitraum von 7 aufeinander folgenden Tagen, jeweils auf einen Zeitraum von 6 Stunden. Als Zeitfenster wurde natürlich der späte Nachmittag bis Abend gewählt. Also der Zeitraum, wo die meisten P2P-Nutzer nach der Schule oder nach der Arbeit Online sind. Zudem hat immer einer von unserer Testtruppe während dieser Zeit vor den Rechnern der Log-Testumgebung (siehe Bild06 gesessen. Einzig geändert bzw. abgekürzt haben wir den Testlauf im Punkt 2.1. Es ist schon klar, dass man auf Grund des eingeschränkten Zeitraumes nur eine Hochrechnung anstellen kann, und es hierbei immer zu gewissen Fehlern im Testergebnis kommt. Aber !!, es geht um die Erkenntnis, ob auch mit einer Hochrechnung "diese Mengen an geloggten IP's" überhaupt annähernd erreicht werden. Und das war eben nicht Fall. Mehr dazu im Fazit.


2.1) Dateien mit nur einem Chunk (Part) > kleiner/gleich 9.28 MByte
Vorab gleich, in diesem Teil gehen wir noch detailliert auf mehrere ScreenShots zu Live-Whois, TraceRoute, usw. ein, die wir von manuell selektierten Quellen grundsätzlich zusätzlich erfasst haben. In den späteren Testabschnitten gehen wir dann darauf nicht mehr ein.
In diesem Teil wird also der Frage nachgegangen, wieso eigentlich bei relativ kleinen Audio-Dateien fast ausschließlich nur noch sog. Sampler-Sammlungen oder Chart-Container geloggt werden. Also komplette Sammel-Werke, die eine recht große Datei (meist Archiv) ergeben. An dieser Stelle könnte man der Ansicht folgen, weil man dann die Möglichkeit hat, gleich die Werke mehererer RI's abzumahnen. Ich denke an dieser Stelle, es gibt noch einen anderen Grund, nämlich ein technisches Problem.
>> TestScreen069 << - das Werk, eine Audio-Datei verpackt in einem Archiv
Die Quellenverfügbarkeit nur an deutschen Quellen sah schon mal sehr vielversprechend aus, zumal das Werk recht aktuell auf einer esel-Seite veröffentlicht wurde.
<a>
>> TestScreen070 << - die Warteschlange, bereits im dritten Download-Versuch
Diesen Test haben wir drei mal wiederholt mit 15 Minuten Pause dazwischen, und jedes mal mit dem gleichen "unglücklichen" Ergebnis. Die Datei war von wenigen geloggten Clients (also nachweisbarer Upload) so schnell geladen, dass der Download nach kurzer Zeit beendet war, und unsere Warteschlange verschwunden ist. Bedeutet natürlich, wir haben keine Quellen mehr zum loggen. Im dritten Versuch haben wir dann die DL-Rate drastisch reduziert, um die Warteschlange möglichst lange offen zu halten. Gebracht hat das aber auch nichts, außer dass wir im Queue-Ranking weiter runter gerutscht sind, und die verfügbaren Quellen wegbrachen. Und trotz der immer mal stark reduzierten DL-Rate (die wir immer mal im Firewall-Router {Bandbreitenbegrenzung > Bild062} beeinflusst haben), war unsere Warteschlange nach spätestens einer Stunde weg. Ergebnis im zweiten Testlauf, ganze vier gelungene Downloads. Und da die verfügbaren Quellen ja auch beim dritten Anlauf nicht wesentlich mehr werden, reduzierten sich die gelungenen DL's natürlich noch.
>> TestScreen071 << - eine bereits zweimal geloggte Quelle
Diese hier angezeigte Quelle hatten wir bereits im zweiten Testlauf erfasst, und diese IP-Adresse ganz gezielt für 10 Minuten blockiert (siehe Musterbeispiel im Bild061). Im dritten Testlauf ist uns dann ein erneuter Download von dieser Quelle gelungen. Allerdings, die magere Ausbeute im dritten Testlauf, zwei gelungene Downloads. Dann war wieder Feierabend. Hier natürlich anzumerken, wir also lediglich einen Zuwachs von nur einer neuen IP mit Download, denn die andere IP hatten wir bereits im zweiten Testlauf geloggt.
<b>
>> TestScreen072 << - die Live-Whois+Ping Abfrage einer "selektierten" Quelle
Interessant ist an diesem Bild072, dass die Gegenstelle gar nicht erreichbar ist.
>> TestScreen073 << - TraceRoute auf die Quelle
Der Tracertest bestätigt uns, die Quelle antwortet nicht. Allerdings kann das auch bedeuten, dass die Gegenstelle hinter einer Firewall läuft, die lediglich nicht auf Ping's antwortet, aber trotzdem zu uns uploaded. Um das zu belegen, müssen wir nämlich den Download-Zuwachs der Gegenstelle loggen. Und da kommt es vor allem auf exaktes Timing an. Schauen wir uns nämlich noch einmal das Bild070 (IP der selektierten Quelle) an, dann ist dieser Nachweis machbar, denn die Quelle überträgt noch Daten zu uns.
<c>
An dieser Stelle wollen wir noch auf ein besonderes Problem aufmerksam machen.
Schauen wir uns noch einmal ganz genau aus Bild070 die selektierte IP an, vor allem aber die Port-Anzeige dahinter. Schauen wir noch auf Bild071 dann stellen wir fest, keine Kad-Verbindung, und auch keine Protokoll-Verschleierung (Obfuskation). Damit könnte die Port-Anzeige "15000" eigentlich an dieser Stelle gar nicht sein. Es müsste "4661" oder "4662" lauten.
>> TestScreen074 << - die Quellen-IP im Firewall-Router
Man achte besonders auf das Feld "Info". Das ist nämlich im Firewall-Router das Informations-Feld des Protokollinspektors (Deep Packet Inspection). Hierzu muss noch auf >> das Bild065 << zurück verwiesen werden. Der sog. "Mangel" funktioniert hier wie folgt.
Der Firewall-Router empfängt ein Datenpaket, analysiert dessen Inhalt, und vergleicht vor allem den Header des Paketes mit den bekannten Port-Definitionen (siehe hier "Definitionen/Dienste" >> im Bild062 <<). Und wenn hier eine Abweichung auftritt dann trägt der Firewall-Router im Info-Feld den Port (Dienst) ein, den er tatsächlich gefunden hat (hier "EDonkey" > Port 4661-4662). Und ein "Mangel" ist es deshalb, weil die Pakete von dieser IP (siehe Bild070) eben Port-15000 lauteten.
<d>
Und um diese hochkomplizierte Materie hier auf den Punkt zu bringen:
Der eMule (hier unser Logging-Client) zeigt nicht immer die Port-Angaben korrekt an. Dieser Fehler tritt zwar relativ selten auf, aber er passiert eben doch hin und wieder. Und relavant ist das nämlich insofern, wenn die "Log-Software/Datenbank" das verwendete P2P-Netz (ed2k oder BitTorrent) oder den Client-Typ im Log-Datensatz aus der Port-Angabe ableitet. Zur Erinnerung, es gab schon Abmahnungen wo ein eMule als geloggter Client genannt, und beim geloggten Datei-Hash ein MD5-Hash (40-stellig, BitTorrent) genannt wurde.

2.1.1) Zusammenfassung
Der o.g. Teil des Tests wurde von uns nach dem dritten Versuch am TestTag-1 abgebrochen, weil er keinen Sinn machte. Es war uns auf Grund der kurzen loggbaren Standzeit der Warteschlange nicht gelungen, überhaupt eine nennenswerte Anzahl an beweissbaren Downloads zu erfassen. Selbst wenn wir nur die Clients an den vorhandenen Dateiteilen (also Logging ohne Download-Nachweis) erfasst hätten, würde sich hier der Aufwand gar nicht lohnen. Selbst wenn wir das Werk jedesmal zum Download neu einstellen, fällt die Menge der loggbaren IP's eher sehr gering aus.
2.1.2) Schlussfolgerung
Große Audio-Sammlungen (Chart-Container) werden vorwiegend aus dem Grund geloggt, weil die Erfassung einzelner kleiner Audio-Dateien nicht genug abmahnfähige IP's generiert, dass sich dieser Aufwand lohnen würde.


2.2) TestTag-2, maximal erreichte Menge an nachgewiesenen Downloads
Vorab noch ein paar Erläuterungen zum Test-Werk. Wir hatten uns für diesen Testlauf ein Filmwerk ausgewählt, welches in einem Archiv verpackt war, und größer als 1.9 GByte war. Die Detail-Angaben wurden bewusst verschleiert, damit hier nicht einige Abmahner noch auf "dumme Gedanken" kommen, bezüglich der sichtbaren IP-Adressen in den folgenden ScreenShots. Auch bei diesem Werk wurde auf die Verfügbarkeit an deutschen Quellen geachtet.
>> TestScreen075 << - die Quellenverfügbarkeit
Wir hatten übrigens auf den ersten Server in der Liste manuell connected, Quellenanzahl = 54.
>> TestScreen076 << - der gestartete Download
Nach wenigen Minuten stand die Verfügbarkeit bei 58 Quellen. Man sieht also, die durchschnittliche Statistik aus Bild075 ist doch recht genau.
<a>
>> TestScreen077 << - der Stand nach etwa einer Stunde
Auch hier hatten wir bis dahin noch keinen einzigen Download, allerdings ist das beim eMule bei so großen Dateien ein normales Verhalten. Und wir dürfen nicht vergessen, wir uploaden nicht, haben keinerlei "positive" Kredit-Punkte bei den Gegenstellen, die uns in der Warteschlange schneller nach oben schieben würden. Es heist also nur, warten bis wir an der Reihe sind. Insofern beachte man auch "unsere" Werte im Queue-Ranking. Und ebefalls noch wichtig, in diesem Testlauf hatten wir die Download-Rate auf etwa 92 kByte/s eingestellt. Wir wollten nicht zu schnell laden, und anderseits auch für einen häufigeren Wechsel der Quellen sorgen. Zusätzlich wurden wie üblich immer mal einige Quellen gezielt erfasst. Man achte im Bild077 vor allem auf Prozent-Verfügbarkeit der Datei bei der markierten Quelle.
>> TestScreen078 << - die üblichen Client-Details
>> TestScreen079 << - Live-Whois+Ping, mit leichten Leitungs-Problemen
Interessant ist hier das Antwort-Verhalten der Quelle. Eine generell "schlechte Leitung" scheidet zumindest beim dem angezeigten Provider i.d.R. schon mal aus. Es ist eher eine Vermutung darauf, dass die Gegenstelle mit Full-Speed noch von anderen Gegenstellen down/uploaded, und "die Leitung" oder der Client auf der Last-Grenze laufen. Aber wie gesagt, es bleibt eine Vermutung. Allerdings genehmigen wir uns an dieser Stelle mal einen Vor-Blick auf das Bild081, und schauen uns den Datei-Zuwachs bei der Quelle am nächsten Tag an. Bezüglich des Werkes von über 1.9 GByte Größe, Kommentar überflüssig. [/B]Aber !!, wir können das "wie", "woher" und "mit wem" mit unserem Logging-Client weder gezielt feststellen, noch in irgendeiner Form beweisen.[/B]
>> TestScreen080 << - TraceRoute-Kontrolle bei selektierten Quellen

2.2.1) Zusammenfassung
Auch in diesem Testlauf mit 6 Stunden Online-Zeit haben wir gerade einmal auf ingesamt 18 Downloads gebracht. Aber !!, die Menge an abmahnfähigen IP's betrug gerade einmal noch 4 verschiedene Quellen. Was war passiert ? Durch die relativ hoch eingestellte Download-Rate wurde permanent nur von zwei Quellen geladen. Auch eine gezielte Blockade der IP-Adressen für 10 Minuten führte nicht zu einem wesentlichen Zuwachs neuer Quellen, von denen wir downloaden könnten. Das hat nämlich unser permanent schlechter QR-Wert bei den Gegenstellen verhindert. Vielmehr präsentierte sich die Blockade-Aktion nämlich so, dass spätestens nach der zweiten Warteschlangen-Aktualisierung (etwa 30 Minuten) die bereits bekannten Quellen erneut in der Liste erschienen, und unser Download von diesen bereits geloggten Quellen erneut einsetzte. Wir hatten also lediglich einen Mehrfach-Download von wenigen Quellen belegen können.
<a>
Ich gehe natürlich schon davon aus, dass bei einer Online-Zeit von mindestens 20 Stunden unsere bewiesenen Downloads von verschiedenen Quellen steigen werden, denn mit zunehmender Wartezeit verbessern wir uns auch im QR-Wert. Allerdings dürfen wir eben auch hier nicht vergessen, es werden allenfalls Downloads von Quellen sein, die wir bereits in der Warteschlange kennen. Und, das o.g. Problem mit dem deutlich fehlenden Quellen-Zuwachs wird sich wiederholen. An unserem eigentlich Ziel, nämlich mit rund 50 (hochgerechnet) Downloads von verschiedenen Quellen ein "aufwandsmäßig tragbares" Logging zu schaffen, sind wir völlig daneben gelandet.
2.2.2) Schlussfolgerung
Auf Grund der Wartschlangen-Problematik (permanent schlechter QR-Wert, wir uploaden nichts) ist es nicht möglich, solch hohe Werte an bewiesenen Downloads zu erreichen, wie bei den Gerichten IP-Adressen zur KNE abgeladen werden.


2.3) TestTag 3-7, Download-Wiederholung und Idendifikation über User-Hash (GUID)
In diesen Testläufen bestand das vorrangige Ziel darin, bestimmte ausgewählte Quellen über mehrere Tage zu verfolgen, und einen Download möglichst erneut zu belegen. Die Idendifikation sollte dabei ausschließlich über den User-Hash (GUID)erfolgen. Als Neben-Ziel bestand weiterhin Downloads von neuen Quellen wie unter Punkt 2.2) zu erreichen, jedoch dieses mal mit drastisch reduzierter Download-Rate. Damit sollte nach der "schlechten Ausbeute" aus Punkt 2.2 untersucht werden, ob die eingestellte Download-Rate des Logging-Clients erheblichen Einfluss auf die Ausbeute an loggbaren IP-Adressen hat. Weiterhin wurde auf den Zuwachs der Dateiteile bei den Quellen geachtet, sowie unser eigener QR-Wert bei der Gegenstelle (sofern diese neu idendifiziert werden konnte). Gerade mit diesem "QR-Wert" wollten wir nämlich sehen, wie sich unser eigener "Null-Upload" auf das Queue-Ranking bei den Gegenstellen auswirkt. Hier sollte sich jeder im Klaren darüber sein, wenn wir jeden Tag mit einem QR-Wert von über 1000 bei der Gegenstelle einsteigen, dann kommen wir dort bezüglich unseres bewiesenen Downloads nämlich auch nach 23 Stunden Dauerlauf niemals zum Zuge.
<a>
Trotz das der User-Hash von der Gegenstelle problemlos geändert und sogar manipuliert werden, haben wir die vorrangige Idendifikation trotzdem darüber vorgenommen. Nämlich so, wie es die Loggerbuden sicherlich auch machen. Allerdings haben wir bei den manuell zusätzlich geloggten Quellen immer eine weitergehende Prüfung der Log-Daten vorgenommen, um eine möglichst hohe Idendifikations-Rate der Quelle zu erreichen. Ich beschreibe an diese Stelle nicht, wie wir da "genau was" überprüft haben. Das hier soll nämlich kein Qualitätssicherungs-Audit für diverse Loggerbuden werden. Ich behaupte sogar an dieser Stelle, das die Loggerbuden bezüglich des User-Hash überhaupt keine weitergehenden Prüfungen durchführen.
<b>
An dieser Stelle noch einmal ein paar wichtige Details, bevor der eigentliche Testlauf kommentiert wird.
>> TestScreen081 << - eine selektierte Quelle vom TestTag-2 (Bild077)
Man achte auf den Datei-Zuwachs bei der Quelle, und vor allem auf unseren QR-Wert dort. Wir sind mit unserem Logging-Client mit einem QR-2948 (Bild077) nach nur einem Tag praktisch "ganz hinten im Bus" gelandet. Hier wird uns nie ein beweissicherer Download gelingen.
<c>
>> TestScreen082 << - ein ScreenShot vom TestTag-4
Dieser ScreenShot ist besonders interessant, weil er ca. 5 Minuten vor dem 6-Stunden-Stop erfolgte. Unser Operator (also der an diesem Abend vor den Rechnern sitzen musste) hatte nämlich beim ersten Start die Warteschlangen-Anzeige nach QR sortiert. Interessant vor allem deshalb, weil bei einem Betrieb von mehr als 6 Stunden hier sich noch zahlreiche Downloads gelingen würden. Also hatte er nur die Log-Aufzeichnung pünktlich gestoppt, aber den Logging-Client noch knapp 2 Stunden weiter laufen lassen. Frustriert war er aber dann trotzdem, denn er konnte gerade mal noch zwei Downloads von zwei Quellen aus der QR-Schlange schaffen. Was war da passiert ??
Als unser Operator die Log-Aufzeichnung stoppte war es bereits kurz nach Mitternacht. Als die Warteschlange die nächste Aktualisierungs-Runde drehte waren gleich 5 Quellen mit einem vielversprechenden QR verschwunden, es blieben nur noch die Quellen mit dem QR-11 und dem QR-42 übrig, von denen übrigens dann auch der Download gelang. Er hatte nämlich nicht daran gedacht, dass viele P2P-Nutzer ihre Clients nicht die ganze Nacht durchlaufen lassen, sondern abschalten wenn sie ins Bett gehen. Und diesen Zeitpunkt hatte er offenbar gerade erwischt. Schade war hier eigentlich nur, dass er frustiert über die versenkte zusätzliche Nachtschicht keinen händischen ScreenShot mehr gemacht hat. Den hätte ich eigentlich gern noch unter das Bild082 gesetzt.
<d>
An dieser Stelle nur noch kurz und ohne Kommentar erwähnt, die sog. zusätzlichen Prüfungen aus Abschnitt 2.3 <a>.
>> TestScreen083 << - Live-Whois+Ping, Gegenstelle nicht erreichbar
>> TestScreen084 << - DNS-Tracker
>> TestScreen085 << - DNS-Tracker

2.3.1) Erläuterung, Testlauf mit ausgewählten Quellen als grafischer Überblick
Ich habe hier lediglich einen Auszug aus den unzähligen ScreenShots zusammengestellt. Die Ergebnisse sind bei den restlichen Quellen aus der Warteschlange ohnehin ziemlich gleich. Zur besseren Übersicht wurden von den selektierten Quellen jeweils die Zeile aus dem oberen und unterem eMule-Fenster herausgeschnitten. Wichtig an dieser Stelle noch. Damit das Ergebnis nicht unnötig verzerrt wird, haben wir von jedem Tag einen "Pool" aus ScreenShots gebildet, die ca. eine Stunde vor dem jeweiligen 6-Stunden-Stop erfolgten. Und die jeweiligen Datensätze (User-Hashes) wurden dann, so kurios das klingen mag, ausgewürfelt (mit richtigen Würfeln). Es wurde danach lediglich geschaut, ob der ausgewürfelte User-Hash auch vor, bzw. nach dem Stichtag zu finden ist. Wir haben also hier eine zufällige Stichprobe aus dem genannten "Pool" gezogen.
Wie bereits oben erwähnt, geht es in den nachfolgenden Grafiken hauptsächlich darum, die Zusammenhänge über mehrere Logging-Tage zu erkennen.
- Wiedererkennung nur über User-Hash
- evtl. gelungener Download
- Zuwachs der Dateiteile bei der Quelle
- QR-Wert bei der Quelle
- mögliche Fehlerquellen
Insofern sollte man sich also die Grafiken genau anschauen, denn "der Teufel" steckt manchmal im Detail.

2.3.2) Erläuterung Quelle-1 (BF99)
>> TestScreen086 << - Statistik Quelle-BF99
Hier sollte man auf die QR-Werte achten. Hier einen "beweissicheren" Download erreichen zu wollen, ist schlichtweg Phantasie. An dieser Stelle muss auch wiederholt klar sein, welche Auswirkungen das eigentlich hat, wenn "der Logger" selbst nicht uploaden darf. Aber, es gibt noch ein Problem, dass auf den ersten Blick gar nicht auffällt. Zweimal die gleiche IP an zwei verschiedenen Tagen (Tag-5 und Tag-6). Grundsätzlich ist das natürlich möglich. Es gibt Provider ohne Zwangstrennung nach 24h, unser ScreenShot lag gerade noch innerhalb der 24h-Session, usw. Die Frage ist allerdings an dieser Stelle, prüft so etwas eine Loggerbude überhaupt ab ? Also ich denke mal, es wird nicht gemacht. Man könnte jetzt meinen, wir lagen innerhalb der 24h-Session, daher hat die Gegenstelle noch die gleiche IP.
>> TestScreen087 << - Client-Whois-Ping Quelle-BF99
Schaut man sich hier im Bild087 jedoch für den Tag-5 und Tag-6 die Client-Infos mal ganz genau an, dann gibts hier gleich die nächsten seltsamen Fragen. Genauso könnte auch der Client am Tag-6 seinen User-Hash geändert haben. Genau feststellen lässt sich das hier nämlich auch nicht mehr. Dieser ScreenShot soll also auch verdeutlichen, wo nämlich bezüglich User-Hash der "Hase im Pfeffer" liegt.

2.3.3) Erläuterung Quelle-2 (AD8A)
>> TestScreen088 << - Statistik Quelle-AD8A
In diesem Bild088 achte man wieder auf die QR-Werte zwischen Tag-3 und Tag-4. Hier wird erneut unser "null-Upload"-Problem deutlich. Zudem ist uns die Quelle am Tag-6 auf Nimmerwiedersehen entfleucht, und zwar ohne einen gelungenen Download. Hieraus kann man übrigens sehr gut ableiten, dass nur noch wenige P2P-Nutzer das fertig geladenen Werk ewig im Share stehen lassen, und es i.d.R. nach kurzer Zeit aus dem Share entfernen.
>> TestScreen089 << - Client-Whois-Ping Quelle-AD8A
Aus den Live-Whois-Abfragen kann man sehr wohl ableiten, dass der Client der Gegenstelle hinter einer Firewall läuft, die nicht auf "Ping's" antwortet. Und hier soll auch mal eine Besonderheit bezüglich Netzprüfung kurz erläutert werden.
<a>
Im Bild089 sehen wir nämlich beim Whois Tag-3 und Tag-4, dass die Gegenstelle aus dem DTAG-Netz kommt, und dass über zwei verschiedene IP-Ranges eingeloggt wurde. Nichts ungewöhnliches denkt man. Ist aber bei der DTAG nicht so. Auf Grund ihres riesigen Adress-Pools kann sich die DTAG (andere Provider mit eigenem Netz übrigens auch) nämlich leisten, bestimmte IP-Ranges aus ihrem Pool ganz bestimmten regionalen Zugangsknoten fest zuzuordnen. Diese Dinger werden hier als "Core POP" und "Regio POP" bezeichnet. Und deren DNS-Namen tragen ein sog. Städte-Kürzel (z.B. ffm = Frankfurt/Main, bln = Berlin, ki = Kiel,... es gibt Listen darüber). Im nächsten Bild090 kann man das sehr schön sehen.
>> TestScreen090 << - TraceRoute, DTAG-Netz
Und das bedeutet aber auch, dass der einloggende DTAG-Kunde i.d.R. immer eine IP-Adresse aus der gleichen IP-Range zugeordnet bekommt, nämlich die von seinem Einzugsbereich des Zugangsknotens. Und daraus resultiert auch, wenn wir eine Gegenstelle im DTAG-Netz heute aus der IP-Range "Kiel" loggen, dann kann es am nächsten Tag eigentlich unmöglich eine IP-Range "München" sein. Wohl kaum das der P2P-User extra nach München fährt, nur um dort "das Werk" weiter zu saugen.
Dieses Beispiel sollte mal erläutern, dass es sehr wohl möglich ist, auch Unzulänglichkeiten bezüglich zweier geloggter IP-Adressen festzustellen.

2.3.4) Erläuterung Quelle-3 (5C0D)
>> TestScreen091 << - Statistik Quelle-5C0D
Hier ist uns am Tag-3 mal wieder ein Download (130kByte) gelungen. Fragwürdig hier natürlich, dass am Tag-6 ohne einen geloggten Status "Download" plötzlich "150kByte" angezeigt werden. Die Erklärung ist ganz einfach. Hier wurde vom Operator eine Download-Blockade manuell ausgelöst. Und bis unser Firewall-Router diesen Befehl auf die IP-Adresse ausgeführt hat, vergehen ein paar Sekunden. Die Differenz der Download-Menge ergibt sich hier aus dem automatischen ScreenShot auf dem Logging-Client, und der IP-Blockade des Firewall-Routers.

2.3.5) Erläuterung Quelle-4 (EBAE)
>> TestScreen092 << - Statistik Quelle-EBAE
Zu dieser Quelle gibts wohl nix mehr zu sagen. Gleich drei belegte Downloads hintereinander. Ich denke das würde sicherlich auch ein Richter als eindeutigen Beweis ansehen. Es war übrigens die einzige Quelle, die wir über den gesamten Testzeitraum loggen konnten. Hier soll also lediglich noch einmal darauf hingewiesen werden, das der belegbare Download (Upload der Gegenstelle) durchaus funktioniert. Allerdings eben nicht in solchen Mengen, wie die Loggerbuden uns hier immer beweissicher verkaufen wollen.

2.3.6) Erläuterung Quelle-5 (6152)
>> TestScreen093 << - Statistik Quelle-6152
Ein echtes HighLight (es gibt zwei davon) aus unserer Stichprobe. Die Quelle hat null Prozent (0%) des Werkes vorrätig, aber wir stehen auf QR-26. Hier dürfen die Loggerbuden mal ganz substantiiert erläutern, was in einem solchen Fall wohl mit welchem Grund geloggt wird.

2.3.7) ScreenShots Quellen 6-11
Die weiteren ScreenShots sollen nicht weiter kommentiert werden, da sich die Unzulänglichkeiten bezüglich "nicht gelungener Download" ohnehin nur wiederholen.
>> TestScreen094 << - Statistik Quelle-6
>> TestScreen095 << - Statistik Quelle-7
>> TestScreen096 << - Statistik Quelle-8
>> TestScreen097 << - Statistik Quelle-9
>> TestScreen098 << - Statistik Quelle-10
>> TestScreen099 << - Statistik Quelle-11

2.3. Zusammenfassung
Die Ergebnisse dieses Testlaufs spiegeln genau das wieder, was nicht nur im Kreise der Abgemahnten immer wieder angesprochen wird. Der beweissichere Download bei jeder geloggten/abgemahnten IP-Adresse ist eine Lüge und technisch überhaupt nicht realisierbar. Dieser Download gelingt allenfalls in Ausnahmefällen. Und selbst hierbei treten häufig Probleme bezüglich eindeutige Zuordnung der IP-Adressen zum User-Hash (GUID) auf. Selbst mit einer positivsten Hochrechnung würden wir hier nicht einmal 50 bewiesenen Downloads von unterschiedlichen Quellen (User-Hashes) pro Woche erreichen.
Wenn wir an dieser Stelle davon ausgehen, dass der Logger zeitgleich im BitTorrent-Netz geloggt hat, und hier die Zahl an loggbaren Quellen (laut diverser Statistiken) etwa um den Faktor-3 höher als im ed2k-Netz ist, erreichen wir niemals eine solche Menge an angeblich bewiesenen Downloads. Denn das behaupten ja die Abmahner immer und immer wieder. Zur Erinnerung noch einmal der Link zur Abmahnwahn-Dreipage, wo diese Menge an Adressen innerhalb einer Woche im September-2009 geloggt wurde.

2.3.9) Schlussfolgerung
Der letzte Testlauf hat die Schlussfolgerung aus Punkt 2.2.2 erneut bestätigt. Selbst wenn unter Anwendung einer Hochrechnung das nicht überprüfte BitTorrent-Netz mit einbezogen würde, ist es nicht möglich solch hohe Werte an angeblich bewiesenen Downloads zu erreichen.
Insofern wäre noch zu überprüfen, wie man ca. 1700 IP-Adressen (oder sogar 11.306) auf welcher Basis geloggt haben will. Das wird in einem Test im folgenden Punkt 2.4 erläutert.


2.4) Snapshot der vorhandenen Datei-Teile (Part-HashSet)
Was wird von den Loggerbuden tatsächlich erfasst, und als Grundlage für die Massenabmahnungen herangezogen ??
Diese Frage erscheint immer wieder in diversen Internet-Foren, und mittlerweile sogar (wenn auch noch sehr zaghaft) von einigen öffentlichen Medien gestellt. Unter den abgemahnten erfahrenen P2P-Nutzern ist diese Frage längst eine klare Sache, "die" loggen fast durchweg nur ein gefundenes Part-HashSet (Dateiteile), ohne irgend einen Beweis für einen Down- oder Upload jemals durchgeführt, oder gar belegt zu haben.
Und an dieser Stelle erläutern wir mit ein paar simplen Beispielen wie das funktioniert, und lassen auch mal die Frage noch offen, welche der beschriebenen Varianten von den Loggerbuden wohl angewendet wird, bzw. angewendet werden könnte.
Hier sollte sich jeder auch darüber im Klaren sein, dass man dafür nämlich keine Spezialsoftware oder aufwendig umprogrammierte P2P-Client-version mehr braucht. Das funktioniert bereits mit einer "gewöhnlichen" guten Mod-Version eines P2P-Clients.
Die genauen Erläuterungen zu den ScreenShots sparen wir uns hier. Wer bisher aufmerksam gelesen hat, wird die Funktionsweise ohnehin sofort erkennen können. Anzumerken wäre noch, es sind also lediglich SnapShots der Quellenverfügbarkeit zum Werk. Also "wir haben gesehen", dass bei dem Client (User-Hash) das Werk, oder Teile davon vorhanden sind. Alle anderen Hintergründe können wir weder belegen noch beweisen.
<a>
>> TestScreen100 << - Dateizuwachs an 3 Tagen
Hier können wir an drei Tagen einen Dateizuwachs bei der Gegenstelle beobachten. Ob die Gegenstelle das Werk selbst geuploaded hat, können wir generell nicht sehen. Auch nicht mit irgendwelcher Spezialsoftware. Einen beweissicheren Download (Upload der Gegenstelle) haben wir nämlich nicht.
>> TestScreen101 << - Dateizuwachs an 2 Tagen
>> TestScreen102 << - ein einzelner Log-Datensatz mit 100%
Die Frage, ob die Gegenstelle hier einfach das Werk in einem freigegebenen Ordner stehen, kann hiermit nicht beantwortet werden.
>> TestScreen103 << - ein einzelner Log-Datensatz mit 0%
Die immer wieder kehrende Frage, was kann hier überhaupt festgestellt werden. Eigentlich nur, dass die Gegenstelle das Werk selbst allenfalls zum Download angefordert hat. Ob die Quelle selbst nur einen Download überhaupt gestartet hat, kann man hier nicht mal sehen.

2.4.1) Zusammenfassung
Egal welche Variante hier angewendet, der pure SnapShot der Quellenverfügbarkeit dürfte die einzige Möglichkeit sein, solche derart hohe Mengen an geloggten IP-Adressen in einer so kurzen Zeit (i.d.R. eine Woche) überhaupt zu generieren. Hier wird auch der Tatsache gefolgt, dass das im BitTorrent-Netz genauso gemacht wird. Es wird bei dieser Logging-Variante weder ein Up/Download beweisen, noch irgendwelche anderweitigen Aktivitäten der Gegenstelle. Es folgt lediglich der Aussage "wir haben da aus der Entfernung irgendwas beobachtet".


2.5) Zusammenfassung und Fazit
Der beweisbare Probe-Download (Upload der Gegenstelle) kann allenfalls in vergleichsweise sehr wenigen Fällen erbracht werden. Die Masse der Abmahnungen basiert einfach nur darauf, dass bei einer beobachteten Gegenstelle zufällig der fragliche Datei-Hash oder Datei-Name gesichtet wurde. Alle weitergehenden Prüfungen bezüglich Beweissicherheit oder Fehlern im Log-Vorgang werden offensichtlich gar nicht erst durchgeführt.





Abschluss-Geschichte, 11.306 IP-Adressen, Vermutung oder Tatsache ??
Erinnern wir uns doch noch einmal an das Ding mit den 11.306 IP-Adressen. Wir können hier hoch- und runterrechnen wie wir wollen, allein schon bei der Quellenverfügbarkeit innerhalb einer Woche kämen wir nie auf solche Zahlen. Wir dürfen hier nicht vergessen, aus jeder geloggten IP-Adresse soll ja eine Abmahnung werden. Zumal wird ja mit dieser Begründung die KNE (Klarnamenermittlung) erwirkt. Man könnte natürlich meinen, hier wurden gleich unzählige Werke gleichzeitig geloggt. Hier drängt sich nämlich noch ein ganz anderer Gedanke auf. Es könnten nämlich hier genauso unzählige kleine Audio-Dateien lediglich per Quellen-SnapShot (siehe Punkt 2.4.1) geloggt worden sein. Das würde nämlich auch die hohe Anzahl an IP's erklären. Das Problem was der Logger aber mit solch einem Log-Monster hat, sind die zig-verschiedenen User-Hashes und IP-Adressen als Folge der dynamischen IP-Vergabe. Das bedeutet auch, die Zuordnung der einzelnen Audio-Dateien zum Inhalt eines abzumahnenden Chart-Containers, über den User-Hash oder die IP herstellen zu wollen, ist ein unsäglicher Aufwand. Das geht eigentlich mit den ermittelten Klarnamen sehr viel einfacher. Hier drängt sich schon der Verdacht auf, dass die bereits bekannten Mehrfach-Abmahnungen auf mehrere Titel eines Chart-Containers, erst nachträglich über die ermittelten Klarnamen konstruiert werden. Da braucht man sich noch nicht einmal mit dem als unsicher bekannten User-Hash herumzuärgern. Und das was wäre, zumindest aus meiner Sicht, wirklich besonders starker Tobak.
Aber eben wie schon angemerkt, es ist eine reine Vermutung. Ich kenne ja den Inhalt der 11.306-Akte nicht. Allerdings, eine andere logische Erklärung habe ich für eine solche IP-Menge jedenfalls nicht.
Zu dieser Vermutung darf sich auch ruhig mal der eine oder andere RA äußern, wenn "das" tatsächlich so wäre.


Und damit beende ich diesen Testbericht an dieser Stelle erst einmal.

Für den noch offene Punkt 2.6 (Sonderbeitrag: unsichere Zuordnung der IP-Adresse) werde ich mir einige Wochen Zeit lassen, da hierfür erst einige Test über einen längeren Zeitraum erforderlich sind. Unsere Logging-Umgebung ist zwar mittlerweile bereits vollständig abgebaut, aber diesen Test kann ich ggf. sogar von zu Haus aus durchführen. Es geht ja hier vorrangig darum, bei bestimmten IP-Adressblöcken das sog. Reseller-Geschehen zu beobachten, wie oft und wie schnell eine IP erneut vergeben wird, welche Fehler dabei bezüglich AI-Zuordnung auftreten können, und ob man "das" mit dem "Durchschnitts-Logging" überhaupt noch feststellen kann.
Und für diese Tests genügt ein gewöhnlicher Mod-Client, und es braucht noch nicht einmal ein rechtlich bedenkliches Werk zum Download. Mal sehen, was bei diesem Test herauskommt.

-CityLight-

PS:
Wenn der eine oder andere hier Rechtschreibfehler endeckt, dann darf er mir das ruhig mitteilen.
Denn dieser Bericht soll später mal als pdf-Version verfasst werden, möglichst ohne Fehler.
Aber bitte Fehler nur in gesammelter Form erläutern, und nicht jeden Buchstaben einzeln.


###############################################
Endpunkt zum Forum-Bericht: Teil-2
###############################################

@ CityLight: Sauber! 'Nen Popo voll Zeit, Aufwand, Nerven und Gehirnschmalz habt ihr da ja offensichtlich investiert, um das Projekt zu realisieren, analysieren und auszuwerten. Dafür erstmal: Hut ab!

Ich habe die ganze Geschichte bisher nur überflogen, werde mir demnächst aber mal Zeit nehmen, das ganze komplett nachzulesen. Da es hier im Forum trotz der Verlinkung der einzelnen Posts ein bisschen unübersichtlich ist, möchte ich anfragen, ob du/ihr den bisherigen Projektbericht einmal als PDF zusammenstellen könnte(s)t?

Antwort gerne auch per PM - die waren bei dir leider deaktiviert.

Zitat von Arrr!

... möchte ich anfragen, ob du/ihr den bisherigen Projektbericht einmal als PDF zusammenstellen könnte(s)t?

....ähhh... am besten noch mit "vorlesefunktion" und screens mit hintergrundmusik?!

Wie wär´s mit "Openoffice" das beinhaltet alles was es braucht.
Mit simplen "dragdrop" bekommst Du alles gebacken. Selbst die screens an den passenden Stellen eingefügt und "speichern als pdf " ist auch möglich.
Du kannst damit sogar, mit einigen Klicks eine richtige "Show" (.pps-kompat.) produzieren.


Sicher, für CityLight wär das auch kein Prob. Aber warum mal nebenbei das "große Fressen" noch in Häppchen schneiden und auf Festtafel Mundgerecht angerichtet servieren?

sry. war jetzt nicht abwertend gemeint. Nur als Denkanstoß, seine Kiste (PC) mal nicht nur zum spielen zu verwenden und das dann "arbeiten" nennen, sondern sie auch mal "kreativ" zu nutzen.

Wenn Du fertig bist...lade es hoch...ich bin sicher der erste der Dir einen virtuellen Orden verleiht.

Zitat von watt_ihr_volt

sry. war jetzt nicht abwertend gemeint. Nur als Denkanstoß, seine Kiste (PC) mal nicht nur zum spielen zu verwenden und das dann "arbeiten" nennen, sondern sie auch mal "kreativ" zu nutzen.

Ich habe dich doch gar nicht angesprochen... Oder?

Zitat von watt_ihr_volt

Wenn Du fertig bist...lade es hoch...ich bin sicher der erste der Dir einen virtuellen Orden verleiht.

Na klar - Schon einmal etwas vom Urherberrecht gehört?

Deinen Posts zufolge, sind wir auf der selben Seite, also spare dir doch lieber deine "Energien" für den "Feind"!

Zitat von Arrr!

Ich habe dich doch gar nicht angesprochen... Oder?

nö, eigentlich nicht, kann aber auch sein, dass ich meine Lautsprecher aus hatte und deswegen nichts hörte.
Da es aber in einem offenen Raum für jeden lesbar ist, musst Du damit rechnen, dass auch andere ihren Senf dazu geben.

Zitat von Arrr!

Na klar - Schon einmal etwas vom Urherberrecht gehört?

Du meinst, man kann jetzt auch schon für eigene Werke abgemahnt werden?

Zitat von Arrr!

Deinen Posts zufolge, sind wir auf der selben Seite, also spare dir doch lieber deine "Energien" für den "Feind"!

Ich weiß nur dass ich auf dieser Seite bin,[welche Örtlichkeit auch immer Du Dir da auch drunter vorstellen magst] und keine Feindbilder habe.

"...Die Urheberrechtsexperten Thomas Dreier, Thomas Hoeren und Annette Kur sehen die Gefahr, dass Zugangssperren für Urheberrechtsverletzungen hoffähig werden, wenn sie einmal in einem internationalen Abkommen aufgenommen werden..."

Rechtsexperten sehen Licht und Schatten im ACTA-Internet-Kapitel

Quelle: heise am 24.02.2010

Was kommt da wohl noch alles auf uns zu?

Zitat von Alter Esel

[I]"...Die Urheberrechtsexperten Thomas Dreier, Thomas Hoeren und Annette Kur sehen die Gefahr, dass Zugangssperren für Urheberrechtsverletzungen hoffähig werden, wenn sie einmal in einem internationalen Abkommen aufgenommen werden..."

Diese Gefahr sieht auch ein Blinder mit Krückstock ohne Experte sein zu müssen - selbst bevor Inhalte des ACTA-Abkommens öffentlich wurden. Nicht falsch verstehen: Natürlich ist sehr gut, dass die genannten Experten öffentlich warnen.