OpenShot trackt Useraktivität via Google-Analytics

Das beliebte Videoschnittprogramm OpenShot trackt seine User im Rahmen der Produktverbesserung via Google-Analytics. Dazu bekommt jede Installation eine eigene CID, die zusammen mit Versionummer, Sprache, OS Version und dem jeweiligen aktuellen Programmfenster an Google-Analytics übermittelt wird. Und genau darin liegt das Problem. Keine Panik, das ist kein Public Shaming Artikel, vielmehr ein „wo liegt da eigentlich das Problem“ Artikel.

OpenShot trackt Useraktivität via Google-Analytics

Bei der Erstinstallation von OpenShot wird der Benutzer zwar gefragt, ob er zur Produktverbesserung beitragen möchte, aber in welcher Form dies passiert, darüber wird er nicht informiert. Was er auch nicht weiß ist, das bereits der erste Start an die Google Server übertragen wird, denn es ist ein OPT-OUT. Die Einwilligung ist vorausgefüllt und wird beim Start auch als gegeben angesehen, wie dies Startprotokoll zeigt:

sudo dnf install openshot

Installiert:
openshot-2.4.4-2.fc29.noarch blender-1:2.80-5.fc29.x86_64
bitstream-vera-sans-fonts-1.10-32.fc29.noarch openshot-lang-2.4.4-2.fc29.noarch
….
python3-libopenshot-0.2.3-1.fc29.x86_64

Fertig.
[surface ~]$ openshot-qt
Loaded modules from installed directory: /usr/lib/python3.7/site-packages/openshot_qt
launch:INFO ————————————————
launch:INFO OpenShot (version 2.4.4)
launch:INFO ————————————————
app:INFO openshot-qt version: 2.4.4
app:INFO libopenshot version: 0.2.3

QMainWindow::addDockWidget: invalid ‚area‘ argument
metrics:INFO Track metric: [200] http://www.google-analytics.com/collect?cid=fc262946-270b-4bde-aa09-723466a9db8b&v=1&tid=UA-4381101-5&an=OpenShot+Video+Editor&aip=1&aid=org.openshot.openshot-qt&av=2.4.4&ul=en-us&ua=Mozilla%2F5.0+%28X11%3B+Linux+x86_64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F37.0.2062.120+Safari%2F537.36&cd1=0.2.3&cd2=3.7.4&cd3=5.11.3&cd4=5.11.3&cd5=Fedora-29-Twenty+Nine&t=screenview&cd=main-screen | (35 bytes)
metrics:INFO Track metric: [200] http://www.google-analytics.com/collect?cid=&v=1&tid=UA-4381101-5&an=OpenShot+Video+Editor&aip=1&aid=org.openshot.openshot-qt&av=2.4.4&ul=en-us&ua=Mozilla%2F5.0+%28X11%3B+Linux+x86_64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F37.0.2062.120+Safari%2F537.36&cd1=0.2.3&cd2=3.7.4&cd3=5.11.3&cd4=5.11.3&cd5=Fedora-29-Twenty+Nine&t=screenview&sc=start&cd=launch-app | (35 bytes)
metrics:INFO Track metric: [200] http://www.google-analytics.com/collect?cid=fc262946-270b-4bde-aa09-723466a9db8b&v=1&tid=UA-4381101-5&an=OpenShot+Video+Editor&aip=1&aid=org.openshot.openshot-qt&av=2.4.4&ul=en-us&ua=Mozilla%2F5.0+%28X11%3B+Linux+x86_64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F37.0.2062.120+Safari%2F537.36&cd1=0.2.3&cd2=3.7.4&cd3=5.11.3&cd4=5.11.3&cd5=Fedora-29-Twenty+Nine&t=screenview&cd=initial-launch-screen | (35 bytes)
ui_util:INFO Initializing UI for MainWindow

Zwar werden direkt keine personenbezogenen Daten durch OpenShot übermittelt, aber immerhin weiß Google jetzt, daß die IP a.b.c.d heute Fedora 29 benutzt, wieoft mit OpenShot rumspielt und das in English. Ich habe über diese Daten keine Kontrolle. Anhang der eindeutigen CID läßt sich auch prima verfolgen, wie oft jemand Openshot startet und benutzt. Natürlich ist es das Ziel der Produktverbesserung, daß man etwas über das Userverhalten erfährt, aber wieso muß Google das auch wissen?

