Abmahn-Laberthread - Seite 273 - gulli:board
#5445

Ich finde die Ansichten von diesem Baxter dort erfrischend.

'Massenhafte Abmahnungen erfordern massenhafte Strafanzeigen'

Werbung

Zitat von Ubuntu11

Abmahn-Laberthread - Seite 273 - gulli:board
#5445

Ich finde die Ansichten von diesem Baxter dort erfrischend.

'Massenhafte Abmahnungen erfordern massenhafte Strafanzeigen'

da stimm ich Dir zu , aber vielleicht wird er wieder anecken.
Ab und zu verbannt Ihn aber der "Dicke" wieder für "immer und ewig" oder Baxter geht von selbst für "immer und ewig".

Das ist eine unendliche Geschichte!

MMG,Mops

Zitat von superdicker

da stimm ich Dir zu , aber vielleicht wird er wieder anecken.
Ab und zu verbannt Ihn aber der "Dicke" wieder ...

Nun , mir geht es hier nur um die Einstellung zum Thema Abmahnwahn.
Eure private Fehde interessiert mich dazu leider nicht.

Zitat von Ubuntu11

nun mir geht es hier nur um die Einstellung zum Thema Abmahnwahn.
Eure private Fehde interessiert mich dazu leider nicht.

Ich sagte: Da stimm ich Dir zu!

MMG,Mops

Serie: Die rechtsmissbräuchliche Abmahnung. Folge 4

Das Lansgericht Bochum sah folgende Umstände im Rahmen einer Gesamtabwägung als Indiz dafür, dass der Abmahner seine Abmahntätigkeit dazu benutzte, um gegen die Wettbewerber Ansprüche auf Zahlung einer Vertragsstrafe sowie Ansprüche auf Ersatz von Aufwendungen oder Kosten der Rechtsverfolgung zu generieren:

* 26 anhänhig gemachte Gerichtsverfahren am selben Landgericht
* Ausspruch von 40 Abmahnungen innerhalb von 9 Monaten
* Unterlassungserklärung sieht Vertragsstrafe auch für nicht schuldhafte Zuwiderhandlung vor
* Geltendmachung einer Vertragsstrafe am Tag nach Abgabe der Unterlassungserklärung
* Abmahner verweigert schon in der Abmahnung eine Verlängerbarkeit der Zahlungsfrist

ja, ja @watt ich weis UWG

trotzdem 40 Abmahnungen in 9 ( in Worte: NEUN) Monaten
ääääh wieviele sind es bei NuL, Waldi, Korni usw ??????????

Und sorry, warum soll man da einen Unterschied machen ob UWG oder UhrG???

Zitat von Kersare

ja, ja @watt ich weis UWG
warum soll man da einen Unterschied machen ob UWG oder UhrG???

"Schnuggel" schön dass Du darum "weißt"
Und, siehst Du auch den Unterschied in den hervorgehobenen Buchstaben?

Wie wäre es damit UWUhrG
Das wäre sicher die ultimative Herausforderung des Bayrischen Flughafenbahnhofzusammenlegers und jetzigen Bürokratieabbaupensionisten* in Brüssel.
Wer Bahnhöfe und Airport´s zusammenlegen kann, schafft das sicher auch mit Gesetzen.
* wer nichts wird wird Wirt, oder nach Brüssel hinwegkomplimentiert

Zitat von watt_ihr_volt

Wie wäre es damit UWUhrG [/COLOR]

"Schnaggel" Deine Kreativität überrascht mich immer wieder

Zitat von watt_ihr_volt

Wie wäre es damit UWUhrG
Das wäre sicher die ultimative Herausforderung des Bayrischen Flughafenbahnhofzusammenlegers und jetzigen Bürokratieabbaupensionisten* in Brüssel.
Wer Bahnhöfe und Airport´s zusammenlegen kann, schafft das sicher auch mit Gesetzen.

In Brüssel hat er ja mords Unterstützung durch unser
Sprachgenie

Zitat von Fuchs & Hase

In Brüssel hat er ja mords Unterstützung durch unser Sprachgenie
Sprachgenie

Der Typ ist genauso schlecht wie das gleichnamige Bier!

Wie heißt es so schön in der Werbung: "Wir können alles außer Hochdeutsch"

Wie sieht es dann erst mit Englisch(Dummdeutsch) aus?

MMG,Mops

Zitat von Kersare

trotzdem 40 Abmahnungen in 9 ( in Worte: NEUN) Monaten
ääääh wieviele sind es bei NuL, Waldi, Korni usw ??????????

Mir reichts langsam von dem Abmahnwahnsinn. Konkret: was können wir dagegen machen? Zur Staatsanwaltschaft laufen und mal das Forum hier bekanntmachen? Das müsste doch langsam wirklich die letzte Schlafmütze von der StA auf den Plan rufen. Oder stecken die auch noch unter einer Decke!?

Zitat von Fuchs & Hase

In Brüssel

da haben noch viel andere "Ikone" Unterstützung.
Verzeihung, ich möchte weder als "Wasserträger dieser oder jener" gesehen werden. Alle trugen und tragen zum derzeitigen "Wahn" bei und vergessen in ihrer "Raffgier" die wahren Probleme der Menschheit

Oder auch hier:

Download

MMG,Mops

Zitat von watt_ihr_volt

Alle trugen und tragen zum derzeitigen "Wahn" bei und vergessen in ihrer "Raffgier" ...

Hier hat sich mal jemand zu Wort gemeldet der für RAFFGIER bekannt ist

Die Deutsche Bank nimmt Stellung zur kommenden UrhG-Reform

Die Schlussfolgerung der DB Research für die Zukunft des Urheberrechts im digitalen Zeitalter lautet darum dann wenig überraschend: „Eine erfolgreiche Urheberrechtsreform kann gelingen, wenn neben den Rechteverwertern, den Künstlern selbst auch die Interessen der Internet-Nutzer mit angehört werden. Die steigende Gleichgültigkeit vieler Internet-Nutzer gegenüber Urheberrechtsverletzungen spricht eine deutliche Sprache“. Eine einseitige Bevorzugung partikulärer Interessen einzelner Beteiligter führt dazu, dass die Endverbraucher, jene, die ja die eigentliche Zielgruppe von Kreativen und Werkschaffenden sind, den Regelungen und Normen im Urheberrecht gegenüber immer gleichgültiger werden, weil sie in ihrer Lebenswirklichkeit keinen Sitz mehr haben. Am Ende wird eine Urheberrechtsreform, die nur wirtschaftliche Belange der Verwerter im Blick hat, die Legitimationskrise des überkommenen Urheberrechts nur verstärken und es werden mehr und mehr alternative Lizensierungsmodelle abseits des traditionellen Geschäftes nachgefragt und genutzt werden.

Hier ist der angekündigte Bericht (Analyse) Teil-3.

Zur Übersicht die Form-Links der bisherigen Berichte.

> Warnhinweis, Änderung User-Hash (GUID)
> Testbericht Teil-1 Teil-A
> Testbericht Teil-1 Teil-B
> Testbericht Teil-1 Teil-C
> Testbericht Teil-2
> Recherche ed2k-Hashes (vlog)

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


3.) das Gutachten einer Log-Software
Für die ganz eifrigen Leser die längere Berichte nur kurz überfliegen, wird auf den Punkt 3.4 und 3.5 verwiesen. Diese Punkte erläutern das eigentliche Problem in dem Gutachten. Diese Abhandlung hier wird diesmal leider sehr lang.

Dieser Bericht wird folgende Punkte erläutern:
- 3.1 Erläuterung zum grundlegenden Testaufbau im Gutachten
- 3.2 das Problem der öffentlichen IP-Adresse
- 3.3 der Transfer-Test mit den Clients untereinander
- 3.4 der Download des Log-Clients
- 3.5 die Log-Software und das reale ed2k-Netz
- 3.6 der Probe-Download und die Quellenverfügbarkeit im Netz
- 3.7 Quellenverfügbarkeit versus Massen-Logging
- 3.8 Zusammenfassung und Fazit

<a>
Es soll hier nicht der komplette Testbericht Teil-2 wiederholt werden. In dieser Analyse wird allerdings einmal sehr genau beleuchtet, wie und in welcher Testumgebung die bereits bekannten Problematiken aus dem Testbericht ("Probe-Download, Leecher-Modus, Kreditsystem") in einem Gutachten zu einer Log-Software überhaupt behandelt wurden. Und da ergeben sich einige höchst fragwürdige Details. Vor allem aber solche Details, die im ed2k-Netz mit realen Clients auf der Gegenseite nun mal Quasi-Standard sind, jedoch im Gutachten (bewusst ??) umgangen, oder gar nicht erst betrachtet werden. Ferner muss noch erwähnt werden; auch wenn sich die Analyse nur auf das ed2k-Netz konzentriert, so sieht die Problematik zum Probe-Download im BitTorrent sicher ganz ähnlich aus. In diesem Verzeichnis befindet sich mit der Datei "bauer-wifs09.pdf" eine Abhandlung in englischer Sprache, die zum gleichen Ergebnis gekommen war (Der sichere? Probe-Download gelang gerade mal in rund 1% der Fälle). Hier noch der Direktlink auf das pdf-Dokument.
<b>
Neuerdings maßen sich ja sogar Inkasso-Firmen an, über die technische Nichtigkeit oder Gültigkeit von Gutachten zu befinden. Also diese Zahlen- und Rechnungsverschieber sollten doch besser in "ihrem" Fachbereich bleiben. Es ist allerdings davon auszugehen, dass einige IT-Dienstleister oder auch Abmahner sich nach dem Bericht zu Wort melden werden (in welcher Form das auch immer erfolgt), nach dem Muster "...wir verwenden eine grundlegend andere Log-Software, und unser Gutachten hat einen völlig anderen Inhalt". Solchen Bemühungen soll vorab gleich mitgeteilt werden, dass die am Anschluss noch beschriebene Problematik zum Probe-Download auf jegliche Form von Log-Software zutrifft, die selbst keinen Upload ausführt. Was im Übrigen ja auch immer wieder explizit erwähnt wird, die Log-Software uploaded nicht.
<c>
Eine grundlegende Klarstellung noch.
Man muss sich von dem Gedanken verabschieden, dass "die Log-Software" grundsätzlich nur Mist produziert. Der sog. Probe-Download funktioniert sehr wohl. Sofern das natürlich in einem "für die zutreffende Log-Software" überhaupt existierenden Gutachten auch nachvollziehbar ist, und wie es technisch ausgeführt wurde. Es gibt natürlich auch eine ganze Menge Abmahner, die entweder nicht in der Lage, oder gar nicht erst Willens sind, den aufzeichnenden IT-Dienstleister überhaupt zu benennen. Solchen Abmahnern sollten dann schon mal ganz gezielte Fragen bezüglich "des Gutachtens" gestellt werden, wenn nämlich genau "das" in der Abmahnung behauptet wird. Ein besonderes Highlight sind natürlich Loggerbuden (der Begriff "qualifizierter IT-Dienstleister" ist hier deutlich überzogen) die der festen Überzeugung sind, mit einem durchgestylten Webauftritt könne man die eierlegende Wollmilchsau einer Log-Software der Allgemeinheit verdummkaufen. Hier überhaupt noch die Frage nach einem Gutachten zu stellen, wäre wohl reine Zeitverschwendung.



