Beim Nexus 5 habe ich zum ersten Mal überhaupt Hardware gekauft, ohne einen Testbericht abzuwarten. Direkt in der ersten Stunde, in der es verfügbar war, habe ich zugeschlagen und bin nach wie vor sehr zufrieden mit meinem Kauf. Wären da nicht die GPS-Probleme, die mich plagen und doch schon gelegentlich für etwas Frust sorgten.

Die Probleme waren nicht von Anfang an so massiv vorhanden sondern scheinen schleichend immer schlimmer geworden zu sein. Zunächst gelegentlich, in letzter Zeit jedoch nahezu immer, ließ der GPS-Lock sehr lange auf sich warten. Zum Teil dauerte es bis zu 15 Minuten, bevor meine Position korrekt angezeigt wurde und nach wenigen Minuten war es dann auch schon wieder vorbei. Sehr stark schwankende Genauigkeit, teilweise blieb meine Position einfach hängen und erst nach einigen Minuten war die Anzeige wieder halbwegs korrekt. Teilweise wurde mein Standort über 500m weiter weg angezeigt, als es tatsächlich der Fall war, die Anzeige hing dann beim Fahren hinterher und ich habe deshalb auch schon mal Straßen verpasst, wenn ich mich auf die Navigation verlassen habe. Sehr nervig, wenn man wie ich doch öfter mal in unbekannten Städten unterwegs ist. Extrem auffällig war das Problem in Ingress, wo ich in letzter Zeit eigentlich nahezu immer weit ab von der Position angezeigt wurde, in Maps oder Waze funktionierte es etwas besser, aber dennoch war ich immer und immer wieder ohne GPS-Empfang.

Wer hier gelegentlich mal mit liest wird jetzt sicher ein Déjà-vu haben, denn ähnliches erlebte ich auch schon mit meinem letzten Smartphone, dem Galaxy S2. Da ich es dort recht einfach mit Hilfe einer App lösen konnte (und demzufolge ganz offensichtlich ein Software-Problem vorlag), hoffte ich auf eine ähnliche Lösung beim Nexus 5 und habe mal ein wenig recherchiert. Und bin zunächst mal im Google Product Forum gelandet und hab mich dort durch den langen Thread gekämpft. Mit dem Problem stehe ich offensichtlich nicht allein da und offenbar bringen auch Austauschgeräte nicht immer eine Verbesserung, selbst Geräte der neuesten Revision. Neukalibrierung hilft nicht oder nur temporär, also doch ein größeres Software-Problem?

Um es kurz zu machen: Ich denke nicht, dass es sich um einen Softwarefehler handelt, im Gegenteil deutet inzwischen sehr vieles darauf hin, dass hier ein Produktions-/Konstruktionsfehler vorliegt und dieser auch bei der aktuellen Hardware-Revision noch auftritt. Darauf deuten verschiedene Umstände hin und auch die Art, wie ich das Problem beseitigen konnte, ist ein mehr als deutliches Zeichen und im Grunde auch der Beweis für diese Theorie. Zum Einen verschlimmern sich Softwarefehler in der Regel nicht schleichend. Gegen Softwarefehler spricht ein wenig auch die Tatsache, dass manche diese Probleme haben, andere nicht. Klarer wurde es, als ich diesen Thread im XDA-Forum entdeckte. Unter anderem beschrieb jemand, dass Druck auf eine Ecke der Gehäuserückseite den GPS-Empfang massiv verbesserte. Und es wurde ein Video verlinkt, in dem ein Hardware-Hack gezeigt wird, der das Problem beseitigt.

Bevor ich das Video jetzt hier poste noch ein paar Worte zu dieser Bastelei: Wer sich an diese Reparatur heranwagt sollte sich darüber im Klaren sein, dass er damit seine Garantie aufs Spiel setzt. Zudem sollten Grobmotoriker besser die Finger davon lassen, da man bei dieser Prozedur unter Umständen schnell mehr zerstören als reparieren kann. Und als letzter Warnhinweis: Wenn Ihr dabei etwas kaputt machen solltet, dann ist liegt es an Euch selbst, nicht an mir 😉

Kurz ein paar Worte zur Beschreibung des Hacks:

