Hallo Zusammen,

Muss da mal was loswerden.............die ganzen Lieder sind ja meistens in guter Quali auch auf You tube zu finden.

Man nehme mal Scooter wird ja oder wurde von Korni abgemahnt
ich meine sogar Jumping all over the World.

So das letzte Lied ist bei You tube " Kontor TV" in HD anzusehen.

YouTube - Scooter - The Sound Above My Hair (Official Video HD)

Was unter Kontor nicht mehr laüft sind diese Lieder die abgemahnt werden

Mal so in den Raum gefragt da Jumpin all....... über 1,4 Millionen Aufrufe hatte.
Kanne es vieleicht auch sein das sie Testen wollen wie das Lied läuft und wenn es gut läuft auch noch Kasse damit machen wollen durch abmahnungen im P2P? durch Digi?

Zitat von CityLight

@all
...die Veröffentlichung des angekündigten Testberichts zu den tatsächlichen Logging-Möglichkeiten...

Bevor ich beginne, an diesem WE den angekündigten Testbericht zu veröffentlichen (auf Grund der Größe wird das in mehreren Teilen erfolgen), sollen vorab alle die Nutzer aufgefordert werden,
die in den letzten Wochen mit einem ed2k/Kad-P2P-Client (eMule & Co) im Netz unterwegs waren,
ihren UserHash (GUID) zu ändern. Dazu muss man z.B. beim eMule im Install-Ordner die Datei "onlinesig.dat", und im Unterordner \config die Dateien "cryptkey.dat" und "preferences.dat" löschen. Mit dem nächsten eMule-Start wird automatisch ein neuer UserHash (GUID) generiert, und die o.g. Dateien neu erzeugt. Damit wird allerdings auch das Credit-System zurückgesetzt. Nähere Informationen zu diesem Thema gibt es auf dieser WebSite.

Ich möchte nämlich nicht, dass sich der eine oder andere P2P-Nutzer auf einem der ScreenShots im Testbericht wieder findet. Alles kann im eigentlichen Testbericht nämlich nicht zugedeckt werden, wenn die Erläuterungen anschaulich bleiben sollen.
In diesem Bild gibts schon mal einen Vorgeschmack, welches Problem ich meine.

Bei dieser Gelegenheit sollte sich der Eine oder Andere P2P-Nutzer auch gleich mal Gedanken bezüglich des händisch eingetragenen Nick-Usernamen machen. Schaut man sich nämlich die wundersamsten Namen in diesem Bild an, dann ist für den Logger wirklich nichts mehr einfacher, einen Nutzer an mehreren Log-Tagen sofort wieder zu erkennen.

Und, wie heißt es immer so schön:

Ich danke für Ihre Aufmerksamkeit.

-CityLight-

Hi zusammen,

sagt mal. Wie ist es denn nun wenn ich aus dem 2-wöchigen Urlaub zurück bin und eine Abmahnung samt versäumter Frist im Briefkasten liegt? Die EV könnte ja dann schon unterwegs sein. Gibt es dort noch ein herauskommen? Kann doch auch nicht sein dass man jede Woche Briefkasten checken muss wegen den Heinis :/

Gruß

Zitat von Ein Mensch

Hi zusammen,
sagt mal. Wie ist es denn nun wenn ich aus dem 2-wöchigen Urlaub zurück bin und eine Abmahnung samt versäumter Frist im Briefkasten liegt?

Dann musst Du ganz schnell unsere mod UE runterladen, ausfüllen und zu Deinem Abmahner schicken.
Denn der hat ein Recht darauf. Dann geht alles seinen Gang..... So einfach ist das.

Hier geht es zu unserer straf- und gerichtsbewehrten mod UE: Muster einer abgeänderten Unterlassungserklärung

Vielen Dank! Die hab ich mir bereits geholt. Hammer Forum hier!

Gruß

In der Sendung Kontraste am letzten Donnerstag ging es um das Zivilrecht und die damit verbundenen Prozesse. In einem konkreten Fall hat eine Mieterin einen anderen Mieter (direkt unter ihr) per einstweiliger Verfügung untersagen lassen gegen die Zimmerdecke zu schlagen. Sie hat die EV auch durchbekommen und der Untermieter wurde unter Androhung einer Strafe untersagt weiter zu machen. So weit so gut. Jetzt kommt das Interessante:

Die Kosten für die EV (Gerichts - und auch Anwaltskosten der Antragstellerin) in Höhe von etwa 1000€ sollte natürlich der Beschuldigte bezahlen. Tat er aber nicht, weil er Hartz 4 Empfänger ist. Nach einem halben Jahr bekam nun die Antragstellerin die Rechnung und ist auch dazu verpflichtet die Kosten des Verfahrens zu übernehmen.

Aussage des Anwaltes hierzu:
Der Staat könne zwar zivilrechtlich eingreifen, aber nicht die Kosten hierfür übernehmen. Wenn der Beschuldigte zwar verurteilt wird, aber nicht zahlen kann, bleibt der Antragsteller auf den Kosten sitzen.

Die Kernaussage des Beitrages ist:
Wer zivilrechtlich gegen jemanden vorgeht, sollte vorsichtig sein. Unter Umständen bleibt der Kläger nämlich auf seinen Kosten sitzen. Insbesondere dann, wenn er Leute verklagt, die keine Kohle haben.

Also bestätigt sich wieder die allseits bekannte Vorgehensweise:

Keine Informationen für Abmahner, damit sinkt das Risiko einer Kostenklage immens, denn der Kläger trägt auf jeden Fall ein nicht unerhebliches Kostenrisiko!

Lg
Der Mondbär

Um noch mal auf meinen Beitrag zurückzukommen, ob man denn mit hundertprozentiger Wahrscheinlichkeit geloggt wurde: Ich habe auf youtube eine Reportage zum Abmahnwahn gesehen, in welcher uns der werte Herr Rasch durch seine Büroräume führte und uns auch gleich seine Gesellen zeigten, die das Netz nach IPs durchforsten.

Zumindest in diesem Beitrag war es so, dass Rasch sagte "HEUTE kümmert sich dieser Mitarbeiter um geschützte Werke der Firma XY." Dann wanderte er zum Nachbartisch und sagte: "Dieser Mitarbeiter hat sich HEUTE vorgenommen nach Werken von XY zu suchen."

Das hat mir wiederum vor Augen geführt, dass vielleicht doch nur tageweise bzw. in kurzen Perioden solche Such- und Protokollierungsaktionen der Antipiracy-Unternehmen durchgeführt werden.

Allerdings mag es sein, dass diese Reportage vor Zeiten gedreht wurde, als die Unternehmen dazu übergingen, automatisiertes Speichern via spezieller Software zu nutzen.

Noch mal eine andere Frage:

Habe ich das richtig verstanden, dass die Unternehmen / Anwälte keinen Anspruch auf IP-Adressen haben, die im Rahmen der Vorratsdatenspeicherung gespeichert wurden? D.h. beispielsweise bei der Telekom, dass die Anfrage nach der IP-Adresse ja weiterhin bereits nach 7 Tagen dort gestellt werden musste, oder? Andernfalls müsste es sich ja um einen unrechtmäßigen Zugriff auf Informationen der Vorratsdatenspeicherung handeln.

Zitat von DonHenley

Allerdings mag es sein, dass diese Reportage vor Zeiten gedreht wurde, als die Unternehmen dazu übergingen, automatisiertes Speichern via spezieller Software zu nutzen.

Möglich wäre auch, dass solche Reportagen nicht immer die alltägliche Wirklichkeit darstellen. Man sollte die Bereitschaft unserer Medien zur Realitätsveränderung nicht unterschätzen. Mir persönlich kamen diese "Berichte aus dem Loggerbuden-Alltag" immer seltsam überzeichnet - fast wie gestellt - vor. Eine rein persönliche Empfindung. Auch ich könnte mich täuschen. Ich halte aber kaum eine Berichterstattung in den Medien über Filesharing für neutral, oft sind das psychologisch ausgefeilte Propagandawerke.

Ich würde mich jedenfalls nicht darauf verlassen, dass nur zu normalen Arbeitszeiten geloggt wird. Die Beweismaschinen dürften Tag und Nacht rattern, möglicherweise auch bei der die proMedia, auf jeden Fall aber bei den anderen Abmahnsyndikaten, wo Sünder schon immer maschinell und vollautomatisch mit Hilfe von *kicher* unfassbar genialer Supersoftware gefangen wurden und werden.

Habe ich das richtig verstanden, dass die Unternehmen / Anwälte keinen Anspruch auf IP-Adressen haben, die im Rahmen der Vorratsdatenspeicherung gespeichert wurden?