3.1) der grundlegende Testaufbau im Gutachten

>> TestScreen400 << - der Testaufbau im Gutachten
Im Bild-400 wurde die grafische Darstellung des Testaufbaus gemäß dem Gutachten dargestellt. Auf den ersten Blick sieht das nicht nur sehr technisch, sondern auch qualifiziert aus. Man testete also mal direkt über das reale Internet (P2P-Netz, ed2k), und nicht in einer Laborumgebung mit einem "internen Netzwerk. Nur war das leider auch in diesem Gutachten viel zu schön um wahr zu sein, denn auch hier offenbaren sich bei genauer Betrachtung immer mehr Zweifel an der Praxistauglichkeit dieses Gutachtens. Interessant ist allerdings die Art und Weise von Text, Begründung und Darstellung, die hier selbst einem technisch Versierten häufig mal den Blick für's "Kleingedruckte" komplett vernebelt. Beginnen wir also mal "Das Gutachten" technisch auseinander zu nehmen. Hier entstehen nämlich durch das Gutachten gleich zwei mal so viele Fragen, wie eigentlich vor und mit dem Gutachten beantwortet werden sollten.
<a>
Zunächst einmal sorgte ein kleiner unscheinbarer Satz mitten im Gutachten für absolutes Erstaunen. Da ist doch tatsächlich dem Kontext sinngemäß zu entnehmen, "Die beim beauftragenden IT-Dienstleister aufgebaute Testumgebung umfasste...". Also in Bezug auf ein sog. unabhängiges Gutachten geht das eigentlich schon mal gar nicht. Aber ok, die Gründe dafür werden im Gutachten nicht benannt, und es könnten auch technische Probleme am eigentlichen Standort des Gutachters gewesen sein. Auch wenn es eigentlich nichts mit einem "ed2k-Gutachten" zu tun hat, haben wir hier mal eine intensive Recherche betrieben.
Die nachfolgenden Punkte <b> bis <d> richten sich also vorwiegend an Technik-Experten. Es soll in erste Linie als Info für DSL-Recherchen und daraus resultierende Probleme dienen. Denn auch solche Dinge sind in so manchem Gutachten höchst fragwürdig dargestellt.
<b>
Schauen wir uns jetzt noch einmal das Bild-400 an, dann sehen wir dort zum Test auch vier erforderliche DSL-Anbindungen an das Internet. Also diese nur einem einzigen Kunden (hier dem Gutachter an seinem Standort) betriebsfähig anzubieten, stellt selbst bei nur zwei DSL-Anbindungen die meisten Anbieter vor erhebliche Probleme. Der Grund dafür ist in der TK-Kabelanbindung (der sog. letzten Meile) zu suchen, und das neben der bekannten Reichweiten-Problematik auch "zu viele" DSL-Kanäle auf einem Kabelstrang (physikalisch bedingt) sich gegenseitig stören. Es gibt zwar in zahlreichen Städten noch die Möglichkeit eine zusätzliche DSL-Anbindung zu beschaffen (z.B. via TV-BK-Kabel oder Wettbewerber mit eigenen aufgebauten Kabelnetzen), allerdings ist das eben auch eine Kostenfrage. Vermutlich wollte auch "der Gutachter" solche zusätzlichen Kosten nur für einen einzigen Gutachten-Test sicher nicht ausgeben. Zudem wurden auch die DSL-Machbarkeiten an beiden Standorten (Gutachter und IT-Dienstleister) überprüft.
Hier noch ein Hinweis für Technik-Experten.
Das eben genannte Problem mit der gegenseitigen Beeinflussung von DSL-Kanälen auf einem vorhandenen Kabel betrifft übrigens alle Netzanbieter, und schlägt sich im sog. DPBO-Wert nieder. Dieser Begriff "DPBO" steht für Downstream Power Back-Off, und ist im Grunde genommen nichts anderes als eine im DSLAM integrierte dynamische Bandbreitenbegrenzung. Diese verhindert, dass sich die DSL-Kanäle auf dem gleichen Kabelweg gegenseitig stören. Interessanterweise hat genau dieser DPBO-Wert einen entscheidenen Einfluss darauf, ob z.B. der o.g. Gutachter an seinem Standort überhaupt eine zweite DSL-Anbindung haben kann, und bis zu welcher Geschwindigkeit das möglich ist.
<c>
Die meisten Leser werden sich jetzt fragen, wie man an solche eben genannte Informationen kommt. Eigentlich ganz einfach, das Internet ist vollgepflastert mit solchen Abhandlungen. Man muss sie einfach nur lesen und auch verstehen können. Das größte Problem hierbei ist natürlich "erst mal suchen und finden". Wer hier geduldig vorgeht, findet sogar Abhandlungen die so mancher Netzbetreiber am liebsten wieder verschwinden lassen würde, bevor es der hart umkämpfte Vertragskunde zu lesen bekommt. Hier sei vor allem das o.g. Problem mit dem "DPBO" erwähnt.
Zunächst mal muss man das TK-Kabel-Problem mit der letzten Meile (also zwischen DSL-Standort und T-Vermittlungsstelle) verstehen. Eine wirklich gute und verständliche Abhandlung (vor allem für Nicht-Experten) ist auf dieser Website zu sehen. Man achte auch auf die weiteren Themen (z.B. DSL) am Ende dieser Website.
Um die Entfernung bis zur nächsten Vermittlungsstelle prüfen zu können (ob DSL überhaupt möglich ist), müssen wir natürlich erst mal wissen, wo denn "das Teil" überhaupt steht. Man darf erstaunt sein, auch "das" findet sich bis ins letzte Detail im Internet.
So finden wir auf dieser Website gleich mal sämtliche DSL-fähigen Vermittlungsstellen exklusiv als Standort-Datei (kml-File) für Google-Earth. Wem das zu kompliziert ist, der bekommt mit dieser pdf-Datei aus dem Web das gleich noch richtig schön nach Postleitzahlen sortiert.
Jetzt brauchen wir nur noch in Google-Maps den gesuchten DSL-Standort sowie den der nächstgelegenen Vermittlungsstelle zu setzen, und lassen dann einfach die Strecke über den Routenplaner berechnen. Dass die TK-Kabel natürlich vorwiegend entlang der Hauptstraßen verlegt werden (also da wo im Fußweg immer die vielen Kabelschacht-Deckel zu sehen sind), sollte man natürlich beachten. Im Ergebnis einer solchen Recherche können wir also schon abschätzen, bekommen wir "hier" überhaupt DSL, und bis zu welcher Geschwindigkeit.
<d>
Der eigentliche Sinn diesen technischen Ausfluges ? Man kann also bereits mit "relativ" einfachen Hilfsmitteln schon feststellen, stimmt denn überhaupt "dieser" Teil in dem Gutachten, und war das mit den angegebenen DSL-Anbindungen überhaupt "dort" machbar. Auf den "Heimat"-Standort des Gutachters traf das nämlich nicht zu. Er hätte aufgrund der bereits problematischen Kabellänge dort mit Ach und Krach vielleicht gerade mal eine DSL6000-Anbindung bekommen, für ASDL2 war das schon sehr sehr knapp. Und dann gleich vier Stück davon auf einer Etage, in einem Haus wo noch zahlreiche andere Nutzer sitzen, könnte bereits an rein technischen Problemen gescheitert sein. Vermutlich ist der Gutachter wohl deswegen mit seiner kompletten Testumgebung zum Standort des IT-Dienstleisters gewandert. Allerdings sieht es auch dort nur geringfügig besser aus. Und, eine Verfügbarkeitsprüfung auf der Telekom-Website zeigte eindeutig, dass dort ringsum kein schnelles VDSL verfügbar ist. Das soll nur insofern erwähnt werden, dass für einige Tests laut dem Gutachten wenigstens zwei der vier genannten DSL-Anbindungen einen Upstream von mindestens 700 kBits/s bringen müssen. Und den gibts wie bekannt nur mit einer ASDL2+ Anbindung. Nähere Erläuterungen dazu gibt es im weiteren Verlauf der Abhandlung.
Fairerweise muss aber hier trotzdem erwähnt werden, dass wir die technischen Möglichkeiten am Standort des IT-Dienstleisters nicht genau kennen, und eine Anbindung mit gleich vier ASDL2+ Leitungen natürlich durchaus denkbar wäre.
Damit erst mal genug mit dem technischen Ausflug ins Reich der DSL-Anschlüsse. Es gibt nämlich noch weitere technische Ungereimtheiten in dem Gutachen.



3.2) das Problem der öffentlichen IP-Adresse