Die GPS-Antenne des Nexus 5 ist von innen auf den hinteren Gehäusedeckel aufgeklebt. Sehr gut zu erkennen ist sie in der linken oberen Ecke auf diesem Foto (Aufdruck HH_GPS 0814) von iFixit. Auf dem Foto sieht man auch sehr deutlich die beiden Kontakte, die das Problem zu verursachen scheinen. Entweder aufgrund der Tatsache, dass das verwendete Material schnell verschmutzt oder korrodiert (was ich mir eigentlich nicht vorstellen kann, wofür aber die schleichende Verschlechterung sprechen würde), oder weil sie nicht weit genug vom Gehäuse abstehen und somit keinen ordentlichen Kontakt herstellen können.

Im Video wird gezeigt, wie der Fehler beseitigt wird: Es wird schlicht und ergreifend ein klein wenig dünne Pappe unter diese Kontakte geschoben und damit üben sie geringfügig mehr Druck aus. Achtet darauf, dass ihr wirklich dünne Pappe benutzt, dünner Bastelkarton war bei mir schon zu dick und das Gehäuse ließ sich nicht mehr ganz schließen sondern blieb einen dünnen Spalt weit offen. Da müsstet Ihr dann mal vorsichtig probieren. Entscheidend ist jedoch, dass schlagartig nach diesem Hack meine GPS-Probleme aus der Welt waren. Ich hab heute mehrere Stunden mit Ingress getestet (was für eine Wohltat mit funktionierendem GPS) und hatte nicht ein einziges Mal Schwierigkeiten mit der Positionsbestimmung oder auch keinen GPS-Empfang. Für mich ist das ein sehr deutliches Zeichen dafür, dass hier seitens LG offenbar etwas ungenau gearbeitet wurde. Ich denke nicht, dass hier mit Software nachgebessert werden kann. Wer sich diese Reparatur nicht zutraut oder keinesfalls die Garantie aufs Spiel setzten möchte, sollte bei GPS-Problemen also einen Umtausch anstreben. Was ich wahrscheinlich auch gemacht hätte, müsste ich dann nicht für längere Zeit auf Erreichbarkeit verzichten.

Hier nun aber das erwähnte Video:

Ich wünsche viel Erfolg beim Basteln und werde mal weiter beobachten, was in nächster Zeit zu diesem Problem noch bekannt wird und ob es Lösungen von Google/LG geben wird.

Wie viele andere sicherlich auch verfolge ich in den letzten Tagen ziemlich aufmerksam die Berichte zu den Abmahnungen rund um redtube.com. Allein mangelnde Zeit hat mich bislang daran gehindert, hier schon mal etwas dazu zu schreiben. Wer bisher tatsächlich noch nichts davon mitbekommen haben sollte, kann sich (unter anderem) ja mal hier, hier, hier oder hier einlesen. Aber Vorsicht, das könnte Zeit kosten…

Inzwischen sind auf jeden Fall schon eine ganze Menge Informationen bekannt geworden, speziell auch die Akteure dieser Aktion betreffend. An diesen Diskussionen möchte ich mich (in erster Linie aus zeitlichen Gründen) nicht beteiligen, meine Meinung hierzu ist ohnehin gefestigt. Nach wie vor offen ist allerdings die Frage: Woher kommen die IP-Adressen? Wie will die mit der „Überwachung“ beauftragte „Firma“ nun exakt herausgefunden haben, wer welchen Stream wann gesehen hat? Hierfür gibt es aktuell diverse Theorien:

1. Zufälliges Auswürfeln
2. Virus/Trojanisches Pferd auf dem PC des „Übeltäters“ (sprich: Abmahnopfer)
3. Umleitung über eine oder mehrere andere Domain mit Hilfe von manipulierten Links oder Traffic-Verkäufern wie Trafficholder.com
4. Auswertung der Logfiles von redtube.com (offiziell oder mit Hilfe eines Insiders)
5. Schaltung von Werbebannern bei Redtube auf exakt den Seiten mit den betreffenden Videos
6. manipulierte Router der „Übeltäter“ (sprich: Abmahnopfer)
7. etc.

Für alle Varianten gibt es gewisse Wahrscheinlichkeiten. Interessant ist beispielsweise, dass auffallend viele abgemahnte Personen davon berichten, in ihrem Browserverlauf für den fraglichen Zeitraum scheinbare Besuche bei retdube.net gefunden zu haben. Einer „Vertipperdomain“, die dem Ziel redtube.com auf den ersten Blick zumindest sehr ähnlich sieht, was für Variante 3 sprechen würde. Diese Variante wird noch dadurch bestätigt, dass die gefundenen URLs offenbar einen direkten Bezug zu den Videos haben, die die abgemahnten angeblich gesehen haben sollen. Zum Beispiel beschreibt hier jemand, er wäre für das Streamen eines Videos abgemahnt worden, dass unter der URL „….redtube.com/49655“ zu finden sei. Im fraglichen Zeitraum findet sich allerdings nichts dergleichen in seiner Browserhistorie. Dafür aber 2 andere Einträge: 49655.retdube.net sowie http//hit.trafficholder.com/transfer.php?http//49655.. Auffallend ist die Übereinstimmung der ID des Videos mit den IDs in den beiden URLs aus dem Verlauf. Doch inwiefern wäre das relevant?