Hätte man da nicht einen eigenen Server benutzen können? So schwer ist das nicht und da OpenShot eine eigene Webseite hat (https://www.openshot.org/de/privacy/), wäre das kein großer Aufwand.

Nehmen wir mal an, die DSGVO würde gelten

Fast selbstredend muß ich an dieser Stelle auf die Datenschutzprobleme hinweisen. Wie Ihr ja wisst, werden IP Adressen seit dem Urteil des Kammergerichts in Berlin aus 2013 als personenbezogene Daten gewertet. An der Einschätzung habe ich meine Zweifel, aber das Gericht sah es nun mal so an. Jetzt ist der Hersteller von Openshot in den USA ansässig und unterliegt somit normalerweise nicht der EU DS GVO.

Das hindert aber natürlich niemanden daran, das mal vom Datenschutz überprüfen zu lassen, schliesslich werden auch US Firmen mit Strafen versehen, die keinen Sitz in der EU haben, sich aber an EU Bürger wenden. Durch die Monopolstellung von OpenShot im Linuxbereich, oder kennt Ihr eine andere brauchbare Software für den Videoschnitt, könnte man eine Sonderbehandlung des Herstellers rechtfertigen. Ich werde das mal unserem Bundesdatenschützer vortragen, mal sehen was er dazu sagt.

Die DS GVO sagt dazu jedenfalls folgendes:

Art. 3 DSGVO Räumlicher Anwendungsbereich

(2) Diese Verordnung findet Anwendung auf die Verarbeitung personenbezogener Daten von betroffenen Personen, die sich in der Union befinden, durch einen nicht in der Union niedergelassenen Verantwortlichen oder Auftragsverarbeiter, wenn die Datenverarbeitung im Zusammenhang damit steht

a) betroffenen Personen in der Union Waren oder Dienstleistungen anzubieten, unabhängig davon, ob von diesen betroffenen Personen eine Zahlung zu leisten ist;

Der Fall ist erfüllt, weil das Programm sich auch an deutsche Benutzer richtet. Ich tendiere also dazu, die DS GVO als zuständig zu befinden. Das es Opensource und frei verfügbar ist, ändert nichts daran.

Openshot ist nicht Facebook

Damit wir uns nicht falsch verstehen, der OpenShot Hersteller ist keiner von den „Bösen Akteuren“ wie Facebook. Das ist mehr so eine „unglücklich umgesetzt“ Geschichte. Entsprechend habe ich das Problem auch beim Hersteller angesprochen. Was dabei raus kommt, werdet Ihr bei Zeiten erfahren.

Zurück zur IP. Wir nehmen ja mal an, daß die DS GVO gilt. In diesem Fall wäre die Übermittlung der IP durch den Webrequest bei Google, eine Übermittlung von Personenbezogenen Daten an Dritte. Dieser Übermittlung muß der Kunde zustimmen bzw. bei Geringfügigkeit, was hier der Fall ist, in der Datenschutzerklärung mitgeteilt bekommen. Wer auf seiner Webseite Google Analytics einsetzt, muß das ja auch in der DSE angeben. Jetzt liegt dem Produkt OpenShot aber gar keine Datenschutzerklärung bei. Nicht mal ein Link, den am anklicken könnte, existiert. Damit habe ich als Anwender keine Chance zu erfahren, daß meine Daten an Google übermittelt werden, welche das genau sind und wie oft das passiert. Transparenz geht anders.

Was OPT-OUT in der Realität bedeutet

Wie ich anfangs gezeigt habe, werden schon beim Programmstart Daten an Google übermittelt, noch bevor ich das per Entfernen des Zustimmungshakens verhindern kann. Das dürfte keine böse Absicht sein, weil der Code den ersten Start es Programms einfach genauso behandelt, wie jeden anderen auch. Da werden also die gleichen Methoden durchlaufen wie sonst auch. Das kann aber nur passieren, weil der Entzug der Zustimmung die Ausnahme ist. OPT-OUT halt. Bei einem OPT-IN würde man also ggf. nie einen Datenabfluß haben.