>> TestScreen401 << - die öffentliche IP ??
Im Bild-401 soll eine Problematik verdeutlicht werden, die im Gutachen einige Fragen offen stehen lässt. An der DSL-Leitung-1 hängen zwei eMule-Clients. An der DSL-Leitung-3 ebenfalls, wovon ein Client ein sog. Leecher-Mod ist, dessen Verhalten hier mit getestet wurde. In diesem Test wurde nämlich auch die Vervollständigung (also Up- und Download) von Testdateien (dazu mehr im Punkt 3.3) der ed2k-Clients untereinander getestet. Also der ganz normale Dateitransfer im ed2k-Netz.
<a>
Jeder der sich mit dem eMule etwas eingehender befasst hat, der wird wissen das sich zwei eMule-Clients hinter einem Router nicht gleichzeitig betreiben lassen. Der Grund dafür liegt daran, dass den beiden eMule-Clients ab dem Router in Richtung Internet die gleiche sog. öffentliche IP-Adresse zugewiesen ist. Kommen jetzt ed2k-Datenpakete wieder zurück, ist der Router nicht mehr in der Lage diese dem jeweiligen eMule-Client im internen Netzwerk zuzuordnen. Ein genaue Beschreibung zu diesem Problem ist unter dem Punkt "Ich sitze hinter einem Router..." unter anderem auf dieser Website zu finden. Es gibt zwar eine komplizierte Umgehungslösung (siehe u.a. diese Abhandlung), aber damit das wie im Bild-401 funktioniert, wird zudem ein leistungsfähiger Router benötigt, der auch mit dem sog. "Full Cone NAT" umgehen kann. Eine Beschreibung dazu gibt es auf dieser Website. In dem Gutachten ist jedenfalls kein Hinweis zu entnehmen, dass eine solche Technik überhaupt eingesetzt wurde. Also entweder stimmt die Beschreibung und Darstellung (siehe Bild-401) im Gutachten nicht, oder die Clients an den beiden DSL-Leitungen sind nur im Wechsel gelaufen. Das allerdings würde der Beschreibung zum eigentlichen Test des Log-Vorganges (siehe Punkt 3.4) im Gutachten wiedersprechen.



3.3) der Transfer-Test mit den ed2k-Clients

>> TestScreen402 <<
Im Bild-402 wird der sog. Dateitransfer der Clients untereinander begutachtet. Dieser Punkt wird etwas ausführlicher erläutert, was da eigentlich genau "wie" in dem Gutachten getestet wurde. Da ergeben sich nämlich bereits für einen Nicht-Techniker erstaunliche Erkenntnisse, was da so alles in dem Gutachten verdreht dargestellt, komplett übersehen, oder gar nicht erst begutachtet wurde. Bei Letzterem sind nämlich die zahlreichen Optionen des eMule (bezüglich Leecher-Erkennung) gemeint, die wohl entweder komplett abgeschaltet oder entfernt wurden. Das spricht wohl nicht gerade für einen praxisorientierten Test, der das Transfer-Verhalten "realer" eMule-Clients im Internet analysieren soll.
<a>
Im Gutachten wird u.a. erläutert, dass für den Transfer-Test der Clients untereinander über 150 Testdateien mit einem Zufallsgenerator erzeugt. Also alles "Müll-Dateien" mit nutzlosen Inhalt. Kein Problem, zumindest für einen Labor-Test kann man das so machen. Diese Dateien hatten alle unterschiedliche Größen bis maximal 60 MByte, eine Datei wurde mit 1 GByte kreiert (steht offenbar für eine große Video-Datei). Die Gesamt-Datenmenge der zu transferierenden Test-Dateien betrug fast 3 GByte. Darauf kommen wir später noch mal zurück. Diese Testdateien wurden auf die verschiedenen Rechner im Bild-402 verteilt, und anschließend überall die Downloads zu den Testdateien gestartet. Der Logging-Client sollte zeitgleich diesen Vorgang beobachten, aufzeichnen, und versuchen sämtliche Test-Dateien von den Clients beweissicher herunterzuladen (also der Beleg für deren Upload). Diesen Vorgang zum Logging-Client betrachten wir noch separat im Punkt 3.4). Dieser Test simuliert also nicht anderes als den "gewöhnlichen" Dateitausch im ed2k-Netz. Allerdings, schauen wir mal zuerst nur auf die Clients.
Die im Punkt 3.2 erwähnte Problematik "öffentliche IP" berücksichtigen wir jetzt mal nicht weiter.
<b>
In der Testumgebung befindet sich auch ein Leecher-Client. Laut Gutachten hat aber auch der seine Dateien von den anderen eMules vervollständigt (also Download). Er hat lediglich keinerlei Upload ausgeführt, was der Test belegen sollte. Damit klingt der Test zwar auf den ersten Blick plausibel, ist er aber nicht. Er läuft völlig an der Praxis vorbei. Dazu müssen wir uns nämlich mal vor Augen führen, auf welchen Typ eMule-Clients, ausgestattet mit welchen Optionen, würde denn ein Leecher-Client im realen ed2k-Netz treffen. Das trifft übrigens genauso für den Logging-Client zu. Das betrachten wir aber später noch. Listen wir also mal detailliert auf.
<c>
>> TestScreen709 << - Option "Uploader belohnen"
Diese Option ist übrigens bei den meisten eMule-Nutzern durchweg aktiviert. Logisch, nur wer mir was gibt bekommt auch was. Leecher soll'n sich zum Teufel scheren. So lautet nun mal die goldene Regel im ed2k-Netz. Und die ist nur sehr schwer, und höchstens mal in Einzelfällen zu umgehen.
>> TestScreen716 << - das Credit System
Der Grund und die Wirkung des Credit-Systems ist im Bild-716 mit wenigen Sätzen erklärt. Das bedeutet für den Leecher nämlich erst mal auch, "Warten bis zum Umfallen".
>> TestScreen710 << - Adé, Leecher-Mods
Der Schrecken eines jeden Leecher-Mods, die berüchtigte Anti-Leecher-Option, ist in nahezu jeder eMule-Mod-Version enthalten. Hier ist es übrigens egal, mit welchem gefakten Client-Typ sich der Leecher im Netz meldet. Diese Funktion idendifiziert die Gegenstellen nämlich gleich nach mehreren Verhaltensmustern. Und das funktioniert erstaunlich präzise. In den meisten neueren eMule-Standard-Versionen ist zumindest eine abgespeckte Version davon enthalten. Welche Leecher-Mods bei den eMules generell keine Chance haben, ist auf dieser Website sehr übersichtlich aufgelistet.
>> TestScreen708 << - der IP-Filter
Nicht zu vergessen die sog. IP-Filter-Funktion. Sie wird zwar nicht durchweg von allen eMule-Nutzern verwendet, aber eine ganze Menge Filtersharer arbeiten dennoch damit.
<d>
Fassen wir jetzt mal zusammen. Auch der Leecher-Client hat seine zu downloadenden Dateien von den anderen eMule-Clients geholt, so laut Gutachten. Damit das überhaupt so funktionierte, müssten in den eMule-Clients im Testaufbau praktisch sämtliche Sicherheitsfunktionen abgeschaltet worden sein. Man kann wohl sogar davon ausgehen, dass das genauso gemacht wurde. Andernfalls wäre nämlich nicht nur der Leecher-Client auf die berühmte Bann-Liste verdonnert worden, sondern etvl. sogar auch der Logging-Client. Den erläutern wir später noch. Und an dieser Stelle der Kommentar: Wohl kaum dass die eMule-Clients im realen ed2k-Netz all die genannten Sicherheitsfunktionen deaktivieren werden, nur damit "das Massen-Logging" überhaupt noch funktionieren könnte. Also soweit geht der Glaube an den Weihnachtsmann ganz sicher nicht.
Und jetzt findet sich doch glatt noch dieser Satz (sinngemäß) im Gutachten: "Die angewendete Testumgebung entspricht..., ... so dass von realistischen Testbedingungen auszugehen war."
Also da bleibt doch glatt die Spucke weg. Die Analyse ist noch nicht mal zu Ende (das dicke Ende kommt nämlich noch), und schon hier muss dem Gutachter vorgehalten werden, diese Testumgebung simuliert nicht die Filetauscherei im realen ed2k-Netz, diese Testumgebung ist schlichtweg Mumpitz. An der Zielstellung "ed2k-Praxisorientiert" vollkommen vorbei gerasselt. Oder gab es etwa die eben erwähnte Zielstellung gar nicht ??



3.4) der Download des Log-Clients