Ja, das hast du richtig verstanden. Auf die Daten der VDS haben die ******** keinen Zugriff. Zugreifen dürfen sie (d.h. darf der Provider) aber auf diese komischen Zusatzdatenbestände, die zum Beispiel die T-Com sieben Tage lang "aus Sicherheitsgründen" speichert. Andere Anbieter (z.B.: Alice/HanseNet) führen keine solchen Zusatzdatenbestände. Daher werden Kunden solcher Anbieter viel seltener bis überhaupt nicht abgemahnt.

Zitat von CityLight

Geht leider nicht anders.

Doch, geht. Ihr könnt die Bilder auf meinen Server laden. Ich bräuchte dann nur irgendwie eine Kontaktadresse, Deine PN sind abgeschaltet.

Hier ist der erste Teil des angekündigten Testberichtes.

###############################################
Beginn zum Forum-Bericht: Teil-1 Teil-A
###############################################


Einleitung zum Testbericht (Log-Software im ed2k-Netz)
Ich habe mir zahlreiche Gedanken darüber gemacht, in welcher Form hier im Forum ein technisch recht komplizierter Testablauf überhaupt halbwegs verständlich erläutert werden soll, damit es keine seitenlange unverständliche Abhandlung wird. Aus diesem Grund habe ich mich entschlossen, hier nur auf das Notwendigste einzugehen. Bedeutet also, neben grundsätzlich notwendigen Erläuterungen (Basics) zur Logging-Möglichkeit und Logsoftware, werde ich mich darauf konzentrieren, die Argumente die immer wieder in den Abmahnungen behauptet werden, einmal gründlich zu hinterfragen ob denn "Das" überhaupt technisch umsetzbar ist. Es ist u.a. später auch vorgesehen, den Testbericht als PDF-Dokument zu verfassen. Mit zusätzlichen technischen Informationen, und vor allem mit hochauflösenden ScreenShots. Hier im Forum sind da leider einige Beschränkungen, bezüglich der zugelassenen Bild- und Dateigröße. Damit werden leider einige ScreenShots manchmal recht unscharf. Die Link-Variante der Bilder auf einem Image-Hoster habe ich erstmal verworfen, da finden in letzter Zeit zu viele wilde Löschaktionen statt, wovon selbst "wikileaks" nicht verschont geblieben ist. Insofern sind die ScreenShots also erst mal ein Kompromiss.
<a>
Weiterhin wird es hier keine ScreenShots zu der Logsoftware geben. Es soll vor allem möglichen rechtlichen Problemen bereits vorab aus dem Weg gegangen werden. Auch wenn die uns vorliegende Logsoftware defintiv auf einem modifizierten P2P-Client basiert, welcher eindeutig der GPL-Lizenz unterliegt, möchte ich vermeiden, dass hier einige Logger nicht noch "auf dumme Gedanken" kommen. Im aktuellen Abmahnwahn ist ja leider alles möglich. Es wird also lediglich Hinweise und ScreenShots dazu geben, wie die anfangs fragwürdige Logsoftware letztendlich doch eindeutig idendifiziert werden konnte, wie diese funktioniert bzw. aufgebaut ist, und welche Log-Daten diese tatsächlich produziert. Für die eigentlichen "scharfen" Tests wurde nämlich eine aktuelle eMule-Mod-Version nach dem Vorbild der Logsoftware modifiziert. Es wurde also eine Log-Umgebung nachgebaut, allerdings mit deutlich höherem Aufwand und Möglichkeiten.
Technisch versierte Leser mögen mir bitte nicht nachtragen/nachfragen, dass ich hier zahlreiche Vorgänge etwas unkonventionell erläutern muss. Immerhin sollen hier auch weniger technisch versierte Leser noch folgen können. Das gilt in erster Linie auch für mitlesende RA's, die sicher andere Probleme haben, als erst mal aufwändige P2P-Netzwerkmaterie zu studieren. Zudem möge man die recht häufigen Links und "Klickparaden" verzeihen, denn ohne diese ist ein so umfassender Beitrag nun mal nicht machbar.
<b>
Bevor es zu den Details geht, hier bereits der erste wichtige Hinweis und eine erste Frage.
Der gesamte Testablauf orientiert sich vorwiegend an den auf dieser Seite genannten folgenden Punkten:

* Verhinderung von Uploads
* Protokollierung von Benutzeraktivitäten
* Speicherung von Teilen der zu überwachenden Datei (Testdownload)

Und an dieser Stelle gleich das erste Paradoxon. Im Abschnitt "Die wichtigsten Daten, die FileWatch mitschreibt, sind die folgenden:" ist u.a. der folgende Text zu finden "ob der protokollierte Client versucht hat, Daten der beobachteten Datei von FileWatch herunterzuladen („u“ für „upload“)."
Dazu können wir nämlich gleich mal folgendes festhalten:
Selbstverständlich versucht der protokollierte Client "das", denn das ist ja der Sinn einer FileSharing-Software. Allerdings stellt sich hier die Frage, wenn "FileWatch" sämtliche Uploads selbst unterbindet, wozu ist diese Option "(u für upload)" denn dann überhaupt da ???



1.) Basics und technische Grundlagen
Dieser etwas umfangreiche Abschnitt soll erst mal wichtige und notwendige Grundlagen erläutern:
- 1.1 wie arbeitet die Log-Software
- 1.2 was kann eine Log-Software von einer "Gegenstelle" überhaupt sehen und erfassen/loggen
- 1.3 wird denn überhaupt eine Log-Software (Spezialsoftware ??) verwendet
- 1.4 welche Daten sind manipulierbar oder häufig fehlerhaft
- 1.5 technischer Aufwand um Log-Daten überhaupt zu filtern und zu verifizieren