Die DS GVO verlangt eine qualifizierte Zustimmung zu so einer Übermittlung, was einem OPT-IN-Zwang gleichkommt. Würde die GVO also für OpenShot gelten, wäre das wie es jetzt ist ein Verstoß gegen Artikel 6 Absatz 1 a , weil auf 1f kann sich der Anbieter nicht berufen, da es datenschutzfreundlichere Wege gibt und nachlesen kann ich es in einer Datenschutzerklärung auch nicht.

Artikel 7 Absatz 1 legt einem Datenschutzverantwortlichen explizit auf, daß er jederzeit nachweisen können muß, daß der Benutzer eingewilligt hat. Schon der Punkt wird zum Problem, weil der nötige Flag lokal auf der Benutzerfestplatte liegt und zu allem übel auch noch vorausgefüllt war. Wenn jemand sein Homeverzeichnis mal neu macht, ist die Bestätigung der Einwilligung futsch, weil wird nicht auf dem Firmenserver (ja Openshot wird von einer Firma entwickelt) gespeichert. Da wird ein Beweis im Worst-Case schlicht unmöglich.

Zusammenfassung

Meine Kritikpunkte sind daher:

  1. OPT-OUT, statt OPT-IN
  2. Daten werden an Google übermittelt
  3. Daten werden vor der Zustimmung übermittelt
  4. Keine Information über die Art und den Umfang der Datenübermittlung
  5. nur durch einen Zufall überhaupt darüber gestolpert.

Das Produkt hat also so kleinere Datenschutzmängel. Einige davon kann man leicht beheben, ohne das die Firma Einbußen hinnehmen muß. Der Hersteller hat da auch einige Tips von mir bekommen, wie er das anstellen könnte. Warten wir mal ab. Wie gesagt, es sind nicht die bösen Datenabgreifer, es ist einfach unüberlegt umgesetzt worden. Wenn aber jemand eine Datenschutzbeschwerde einreichen würde, und so diese von der Behörde angenommen würde, hat der Hersteller von OpenShot IMHO, schon wegen des fehlenden Einwilligungsbeweises, ein größeres Problem am Hacken.

Wie schaltet man das jetzt wieder ab?

Kommen wir mal zur Lösung des Problems auf Eurer Seite. Das ist zum Glück einfach und zuverlässig machbar. Im „Bearbeiten“ Menü in die „Voreinstellungen“ wechseln, dort die „Fehlerbehebung“ aufrufen und diesen Haken hinter „Mess- und Fehlerdaten anonym senden“ entfernen:

Damit übermittelt Openshot dann ab sofort keine Daten mehr an Google. Habe ich natürlich geprüft 😉

Aber denke bitte daran, daß Ihr die nächste Installation von OpenShot ohne Internetzugang ( Stecker ziehen, Netzwerk abschalten ) startet und dann gleich den Haken entfernt.

Dutzende von Spionagecellen in Washington gefunden

Das NBC Channel 4 Nachrichten Team hat da mal eine kleine Exkursion in Washington gemacht und dabei über 40 Sting-Rays gefunden. Das sind Geräte die Mobilfunkmasten simulieren. Das macht eine Regierung normalerweise und das Handy von Verdächtigen abzuhören, aber in Washington macht das wohl jeder. Scheint ne Art Volkssport zu sein, besonders um Botschaften herum 😀 Da trackt jeder jeden 😉

„Das News4 I-Team bat Turner, mit einer speziellen Software, die auf drei Handys mit drei verschiedenen Carriern geladen war, durch die Hauptstadtregion zu fahren, um die Geräte (Sting-Rays) an verschiedenen Orten zu erkennen.

„Wenn man also diese roten Balken sieht, sind das sehr verdächtige Ereignisse“, sagte Turner.

Wenn Sie in oder in der Nähe des Distrikts wohnen, wurde Ihr Telefon wahrscheinlich irgendwann verfolgt, sagte er.

Ein kürzlich veröffentlichter Bericht des Ministeriums für Heimatschutz nannte die Spionagegeräte ein echtes und wachsendes Risiko.“ (Übersetzt mit www.DeepL.com/Translator)