Trafficholder sorgt nach eigenen Angaben für genügend Aufrufe auf Seiten im Bereich „Erwachsenenunterhaltung“, wenn man den entsprechenden Service bucht. So genannter „skimmed traffic“. Trafficholder selbst schreibt dazu:

Skimmed traffic is blind clicked traffic coming from free adult websites (TGPs, MGPs, etc.). Clicking on the thumbnails a visitor may be redirected to a content page (a promo gallery) or to any other adult website (yours, for example). That is what we offer.

Es ist also ohne Schwierigkeiten realisierbar, dort ein wenig Traffic zu buchen. Die Nutzer klicken „blind“ auf einen Link und werden dann umgeleitet auf beispielsweise 1234567.xsized.de. Ich muss unter dieser URL nun schlicht eine Weiterleitung auf zum Beispiel www.youtube.com/1234567/ einrichten und könnte dann anhand unterschiedlichster Logs und Auswertungen ziemlich genau sehen, welche IP-Adressen diesen (nicht existierenden) Link auf Youtube aufgerufen hätten. Verpacke ich das Ganze dann noch in eine WebSite, die einfach nur wie eine Werbung aussieht und bette das Video in einem winzigen Iframe ein, dann merkt der Nutzer nicht einmal, dass er das Video geladen hat. Im (extrem unwahrscheinlichen bis unmöglichen Fall) einer Überprüfung des Streaming-Providers (in meinem Beispiel Youtube) ließe sich so auch noch feststellen: Ja, die IP-Adresse sowieso hat im fraglichen Zeitraum das Video abgerufen. Diese Variante der Beschaffung der IP-Adressen erschient mir in diesem Fall die wahrscheinlichste, wahrscheinlich wird es auch tatsächlich so abgelaufen sein.  (Eine spannende Grafik hierzu gibt es übrigens auch, erstellt hat sie Jan Broer aus München)

Aber was ist denn nun mit der tollen Software GLADII 1.1.3, mit der die Protokollierung stattgefunden hat? In meinem Beispiel wäre dies ein schlichtes Tool zur Auswertung von Logfiles. Aber es gibt ja ein Gutachten zu dieser Software, das dem LG Köln vorgelegt wurde. Zu diesem Gutachten sind nun hier und auch hier (und sicher auch anderswo) ein paar wenige Details bekannt geworden. Die Pressestelle des LG Köln schreibt zum Gutachten (Hervorhebung durch mich):

Laut Gutachten wurden die hinterlegten Testdateien sodann von dem Gutachter mit verschiedenen Browsern abgerufen und die Uhrzeit protokolliert. Im Anschluss hieran habe der Gutachter über die Software GLADII 1.1.3 eine Übersicht der überwachten Medien-Hoster aufgerufen. Die Software habe dabei eine Reihe von Informationen, unter anderem die IP-Adressen der Besucher der jeweiligen Seite, angeboten. Dabei seien auch die testweise erfolgten Abrufe der oben genannten Dateien angezeigt worden (inklusive zwischenzeitlichem Stoppen und Fortsetzen der Wiedergabe des Videos).

Zugegeben, da ist der Schwachpunkt meiner Beschreibung des für mich wahrscheinlichsten Ablaufes oben. Denn: Ich könnte bei einer solchen Weiterleitung protokollieren was ich wollte, ich könnte in den Logs niemals erkennen, wie viel von dem Video übertragen wurde, ob es überhaupt übertragen wurde, schon gar nicht ob es gestartet oder gestoppt wurde. Ich sähe lediglich: Da war IP-Adresse sowieso da und wurde weitergeleitet an… Ob das Video übertragen wurde bleibt bei dieser Methode offen. Es sei denn, ich leite den Besucher nicht einfach auf die Zielseite weiter sondern schleuse den kompletten Datenverkehr durch einen von mir kontrollierten Server. Ein Proxy zum Beispiel. Dann sehe ich: Diese Daten wurden bei redtube.com abgeholt und die habe ich dann an mein Opfer weitergeleitet. Beweise ich damit, dass der Abgemahnte tatsächlich das Video auch gesehen hat? Kein Stück. Alles was ich damit beweisen kann ist das Daten geflossen sind. Darüber hinaus handelt es sich in diesem Fall sogar noch um eine (meiner Meinung nach strafbare) Manipulation des Datenstroms meines Opfers. Und die Sache hat einen weiteren Haken: Ich kann selbst in diesem Fall nicht erkennen, ob das Video zwischenzeitlich gestoppt oder fortgesetzt wurde! (Das kann ich übrigens auch nicht, wenn ich mich direkt auf dem Server des Anbieters herumtreiben würde oder auf dem Router bzw. der Leitung meines Opfers mitschneide)