Im Punkt 3.3 <a> wurde bereits erwähnt, dass der Log-Client während des Tauschvorganges der Clients untereinander von diesen die Testdateien herunterladen soll, um deren "illegalen" Upload zu nachzuweisen. Im Prinzip also der gewöhnliche Logging-Vorgang im Internet, der die Grundlage einer jeden Abmahnung darstellt.
>> TestScreen403 << - der Log-Vorgang in der Theorie
Das Bild-403 zeigt den Datenstrom der Testdateien in Richtung Log-Client, so wie es im Gutachten beschrieben ist. Das die Clients untereinander noch die Testdateien austauschen (siehe Bild-402), soll jetzt hier nicht weiter erwähnt werden. Allerdings, ausgehend von der Problematik (öffentliche IP-Adresse) unter Punkt 3.2 <a>, musste die Grafik etwas korrigiert werden. Und zwar so, dass die Logging-Umgebung einen Sinn ergibt und überhaupt funktioniert.
>> TestScreen404 << - die korrigierte Logging-Umgebung
Der Leecher-Client wurde bewusst mit in die Grafik aufgenommen. Denn laut dem Gutachten konnte auch dieser vom Log-Client aufgezeichnet werden. Da der Leecher-Client jedoch keinerlei Upload ausführt, ist das übrigens schon der erste Hinweis darauf, dass die Log-Software primär erst einmal die sog. Warteschlange aufzeichnet. In dem Moment wo der Leecher-Client eine Datei zum Download anfordert, ist dieser nämlich ebenfalls in der Warteschlange zu sehen. Kommen wir jetzt auf die Testdateien zurück, die laut Gutachten verwendet wurden.
<a>
Wie schon im Punkt 3.3 <a> angedeutet, wurden die Testdateien per Zufallsgenerator erzeugt. Besonders hervorzuheben sind hier die Dateinamen, die den Testdateien verpasst wurden. Hier handelt es sich lediglich um ein paar Buchstaben, gefolgt von einer laufenden Nummer, und einer völlig sinnlosen Dateiendung. Nennen wir die Testdateien also einfach "zufall001.zuf" bis "zufall150.zuf". Eine solch ähnlich unsinnige Dateiendung wurde hier im Gutachten tatsächlich verwendet. Der Grund dafür ist im Gutachten ebenfalls benannt. Er lautet sinngemäß, "Durch die zufällige Erzeugung der Testdateien und der Dateinamen konnte sichergestellt werden, dass bei keinen anderen Clients im ed2k-Netzwerk diese Testdateien jemals verfügbar gewesen sind, bzw. diese die Testdateien jemals besessen hatten". Im Klartext bedeutet das ganz einfach, niemand außerhalb der Testumgebung besitzt diese Dateien, und kennt diese demzufolge auch nicht. Was aber in dem Gutachten (mal ganz aus Versehen mit Absicht?) weggelassen wurde, dass auch niemand außerhalb der Testumgebung diese Dateien zum Download anfordern wird. Es kennt sie ja niemand im ed2k-Netz. Und diesen Hinweis sollten wir uns sehr gut merken, denn der zeigt noch ungeahnte Folgewirkungen auf.
<b>
Im Gutachten heißt es weiter, dass alle Testdateien innerhalb von 12 Stunden vom Log-Client heruntergeladen werden konnten. Das ist schon mal insofern interessant, dass diese gewaltige Datenmenge (wie schon im Punkt 3.3 <a> erwähnt) ja nur von zwei Clients geuploaded werden konnte. Der dritte Client ist ein Leecher der nicht uploaded, und niemand außerhalb der Testumgebung hatte diese Dateien vorrätig. Das bedeutet aber auch, dass diese Datenmenge über den Upstream der DSL-Leitungen 1+2 erbracht werden muss. Und ohne jetzt in Bitraten-Kleinkleckerei zu verfallen, ist das der Grund weshalb im Punkt 3.1 <d> bereits unterstellt werden musste, dass hierfür aufgrund des Upstreams mindestens zwei ASDL2+ Anbindungen erforderlich wären. Wie bekannt gibts nämlich ADSL-6000 i.d.R. nur bis zu einem Upstream von 576 kBit/s. Und das reichte für die o.g. Datenmenge nun mal nicht. Das durchweg alle Provider bei jeder DSL-Anschlussform auch noch ganz dezent darauf verweisen (... mit einem Up/Downstream von bis zu...), erwähnen wir besser gar nicht. Jeder kennt diese Allzweck-Ausrede mittlerweile aller Anbieter, wenn die Up/Down-Leistung laut Vertrag mal wieder nicht erreicht wird. Soll ja bei einigen Anbietern sogar schon der Regelfall sein.
<c>
Fassen wir also mal vorab zusammen. In der Testumgebung wurden 150 Testdateien von nur zwei Test-Clients (Nummer 3 war ja ein Leecher-Client) komplett heruntergeladen ("Komplett" steht übrigens im Gutachten). Begleitet von dem Problem, dass niemand außerhalb der Testumgebung diese Testdateien kannte, niemand diese Dateien vorrätig hatte, und bei niemandem außerhalb der Testumgebung damit ein Upload zu beweisen wäre. Also ein praxisorientierter Test sieht wohl irgendwie anders aus.
<d>
Jetzt gibt es da noch diese Geschichte mit dem "verkürzten" Probe-Download, wo nur ein sehr kleiner Datenblock der Datei zum vermeintlich beweissicheren Vergleich herunter geladen wird. Zumindest soll das ja die Log-Software versuchen, und auch noch fehlerfrei hinbekomen. An diesem "Mini-Download" hatten wir uns schon im Feldtest (siehe Signatur im Posting) die Zähne ausgebissen. Das hatte mit gezielt begrenzten Download-Blöcken unterhalb 20 kByte zu massenhaften Fehlern geführt. Selbst im Bereich von 20 bis 100 kByte gab es da immer wieder Download-Probleme, oft wurden wir sogar von der Gegenstelle auf die Bannliste verdonnert. Wir hatten das dann aufgegeben, und eine Download-Begrenzung von etwa 120 kByte technisch anderweitig gelöst. Nun wird aber das mit dem Mini-Download immer noch über diverse Logger-Software behauptet, dass das fehlerfrei und beweissicher funktionieren soll. So auch in dem Gutachten. Konkret vorgelegt hat das bis heute noch kein einziger IT-Dienstleister, es wird immer nur behauptet. Hier soll noch mal ganz dezent auf den eMule Quell-Code verwiesen werden. Unter anderem ist nämlich auch dort bei den Code-Zeilen 981 und 1160 der Hinweis (in englisch) zu finden, dass die Begrenzung der Download-Blöcke auf Werte im 10kByte-Bereich nicht nur zu Problemen, sondern auch zu Fehlern führte. Diverse IT-Dienstleister die immer auf diesem vermeintlich fehlerfreien Mini-Download herumreiten, können uns das gerne mal erklären. Auch "wir" lernen gern dazu. Übrigens, der o.g. Quell-Code unterliegt noch immer der Lizenz der GPL. Stimmts meine Herren IT-Dienstleister, falls das mal wieder Einer versehentlich vergessen haben sollte.
<e>
Grundsätzlich sollte also, wenn wir die Geschichte mit dem Mini-Download jetzt mal weglassen, mit den Testdateien (siehe Punkt 3.4 <c>) der Nachweis erbracht werden, dass die Log-Software funktioniert. Und das macht sie auch. Das konnte nämlich in diesem Praxistest bereits festgestellt werden. Allerdings gibt es da noch einen richtig üblen Stolperstein, der seltsamerweise in dem Gutachten ebenfalls gar nicht erst erwähnt wurde. Allmählich drängt sich das Gefühl auf, dass hier in dem Gutachten relevante Probleme im ed2k-Netz verschleiert werden.
<f>
Wer jetzt der festen Überzeugung ist, dass sich die oben genannte Erkenntnis (die Log-Software funktioniert grundsätzlich erst mal) auf das reale ed2k-Netz übertragen lässt, der konnte entweder der technischen Materie nicht mehr ganz folgen, oder hat ganz einfach den eigentlich entscheidenden Problem-Punkt einer Log-Software nicht erkannt. Dieser entscheidende Punkt, der übrigens im kompletten Gutachten mit keiner einzigen Silbe erwähnt wird, ist nämlich das berüchtigte Credit-System. Das ist nun mal gerade beim eMule vorhanden, wird durchweg auch genutzt, und lässt sich eben nicht durch ein Gutachten mal einfach so wegzaubern. Zur Erinnerung noch mal die Kurz-Beschreibung und Wirkung. Und das hat eine fatale Wirkung auf die Log-Software (im übrigen auf jegliche Form von Log-Software die nicht uploaded) und natürlich auch auf das Gutachten. Mehr dazu im folgenden Abschnitt.

An dieser Stelle mal eine erste Zusammenfassung:
Der Gutachter hat eine recht aufwändige Testumgebung direkt beim beauftragenden IT-Dienstleister aufgebaut, was der Definition "unabhängiges Gutachten" wohl nicht gerade zuträglich ist. Der Testaufbau selbst enthält schon einige technische Unzulänglichkeiten, die bereits Zweifel an der Praxistauglichkeit des Gutachtens aufkommen lassen. Der eigentlich beweissichere Download-Test der Log-Software wurde mit unzähligen Testdateien durchgeführt, die außerhalb der Testumgebung weder bekannt waren, noch in der Praxis überhaupt so vorkommen. Der Beweis, dass die Log-Software in einem ed2k-Netz mit unzähligen realen Gegenstellen dann auch so funktioniert, konnte mit dem Gutachten bisher noch nicht mal im Ansatz erbracht werden.



3.5) die Log-Software und das reale ed2k-Netz