Das Nachrichten Team war sich sicher, daß es noch viel mehr finden würde, wenn Sie noch einige Stunden rumkurven würden. Ich glaube, daß mache hier in Berlin auch mal irgendwann 😀

Quelle: https://www.nbcwashington.com/investigations/Potential-Spy-Devices-Which-Track-Cellphones-Intercept-Calls-Found-All-Over-DC-Md-Va-482970231.html

Linux – DNS-DeTracking mit nscd

Das Problem

Wenn man alle seine DNS Anfragen über einen einzigen Anbieter abwickelt, kann der leicht herausbekommen, wofür man sich interessiert, da er ja jede Domain kennt, mit der man „reden“ will.

Wenn man von einem DNS Anbieter, sei es die Deutsche Telekom oder Google, nicht vollumfänglich getrackt werden will, kann man nur seinen eigenen DNS-Cache betreiben, oder laufend den DNS Anbieter wechseln ? Oder gibt es da vielleicht noch eine dritte Möglichkeit ?

Methode 1:

Jeder kann sich einen DNS Cache auf dem eigenen PC installieren. Der Nachteil ist, es ist nicht besonders effizient und bei einigen DSL-Anbietern kann man auch nicht selbst die DNS Auflösung machen. In letzterem Fall solltet Ihr Euch auf jeden Fall einen Tunnel in die freie Welt aufbauen, z.b. per VPN. Einen eigenen Server der dafür ausreicht kann man sich schon für 6,50 € im Monat mieten. Ihr braucht  dann noch sowas : UDP Traffic per SSH tunneln, Die Vorratsdatenspeicherung umgehen oder VDS: Schnell ein VPN aufsetzen . Es geht zwar nicht um die Vermeidung der VDS, aber das Prinzip ist das gleiche. Aber wenn Ihr sowieso schon einen eigenen Server habt, laßt den das DNS Cache übernehmen.

Wieso ist das nicht effektiv ?

Ein DNS Cache macht nur dann Sinn, wenn viele Klienten in einem Netzwerk das Cache benutzen, denn der eigentliche Sinn ist, daß nicht jeder Rechner die Root-DNS kontaktiert, sondern das man möglichst viele Anfragen lokal selbst beantworten kann, weil man bereits einmal danach gefragt hat. Das geht zum einen schneller, zum anderen spart es Traffic ein. Das man seinen Fußabdruck dabei kleiner hält, fällt praktischerweise nebenbei ab. Je mehr einen DNS Cache benutzen, desto mehr gehen auch die eigenen Anfragen in der Masse unter.

Methode 2:

Ein Script, daß laufend die /etc/resolv.conf  neu und die DNS Servernamen in der Reihenfolge zufällig hinein schreibt, ist mit ein bisschen Bash-Foo machbar. Dauer ca. 15 Minuten.

Methode 3:

Schauen wir uns mal die /etc/resolv.conf an, finden wir dort:

; generated by /usr/sbin/dhclient-script
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Wenn man nichts weiter auf seinem Rechner installiert hat, wird in genau dieser Reihenfolge ein DNS nach dem Anderen abgefragt, wenn der vorherige DNS nicht rechtzeitig antwortet.

Das Verhalten kann man aber ändern:

options rotate
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Jetzt würde ein entsprechend gut programmierter Resolver, das ist der Programmteil, der die DNS Auflösung macht, zufällig aussuchen, welchen der DNS er benutzt. Trägt man hier also viele öffentliche DNS Server in dieser Liste ein, verteilt man alle DNS Anfragen auf diese Server, was jedem einzelnen logischerweise die Möglichkeit nimmt, ein umfangreiches Profil zu erstellen.

Dummerweise juckt diese Anweisung kaum einen Resolver. Das geht sogar soweit, daß der erste in der Liste mal einfach überlesen wird 🙂 Also muß eine Lösung her, die diese Anweisung respektiert: NSCD

dnf install nscd
systemctl start nscd
systemctl enable nscd

Ab jetzt werden DNS Abfragen über den NameserverCacheDämonen abgewickelt, und der fragt zufällig die DNS in der Liste an. Da es sich auch um einen Cache handelt, fragt er im Laufe der Zeit ( TTL eines Eintrags ) nur einmal die Rootserver an ( Kleiner Fußabdruck ) .