1.1) Die getestete Logsoftware
Zuerst mal vorab. Ich denke schon, dass gewisse IT-Dienstleister (Logger) versuchen werden das nachfolgend Genannte zuerst in Frage zu stellen. Gewisse Presseerklärungen samt Wiederlegungsversuchen diverser Abmahnzellen sind immer nach der Veröffentlichung "brisanter" Berichte nicht nur diesem Forum ja mittlerweile bestens bekannt. Insofern wird dieser Abschnitt also etwas üppiger ausfallen.
<a>
Die Hintergründe, wie diese Logsoftware in unsere Hände geraten ist, sollen hier nicht näher erläutert werden. Nur soviel dazu, im INet werden in letzter Zeit erstaunlich häufig brisante Dinge zum Thema P2P-Abmahnwahn geleakt. Und hier war es eben mal eine Logsoftware, zumindest ein Teil davon. Ob das durch einen ehemaligen frustrierten Mitarbeiter, oder versehentlich geschehen ist, interessiert uns erst mal gar nicht. Ich sehe darin auch keine Probleme, falls irgendein sog. IT-Dienstleister (Logger) hier irgendwelche Ansprüche anmelden sollte. Hier sollte sich der eine oder andere Logger vorerst viel ernstere Gedanken bezüglich der o.g. GPL-Lizenz machen, und wie er das dann überzeugend begründen möchte. Ich erinnere da an diese kürzliche Verbeugung des Softwareriesen Microsoft vor dieser ketzerischen GPL-Lizenz. Die dachten nämlich auch, sie könnten sich einfach mal darüber hinwegsetzen, es wird schon keiner merken. Nun, da irrte sich wohl der Softwareriese.
<b>
Nun zur Logsoftware. Die uns vorliegende filewatch-Version, zumindest nannte sich das Archiv so, war gleich zu Beginn recht suspekt. Im Archiv befanden sich lediglich drei Dateien, eine "filewatch.exe" eine sog. "provider.dat" und eine "database.mdb". Keine Beschreibung, keine irgendwelchen Quellcodes, nichts... , einfach nur die drei Dateien. Die "filewatch.exe" stellte sich als Installer-Paket heraus, mehr dazu weiter unten.
Die sog. "provider.dat" wurde mit einem Editor geöffnet, und gab Erstaunliches preis. Eine komplette Liste mit allen IP-Adressbereichen und hinterlegten Namen aller Provider in Deutschland. Aufgebaut nach dem Vorbild der bekannten "ipfilter.dat", die u.a. vom eMule zum Blockieren "böser" IP-Bereiche/Adressen wird. Allerdings war diese "provider.dat" vorwiegend so definiert, bestimmte IP-Bereiche zu filtern, nur Deutschland eben. Wir konnten auch feststellen, dass der Stand recht veraltet, und vermutlich die bekannten IP-Range-Listen vom FTP-Server des RIPE NCC herangezogen wurden.
<c>
Bei der "database.mdb" (ein MS-Access Datenbankfile) wurde es richtig interessant. Kein Kennwortschutz, dafür höchst interessante Feldnamen, und 20 unvollständige Datensätze die jedoch eindeutig von einem ed2k-Client stammen mussten. Da waren zunächst zwanzig mal ein identischer MD4-Hash (ed2k, 32 Zeichen Länge). Interessant auch, die Feldlänge war hier in der Tabelle auf 40 Zeichen gesetzt. Also bereits vorbereitet für einen MD5-Hash (BitTorrent). Den ed2k-Hash haben wir natürlich bei shortypower eingegeben, und sind fündig geworden. Ein "Werk", welches wir auch in der Abmahndatenbank gefunden haben. Allerdings passte der mit dem Abmahner verbandelte Logger irgendwie nicht zu dem hier vorliegenden "FileWatch", dazu aber weiter unten mehr. Der Inhalt der restlichen Datenfelder der "database.mdb" war ebenfalls recht schnell aufgeklärt, es waren defintiv Log-Daten aus einem ed2k-Client. Weitere Details lassen wir jetzt hier weg, die gibts dann später in der "langen" pdf-Version. Ebenso hatten wir zu diesem Zeitpunkt bereits ein internes P2P-Netz vorbereitet. Bestehend aus mehreren Rechnern, und u.a. auch einem lugdunum-ed2k-Server (dazu gibts ja vorkonfigurierte Images im INet). Weitere Details dazu ebenfalls in der pdf-Version.
<d>
Jetzt war das Installer-Paket "filewatch.exe" auf einem Test-Rechner an der Reihe. Und hier hagelte es Fehlermeldungen zu nicht gefundenen Ordner-Pfaden, die Installation unter WinXP klappte nicht. Der befreundete Applikations-Entwickler erkannte das Problem sofort. Das Installer-Paket wurde offenbar unter Win2000 erstellt und enthielt einen kleinen (aber bösen) Fehler, der nach seiner Praxis sehr oft leicht übersehen wird. Ohne weiter ins Detail zu gehen, auf dem Test-Rechner wurde Win2000 installiert (das musste erst mal irgendwo wieder ausgegraben werden), und die Installation wiederholt. Diesmal gab es keine Probleme.
<e>
Und jetzt war "Bauklötzer staunen" angesagt, es präsentierte sich die bekannte Oberfläche einer Shareaza 2.1 Version. Besonders konfus, die Option für BitTorrent-Netzwerke konnte nicht aktiviert werden. Obwohl die genannte "veraltete" Version das eigentlich laut sourceforge.net beherrschen sollte. Ohne weitere Details, wir haben den sog. Logging-Client einfach in Gang gesetzt, und trafen nach nur 30 Sekunden auf das nächste Problem. Der als "Logging-Opfer"-Gegenstelle gestartete P2P-Client mit einer recht neuen eMule 0.49c-Mod-Extreme-Version idendifizierte den Logging-Client als Leecher-Version (Shareaza 2.1 Leecher-Edition), und bretterte ihn erst mal gleich auf die Bann-Liste. Also mussten wir erst einmal die Leecher-Erkennung
>> TestScreen001 <<
deaktivieren. Die weiteren Details gibts dann in der pdf-Version.
<f>
Nach diesem ersten Testlauf haben wir erstmal den Logvorgang gestoppt, haben uns die geloggten Daten in der "database.mdb" angesehen, und waren trotz erst mal funktionierender Logging-Funktion irgendwie ratlos. Ein Shareaza-Client der kein BitTorrent beherrscht, der TaskProzess-Name lautete "filewatch.exe", und auch die aufgezeichneten Log-Daten entsprachen nicht der "FileWatch"-Beschreibung auf der o.g. WebSite. Wir hatten also definitiv eine Logsoftware, jedoch mit offenbar falschem Namen, keinen QuellCode, keine Beschreibung, einfach nichts. Auch der mittlerweile noch hinzugezogene befreundete Programmierer (ein C++ und u.a. auch P2P-Profi) hatte ebenfalls keine Lust mehr die Software noch weiter auseinander zu nehmen.
<g>
Und in einem solchem Falle befragt man also erst mal die Datenkrake Google, die kennt nämlich Alles und Jeden, und vergisst absolut nix. Also haben wir mit den Feldnamen aus der "database.mdb" mal das Netz durchforstet, und sind fündig geworden. Die Suche führte uns zu einem geleakten pdf-Dokument von "Davenport Lyons" aka "Logistep". Und das kannte ich bereits. Der User @USA/Baxter/... hatte es ja freundlicherweise in diesem Posting mal vorsorglich sichergestellt. Leider funktioniert mittlerweile dieser Link auf das Dokument nicht mehr. Zum Glück hatte ich es jedoch damals sichergestellt. Und hier sind wir auf sehr interessante Gemeinsamkeiten bezüglich der vorliegenden Logsoftware gestoßen. Hier ein paar ScreenShots dazu:
>> TestScreen002 << - Ein modifizierter Shareaza-2.1.0-Client, kein direkter Hinweis auf BitTorrent.
>> TestScreen003 << - verhält sich wie ein "normaler" Client in der Warteschlange
>> TestScreen004 << - die Logdaten-Angaben passen
>> TestScreen005 << - Ausgabe in das Datenbankfile
>> TestScreen006 << - die Feldnamen aus der Datenbank-Reportdefinition passen
Und dann gab es da noch von @USA/Baxter dieses Posting mit diesem SreenShot.
>> TestScreen007 << - Logdaten finden sich im sog. "Management-Tool" wieder
<h>
Jetzt könnte man meinen, wir hätten die Logsoftware (zumindest das P2P-Log-Modul) von Logistep vorliegen. Die Antwort lautet leider [B]Nein[B], und wir wissen es nicht genau. Denn es ergeben sich eine Reihe offener Fragen. Logistep bezeichnet seine Logsoftware als "File Sharing Monitor", bei uns lautet das "filewatch.exe". Zudem beherrscht laut dem pdf-Dokument (Logging-Auszug im Anhang) von "Davenport Lyons" die Logistep-Software BitTorrent-Netzwerke. Ein neuerer Bericht dazu, den wir übrigens auf dieser WebSite (Link ganz unten) gefunden haben, bestätigt das auch. In der uns vorliegenden Software funktioniert BitTorrent jedoch nicht. Zu der genannten Log-Software "FileWatch" will unsere Software auch nicht so recht passen.
Unsere Vermutung geht dahin, dass die Logistep-Software offenbar an "andere Interessenten" weiter veräußert werden sollte, und hier bei uns eine Test-Version irgendwo dazwischen vorliegt. Vermutlich hatte sich irgendein Programmierer bereits daran gemacht, es als "Filewatch" umzubauen, und über "den" ist die Software offenbar ins INet gelangt. Ob das tatsächlich so ist, wissen wir eben auch nicht. Es bleiben Vermutungen. Zudem mussten wir feststellen, dass die uns vorliegende Log-Software nicht alle Informationen so aufzeichnet, wie das z.B. in der Beschreibung von "FileWatch" der Fall ist.
<i>
Also haben wir uns an dieser Stelle entschlossen, eine eigene Logging-Umgebung nachzubauen, allerdings mit deutlich höherem Technik-Aufwand, der nach unserer Ansicht überhaupt ein halbwegs sicheres Logging ermöglichen würde. Also nicht dieser von zwielichtigen Gutachtern und einigen Abmahnzellen immer wieder behauptete, technisch formulierte Schwachsinn. Damit auch die technischen Erläuterungen sowie auch dieser Test selbst überhaupt noch beherrschbar bleiben, haben wir uns hier nur auf das ed2k/Kad-Netz beschränkt. Dazu ist u.a eine eMule-Mod-Extreme-7.2 Version zum Einsatz gekommen, die von unserem Programmierer nach unseren Belangen entsprechend modifiziert wurde. Ein Problem war das für unseren C++ Profi überhaupt nicht, denn die aktuellen eMule-Mod-Versionen gelten nicht nur als absolut ausgereift, es gibt auch einen unendlichen Fundus an Beschreibungen, Quellcodes, Ressourcen, usw. Und wer von dieser Materie etwas versteht und auf diese WebSite schaut, der wird erkennen, dass praktisch jede Funktion im eMule programmtechnisch nachvollziehbar ist.
Ich behaupte an dieser Stelle sogar, dass einige Loggerbuden, oder von denen beauftragte Programmierer, sich auf dieser Seite ausgiebig bedient haben.