In diesem Abschnitt soll einmal genau erläutert werden, was die begutachtete Log-Software im (realen) ed2k-Netz tatsächlich erwartet. Obwohl die Testumgebung (siehe Bild-400) mit dem Internet (und damit auch dem ed2k-Netz) verbunden war, kann hier von einer realen Tauschbörsenumgebung überhaupt keine Rede mehr sein. Denn dazu gehören nämlich auch "reale" Gegenstellen, und nicht irgendwelche Clientversionen, die für den Test zurecht gebogen wurden. Rufen wir uns noch einmal den Punkt 3.4 <c> in Erinnerung "...niemand außerhalb der Testumgebung kannte diese Testdateien...". Das bedeutet also auch, nur der Log-Client hatte diese Dateien als Einziger zum Download angefordert. Damit gibt es jedoch auf den Clients in der Testumgebung auch keine weiteren Nutzer in einer Warteschlange, und das sog. Credit-System wird praktisch wirkungslos (sofern das überhaupt auf den Test-Clients aktiviert war). Logisch, wenn nur ein Nutzer die Datei zum Download anfordert, gibts auch keine Warteschlange "zum hinten anstellen" mehr. Der Nutzer (auch wenn es ein Leecher ist) kommt dann sofort zum Zuge (Download).
Und jetzt unterstellen wir doch einfach mal dem Gutachten, man hätte nur den Log-Client mit dem ed2k-Netz verbunden, und die Filetauscherei einer "realen" Datei loggen lassen. Also nicht irgendeine selbst erfundene Datei, deren Name und Dateihash niemand im ed2k-Netz kennt.
<a>
Also werden wir mal einen aktuellen Datei-Typ aus dem ed2k-Netz schnappen, der immer wieder mit Vorliebe geloggt und abgemahnt wird. Selbstverständlich wird auch bei diesen Datei-Typen erst mal behauptet, die werden durchweg alle massenhaft via P2P illegal verbreitet. Das es diese massenhafte illegale Verbreitung gibt, wird wohl niemand bestreiten wollen. Ein Blick in's P2P-Netz genügt da bereits. Nur trifft das eben leider nicht auf alle Werke (Dateien) zu. Ein digitales Werk das keiner legal kaufen will, weil es vielleicht einfach nur schlecht produzierter Plunder ist, das will auch im P2P-Netz eigentlich niemand haben. D.h., neben der üblichen KostNix-Fraktion die wirklichen jeden Mist herunterladen, wird solches digitales Werk nur wenige Abnehmer finden, und schon gar nicht sich via P2P massenhaft verbreiten. Interessanterweise ist das bereits an der sog. Quellenverfügbarkeit deutlich zu sehen. Ein simple Einsteiger-Beurteilung übrigens, deren Sinn zahlreiche Abmahner bis heute noch nicht begriffen haben. Statt dessen werden Abmahnungen immer mit solchen Sprüchen hier pauschal zugedröhnt. Schauen wir mal weiter.
>> TestScreen720 << - ein aktuelles Hoppelwerk
Die besondere Aufmerksamkeit gilt erst einmal der Quellenverfügbarkeit. Fairerweise sagen wir mal OK, das Werk wird etwas rege getauscht und findet Abnehmer. Allerdings, bei "Massenhaft" würde die Anzeige doch deutlich anders aussehen. Im weiteren Verlauf werden wir noch etwas detaillierter auf diese Quellenverfügbarkeiten eingehen. Zunächst erst mal weiter mit der Log-Software.
<b>
Zunächst einmal müssen wir wieder eine Behauptung aus dem Gutachten erwähnen. Da steht u.a. (sinngemäß) "Bei einem ed2k-Client geschieht das Anbieten und Herunterladen von Dateien quasi gleichzeitig". Nun, das stimmt zwar vom Grundsatz her, ist aber nur die halbe Geschichte. Denn bevor ein Client die Datei überhaupt zum Download für andere Gegenstellen anbieten kann, muss er erst mal selbst einen gehörigen Teil fehlerfrei heruntergeladen haben. Insofern ist eine solche Aussage erst mal eine fehlerhafte Darstellung.
>> TestScreen715 << - das Chunk-Problem
Bevor der Client die Datei nicht im SharedOrdner stehen hat, hat der Log-Client also auch keine Chance auf einen Probe-Download. Aber, in dem Moment wo der Client den Download startet, taucht er nach wenigen Minuten in der Liste der verfügbaren Quellen auf, obwohl er die Datei noch gar nicht in seinem Shared-Ordner stehen hat. Allerdings erscheint der Client in einer Warteschlangenliste noch mit null Prozent (0%) der Datei vorrätig. Die genauen technischen Umstände, wieso es überhaupt zu einer solchen 0%-Anzeige kommt, sollen hier nicht weiter erläutert werden. Das würde zu weit führen.
>> TestScreen099 << - Quelle aus Testbericht Teil-2
Das Bild-099 zeigt einen solchen Client.
<c>
Diese Quellenanzeige kann natürlich auch der Log-Client sehen. Interessanterweise kann der Log-Client damit bereits den Download bei der Gegenstelle (Client) anfordern, obwohl dort noch gar kein Teil der Datei geuploaded werden kann (0% der Datei vorrätig). Auch wenn dort 100% stehen würde, hat der Log-Client erst mal keine Chance auf einen Probe-Download. Da es hier jedoch mehrere Nutzer mit einer Download-Anforderung gibt, darf sich der Log-Client nämlich erst mal ganz brav in der Warteschlange anstellen. Hier wiederum sei nochmal erwähnt, der Log-Client uploaded nicht (was übrigens im Gutachten ausdrücklich festgestellt wurde), arbeitet damit praktisch im Leecher-Modus, und kann demzufolge auch keine "positiven" Credit-Punkte durch den Upload erlangen. Im Endergebnis landet der Log-Client erst mal ganz weit hinten in der Warteschlange.
<d>
Die einzige Möglichkeit für den Log-Client, sich in der Warteschlange bei den Gegenstellen nach oben zu arbeiten, besteht also nur in einer geduldigen Wartezeit. Eine detaillierte Beschreibung wie das genau funktioniert, ist in den beiden folgenden Links nachzulesen. Credit-System / Bewertung und Punkte . In den nachfolgenden drei Bildern hatten wir das früher schon mal pro Tag mit je einer Stunde Online-Zeit getestet. Nur um mal zu sehen, ob die reine Wartezeit (ohne jeglichen Upload) einen Einfluss auf unseren QR-Wert hat. Wir hatten uns dazu extra eine Gegenstelle (siehe Markierung im Bild) auserkoren, wo der Provider keine Zwangstrennung nach 24h macht. Was übrigens an der IP-Adresse der Gegenstelle erkennbar ist.
<e>
Ein Testlauf an drei aufeinander folgenden Tagen, mit je 1 Stunde Online-Zeit.
>> TestScreen733 << - Tag1
>> TestScreen734 << - Tag2
>> TestScreen735 << - Tag3
Wie wir in den Bildern sehen können, haben wir uns selbst mit einer kurzen Wartezeit pro Tag bereits bei einer Gegenstelle deutlich nach oben gearbeitet. Das funktioniert natürlich auch mit dem Log-Client. Allerdings, damit das über mehrere Tage läuft, hat die Sache einen Haken. Der Log-Client darf seinen Userhash in diesem Zeitraum nicht ändern. Wer das Credit-System verstanden hat, vor allem wo die Punkte gespeichert werden, der wird erkannt haben worin der Haken besteht. Die notwendigen Angaben für das Credit-System werden nämlich immer bei der jeweiligen Gegenstelle gespeichert. Je nach Client-Einstellungen bleiben diese Daten dort sehr lange erhalten. Damit wird aber auch der Log-Client für technisch erfahrene eMule-Nutzer idendifizierbar. Wir haben übrigens u.a. mit dieser Methode bereits mehrere eindeutige Logger-Clients in einer Datenbank gebunkert. Einige Loggerbuden behaupten nämlich, ihre Logger-Clients seien völlig unsichtbar. Nun das sind sie nicht, auch nicht wenn die IP-Adressen über einen Anonymizer-Dienst laufen. Das wir zu diesen IP's keine Namen oder Besitzer erfahren können, ist natürlich der Sinn dieser Dienste. Aber da gibts ne ganz simple Logik. Ein P2P-Teilnehmer der permanent Hoppelwerke saugt oder verbreitet, nur weil's hier kostenlos ist, der wird dafür sicher keinen Anonymizer-Dienst bemühen der auch noch Geld kostet. Das wollen wir extra für einige sog. IT-Dienstleister nur mal so am Rande bemerkt haben.
<f>
Wer in den Bildern 733-735 "unseren" QR-Wert sowie auch den Dateizuwachs der selektierten Gegenstelle betrachtet, der wird sicherlich das Kardinals-Problem der Log-Software erkannt haben. Wir können uns zwar mit einer geduldigen Wartezeit permanent nach oben arbeiten, jedoch hatte hier die Gegenstelle am Tag-3 die Datei offenbar bereits vollständig heruntergeladen, und wird uns als "aufzeichenbare Quelle" in Kürze verloren gehen. Und zwar ohne das wir einen beweissicheren Probe-Download durchführen konnten. Der genaue Hintergrund, und welche Auswirkungen das eigentlich hat, wurde bereits im Testbericht Teil-2 festgestellt und detailliert erläutert. Das soll hier nicht noch einmal wiederholt werden. Im Gutachten jedoch wird diese vollständige Problematik zu Punkt 3.5 noch nicht einmal im Ansatz erwähnt.
<g>
Ein weiterer wichtiger Punkt. Wir können zwar in den Bildern 733-735 an Hand der Verfügbarkeitsanzeige über die Gegenstelle einen Vermutung anstellen, dass die Gegenstelle die Datei von anderen Quellen herunter geladen hat, allerdings wissen wir nicht "wann" und "von wem". Eine Log-Software kann das "aus der Ferne" nicht feststellen, es bleibt eine reine Vermutung. Einen Upload der Gegenstelle zu anderen Gegenstellen kann die Log-Software aus der Ferne schon mal weder sehen noch beweisen. Zudem fehlt der Log-Software, aufgrund des nicht erreichten Probe-Downloads, sogar der Beleg für nur einen einzigen Upload der Gegenstelle. Hier soll an dieser Stelle auch gleich noch auf ein interessantes Gutachten (pdf-Datei) des Fraunhofer Institute IPSI verwiesen werden. Dort hatte man nämlich (Seite 3/6 unten im pdf-Dokument) bereits im Jahre 2006 folgendes festgestellt: Darüber hinaus ist es in eDonkey nicht möglich, von außen einen Einblick in der Liste der aktuell laufenden Uploads oder Downloads eines Teilnehmers zu bekommen, da dies im eDonkey-Protokoll nicht vorgesehen ist.
Eine höchst interessante Aussage. Deren erwähnenswerter Hintergrund wurde nämlich im hier analysierten Gutachten zur Log-Software gleich mal (vorsichtshalber) komplett weggelassen.
<h>
Zum Abschluss des Punktes 3.5 soll noch ein weiteres Detail intensiv beleuchtet werden.
In diversen bekannt gewordenen Veröffentlichungen zur Log-Software wird ja immer wieder behauptet, die Log-Software zeichnet nur IP-Adressen (Quellen) auf, von denen ein rechtswiedriger Upload nachgewiesen werden konnte. Der bekannte Probe-Download also. Anderseits ist in diversen Gutachten wiederum die Rede, dass auch Metadaten (z.B. die Warteschlangen-Infos) mit aufgezeichnet werden, und eine Unterscheidung ob ein sog. bewessicherer Probe-Download erfolgte, dann über eine entsprechende Markierung der Log-Datensätze erfolgt. Kurz gesagt, hinter dem IP-Log-Datensatz steht in der Liste ein großes "D", was für einen gelungenen Probe-Download steht. Nun, wir haben bis heute noch keine einzige Loggerliste gesehen, wo dieser Zusatz "D" enthalten war.
<i>
An dieser Stelle wäre natürlich bereits von einigen IT-Dienstleistern das Totschlag-Argument zu hören, "unsere ausgegebenen IP-Listen wurden bereits nach solchen Quellen gefiltert, von denen der Probe-Download nachgewiesen werden konnte". Die Ausgabe-Liste also gefiltert nach dem Zusatz "D". Dummerweise liegen aber ausgerechnet von der hier begutachteten Log-Software Ausgabelisten vor, mit zahlreichen IP-Adressen in denen eben kein Probe-Download nachzuweisen war, und ganz offensichtlich reine Metadaten aufgezeichnet wurden. Der berühmte Warteschlangen-Screenshot also. Und auch hier fehlt ein Zusatz "D" generell auf den Listen. Offenbar ist wohl diese Unterscheidung auf den IP-Listen gar nicht erwünscht.
Und bevor sich einige IT-Dienstleister für die angebliche Beweissicherheit solcher Metadaten-Aufzeichnungen weiter mit abenteuerlichen Begutachtungen ins Zeug legen, empfehlen wir nochmals einen Blick in das unter Punkt 3.5 <g> genannte Gutachten. Am Besten gleich einen Schulungskurs dort buchen, dann können etwaige Zweifel bezüglich der Metadaten im ed2k-Protokoll gleich vor Ort mit dem Institut geklärt werden.
<j>
Die restlichen fragwürdigen Abhandlungen in dem Gutachten können wir uns im weiteren Detail sparen. Deren Erläuterung liese sich hier endlos fortsetzen. Generell ist die komplette Abhandlung in dem Gutachten an vielen Stellen zweifelhaft. Beschriebene technische Details widersprechen sich oft ein paar Seiten weiter, gefolgt von weiteren Erkenntnissen, die dann für völlige Verwirrung sorgen. Es drängt sich hier das Gefühl auf, dass der ausführende Gutachter stellenweise nicht mehr Herrscher über die Testumgebung war. Hier gibt es definitv zwischen der Testumgebung, den Ergebnissen der Log-Software, sowie der Darstellung im Gutachten in deutlich sichtbares Sender-Empfänger-Problem.
Abschließend muss an dieser Stelle in Richtung des Gutachters eine völlig banale Frage gestellt werden:
Wieso wurde hier nicht, an Stelle des riesigen Aufwandes an Zeit, Technik und Testdateien, einfach mit einer Testdatei, und einer aktuell illegal verbreiteten Datei in einer realen ed2k-Client-Umgebung getestet ?? Mit der Testdatei kann der Null-Upload der Log-Software, und mit den Test-Downloads einer real illegal verbreiteten Datei die beweissichere Aufzeichnung und das Verhalten der Log-Software getestet werden. Und die Legitimation durch einen RI für den Download der rechtlich geschützten Datei kann ja wohl nicht das Problem gewesen sein.