Warum eigentlich nicht?

Das ist recht einfach erklärt: schaue ich mir mittels der etablierten Streaming-Methoden (wie bspw. auf Youtube oder eben auch Redtube) einen Stream an, dann erfolgt keine Rückmeldung an den Server, wenn das Video angehalten bzw. pausiert wurde. Ihr könnt das zum Beispiel auch erkennen, wenn ihr das Video einfach mal anhaltet. Macht garantiert jeder mal, wenn das Laden des Videos zu lange dauert: Anhalten, mit etwas anderem beschäftigen und dann in ein paar Minuten nochmal nachsehen und zu Ende anschauen. Weil der Browser nämlich in der Zwischenzeit das Video im Hintergrund weiter lädt, er meldet nicht an den Server „Lass mal gut sein, der guckt grad nicht“. Das Anhalten und Fortsetzen ließe sich nur auf eine einzige Weise erkennen: Wenn ich mich direkt auf dem PC meines Opfers herum treibe. Dann (und NUR dann) habe ich die Möglichkeit, auch beweissicher das zwischenzeitliche Pausieren des Players zu erkennen.

Ein wenig anders verhält es sich, wenn ich den Player tatsächlich stoppe, also nicht nur auf die Pausentaste klicke, sondern auf Stop. Dann würde der Stream abgebrochen und beim erneuten Abspielen noch einmal neu geladen, vielleicht sogar (je nach Player und Server) auch ab der Stelle, an der ich angehalten habe. Aber: Der Player auf Redtube hat diese Möglichkeit nicht. Es gibt nur eine Pausentaste, mehr nicht. Und die macht nur eine Sache: Das Abspielen anhalten, auf keinen Fall jedoch den Stream. Der wird fröhlich im Hintergrund weiter geladen, bis er komplett geladen und gepuffert wurde.

Somit kann man festhalten: Die einzige technische Möglichkeit, um eine Überwachung eines Streams auf exakt diese Weise durchzuführen, wie sie im Zitat zum Gutachten beschrieben wurde, ist: Ich müsste Code auf den PC der Person einschleusen, die den Stream betrachtet und dann die Handlungen beobachten und protokollieren. Eine Möglichkeit, das von außerhalb zu erkennen, existiert aus den beschriebenen (und einigen weiteren) Gründen nicht. Wie „legal“ es allerdings wäre, auf diese Weise abmahnwürdiges Verhalten einer Person zu erfassen dürfte jedem klar sein. Zudem wäre in diesem Fall auch ohne weiteres möglich, das abmahnwürdige Verhalten ohne das Wissen dieser Person selbst herbei zu führen (und es gibt zumindest in einigen Berichten Anzeichen, dass dies geschehen sein könnte).

Für mich ist also die eingangs beschriebene Variante mittels Traffic-Kauf und Redirect tatsächlich die einzig wahrscheinliche Möglichkeit. Allerdings lässt sich damit nicht beweisen, dass die Person hinter der IP tatsächlich das Video gesehen hat. Genau so wenig lässt sich beweisen, dass die Person das Video überhaupt bewusst aufgerufen hat (oder die Seite überhaupt erkennen konnte). Zumindest lässt es sich technisch nicht beweisen, wie es rein rechtlich aussieht, das kann ich mit meinem laienhaften Rechtsverständnis nur vermuten.

Update 14.12.: Heise scheint meine Annahmen zur „Ermittlung“ der IP-Adressen zu teilen. Und schrieb gestern Abend dazu noch: „Viele Indizien sprechen nun für eine Vorgehensweise, die in den strafrechtlich relevanten Bereich reicht und zumindest den Verdacht auf Computerbetrug in gewerblichem Ausmaß nahelegt.„