1.2) was kann eine Logsoftware sehen und erfassen
Bevor ich mit den ersten Details beginne, soll noch einmal auf dieses frühere Posting verwiesen werden. Hier wurden bereits einige Details dazu grundlegend erläutert. Auf die grundlegende Technik, wie hier was genau funktioniert, soll hier nicht weiter eingegangen werden. Das ist für die pdf-Version geplant. Als Wiederholung auch hier der Hinweis, es wird ausschließlich die servergestützte ed2k-Technik (eMule & Co) erläutert. Das sieht in der Technik hinter BitTorrent & Co eigentlich fast genau so aus, aber im Detail ist die Funktionsweise hier doch etwas anders, und von einem Laien nur schwer zu verstehen. Das ed2k-Netz lässt sich da leichter erklären. Leicht verständliche Infos dazu gibts u.a. auf dieser eMule-WebSite.
<a>
Bevor wir loslegen, wieder als Erinnerung: Alles was der eMule vom Client der Gegenstelle anzeigen kann (auch z.B. in Form von Grafik-Balken), dass muss ja von irgendwelchen Zahlen im Programm-Hintergrund gebildet werden. Und genau diese lassen sich auch in eine Datei "umlenken" oder kopieren, eben in eine Log-Datei zum Beispiel. Selbst eine eMule-Standard-Version bringt über die Option "Log/Verbose" bereits zahlreiche Funktionen mit, eine Log-Datei zu erzeugen. Das ist unter anderem auf dieser WebSite sehr schön zu sehen. Einige "erweiterte" eMule-Mod-Versionen gehen da sogar noch weiter ins Detail. Das ist alles nur eine Frage der Programmierung.
Aber auch hier gilt vereinfacht gesagt: Alles was die beste eMule-Mod-Version nicht "in Form von Zahlen o.ä." zur Anzeige bringen kann, dass kann die loggende Gegenstelle auch unmöglich feststellen. Dieser Grundsatz gilt erst mal.
An dieser Stelle aber gleich ein sehr wichtiges Detail. Auch wenn in nahezu allen Menüs des eMule kein "TimeStamp" zu sehen ist, wird dieser im Hintergrund trotzdem in eine Log-Datei mit ausgegeben, und zwar auch mit Datum.
>> TestScreen008 << - hier ist das deutlich zu sehen
Im weiteren Schritt gibt es dann aber noch die zahlreichen Sicherheitsfunktionen. Diese führen dazu, dass die Logsoftware von der Gegenstelle bestimmte Informationen gar nicht erst erhält, oder sogar gleich die Verbindung abgewiesen bzw. blockiert wird. Dann sieht der Log-Client hier gar nichts mehr.
>> TestScreen009 << - hier haben wir z.B. einige dieser Sicherheitsfunktionen
An dieser Stelle soll gleich einem Einwurf vorgebeugt werden. Standardmäßig ist der IP-Filter nach der ersten Installation des eMule zwar ausgeschaltet. Jedoch genügt es bereits, wenn sich eine "ipfilter.dat" im "\config"-Ordner befindet, die IP-Filterung bereits wirksam werden zu lassen.
>> TestScreen010 << - und die Leecher-Erkennung einer eMule-Mod-Extreme-Version
Zusammengefasst bedeutet das also, wenn der Logging-Client sich hier nicht selbst "an gewisse Regeln" hält, dann bekommt er entweder keine Infos mehr, oder er wird gleich auf der Gegenstelle komplett blockiert. Und das gerade diese Leecher-Erkennung sehr wirkungsvoll arbeitet, haben wir bereits im Abschnitt "1.1) <e>" zu spüren bekommen.
<b>
Also, zunächst einmal müssen wir natürlich auf Dateisuche gehen, wenn wir den ed2k-Link für unser zu loggendes Werk nämlich nicht kennen. Diesen Link können wir uns natürlich auch von einer "esel-Seite" besorgen. Ich behaupte sogar, die meisten Logger machen zu Beginn genau "das". Aber wir haben eben keinen ed2k-Link, und müssen das Werk selbst mit unserem Log-Client suchen.
>> TestScreen011 << - das sieht dann so aus
So richtig was zum Loggen (Clients) haben wir da aber leider immer noch nicht. Neben dem ed2k-Link und einigen Datei-Infos sehen wir allenfalls noch, ob hier irgendwelche Fake-Namen unterwegs sind. Ob das die Logger überhaupt abprüfen ??
>> TestScreen012 << - hier sind die Datei-Details
Und wir sehen gleich einen Hinweis auf einen Fake. Ein eindeutiger Beweis ist das allerdings nicht. Dieses Anzeigefeld basiert nämlich auf einer "Datei-Bewertung", die von jedem Nutzer geändert werden kann. Eigentlich müssten wir jetzt erst mal weiter prüfen, ob es sich hier tatsächlich um unser zu loggendes Werk von "Pink Floyd" handelt. Und diese Prüfung haben wir natürlich gleich mal hier gemacht. Auf den ersten Blick sehen wir, es handelt sich wohl um einen Porno. Allerdings, in der Anzeige könnte auch stehen, 10x Pink Floyd und 2x Porno. Wir haben also immer noch keinen eindeutigen Beweis. Und dazu laden wir das Werk herunter, als Beweissicherung und zur Überprüfung. So wie es von den Loggern ja immer wieder behauptet wird. Das bedeutet aber jetzt auch, wir müssen das Werk selbst zum Download einstellen (wohlgemerkt, ohne Upload natürlich). Und im Anschnitt "1.1) <g> TestScreen003" war auch zu lesen, dass das genau so gemacht wird. Und bei dieser Gelegenheit können wir auch gleich Loggen, wenn wir sowieso schon beim Laden sind. An dieser Stelle wird es bereits interessant. Machen das die Logger so ?? Ich behaupte, JA.
<c>
Führen wir uns nämlich mal folgendes vor Augen. Wir versuchen eine mehrere hundert Megabyte große Datei zu laden, ohne jeglichen Upload. Weil wir damit das Credit-System nicht nutzen können, landen wir in der Warteschlange bei den Gegenstellen jedes mal "ganz hinten im Bus". Zudem werden uns auf Grund der Leecher-Erkennung zahlreiche Clients immer wieder auf die Bann-Liste verdonnern. Wir bräuchten also einen recht langen Zeitraum, um das Werk zur Ansicht und Beweissicherung überhaupt erst mal runterzuladen. Kommt noch hinzu, wenn wir es mit einem Archiv oder einem Image zu tun haben, dann brauchen wir die Datei zur Ansicht vollständig. Betrachtet man sich jetzt noch die Zeitspanne, wann abgemahnte Werke auf einer "esel-Seite" erschienen sind, und wann diese bereits angeblich schon geloggt wurden, dann sind hier Zweifel angebracht. Insofern behaupte ich nämlich, mit dem ersten Download zur Beweissicherung/Ansicht wird gleich fleißig "ins Blaue" geloggt. Wenn wir es nämlich dann endlich mal geschafft haben das Werk vollständig zu laden, und es ist nach Ansicht tatsächlich "unser Werk", dann haben wir eine Menge an geloggten Clients ganz effektiv gleich nebenbei mit auf Lager. Die entscheidende Frage ist natürlich, was passiert mit den hier völlig zu Unrecht ermittelten Log-Daten, wenn es nach Beweis-Ansicht eben nicht "unser Werk" war. In der geplanten pdf-Version werden dann zusätzliche Details dazu enthalten sein, was an diesem eben genannten Punkt tatsächlich veranstaltet wird. Ein bis hier nicht genannter Logger wird sich dann ganz warm anziehen dürfen.
<d>
Im weiteren Verlauf wird jetzt nur auf solche Daten verwiesen, die sich ermitteln lassen und die auch für das Logging überhaupt sinnvoll wären. In vielen Menüs werden nämlich auch Werte angezeigt, deren Aufzeichnung als Log-Daten nutzlos ist.
>> TestScreen013 << - der Download wurde gestartet
Wir sehen zum Werk einen vollständig blauen Balken, damit ist es vollständig zum Download verfügbar. Eine genaue Beschreibung, was die Grafikbalken genau bedeuten, findet sich hier. Wichtig an dieser Stelle, der Grafikbalken wird aus Zahlenwerten im Hintergrund berechnet. Dahinter verbirgt sich nämlich das sog. Part-HashSet, und das ist aus meiner Sicht ganz besonders wichtig. Denn dieses wird als Berechnungsgrundlage für sämtliche Anzeigen zu Quellenverfügbarkeit und Dateiteilen herangezogen. Für das Werk können wir das Part-HashSet aufrufen, und auch sichern/loggen.
>> TestScreen014 << - zusätzlich zu den Datei-Infos
>> TestScreen015 << - loggen wir noch das komplette Part-HashSet
Ob die Logger das tatsächlich verwenden, können wir nicht beantworten. Zumindest bei "FileWatch" wird es erwähnt. Nach meiner Ansicht braucht man es für ein beweissicheres Logging auf jeden Fall.
Interessant hier noch, trotz geringer Quellenzahl hat der Download sofort gestartet. Allerdings hält dieser Zustand nicht sehr lange an. Der Grund liegt in der Kombination "Credit-System" und "neuer Benutzer", und ist hier erwähnt.
<e>
In den folgenden Bildern ermitteln wir die Daten zu einer Gegenstelle. Diesen Teil sollte man sich genau einprägen, denn hier ergeben sich nämlich in den späteren Tests die meisten ungeklärten Fragen, bezüglich Loggerbuden und Beweissicherheit.
Auch hier noch eine Anmerkung. In den späteren "scharfen" Tests werden einige Teile (z.B. Werkname, DateiHash) grundsätzlich abgedeckt sein. Nicht das hier einige Loggerbuden noch an Hand der ScreenShots auf "dumme Gedanken" bezüglich Abmahnen kommen.
>> TestScreen016 << - im oberen Teil die Warteschlange, unterer Teil die automatische Client-Selektion
>> TestScreen017 << - die zugehörigen Details vom selektierten Client
Wie hier die "automatische Client-Selektion" programmiertechnisch gelöst wurde, soll hier nicht näher erläutert werden. Die "gewöhnliche" eMule-Version macht das nämlich nicht.
An dieser Stelle können wir bereits alles loggen, was für den Ertappten irgendwie "böse" ist. Zuerst schauen wir uns aber im Bild016 im oberen Teil die Balken-Grafik an. Wie bereits oben bemerkt, verbirgt sich auch hier ein Part-HashSet dahinter. Und zwar diese Teile des Werkes, die der selektierte Client bereits in seinem Share stehen hat. In der Mitte der Anzeige wird daraus der Prozent-Wert berechnet. Wichtig allerdings hierbei, das vorhandene Part-HashSet der Gegenstelle können wir nicht mit einem Menü aufrufen (wie in Bild015). Allerdings kann der eMule das im Hintergrund trotzdem verarbeiten und der Gegenstelle zuordnen. Das sieht in etwa so aus:
>> TestScreen018 << - die Nummer "0000" steht für den Datei-Hash des Werkes (siehe Bild014)
<f>
Und jetzt betrachten wir uns im Bild016 noch einmal genau den unteren Teil. Da steht bei "Hoch+Heruntergeladen" nämlich genau "0 Bytes". Und diese Anzeige bezieht sich auf die Datenmenge, die die angezeigte Gegenstelle mit unserem Logging-Client getauscht hat, nämlich gar nix. Es gibt nämlich keine Möglichkeit festzustellen, welche Teile der Datei die Gegenstelle mit anderen Nutzern getauscht hat, und ob "sie" das überhaupt getan hat. Hat die Gegenstelle nämlich z.B. das komplette Werk zufällig in einem freigegebenen Ordner stehen, dann steht die Anzeige aus Bild016-oberer-Teil nämlich auch auf 100%. Und zwar ohne dass der User das Werk jemals Down/Uploaded hat.
Fassen wir hier also zusammen:
Mit der Anzeige des Part-HashSet einer Gegenstelle können wir nur sehen, welche Teile des Werkes in einem freigegebenen Ordner liegen. Und dass muss wohlgemerkt noch nicht einmal die Festplatte der Gegenstelle sein (Stichwort: FTP-Netzwerkfreigaben).
Die Anzeige des Part-HashSet der Gegenstelle zeigt uns nur die dort vorhanden Teile zum Datei-Hash (Werk) an. Auch wenn sich die Anzeige des Part-HashSet verändert, können wir allenfalls eine vage Vermutung anstellen, dass unsere Gegenstelle einen Up/Download noch mit anderen Gegenstellen durchgeführt hat. Beweisen können wir das nicht einmal im Ansatz. Denn dazu müssten wir den P2P-Datenverkehr kennen, den unsere Gegenstelle mit den anderen Gegenstellen durchgeführt. Und das ist technisch nun mal nicht möglich.
Und dieses Fazit sollten wir uns jetzt gaaaaanz genau einprägen. Im letzten Teil des Tests wird noch genau auf dieses Problem eingegangen, welches nämlich das komplette Abmahn/Logging-Wesen in Frage könnte.
<g>
In den nächsten zwei Bildern können wir einen Upload der Gegenstelle belegen. Bedeutet, unser Logging-Client hat es geschafft, von der Gegenstelle zu Downloaden. Also genau das, was die Loggerbuden eigentlich nachweisen müssten. Aber aufgepasst, der Teufel steckt im Detail bzw. in einem fehlenden TimeStamp.
>> TestScreen019 << - ein angezeigter Download, jedoch keine aktive Verbindung
>> TestScreen020 << - die Client-Details dazu
In diesem Bild019 konnten wir einen Download von der Gegenstelle (sie hat also zu uns geuploaded) feststellen. Allerdings zeigt uns die Anzeige "Verbindung = Nein" und "Upload = leer" an. Mehr zu dieser Anzeige im nächsten Abschnitt. Das bedeutet jetzt, wissen dass die Gegenstelle zu uns 520 KByte geuploaded hat, aber wir wissen nicht wann das war. Dazu brauchen wir nämlich mindestens einen "vorherigen" Log-Datensatz (TimeStamp). Und wenn wir diesen nicht haben, oder durch irgendeinen Fehler nicht mehr richtig zuordnen können, dann haben wir Pech gehabt. Wir sehen jetzt nur, "der hat geuploaded", aber wir wissen nicht wann.
Fassen wir also auch hier zusammen:
Nur ein einzelner TimeStamp genügt eben nicht, um einen Upload eindeutig nachzuweisen.
Auch das sollten wir uns sehr genau einprägen.
<h>
In den nächsten zwei Bildern kommen wir zum umgekehrten Fall.
>> TestScreen021 << - ein angezeigter Download, mit laufender aktiver Verbindung
>> TestScreen022 << - die Client-Details dazu
In diesem Bild021 ist es uns trotz Leecher-Modus (denn wir dürfen ja selbst nicht Uploaden) endlich mal gelungen, eine Gegenstelle beim Upload (wir laden dort also herunter) praktisch auf "frischer Tat" zu ertappen. Im Prinzip könnte man das zumindest im Ansatz als Beweis durchgehen lassen, wenn da nicht noch ein "technisches" Problem mit den beiden Anzeigen "Verbindung" und "Upload" wäre.
Diese beiden Anzeigen signalisieren nämlich lediglich, dass eine Verbindung zur rechts daneben angezeigten IP-Adresse besteht, und dass wir gerade Daten empfangen. Welche Art Daten das sind, sagt uns die Anzeige nämlich nicht. Diese Anzeige springt nämlich auch über einen bestimmten Zeitraum auf "Verbindung = Ja" und "Upload = <<", wenn unser Log-Client eine Statusabfrage über eine Kad-Verbindung (Kademlia, serverlose Verbindung) gesendet, und darauf hin den Quellenstatus zurück erhält. Und wenn wir uns jetzt das Bild022 anschauen, sehen wir nämlich eine aktive Kad-Verbindung. Damit stehen wir vor dem gleichen Problem, wie im Abschnitt <g> erwähnt. Bedeutet also auch hier, ein einzelner TimeStamp genügt nicht. Um hier tatsächlich einen Upload der Gegenstelle zu belegen, müssten wir nämlich die Anzeige "Heruntergeladen" über einen längeren Zeitraum überwachen, ob der angezeigte Wert deutlich nach oben geht.
Ein tatsächlicher Upload der Gegenstelle lässt sich eigentlich nur feststellen, wenn dieser über einen längeren Zeitraum aufgezeichnet wird.
Die restlichen Anzeigen im eMule bzw. Angaben die man aufzeichnen könnte, sind für den eigentlichen Logvorgang eher nebensächlich, und sollen an dieser Stelle auch nicht weiter erläutert werden.