3.6) der Probe-Download und die Quellenverfügbarkeit im Netz

In diesem Abschnitt des Berichtes konzentrieren wir uns weniger auf das Gutachten, sondern mal vorwiegend um die "reale" Quellenverfügbarkeit von abgemahnten Werken, und was da immer in Verbindung mit diverser Log-Software (die ja durch den fehlenden Upload im Leecher-Modus arbeiten muss) regelrecht herbei gezaubert wird. Diesen Begriff muss man hier tatsächlich so deutlich vorbringen. Wenn in einem 24 Stunden Zeitraum zu einem Dateihash recht konstant gerade mal 80 verfügbare ed2k-Quellen gefunden werden können (in ganz Europa wohlgemerkt), dann kann im gleichen Zeitraum keine Loggerliste zusammengeklempnert werden, auf der für über 120 IP-Adressen gleich noch durchweg der Probe-Download behauptet wird. Und das auch noch gefiltert auf IP-Adressen, die nur in Germany liegen. Das ist leider kein Witz, sondern bittere Realität. Festgestellt in einer vorliegenden Loggerliste, die sicherlich ebenfalls zur Klarnamenermittlung beim zuständigen Gericht abgekippt wurde. Und das ist schon gelinde gesagt, ein starkes Stück an Dreistigkeit. Den absoluten Gipfel mit der bekannten 11.000 IP-Adressen-Liste wollen wir da besser gar nicht mehr erwähnen. Erforschen würden wir "diese Liste" allerdings schon ganz gerne mal.
<a>
An den folgenden "realen" Statistiken im Netz soll einmal gezeigt werden, auf welche Probleme die Log-Software tatsächlich gestoßen wäre, wenn man in dem Gutachen eine "realistische" Testumgebung angewendet hätte. Hingegen werden solche Probleme im Gutachten noch nicht einmal angedeutet. Das der Gutachter solche Probleme nicht gekannt oder erkannt hatte, wird ihm definitv niemand abkaufen. Allein schon aufgrund des sehr professionell ausgeführten Gutachtens muss hier der Vorwurf erhoben werden, dass die Begutachtung der Log-Software mit einer völlig unrealistischen Testumgebung ein Ergebnis vermitteln soll, welches dem Interesse des beauftragenden IT-Dienstleister folgt.
<b>
Zunächst eine technische Erläuterung zur Auswirkung der Quellenverfügbarkeit auf das Verhalten (Problem) der Log-Software. Wir hatten bereits im Testbericht Teil-2 feststellen müssen, dass die Quellenverfügbarkeit einen erheblichen Einfluss auf den "gelungenen Probe-Download" hat, und auf den ersten Blick eher unlogisch erscheint. Bei extrem vielen Quellen gelingt überhaupt kein Download, bei sehr wenigen Quellen verhält es sich umgekehrt. Hier darf man nicht übersehen, die Log-Software arbeitet im Leecher-Modus, und kann sog. Credit-Punkte bei den Gegenstellen nur über die Wartezeit sammeln. Das hat u.a. folgende fatale Wirkung. Durch eine extrem hohe Quellenverfügbarkeit (über 500 Quellen) wird die Warteschlange derart groß, dass die Log-Software aufgrund des schlechten QR-Wertes permanent nach hinten verdrängt wird, weil immer wieder neue Quellen mit deutlich besserem QR-Wert auftauchen. Die Log-Software hat hier fast keine Chance, innerhalb von 24 Stunden überhaupt einen Probe-Download erfolgreich zu starten. Bei einer mittleren Quellenanzahl (etwa 50 bis 200) gelingen Probe-Downloads ohne Probleme. Allerdings, wie bereits im Testbericht Teil-2 festgestellt, hält sich auf Grund der Leecher-Problematik "diese Ausbeute" doch arg in Grenzen. Für beweissichere Probe-Downloads in Massen reicht das schon mal gar nicht. Bei sehr wenigen Quellen (unter 20) gelingt der Probe-Download aufgrund der sehr kleinen Warteschlange nahezu mit der Hälfte der angezeigten Quellen. Nur kann man eben auch "diese Ausbeute" als massenhaft praktisch voll vergessen. Die hier eben genannten Erläuterungen sollten wir im Hinterkopf behalten, damit es nicht zu Fehlinterpretationen (Quellenanzahl versus Probe-Download) kommt.
<c>
Bevor wir beginnen die bekannten ed2k-Statistiken zu erläutern, noch ein deutlicher Hinweis an alle Zweifler dieser Grafiken.
Diese Statistik-Grafiken sind nicht irgendeine Selbstbeweihräucherung von diversen ed2k-Server-Betreibern. Hinter diesen Statistiken verbirgt sich ein OpenSource-Projekt mit einer sehr professionellen Software, in welcher die Datenerhebung im P2P-Bereich eher ein Nebenprodukt ist. Das eigentlich dahinter liegende Projekt The OFF System findet bereits in vielen Bereichen des Internet seine Anwendung, und nicht nur im P2P-Bereich. Und das arbeitet erstaunlich präzise. Genauere Infos und Details zu einer "Statistik-Software" sind u.a. auf dieser Website zu finden. Das wollten wir nur noch mal anmerken, falls wieder ein IT-Dienstleister seine Zweifel an der Aussagekraft dieser Statistiken daherlabert.
<d>
Beginnen wir mit der bereits im Punkt 3.5 <a> (Bild-720) erwähnten Datei.
>> TestScreen720 << - 08.07.2010
Zu Beginn fällt sofort auf, nach dieser Datei hat bisher kaum jemand nachgefragt. Es gibt keine Datum-History. Eine genaue Erläuterung zur Funktion der datum-History folgt am Ende des Abschnittes 3.6. Das ist also insofern schon mal fragwürdig, da diese Datei laut der Abmahndatenbank bereits in 05-2010 geloggt, und 06-2010 abgemahnt wurde. Der RI ist übrigens ein alter Bekannter. Werke dieses RI sind in der Vergangenheit bereits mehrfach mit höchst seltsamen Logging-Zaubereien aufgefallen.
>> TestScreen721 << - nach knapp 24 Stunden
Die Quellenverfügbarkeit sieht noch nicht mal im Ansatz nach "Massenhaft" aus. Ferner sollten wir uns den in dieser ominösen vlog-Datei enthaltenen Datum-Code mal sehr gut merken. Der taucht nämlich später noch mal auf.
>> TestScreen722 << - 13.07.2010
>> TestScreen723 << - 18.07.2010
Hier noch zum nachschauen der Link auf die aktuelle Statistik.
<e>
Da wir ja alle Angaben verifizieren sollten, wie in einem gründlichen Gutachten, haben wir natürlich "Live" auch im ed2k-Netz nach dieser Datei gesucht. Also haben wir uns gleich mit dem ed2k-Server verbunden, der uns die meisten Quellen anzeigte (eDonkeyServer No2).
>> TestScreen726 << - 18.07.2010
>> TestScreen727 << - 18.07.2010
Interessant ist hierbei, dass wir dieses "Lustschweinchen Teil 2" nur ein einziges mal im Netz gefunden haben, und auch (außer der ominösen vlog-Datei) keine weiteren Fake-Namen zu diesem Hash gefunden wurden. Und auch die Quellenanzeige stimmt fast perfekt mit der Statistik überein.
>> TestScreen724 << - 13.07.2010
>> TestScreen725 << - 18.07.2010
Auch diese ominösen Fake-Namen (vlog-Datei) konnten wir an zwei verschiedenen Tagen finden. Zuletzt haben wir noch zu dem Dateihash die Datenkrake Google befragt. Deren böser Cache vergisst nahezu gar nichts.
>> TestScreen728 << - Google-Abfrage am 18.07.2010
Es war übrigens der einzige Eintrag, der am 18.07.2010 zu finden war. Wir sehen nicht nur den Dateihash, sondern auch die Tauschbörsenseite und das sog. Releaser-Datum. Höchst interessant, dann das passt genau zum Namen dieser ominösen vlog-Datei. Den Zusammenhang wollen allerdings hier nicht erläutern. Das wird wieder genug Stoff für einen neuen Bericht.
<f>
Fassen wir also mal hier zusammen, und vergessen dabei auch den sog. IT-Dienstleister (Logger) nicht.
Laut Abmahndatenbank wurde diese Datei bereits im Mai-2010 geloggt. Die relativ konstante (mittlere?) Quellenverfügbarkeit über mehrere Tage lässt sicher auch Einiges an Probe-Downloads möglich werden. Allerdings passt die Datum-History (Erläuterung dazu im Punkt <g>) schon mal gar nicht zum Log-Zeitpunkt. Auch der Google-Cache mit Stand vom 05.07.2010 erweckt den Eindruck, dass bis zu diesem Datum eigentlich noch gar niemand nach diesem Hash gesucht hat. Offensichtlich auch der Logger nicht.
Nun wird in diversen Kommentaren sowie sogar eidesstattlichen Versicherungen ja immer wieder behauptet, der Dateihash wurde vor dem eigentlichen Log-Vorgang aus dem Netz herunter geladen, und mit dem Originalwerk per Ansicht beweissicher verifiziert. Das der Logger dieses Werk (Datei) dazu natürlich erst mal komplett herunterladen muss, wohlgemerkt mit einem Client im Leecher-Modus, erwähnen wir gleich besser gar nicht mehr. Und bereits hier müssen wir mal ganz krass fragen: Wo, zum Geier noch mal, hat der Logger den Dateihash hergeholt, wenn dieser erst am 3. Mai 2010 veröffentlicht wurde, die Quellenstatistik zu diesem Hash vor dem 08.07.2010 keinerlei Datum-History anzeigt, der Goggle-Cache vor dem 05.07.2010 nix kennt, und die Dateisuche zu dem Hash über sämtliche TB-Seiten (mit Ausnahme der TB-Seite im Bild-728 ) bisher erfolglos war. Hier sollte doch mal der Abmahner seine Loggerbude fragen, wie er denn das nun angestellt hat, mit der Verifizierung des Werkes/Dateihash vor den beweissichernden Probe-Downloads.
<g>
Zum Abschluss dieses Punktes soll die Entstehung dieses "History-Datums" in der Statistik mal etwas unkompliziert erläutert werden, und zwar so das auch Nicht-Experten noch folgen können. Profis mögen also Nachsicht üben, wenn einige Dinge hier ganz technisch korrekt dargestellt sind. Es geht lediglich um das Prinzip.
Grundsätzlich ist dieses History-Datum für jeden relativ leicht nachvollziehbar. Im Prinzip funktioniert das erst mal ähnlich der Technik des Google-Cache. Dessen genaue Funktionsweise soll jetzt aber nicht näher erläutert werden, das würde zu weit führen. Wir versuchen es mal ganz einfach. Prinzipiell wird im Google-Cache der Inhalt einer Website quasi eingefroren, wenn ein bestimmter Suchbegriff auf diese Website verlinkt wurde. Im Bild-728 sehen wir zum Beispiel oben rechts das Datum und die Uhrzeit, wann der Inhalt eingefroren wurde. Um eine solche Aktion überhaupt auszulösen, muss natürlich auch ein Internetnutzer genau an diesem Tag die Suchfunktion von Google bemüht haben. Das könnte z.B. die Suche nach dem Dateihash gewesen sein. Im Prinzip lässt sich damit auch feststellen, wann in Google das erste mal jemand nach diesem Dateihash gesucht hat. Nachteilig ist allerdings, dass Google immer mal die Cache-Seiten aufräumt, wenn es längere Zeit keine Suchanfragen zu dem Begriff gibt. Bedeutet bei einem Dateihash allerdings auch, keiner hat mehr über längere Zeit nach diesem Begriff gesucht. In ähnlicher Form wird das History-Datum in der ed2k-Statistik erzeugt, wenn ein Nutzer dort nach einem Dateihash sucht.
Im Übrigen kann die Suchanfrage auch über eine Verlinkung auf die Statistik-Seite erfolgen, was u.a. der eMule über die Funktion "Web-Dienste" nutzen kann.
Eingefroren werden hier jedoch nur die Quellenverfügbarkeiten, die von diversen Index-Servern geliefert werden. Das dieser Dateihash natürlich erst mal existieren muss, braucht sicher nicht weiter erwähnt werden. Die Besonderheit ist hierbei allerdings, dass die History-Tabelle erst erzeugt wird wenn ein Nutzer das erste mal nach "diesem" ed2k-Hash gesucht hat, und dass die History-Tabelle dann permanent weiter aufgelistet wird. Diese History-Tabelle zu dem Dateihash bleibt übrigens erhalten (zumindest nach dem derzeitigen Erkenntnisstand), auch wenn dieser Dateihash aktuell auf keinem Index-Server erscheint. Bedeutet, zur Zeit tauscht absolut niemand im Netz diese Datei. Im Punkt 3.7 wird noch ein Beispiel dazu gezeigt.
Zusammengefasst, dieses History-Datum ist insofern besonders interessant, wenn solche Fragen wie im o.g. Punkt <f> aufgeklärt werden müssen.