Damit wäre das Trackingproblem erledigt, wenn Ihr viele DNS Server zur Verfügung habt.

Einen eigenen DNS Cache auf dem PC zu betreiben, ist nicht weiter wild, man müßte nur den named installieren und starten. Da aber bei DNS Abfragen einiges unterwegs schief gehen kann, ist eine starke DNS Infrastruktur wie bei Google durchaus ein starker Partner.

Welche Methode für Euch die richtige ist, müßt Ihr wissen.

Tracking über Browser API des Batteriestatuses

Wie die Webseite TheHackernews.com heute berichtet, ist es Forschern der Standford University bereits in 2015 gelungen, einen Super-Super-Cookie zu nutzen, in dem sie über die Browser API der mobilen Versionen von Chrome, Opera und Firefox den Batteriestatus abgefragt haben. Durch die Kombination von angezeigter „verbleibender Zeit in Sekunden“ und dem Prozentwert der Ladung, ergeben sich bis zu 14 Millionen Kombinationen, die man Geräten zu ordnen kann.

Steve Engelhard and Arvind Narayanan von der Princeton University, konnten nun in einem Forschungsbericht  zeigen, daß diese Technik bereits von Webseiten zum aktiven Tracken von Benutzern eingesetzt wird.

Zusammen mit anderen Techniken wird es damit immer schwerer dem Online-Tracking zu entgehen. Aber natürlich kann man etwas dagegen tun, denn auch für FireFox Mobile gibt es Noscript!  Ohne Javascript kann man Browser-Api’s nicht abfragen, was dazu führt, daß man nur ohne Javascript surfen muß.

Sollte man jetzt glauben, den Webseitenbetreibern ginge nur ums das reine Tracking dabei, weit gefehlt, daß ist nur zur Verbesserung der Identifikationsrate da, denn Tracking geht über sehr viele Browsermerkmale bereits gut ( mit Javascript).

Den Batteriestatus zu kennen, verleitet Verkäufer jetzt aber dazu, abhängig vom Stand die Preise zu ändern. Der Gedanke: „Der User ist unter Stress, weil seine Batterie bald schlapp macht und daher kauft er jetzt sofort das Erstbeste zum erstbesten Preis. Suchen bei der Konkurrenz kommen wegen des Batteriestandes nicht mehr in Frage. “

Damit könnte der Verkäufer sogar recht haben. Also, was heißt das ? Bei FireFox Javascript abschalten und gleichzeitig eine neue Kampagne starten, diese API zu begraben! Das man Chrome dazu bewegen kann, ist eher unwahrscheinlich. Google lebt ja vom Tracking anderer Leute 😉

Referenzen:

INRIA Privatics Forschungsbericht
Lukas Olejnik Blog
Random Walker – OpenWPM

Quelle: thehackernews.com

Nicht witzig: Tracking per Audio-Fingerprinting

Forscher der Princeton University haben einer neuen Trackingtechnik auf die Finger geschaut und festgestellt, daß 80% der TOP Webseiten im Netz Ihre User über ein neues Trackingverfahren namens Audio-Fingerprinting verfolgen. Mehr oder minder sind es natürlich die Werbenetzwerke die den User damit tracken.

Benutzt wird dazu die Audio-Context API moderner Browser. Wie man vermuten würde, müßte hier Ton im Spiel sein, aber dazu müßte der Browser die Einwilligung des Benutzers einholen und das würde auffallen, also trackt man den User anhand der Geräte spezifischen Daten wie Signale verarbeitet werden.

Meint, er sind ein Signal per API erzeugt, an die Audiohardware geschickt und dann geschaut was zurück kommt. Das wird auch beim Canvas-Fingerprinting benutzt.

Alle diese Methoden setzen aber Javascript voraus und sind damit mit NoScript leicht zu deaktivieren. NoScript bleibt damit das nützlichste Privacytool überhaupt.

Auf der Webseite der Hackernews findet sich auch eine Übersicht, wer trackt und wie. Treibende Kraft dahinter scheint Google zu sein.

Wer das mal live sehen will, klickt hier. Immer dran denken, ohne Javascript funktioniert es nicht.