1.3) Verwenden denn die Logger überhaupt eine Log-Software (Spezialsoftware??)
An dieser Stelle werden sich wohl Einige jetzt fragen, ob wir evtl. einen Joint zuviel geraucht haben. Zuerst untersuchen wir die sog. Spezialsoftware, und dann stellen wir in Frage das "diese" überhaupt verwendet wird. Nun denn, wir haben keinen zuviel geraucht, sondern mal lediglich den "Blick-Horizont" etwas erweitert. Und das sollten an dieser Stelle auch mal einige Richter tun.
Zunächst betrachten wir uns doch mal die Abmahnungen selbst. Da ist durchweg die Rede von, Spezialsoftware, Spezial-Firma, vereidigter EDV-Sachverständiger, Spezial-Gutachten, eidesstattliche Erklärungen, usw. Also die ganze Palette an undurchsichtigen Dingen, die bis heute noch keiner so richtig gesehen hat. Alles irgendwie "Top Secret" bei den Abmahnzellen. Und die meisten Richter haben diese Dinge bisher sicher auch noch nicht gesehen, und fragen auch erst gar nicht danach. Die Spezial-Firma, als qualifizierte EDV-Fachfirma sozusagen, wird schon recht haben. Eben nicht substantiiert, das irgendwie anzuzweifeln.
<a>
Jetzt machen wir mal einen Blick zurück, und schauen uns genau die letzte Kommentarzeile in diesem Web-Beitrag an. Und jetzt schauen wir uns mal auf dieser Web-Site und auf dieser Web-Site genau das Produkt-Portfolio dieser Spezialfirma an. Also für meinen Teil stellt sich da eher die Frage, ob hier nicht der hauseigene Angestellte EDV-Fachmann (den es sicherlich hier geben wird) von "Cheffe" mal eben "animiert" wurde, ein paar simple P2P-Clients (zwecks Logging und "Kohle verdienen") aufzustellen. Immerhin generieren diese Dinger ja ne Menge Logdaten selbst (Stichwort: verbose.log), die man ja mit einem x-beliebigen Datenbank-Programm einlesen kann. Zur Not kann das ja auch ein EDV-Student mal als Nebenjob übernehmen. Und hier werden sich die meisten fragen, geht denn das überhaupt.
<b>
Dann werden wir mal an einem einfachen Beispiel zeigen, was eine gewöhnliche (also nicht extra umgebaute) eMule-Mod-Extreme-Version bereits in punkto Log-Daten leistet. Und diese eben genannte "eMule-Baureihe" gibt es nicht erst seit gestern.
>> TestScreen023 << - die Log-Optionen
Im Bild023 sehen die Log-Möglichkeiten, die bereits eine unveränderte Mod-Version bietet. Auf die Bedeutung der Optionen soll nicht weiter eingegangen werden. Anzumerken noch, der "Log Level = 5" ist die Standard-Einstellung und wurde nicht verändert.
>> TestScreen024 << - das Standard-Fenster der eMule-Mod-Version
Im Bild024 sehen wir im oberen Teil die Warteschlange, und das wir gerade von der Gegenstelle "Gnyrf!" (schwarze Strichmarkierung) herunterladen. Die Gegenstelle uploaded also zu uns. Weiterhin sehen wir, es wurden bereits 290kByte an Daten zu uns übertragen. Dieser Wert gilt immer nur für die aktuelle Verbindung. Im unteren Teil sehen wir die Details der Gegenstelle. Wer die vorherigen Abschnitte aufmerksam gelesen hat, kennt ja bereits die Bedeutung der einzelnen Felder.
>> TestScreen025 << - das Detail-Fenster der Gegenstelle
Der Unterschied zum vorherigen Fenster basiert darauf, dass die ScreenShots manuell mit einem bestimmten Zeitabstand ausgelöst wurden. In dieser Zeit hat die Gegenstelle ja weiter Daten zu uns übertragen. Der Wert "Uploaded = 310 KB" zeigt uns die Datenmenge der Gegenstelle an, die während der gerade laufenden Verbindung zu uns übertragen wurden. Im zweiten Wert "Uploaded gesamt = 4.14 MB" wird die Menge aus dem ersten immer gleich aufsummiert. Daraus resultiert jedoch auch, die Gegenstelle muss bereits zu einem früheren Zeitpunkt zu uns geuploaded haben. Das kann durchaus mehrere Tage zurückliegen. Es müssen also frühere auch Log-Datensätze vorhanden sein. Darauf wollen wir jetzt nicht weiter eingehen.
>> TestScreen026 << - die Logdatei (verbose.log) des eMule
Im Bild026 sehen wir den Inhalt der Logdatei. Die Einträge folgen programmtechnisch bedingt immer einem bestimmten Muster. Die Datumsangabe vor dem TimeStamp haben wir ausgeblendet.
>> TestScreen027 << - aus der Logdatei wichtige Einträge extrahiert
Im Bild027 haben wir zum besseren Verständnis mal nur ein paar wichtige Einträge extrahiert und markiert. Bereits an diesem simplen Beispiel sehen wir bereits, wann die Verbindung zur Gegenstelle begonnen hat, wann sie geendet hat, und wieviel Daten zu uns übertragen wurden. Zu erwähnen noch der Eintrag "You cancelled the download". Bedeutet, im Log ist bereits sogar zu sehen, dass wir den Download manuell gestoppt haben, und anschließend die Anwendung komplett beendet wurde.
<c>
Dieses Beispiel zeigt also bereits sehr eindrucksvoll, dass es selbst mit einer gewöhnlichen eMule-Version möglich ist, die Grundlage für eine komplette Logging-Umgebung zu schaffen. Die eigentliche Kunst besteht dann nur noch darin, mit einer Datenbankanwendung die Logdateien einzulesen, zu Filtern und zu Sortieren, und die entsprechenden Provider zu den IP-Adressen zu ermitteln. Das lässt sich über ein "Whois-Tool" gleich mit von der Datenbank-Anwendung aus erledigen. Eine solche Datenbank-Anwendung zu programmieren, das bekommt jeder halbwegs fähige IT-Student hin. Deutlich komplizierter und viel teurer wird es da schon, einen fähigen Programmierer zu finden, der eine eMule-Mod-Version komplett auf die eigenen Erfordernisse einer Loggerbude vollständig umbaut. Ein Problem ist das natürlich nicht.
Betrachten wir uns jetzt abschließend noch einmal einfach nur die im Abschnitt <a> genannte Loggerbude, dann sollten wir uns spätestens hier die Frage stellen, warum auch von den anderen bekannten Loggerbuden bisher nirgendwo mit Details rausgerückt wird, welche Art Log-Software überhaupt verwendet wird, und welche Logging-Umgebung (Datenbank) hier überhaupt beweissicher zum Einsatz kommt. Es bleiben also noch immer eine Menge Fragen offen, die eigentlich die Gerichte den Loggerbuden stellen sollten, und nicht dem Abgemahnten.