3.7) Quellenverfügbarkeit versus Massen-Logging

In letzten Abschnitt des Berichtes zeigen wir noch zwei kurze Musterbeispiele, die den Fragen (Probe-Download gelungen oder nicht) aus Punkt 3.6 <b> nachgehen. Also einmal ein Werk (Dateihash) mit einer recht hohen Quellenverfügbarkeit, und einmal ein Werk mit einer Quellenausbeute die man sprichwörtlich "in die Tonne treten kann". Vorab gleich angemerkt, beide Werke wurden auch geloggt. Zumindest hat das der Abmahner behauptet. Wie das allerdings funktioniert haben soll, konnte auch der Abmahner bis heute noch nicht beantworten. Mit der Frage nach der beweisgesicherten Verifizierung mit dem Originalwerk, erschrecken wird den Abmahner besser gleich gar nicht erst.
<a>
>> TestScreen731 << - 22.12.2009
Bei dem hier gezeigten Dateihash war die Quellenverfügbarkeit sogar hoch genug, dass ein Statistik-Graph erzeugt wurde. Leider fehlt der hier im Screenshot (Bild-732). Kein Problem, er ist nicht verloren und im Bild-732 wieder zu sehen.
>> TestScreen732 << - 19.07.2010
Dieses Werk hatte in der Tat eine bemerkenswerte Quellenstatistik hingelegt. Man könnte glatt meinen, dass es sich hierbei nicht unbedingt um ein grottenschlechtes B-Movie handelte. Es fand nämlich jeder Menge Abnehmer, denen das Werk ganz offensichtlich auch ein intensiver Upload wert war. Zumindest konnten wir auch dem Google-Cache entnehmen, dass dieses Werk immer noch nachgefragt wird. Zudem zeigt auch die aktuelle Statistik, dass dieses Werk im ed2k-Netz immer noch "ganz ordentlich" unterwegs ist.
Was sich uns allerdings nicht so recht erschließen mag, ist der exorbitante Einstieg zum ersten History-Datum, mit knapp 400 Quellen bei über 200 vollständig verfügbaren. Das ist schon sehr ungewöhnlich. Zumal wir auch diesen Dateihash erst mit Release-Datum 25.10.2009 auf der berühmten Esel-Seite "saugstube.to" finden konnten. Welches im Übrigen mal wieder (rein zufällig??) zum Bild-731 passt. Wie in so kurzer Zeit eine derart hohe Verfügbarkeit an sog. "vollständigen Quellen" zustande kommen soll, ist auch für uns kaum noch nachvollziehbar. Wir reden hier über eine Datei mit über 1.3 GByte Größe. Übersehen sollten wir auch nicht die zu erwartende enorme Größe der eMule-Warteschlange, die sich bei einem Dateihash mit so hoher Verfügbarkeit i.d.R. auf den Clients ergeben wird. Unter Punkt 3.6 <b> wurde bereits erwähnt, mit welchem Problem die Log-Software (Versuch des Probe-Downloads) bei so hohen Quellenverfügbarkeiten konfrontiert wird. Völlig suspekt erscheint uns da insofern die Tatsache, dass dieses Werk laut Abmahndatenbank auch noch im selben Zeitraum (10-2009) geloggt wurde. Wir wollen hier keine Spekulationen ausstreuen, wer hier wohl am Upload dieses Werkes denn so alles mit beteiligt war. Betrachtet man sich aber allein schon die Datumzeiträume zu diesem Werk (Dateihash), dann können auch wir uns gewisse Theorien hier nicht mehr verkneifen.
<b>
>> TestScreen729 << - 20.11.2009
>> TestScreen730 << - 19.07.2010
Bei diesem Werk wollen wir nicht noch einmal alle Erläuterungen wie unter Punkt <a> wiederholen. Aber auch dieses Werk wurde laut Abmahndatenbank bereits in 05-2009 geloggt. Hier müssen wir bereits die drastische Frage stellen, was hat hier die Loggerbude eigentlich zusammengeklempnert, dass es überhaupt noch zu Abmahnungen kommen konnte. Die Loggerbude (der Begriff ist hier durchaus gerechfertigt) ist übrigens ein alter Bekannter, der nicht nur in diesem Artikel schon negativ aufgefallen war, sondern sich auch noch gleichzeitig als Rechteinhaber über diese hochgeistigen Werke zu präsentieren versuchte. Der Rest dieser höchst abstrusen Geschichte zu der Loggerbude ist es gar nicht mehr Wert, hier überhaupt noch weiter genannt zu werden.
Dieses o.g. Werk (Bild-729) war übrigens auf keiner der üblichen TB-Seiten aufzufinden. Der einzige Hinweis war im Google-Cache zu finden. Und auch die aktuelle Statistik lässt nur noch einen Schluss zu, praktisch niemand im ed2k-Netz konnte für dieses Werk (Dateihash) begeistert werden. Wiederum stellt sich die Frage, wie soll das Ding mit dem massenhaft beweisgesicherten Probe-Download hier funktioniert haben. Die weitere Frage, wie denn die Verifizierung des Dateihashes mit dem Original-Werk erfolgte, können wir uns hier sicher gleich komplett ersparen. Ebenso die abschließende Frage, wer denn nun zu dem o.g. Log-Zeitpunkt tatsächlich welche Rechte an dem Werk inne hatte, dürfte zumindest bei den am Log+Abmahnvorgang beteiligten Personen noch einige Magenschmerzen verursachen.



3.8 ) Zusammenfassung und Fazit

An dieser Stelle sollen noch einmal die wichtigsten Punkte aus der Abhandlung zusammengefasst werden.

<a>
Der Gutachter hatte die komplette Testumgebung am Standort dee beauftragenden IT-Dienstleisters aufgebaut. Unabhängig der Möglichkeit, dass hier technische Anschlussprobleme am Heim-Standort des Gutachters vorgelegen haben könnten, repräsentiert eine solche Vorgehensweise nicht gerade die Darstellung eines unabhängigen Gutachtens, welches eigentlich frei von der Möglichkeit der Einflussnahme durch den Auftraggeber sein sollte.
<b>
Die verwendete Testumgebung wirft zahlreiche technische Fragen auf, die mit dem üblichem Netzwerkbetrieb mehrerer ed2k-basierender Clients teilweise nicht mehr in Übereinstimmung zu bringen sind. Zudem sind die technischen Beschreibungen zur Testumgebung nicht nur sehr verwirrend dargestellt, sie wiedersprechen sich in einigen Punkten im Gutachten sogar noch selbst.
<c>
Es wurden in den Testläufen zwar eine riesige Menge an Dateien verwendet, jedoch keine einzige dieser Testdateien würde jemals in der hier verwendeten Form in einem ed2k-Netz auftauchen, und konnten somit auch nicht von "realen" ed2k-Nutzern aus dem Internet zum Download angefordert werden. Die Menge solcher Download-Anforderungen von realen ed2k-Nutzern hat jedoch einen ganz erheblichen Einfluss auf die sog. Warteschlangen-Größe bei allen beteiligten ed2k-Clients, welche zudem noch vom bekannten eMule-Credit-System intensiv beeinflusst wird. Durch die Verwendung der o.g. völlig unrealistischen Testdateien (Datei-Namen und Hashes) wurde hier ein ed2k-Tauschbörsenbetrieb simuliert, der im völligen Gegensatz zum realen Tauschbetrieb im ed2k-Netz steht.
<d>
In dem Gutachten wurde permanent unterstellt, dass die hier gewonnenen Ergebnisse den einwandfreien Betrieb der Log-Software belegen, und somit auch den Ergebnissen bei der Aufzeichnung illegaler Aktivitäten von ed2k-Gegenstellen entsprechen müssen. Abgesehen von dieser abenteuerlichen gutachterlichen Feststellung, wurden technische Probleme (ed2k-Protokoll), auf welche die Log-Software im aktiven Betrieb mit realen ed2k-Gegenstellen nun mal treffen würde (Warteschlangen-Einstufung, Credit-System, schlechte Quellenverfügbarkeit, Leecher-Erkennung, usw.), im Gutachten noch nicht einmal ansatzweise erwähnt. Hier bleibt die Frage offen, ob der Gutachter diese Probleme nicht gekannt hatte (was nur schwer vorstellbar ist), oder es der Wunsch des beauftragenden IT-Dienstleisters war, diese Probleme tunlichst nicht zu erkennen.
<e>
An Hand eines Test-Szenarios mit zahlreichen Muster-Dateien aus dem aktiven Tauschbetrieb im ed2k-Netz wurde das Problem der Quellenverfügbarkeiten, sowie auch deren Wirkung auf den beweissichernden Probe-Download der Log-Software untersucht. Im Gutachten selbst wurde eine solches Test-Szenario gar nicht erst durchgeführt. Selbst weiterführernde Recherche-Möglichkeiten im Internet bezüglich der Verifizierung von Quellenverfügbarkeiten (z.B. ed2k-Hash-Statistiken) wurden gleich gar nicht erst erwähnt.
<e>
Statt dessen wird im Gutachten permanent hervorgestellt, der Probe-Download der Log-Software konnte stets fehlerfrei und beweissicher belegt werden. Diese Feststellung im Gutachten ist schon insofern zweifelhaft, dass ausgerechnet eine von der hier begutachteten Log-Software generierte Aufzeichnungs-Liste (IP-Liste/Logging-Liste) vorliegt, die nicht nur zahlreiche Fehler enthält, sondern der auch wichtige Zusatzinformationen (z.B. Download-Markierung des IP-Datensatzes) ganz einfach fehlen. Völlig unverständlich schon aus dem Grund, dass die Log-Software gemäß dem Gutachten solche beweissichernden Zusatzinformationen nicht nur generiert, sondern auch zuverlässig speichert.

Damit beenden wir die Zusammenfassung und kommen zum abschließenden Fazit.


Das hier analysierte Gutachten zu einer sog. Aufzeichnungssoftware (Log-Software) vermittelt auf den ersten Blick ein äußerst glaubwürdiges und professionelles Bild. Bei genauer Betrachtung jedoch sind die Vorgehensweise sowie auch die Ergebnisse des Gutachtens noch nicht einmal annähernd auf einen realen ed2k-Tauschbörsenbetrieb übertragbar. Das ein solches Gutachten, welches ganz offensichtlich von einem IT-Profi erstellt wurde, auch als Entscheidungsgrundlage für diverse Rechtsstreitigkeiten zu sog. FileSharing-Fällen herangezogen wird, gibt Anlass zu deutlicher Kritik. Vor allem auch die Tatsache, dass in dem Gutachten mit bemerkenswerter Gründlichkeit versucht wird, der vom beauftragenden IT-Dienstleister verwendeten Aufzeichnungssoftware eine durchweg fehlerfreie und beweissichere Funktion zu belegen, gibt dem gesamten Gutachten einen mehr als anrüchigen Charakter. Hier gibt es, bezüglich der eigentlichen Signalwirkung eines Gutachtens, definitv ein erhebliches Sender-Empfänger-Problem.
Und hier sollte allen Beteiligten bei den sog. FileSharing-Fällen nahe gelegt werden, dass man auch bei einem auf den ersten Blick äußerst professionell erstellten Gutachten, zukünftig doch etwas genauer hinschauen sollte. Nicht alles was glänzt, besteht auch wirklich aus Gold.


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

Ein weiterer Bericht ist zunächst erst mal nicht geplant.
Allerdings werden wir weiter diese Dateihashes im Auge behalten,
hinter denen sich immer diese ominösen vlog-Dateien verbergen.
Die entsprechende Liste wird dann immer mal veröffentlicht.
Damit ist die Berichts-Reihe "Testberichte" abgeschlossen.

-CityLight-

Zitat von heinz01

was können wir dagegen machen?

Wie gehabt, wie immer:

1. MOD-UE per ES+RS
2. kein Kontakt zum Abmahner
3. Keine Kohle für Abmahner
4. Abwarten und Tee trinken
5. Kein Filesharing mehr

Zitat von heinz01

Zur Staatsanwaltschaft laufen und mal das Forum hier bekanntmachen?

Was sollte es denn bringen? Meinst Du, würde er völlig entsetzt und geschockt über die Abmahn-Mafia reagieren? Oder würde er Unmittelbar danach eine Spezialeinheit hinschicken, um das Netzwerk zu vernichten?

Zitat von heinz01

Oder stecken die auch noch unter einer Decke!?

Ich habe schon mal meine Meinung darüber in einem anderen Thread geäußert. Klick mich

PS.: Du möchtest dich bitte noch viel mehr in der Materie vertiefen. Bitte fang mal an zuerst mit „Das kleine ABC für Neuabgemahnte“ in meine Signatur, und danach lies die Beiträge der erfahrenen Forenuser durch! Genauso habe ich auch gehandelt, als ich meine Abmahnung bekommen habe.
Meiner Meinung nach, das Forum hier ist dank vielen erfahrenen Forenuser eine von besten Informationsquellen!


Gruß
Sycron

Serie: Die rechtsmissbräuchliche Abmahnung. Folge 5

[...]vielmehr müssten weitere Umstände hinzutreten, die die Missbräuchlichkeit der Geltendmachung des Anspruchs begründen. Das Gericht erblickte diese zusätzlichen Umstände in der vorstehenden Entscheidung in folgenden Punkten:

* Getrenntes Vorgehen gegen die juristische Person und ihrer Repräsentanten wegen desselben Verstoßes ohne sachlich nachvollziehbaren Grund
* Aussprechen mehrerer Abmahnungen, die von vornherein hätten gebündelt werden können, sog. mangelnde Verhältnismäßigkeit
* Ausübung erheblichen Drucks auf den Abgemahnten durch Hinweis auf höhere Kosten (für den Fall einer gerichtlichen Geltendmachung des Unterlassungsanspruchs) und Setzen enger Fristen
* Vorformulierte Unterlassungserklärung sieht eine Vertragsstrafenzahlung von 7.000 Euro je Verstoß vor

Achsoooo, ist ja UWG.
Im UhrG können die Fristen ruhig 2 Tage betragen und der seelische Druck auf den Abgemahnten kann ruhig ins unermessliche gehen (ich vergaß)

Zitat von Sycron

Was sollte es denn bringen? Meinst Du, würde er völlig entsetzt und geschockt über die Abmahn-Mafia reagieren? Oder würde er Unmittelbar danach eine Spezialeinheit hinschicken, um das Netzwerk zu vernichten?

Offensichtlich geschieht hier Unrecht, strafbares Unrecht. Und bei hinreichendem Verdacht ist es sogar die PFLICHT der Staatsanwaltschaft, hier tätig zu werden.

Zitat von heinz01

Offensichtlich geschieht hier Unrecht, strafbares Unrecht. Und bei hinreichendem Verdacht ist es sogar die PFLICHT der Staatsanwaltschaft, hier tätig zu werden.

Abmahnungen gibt und gab es schon immer und sie sind föllig legal.
Was hier zu bemängeln und anzuprangern ist die Art und Weise, wie sie zu Stande kommen.

Zitat von ulrich

Was hier zu bemängeln und anzuprangern ist die Art und Weise, wie sie zu Stande kommen.

Genau das meine ich. Merkwürdige Beweise, massenhaftes Abmahnen auch Unschuldiger mit wirtschaftlichem Gewinn im Hinterkopf.

Zitat von Kersare

Achsoooo, ist ja UWG.
Im UhrG können die Fristen ruhig 2 Tage betragen und der seelische Druck auf den Abgemahnten kann ruhig ins unermessliche gehen (ich vergaß)

- Es wird immer Grundsätze geben die sich überschneiden ("Dementsprechend werden teilweise auch für das Patentrecht die von der Rechtsprechung zum Marken- und Urheberrecht entwickelten Grundsätze herangezogen" und auf den Einzelfall zugeschnitten werden müssen

Die Fristen jedoch sind überall gleich: Sie müssen angemessen sein was eine Woche nach Ausstellung bedeutet. Wird aber ein Schreiben um 10:00 Uhr Freitags eingeworfen das eine Frist um 12:00 Freitags enthält kann kein Mensch mehr von angemessen reden wenn das Schreiben eine Woche zuvor datiert wurde. Das Verschulden liegt hier nicht beim Abgemahnten.