###############################################
Trennungspunkt zum Forum-Bericht: Teil-1 Teil-B
###############################################

Der Testbericht wird in Kürze an diese Stelle mit den noch fehlenden Punkten 1.4) und 1.5) fortgesetzt.
Der eigentliche "scharfe" Testbericht Teil-2 ist noch in Arbeit. Auf Grund der enormen Datenmenge und der unzähligen ScreenShots musste ich für die Veröffentlichung hier im Forum den gesamten Bericht grafisch aufbereiten, damit es noch übersichtlich bleibt. Da das ein enorm hoher Aufwand ist, kann also noch einige Tage dauern.

-CityLight-

Zitat von CityLight

Hier ist der erste Teil des angekündigten Testberichtes.
-CityLight-

RESPEKT -CityLight-

Da haben sich die ************ mit Dir wohl genau den falschen Gegner ausgesucht.
Ich find`s klasse was Du Dir für Arbeit machst die Technik zu durchleuchten.
Wenn sowas erstmal von einem OLG nachvollzogen wird, dann dürfte wohl das ganze Geschäftsmodell auseinanderbrechen.

Schade dann halt um diejenigen die bereits überwiesen haben.

@CityLight:
Ich möchte meine Bewunderung aussprechen für alles, was du bereits geleistet und berichtet hast. Andere haben über die prinzipiellen Schwächen der Logmethoden referiert, aber du und deine Mitwirkenden, ihr habt die Möglichkeiten konkret ausgelotst. Vor einem Jahr schwebte mir etwas Ähnliches vor, aber trotz jahrelanger Erfahrung als Datenbankentwickler und objektorientierter Programmierer fehlt mir die Erfahrung mit C++ und auch - muss ich zugeben - ein bisschen den Mumm, meine Anschlüsse für ein solches Projekt herzugeben.

In der Diskussion über die von euch entdeckte Software und ihre fehlende Bittorrent-Fähigkeit verlinkst du Davenport-Lyons-Korrespondenz von Nov 2008. Diese bezieht sich allerdings nicht auf einen Logvorgang von Logistep, sondern auf Daten von DigiProtect und Scooter von April 2008. Zu diesem Zeitpunkt hat die Kooperation mit Logistep bereits aufgehört (siehe Fax an gulli). Daher können wir vermuten, dass diese Daten von einem frühen Logvorgang von Digirights Solution GmbH stammen, auch wenn die Firma erst im Juni 2008 in Darmstadt ins Handelsregister eingetragen wurde. In ihrer PPT-Präsentation nennen sie die Software Filewatch. So ist es naheliegend, dass das was euch in die Hände gefallen ist, ein früher Entwurf dieses Projekts ist.

Nun zu den Ergebnissen. Ich teile deine Ansicht, dass das Part-HashSet des geloggten Clients besonders wichtig ist. Mit verschiedenen Argumenten willst du dann zeigen, dass ein einzelner Zeitstempel (TimeStamp) nicht ausreichend ist, um ein Upload vom geloggten Client zu beweisen. Du schreibst allerdings von Uploads in der Größenordnung von mehreren Hundert KByte. An anderer Stelle schreibst du "über einen längeren Zeitraum überwachen, ob der angezeigte Wert deutlich nach oben geht". Das scheint mir leider falsch. Es genügt, ein Mini-Download zu beweisen - siehe die Diskussion mit RA Eikmeier im rka-Thread. Daher denke ich, dass die Log-Software so modifiziert ist, dass sie nur einen kleinen Block mit der Message "OP_REQUESTPARTS" anfragt. Bei Bittorrent wird ein "request <id=6>" ohnehin nur für 16 KB vorgesehen. Dieser Block kann dann in Sekundenschnelle mit dem vorliegenden Original verglichen werden. Ein einziger Zeitstempel müsste dann genügen.

Diese Vorgehensweise nachzubilden dürfte für dein C++-Experte machbar sein. Zumindest in der Theorie sind die Downloads bzw. für die Juristen das Vorhandensein des abgemahnten Werks damit zu beweisen. Ich sehe immer noch die Probleme der Korrektheit der Logs und der Identifikation des Gegenübers, der IP-Verwechslung, aber das sind andere Baustellen.

Andere Logger verwenden wahrscheinlich keine Spezial-Software (Beispiel).

Zitat von Eikmeier

Doch, geht. Ihr könnt die Bilder auf meinen Server laden...

Das Angebot kam von "anderer" Stelle auch schon. Ich habe die schnellste Lösung über imgbox gewählt. Ist zwar öffentlich, aber kein Problem. Wir achten schon darauf, dass in den ScreenShots keine rechtlich bedenklichen Inhalte zu sehen sind. Und auf IP-Adressen trifft das ja auch nicht zu, wie uns einige Gerichte ja bereits ausgiebig belehrt haben.
Zudem müssen wir für imgbox die Bildauflösung nicht mehr reduzieren, und gehen natürlich davon aus, dass jeder Interessierte sich die Screens auch sichern wird. Insofern war "das" die optimalste Lösung.

Trotzdem für das Angebot.

-CityLight-

Zitat von dreizack

Es genügt, ein Mini-Download zu beweisen

Ich sehe das vollständig anders (jeher schon).

UA deswegen bin ich mal zu Besuch bei der "Kammer des Schreckens" in Frankfurt gewesen. Die traumatische Erfahrung einer richterinnenlichen Ausführung über das Thema "Beweissicherheit" in diesem Bezug werde ich die nächsten Jahre nicht los, was mich sehr motiviert.

- Ich habe zwei Test in Verfahren bezüglich der Wirkung neuerer BGH-Rechtsprechung durchgeführt. Im einen Verfahren warte ich heute noch auf eine richterliche und gegenanwaltliche Meinung. Im Anderen Verfahren ist der Gegner "hysterisch kreischend" davon gefleucht.

- Wenn wir nämlich von einem "Sekundenlog" reden erfüllt dieser nie und nimmer die vom BGH aufgestellten Normen, wie denn eine Person zu behandeln sei wenn es zu einem technischen Vervielfältigungsprozeß nach § 53 UrhG kommt: "Dabei ist maßgeblich darauf abzustellen, ob der Hersteller sich darauf beschränkt, gleichsam „an die Stelle des Vervielfältigungsgeräts“ zu treten und als „notwendiges Werkzeug“ des anderen tätig zu werden – dann ist die Vervielfältigung dem Besteller zuzurechnen (vgl. BGHZ 141, 13, 22 – Kopienversanddienst) –, oder ob er eine urheberrechtlich relevante Nutzung in einem Ausmaß und einer Intensität erschließt, die sich mit den Erwägungen, die eine Privilegierung des Privatgebrauchs rechtfertigen, nicht mehr vereinbaren lässt – dann ist die Vervielfältigung dem Hersteller zuzuordnen (vgl. BGHZ 134, 250, 264 f. – CB-Infobank I). Hat derjenige, der die Vervielfältigung selbst vorgenommen hat, die Vervielfältigungsstücke für den eigenen Gebrauch angefertigt, kann dieser Vervielfältigungsvorgang nicht einem Dritten als Vervielfältigungshandlung zugerechnet werden. Für urheberrechtswidrige Vervielfältigungen haftet dann allein der Hersteller als Täter. Soweit ein Dritter hierzu einen Beitrag geleistet hat, kommt lediglich dessen Haftung als Teilnehmer oder Störer in Betracht (vgl. dazu BGH, Urt. v. 15.1.2009 – I ZR 57/07, Tz. 13 – Cybersky)." [BGH, Urteil des I. Zivilsenats vom 22.4.2009 - I ZR 216/06]

Die Kölner Auskunftsrichter sind auf diese Rechtsprechung nicht eingegangen, die gerade beim Thema "Evidenzia" von allerhöchster Bedeutung ist. Die können zu Ihrem Softwarefehler labern was sie wollen: Auf den epac-Berichten ist das entscheidende nicht zu sehen: Der tatsächliche Angebotsstand. 100%? 0,5%. Ich kann nicht ersehen, ob der geloggte Anschlußinhaber als Täter oder Störer zu qualifizieren ist.

Darüberhinaus [princess schau mal da hin] habe ich die ganze Zeit eine Argumentation Dr. Eikmeiers blöd angeglotzt, dabei hätte es mir wie Schuppen von den Augen fallen sollen: "Falls die Beklagte zu 1 – und nicht der jeweilige Kunde - die Sendungen der Klägerin auf den „Persönlichen Videorecordern“ der Kunden abspeichert, macht sie diese Sendungen damit allerdings im Sinne des § 87 Abs. 1 Nr. 1 Fall 2 UrhG insoweit zugänglich, als die Kunden die Sendungen dann von jedem Ort und zu jeder Zeit (§ 19a UrhG) über einen PC abrufen können. Es fehlt jedoch, wie das Berufungsgericht mit Recht angenommen hat, an einem Zugänglichmachen gegenüber der Öffentlichkeit. Das Zugänglichmachen einer Funksendung ist im Sinne des § 87 Abs. 1 Nr. 1 Fall 2 UrhG öffentlich, wenn diese einer Mehrzahl von Mitgliedern der Öffentlichkeit zugänglich gemacht wird (§ 15 Abs. 3 UrhG). Diese Voraussetzung ist nicht erfüllt, wenn – wie im Streitfall - jede einzelne Aufzeichnung nur jedem einzelnen Kunden zugänglich ist (LG Braunschweig AfP 2006, 489, 491; Hofmann, MMR 2006, 793, 795; ders., ZUM 2006, 768; Becker, AfP 2007, 5, 6; Dreier in Festschrift Ullmann, 2006, S. 37, 44)." [BGH-ebenda]

Das ist nur Supercool: "Diese Voraussetzung ist nicht erfüllt, wenn – wie im Streitfall - jede einzelne Musikdatei nur jedem einzelnen Gegenüber das ein Filesharingprogramm installiert hat zugänglich ist." Dieser Personenkreis kann gar nicht die Mehrzahl der Mitglieder der Öffentlichkeit sein. [siehe § 19a UrhG - Mitglieder der Öffentlichkeit]

Die komplette 70 000-Abmahungs-Evidenzia-Klitsche basiert aber nur auf einer Anspruchsgrundlage: Einer Verletzung des § 19a UrhG. Der Anspruch wird ergo ohne Begründung vorgetragen.

Die Ausrede des "Angebots an alle"? "Daher kann in dem an jedermann gerichteten Angebot zur Aufzeichnung und zum Abruf künftig ausgestrahlter und gespeicherter Sendungen kein öffentliches Zugänglichmachen gesehen werden, weil sich das betreffende Werk zur Zeit des Angebots nicht in der Zugriffssphäre des Vorhaltenden befindet (LG Braunschweig AfP 2006, 489, 490 f.; Braun, AfP 2007, 5, 6; a.A. OLG Köln GRUR-RR 2006, 5; LG München I ZUM 2006, 583, 585)." - es wird (100%? 0,5%) schlicht nicht bewiesen, dass diese Maßgabe erfüllt ist.

Und nun durch die "Evidenzia-Skandal"-Geschichte noch die Frage ob denn die Herrschaften überhaupt fähig sind den „Maßstäben der Offensichtlichkeit einer Rechtsverletzung“ genüge zu tun. [vgl. OLG Köln im Beschluß vom 21.10.2008, Az.: 6Wx 2/08]

Fazit: Juristisch gesehen ist der Sekundenlog bereits jetzt schon Geschichte. Mit der (mich) überraschenden Veröffentlichung der Stellungnahme der Richterschaft in Köln ist zudem die notwendige Bresche dort geschlagen in die man zügig hinein schiessen muß, was ich mir erlauben werde zu tun.

Zitat von dreizack

... Das scheint mir leider falsch. Es genügt, ein Mini-Download zu beweisen - siehe die Diskussion mit RA Eikmeier im rka-Thread. Daher denke ich, dass die Log-Software so modifiziert ist, dass sie nur einen kleinen Block mit der Message "OP_REQUESTPARTS" anfragt. Bei Bittorrent wird ein "request <id=6>" ohnehin nur für 16 KB vorgesehen. Dieser Block kann dann in Sekundenschnelle mit dem vorliegenden Original verglichen werden. Ein einziger Zeitstempel müsste dann genügen.

Das haben wir unzählige Male probiert, und sind dabei mit dem eigentlichen Ziel (möglichst eine große Anzahl von Downloads zu erreichen) nie auf einen grünen Zweig gekommen. Zuerst hatten wir den modifizierten muli nach einer Datenmenge von 20480Byte (resultiert aus der MTU-Size) den Download von der Quelle (brachial) abbrechen lassen. Mit dem Ergebnis, dass wir permanent im Queue nach hinten gerutscht sind. Von einigen Clients wurde wir gar gleich gebannt. Es war hier unmöglich innerhalb einer Session von der selben Quelle noch einmal einen Download zu schaffen.
Dann haben wir die gesamte DL-Rate drastisch reduziert, mit dem Ergebnis das uns die Kad-Quellen reihenweise rausgeflogen sind.
Zum Schluss haben wir die gesamt-DL-Rate auf 12KB fest eingestellt, was in Bezug Warteschlange und häufigeren DL's von einzelnen Quellen ein optimaler Wert war. Die DL-Rate pro Quelle (Connection) haben wir dann über den FirewallRouter per Load-Balancing noch einmal reduziert.
Das haben wir dann für den "scharfen" Test verwendet. Die bisherigen ScreenShots zeigen nur Muster aus den vorhergehenden Experimenten.

Ich fasse noch mal zusammen. Wir haben versucht mit möglichst vielen IP-Adressen (nur aus Deutschland übrigens) einen Download zu starten, um damit den Up der Gegenstelle zu beweisen. Und hier gibts einige Loggerbuden, die schaffen das angeblich mit über 1000 IP's pro Woche. Darum geht es ja in dem ganzen Abmahnwahn.
Und das haben wir mit diesem ominösen Probe-DL, der nach einer bestimmten Datenmenge (bei uns waren es 20.48kb) brachial gestoppt wird, absolut nicht geschafft. Im Gegenteil, auf die maximale Ausbeute an DL's pro IP hat sich das sogar negativ ausgewirkt. Insofern haben wir das Konzept mit diesem Mini-DL wieder verworfen.
Das sollen die Loggerbuden doch dann mal ganz genau erklären, wie sie das realisiert haben wollen. Mini-DL mit nachweislicher Negativ-Folgewirkung, bei 1000 bewiesenen DL's (Upload der Gegenstelle) pro Woche.
Nee, das würd ich nich mal dem Weihnachtsmann glauben, wenn ich noch ganz klein wär.

-CityLight-

Ist es eigentlich möglich, das man geloggt wurde, aber eigntlich der Emule-Client gar keinen Upload ermöglicht? Sozusagen, das die Datei nur "gesichtet" wurde. Eine Urherberrechtsverletzung kann aber nur erfolgen, wenn es wirklich möglich ist zu uploaden.

Zitat von Dreizack

Es genügt, ein Mini-Download zu beweisen

Zitat von Shual

Ich sehe das vollständig anders (jeher schon).

Darauf hatte ich gehofft. Meine Kurzfassung schien mir die logische Konsequenz aus der Aussage von RA Eikmeier:

Der Abmahner muss auch nichts komplett geladen haben. Ausreichend ist, wenn die gesamte Datei bzw. das gesamte Archiv beim Täter auf dem Rechner liegt und dieser es zum Download anbietet.

und seine Erläuterungen dazu im rka-Thread. Das gefiel mir nicht sonderlich und ich kenne eher die amerikanische Auseinandersetzung über die Definition von "zugänglich machen" als die deutsche, daher lasse ich mich nicht auf einen juristischen Streit mit dir oder mit ihm ein. Ich hoffe, ihr könnt es zwischen euch und den Kölner Richtern klären und mir es bei Gelegenheit verständlich machen.

Ich wage nur noch eins: Deine supercoolen Überlegungen zum Thema § 19 a UrhG leuchten mir nur teilweise ein. Die Tatsache, dass Personen nur einzeln das angebotene Material abrufen können und dann nur sehr langsam, dass für ein Download im Durchschnitt lediglich ein Upload stattfindet, sollte - wie Hadron argumentiert - den Streitwert drücken. Mit der Argumentation, dass überhaupt keine Verletzung stattfindet, kann ich mich noch nicht anfreunden (aber ich bin zum Glück nicht der Richter). Selbstverständlich gehören solche Bagatelle trotzdem nicht vor Gericht.

Zitat von Der_Kater

Ist es eigentlich möglich, das man geloggt wurde, aber eigntlich der Emule-Client gar keinen Upload ermöglicht? Sozusagen, das die Datei nur "gesichtet" wurde.

Wow, da hat der MiezeKater aber schon seeehr aufmerksam gelesen, und gleich mal die richtige brisante Frage gestellt.
Aber du solltest die Frage ändern, nämlich ob dem Logger überhaupt der DL gelungen ist. Die Frage, ob die Gegenstelle das überhaupt ermöglicht hätte, stellt sich bei 1000 bewiesenen?? DL's pro Woche gar nicht mehr.
Im Testbericht Teil-2 bekommst du eine Antwort darauf.

Zitat von Der_Kater

Eine Urherberrechtsverletzung kann aber nur erfolgen, wenn es wirklich möglich ist zu uploaden.

Zumindest behaupten die das doch immer wieder. Wie war gleich der Text in einem bekannten Abmahnschreiben...

Nachdem das streitgegenständliche Filmmaterial im Rahmen einer Suchanfrage lokalisiert worden ist, wird eine direkte Verbindung zwischen den Rechnern über das Internet hergestellt, auf welchen sich das streitgegenständliche Filmmaterial befindet. Eine solche Verbindung wird unmittelbar die IP-Adresse hergestellt, welche von unserer Mandantin mitsamt weiteren Informationen mitprotokolliert wird und über welche das streitgegenständliche Filmmaterial von Mitarbeitern unserer Mandantin geladen und gespeichert wird. Hierbei findet eine Überprüfung hinsichtlich der Authentizität des streitgegenständlichen Filmmaterials statt.

Nee, is ja n Ding.
1000 mal pro Woche , klingt irgendwie schon wieder nach Weihnachtsmann.

-CityLight-

@ Citylights

Wollte Dich was über PN fragen, geht aber nicht.

EDIT BY PRINCESS
Und ich schieb gleich mal ne Frage an @Citylights hinterher:
Kann ich den Beitrag von gestern 14:11 nun löschen?

Zitat von dreizack

Ich hoffe, ihr könnt es zwischen euch und den Kölner Richtern klären und mir es bei Gelegenheit verständlich machen.

Ich wage nur noch eins: Deine supercoolen Überlegungen zum Thema § 19 a UrhG leuchten mir nur teilweise ein. Die Tatsache, dass Personen nur einzeln das angebotene Material abrufen können und dann nur sehr langsam, dass für ein Download im Durchschnitt lediglich ein Upload stattfindet, sollte - wie Hadron argumentiert - den Streitwert drücken. Mit der Argumentation, dass überhaupt keine Verletzung stattfindet, kann ich mich noch nicht anfreunden (aber ich bin zum Glück nicht der Richter). Selbstverständlich gehören solche Bagatelle trotzdem nicht vor Gericht.

Um DAS THEMA bei den Kölner Richtern anspruchsvoll zu klären bräuchte man etwas das fehlt: Einen adäquat strategisch und intelligenzmäßig passenden Gegner. Hat man leider nicht. (Sowas gibts momentan bei den Abmahnern nur bei der Kanzlei Waldorf. Deren kommentierenden Schriftsätze zu BGH-Urteilen sind vorbildlich und daher geeignet die Richterschaft zu interessieren.) Bei den aktuellen Gegner fehlt es bislang an jeglichem Nachweis im qualitativen Bereich.

Deswegen muß das LG Köln dran glauben.

Zum Zweiten Punkt: Das sind nicht "meine Gedanken", sondern Theorien über Gedanken von BGH-Richtern (im Volksmund "von der Rechtsprechung zum Marken- und Urheberrecht entwickelten Grundsätze" genannt), die sich sowieso durchsetzten werden. Es geht auch gar nicht um "irgendwas", sondern eben Grundsätze die von der Klägerseite eine entsprechend qualitativ und inhaltlich ausgestaltete Beweisführung fordern.

Ich gehe sogar mittlerweile sowei allen Anwälten zu empfehlen im Schriftsatz I deutlich zu machen, dass der aktuelle klägerische Vortrag (in Köln und auch anderswo) dem Beklagten eine sorgfältige und auf Förderung des Verfahrens bedachten Prozessführung nicht möglich macht. Bei manchen der abseitigen Theorien ("Exponentialrechungssschadensersatzdarstellungsmode ll") kann zumindesten mein Gehirn kaum etwas Vernünftiges vorbringen, da es in eine dreiwöchige Schockstarre verfällt. Man denkt immer, man hat den dümmsten Fehler gesehen und zack... kommt noch ein besserer. (Nein, ... der erste der den §277-er-Einwurf erleiden mußte hat sich beim Gericht umfänglich über seine Klageschriftarbeit entschuldigt... )

Fazit: Es gibt eben Leute, die an der schnellen Millionen-Kohle interessiert sind. Und Leute, die an der Entwicklung der Rechtsprechung interessiert sind.