Tracking in Apps: Ist das legal? – Eine Übersicht über die mobile Trackinglandschaft

FireShonks-Vorspannmusik

Engel: Ich freue mich auf den Vortrag “Tracking in Apps - eine Übersicht über die mobile Tracking-Landschaft” mit Benni, Lorenz und Malte. Die drei sind aktiv beim Verein Datenanfragen.de e. V. und sie werden uns erklären, inwiefern mobile Apps immer noch ein Blackhole in Sachen Tracking darstellen, was eigentlich die gesetzlichen Rahmenbedingungen sind, was die gelebte Realität ist und welche Ideen sie dazu haben. Die Bühne gehört euch.

Malte: Ja, herzlich willkommen zu unserem Vortrag “Tracking in Apps - ist das legal?”. Wir wollen euch heute gerne eine Übersicht geben über die mobile Tracking-Landschaft. Und wir, das sind Benni, Lorenz und ich, Malte.
Benni hat mal Informatik studiert und ist jetzt jemand, der Datenschutz mag und IT-Sicherheit sowie all things FOSS. Aber er hasst Computer. Lorenz studiert gerade Physik und findet, dass ein konsequenter Datenschutz auch eine Systemtransformation fordern muss. Ich bin Doktorand am Institut für Anwendungssicherheit an der TU Braunschweig und mag automatische Analysen und all things privacy.
Ihr könnt uns gerne alle erreichen per E-Mail, mit PGP auch bei Bedarf sowie auf Mastodon und Matrix. Die Sachen sind hier entsprechend verlinkt. Und wir sind alle drei vom Datenanfragen.de e. V. Das ist ein gemeinnütziger Verein und der hat es sich zur Aufgabe gemacht, euch bei der Ausübung eures Rechtes auf Datenschutz zu helfen.

Und heute geht es viel um Tracking. Aber Tracking, was ist Tracking überhaupt? Unter Tracking verstehen wir, wenn eine Anwendung ein Nutzungsverhalten sammelt von euch und das an die Anbieterin der Anwendung oder an Dritte schickt.

Warum passiert das? Zum Beispiel für Werbung oder Telemetrie oder Marktanalyse sowie der Verkauf eurer Daten. Und das ist meistens ein Aufzeichnen eures Verhaltens für finanzielle Ziele. Und das bringt uns Nutzer_innen erstmal ziemlich wenig. Aber andere, potentiell Dritte oder die Anbieter des Dienstes erfahren ziemlich viel über uns.

Ihr habt vielleicht schon mal im Firefox gesehen, da gibt es diese about:protections-Seite. Wenn ihr das eingeschaltet habt, dann seht ihr da, wie viele Tracker von Firefox blockiert wurden. Zum Beispiel hier auf dem Screenshot wurden 270 Tracker geblockt in der letzten Woche. Das heißt, das ist schon mal eine ganze Menge und das ist sogar in echt noch viel mehr, denn in diesem Browser hatten wir schon Extensions installiert, die Tracker blockieren. Das heißt, Tracker sind im Internet zumindest überall.

Und das ist potentiell noch kritischer auf dem Handy, denn Apps auf dem Handy haben ja potentiell viel mehr Zugriff auf unsere Daten, wie die ganzen Sensoren in so einem Handy oder unsere Kommunikation und unsere Kontakte. So als Beispiel sei da genannt die DB Schnüffel-Navigator-Sache, die von Kuketz und Digitalcourage recherchiert wurde. Da wurde ja festgestellt, dass der DB Navigator, also diese App, mit der man irgendwie Tickets kaufen kann, viele Daten zu Adobe schickt. Und das ist ja erstmal keine schöne Sache. Da konntet ihr, glaube ich, auch gestern mehr darüber hören.

Genau, bevor wir jetzt ins Detail stürzen und schauen, was Apps so übermitteln, wollen wir uns mal anschauen, was die Entwickler sagen, was ihre Apps übermitteln. Wir haben hier unter iOS und Android, also dem Apple App Store und dem Google Play Store, die Vorgabe, dass Entwickler_innen selbst deklarieren müssen, welche Daten sie sammeln. Das sieht dann im Apple App Store zum Beispiel so aus. Da haben wir hier dann zum Beispiel einen Screenshot von der Seite für die Facebook-App. Da haben wir hier dann zwei große Kategorien der Daten, die zum Tracking deiner Person verwendet werden und mit dir verknüpfte Daten. Das sind Sachen, die Entwickler selbst über ihre Apps angeben. Zum Beispiel haben wir hier auf der linken Seite beim Tracking Kontaktinformationen und bei den mit dir verknüpften Daten ziemlich viel.

Wir haben uns das alles mal systematisch angeschaut mit meinem Kollegen Simon Koch. Da ist ein akademisches Papier draus geworden. Das könnt ihr auf der PETS nachlesen. Das ist Open Access. Ich stelle euch mal kurz so zwei Kleinigkeiten daraus vor, die ganz interessant sind.

Denn wir haben auch die Kategorie der nicht mit dir verknüpften Daten, aber da findet man ab und an dann doch so Sachen, die eindeutig mit einem verknüpft sind. Zum Beispiel eine Benutzer-ID oder eine E-Mail-Adresse. Wie kann das sein, dass die Benutzer-ID oder meine E-Mail-Adresse nicht mit mir verknüpft sein soll? Also anscheinend sind da öfter mal Widersprüche in diesen Labels.

Und wir haben festgestellt, dass 16 % der Apps, die wir betrachtet haben, Daten übermittelt haben, die sie gar nicht in ihren Labels angegeben haben. Das heißt, wir können auf diese Labels nicht so super vertrauen. Da gibt es anscheinend wenig oder keine Consistency Checks und die Entwickler können auch frei angeben, was sie wollen. So wirkt es zumindest.

Google ist dann dieses Jahr nachgezogen und hat auch diese Labels eingeführt. Die heißen da ein bisschen anders und machen noch ein bisschen was anderes. Sie machen vor allem ein bisschen mehr. Bei Google wird noch angegeben, ob man Daten löschen kann und ob die Daten auf dem Transport verschlüsselt werden. Aber sonst ist es sehr ähnlich. Hier haben wir wieder einen Screenshot von Google Play Store. Diesmal ist es die Amazon-App und da sehen wir diese vier Punkte. Also die Apps kann die folgenden Datentypen an Dritte weitergeben und die App kann die folgenden Datentypen erheben sowie Transportverschlüsselung und Löschung der Daten.

Und wir haben das mal systematisch gesammelt und hier sortiert nach Zweck. Denn die Entwickler_innen geben auch einen Zweck an, wofür diese Daten benutzt werden. Und der Zweck Numero 1 ist die Analyse und die Funktion der App ist auf Punkt Nummer 2. Sowohl in Blau bei den erhobenen Daten als auch in Orange bei den weitergegebenen Daten. Das heißt, die Entwickler_innen geben an, dass ihre Top-Zweck zur Nutzung der Daten die Analyse ist und nicht die Funktionsweise der App. Das fanden wir ziemlich erschreckend.

Und da gibt es auch so ein paar beunruhigende Geständnisse. Zum Beispiel gibt Facebook an, dass sie eure politische oder religiöse Überzeugung sammeln, eure sexuelle Orientierung und die Gesundheitsdaten zu Analysezwecken. Oder Amazon erheben und teilen eure Gesundheitsdaten für Analysezwecke, laut eigener Aussage durch diese Labels. Oder diese Kinderspiel-App Roblox, die erhebt eure sexuelle Orientierung für Analysezwecke und teilt sie für Analyse- und Werbe- oder Marketingzwecke. Das könnt ihr nochmal in Ruhe nachlesen auf unserem Blog, da gibt es auch einige Beispiele dieser Art. Genau.

Tatsächlich haben wir uns auch mal angeschaut: stimmt das denn, was in den Labels steht? Auch beim Google Play Store und haben die mal ausgeführt und beobachtet. Wir können jetzt aber nur eine Aussage treffen über die Sachen, die wir beobachten konnten. Das heißt, wir haben hier in dieser schönen Grafik relativ viel grau. Grau sind Daten, die deklariert wurden, aber für uns nicht beobachtet wurden. Das liegt daran, dass wir mit den Apps nicht viel gemacht haben, wir haben nur gestartet und geschaut, was passiert ist. In dunkelblau haben wir dann die Sachen, die korrekt nicht deklariert wurden und auch nicht beobachtet wurden. Und in orange haben wir den spannenden Teil der Daten, die nicht deklariert wurden, die wir aber beobachten konnten. Und insbesondere hier bei der ersten Kategorie “Standort” ist das ziemlich gruselig und zeigt uns mal wieder, dass wir nicht wirklich auf diese Labels vertrauen können.

Deswegen wollen wir uns jetzt mal genauer anschauen, was tatsächlich so von den Apps übertragen wird. Deswegen habe ich euch ein paar Beispiele mitgebracht. Die sind ein bisschen älter, aus dem März ‘21 für Android und aus dem August ‘21 für iOS.

Zum Beispiel haben wir hier Audible, diese Hörspiel-App, unter Android und die POSTet irgendwie an so einen Tracker, also hier an control.kochava.com. Und die POSTen unter anderem die Einstellung meines Bildschirms. Also wie hell ist der? 0,4. Okay. Wie rum steht der? Im Portrait. Okay. Wie laut ist gerade meine Lautstärke eingestellt? Ein Drittel. Und wie heißt eigentlich mein Mobilfunkanbieter? Okay, das sind jetzt Informationen. Warum werden die jetzt irgendwie weggeschickt? Oder wie groß mein Bildschirm ist? Wer mein Handy hergestellt hat? Und die Architektur des Handys? So wie der Batteriestatus? Es lädt nicht. Not charging. Und es hat gerade 77%. Und das wird dann verknüpft mit IDs. Zum Beispiel hier eine ID von Kochava selber sowie eine nt_id und eine adid. Und diese adid hier ist die Google-Ad-ID. Die wird von Google eurem Gerät zugewiesen und erlaubt es den Trackern, auch untereinander eure IDs miteinander zu verknüpfen. Hier wird dann zum Beispiel die ID von Adobe, der Adobe Marketing Cloud, die marketingcloudvisitorid, wie es hier heißt, noch dazu verlinkt. Das heißt, die Tracker können die IDs von verschiedenen Unternehmen untereinander verknüpfen. Das finden wir ziemlich beunruhigend.

Oder ein anderes Beispiel, PayPal unter iOS. Die POSTen irgendwie an paypal.com. Und zwar wieder so ein paar IDs, die wir schon mal gesehen haben, hier auf der linken Seite. Und Geräteinformationen über unser Handy, wieder ziemlich viel. Aber auch neu, jetzt diesmal, IP-Adressen und den Namen des WLANs, sowie die BSSID sowie unseren Proxy und unsere Location. Das finden wir auch echt erschreckend.

Oder hier Bitmoji unter Android. Hier gibt es irgendwie so ein Array an Events. Und zum Beispiel wird hier mit einem Timestamp geschickt, wann die Application geöffnet wurde oder dass irgendwie ein Experiment gefahren wird oder dass wir die Welcome-Sache gesehen haben. Und jedes Mal wird geschickt, “Hey, hast du Snapchat installiert?” – “Nee.” Spannend.

Oder Indeed. Noch mal so als kleinen Disclaimer. Die Sachen, die wir jetzt zeigen, die sind alle schon gekürzt von uns. Die sind eigentlich größer. Insbesondere hier. Auf der linken Seite haben wir wieder so Daten, die wir vorher schon mal gesehen haben. Und jetzt neu rechts werden einfach von vielen Sensoren die Daten mitgeschickt. Zum Beispiel hier unser Beschleunigungssensor oder Magnetfeldsensor oder das Gyroskop. Da wird der Name der Sensors mitgeschickt und die genauen Daten auf allen drei Achsen.

Oder zu guter Letzt unter iOS, so eine Social-Media-App namens Poparazzi. Und die schickt einfach direkt alle Kontakte aus eurem Adressbuch weg. Ohne, dass irgendeine Interaktion mit der App stattfindet. Werden einfach direkt alle weggeschickt. Hier sehen wir zum Beispiel jetzt so eine Telefonnummer und einen vollen Namen.

Und jetzt haben wir ein paar so Beispiele gesehen, aber jetzt möchten wir uns mal gerne anschauen, wie wir das automatisieren können, damit wir an schöne Ergebnisse kommen und schöne Aussagen treffen können darüber, wie sich Apps so verhalten.

Unter Android ist das ein bisschen einfacher als unter iOS, deswegen fangen wir damit an. Wir haben, wie ihr vielleicht schon in den vorherigen Screenshots gesehen habt, einen Emulator benutzt, mit Root-Rechten. Das ist der Emulator, den uns Google zur Verfügung stellt zu Entwicklungszwecken. Und den kann man mit ADB instrumentieren. ADB ist die Android Debug Bridge. Mit der kann man ziemlich viel anstellen unter Android, zum Beispiel Apps installieren und Apps deinstallieren sowie den Emulator zurücksetzen über so Snapshots. Wenn wir Apps installieren, dann kriegen die alle Berechtigungen. Das machen wir hier technisch mit dem -g.

Damit wir den Traffic ja mitlesen können, setzen wir uns auf die Leitung. Also wir machen so einen Machine-in-the-Middle-Angriff mit einem Programm, was echt cool ist, mitmproxy. Und, damit wir auch dann HTTPS-Traffic lesen können, installieren wir gegebenenfalls ein Zertifikat oder nutzen direkt objection und Frida. Die sorgen einerseits dafür, dass alle Zertifikate akzeptiert werden und andererseits umgeht objection für uns Certificate Pinning. Denn Apps und Webseiten können ja gegebenenfalls sagen, wir nehmen nur dieses eine Zertifikat für verschlüsselten Traffic an. Und das können wir mit objection umgehen.

objection arbeitet auf Frida als Basis und Frida ist euch vielleicht noch nicht bekannt, das ist ein ziemlich cooles Ding. Das ist so ein Toolkit und das injiziert man in einen Prozess und dann ist so eine JavaScript-Runtime drin, mit der man im System rumspielen kann. Das klingt ein bisschen komisch, ist aber echt cool und super mächtig, denn man kann damit dynamisch interne Methoden aufrufen, zum Beispiel hier im Screenshot. Und das hat auch so ein relativ angenehmes Interface, mit dem man per Autocomplete sich ziemlich gut rumspielen kann. Wir sehen hier zum Beispiel, dass wir uns eben so einen App-Kontext holen und da können wir da so Systemaufrufe mit machen.

Und objection implementiert dann intern Sachen, die Certificate Pinning ausschalten. Das geht über Frida per Hooking. Wir können also Funktionen aus dem System hooken und überladen mit eigenen Funktionen. Wir haben mal so ein Beispiel mitgebracht. Hier wird eine Referenz auf so einen Certificate-Checker genommen, in dem Fall hier aus Cordova, also PhoneGap. Und das implementiert da so einen Certificate-Pinning-Prozess. Und jetzt nehmen wir uns einfach diesen Checker und überschreiben ihn mit der eigenen Implementierung. Und die returned einfach immer true. Das heißt, wenn eine App irgendwie mit diesem Call prüfen möchte, ob ein Zertifikat stimmt, kommt nicht der eigentliche Check dran, sondern unser überschriebener, der einfach immer true zurückgibt, also immer wahr und dadurch wird dann der Check umgangen. Das heißt aber auch, dass wir das für jeden möglichen Check machen müssen und wenn jetzt eine App einen eigenen Check implementiert oder wir einen verpasst haben, dann verpassen wir den Traffic. Das heißt aber andererseits auch, dass alles, was wir sehen können, auch wirklich passiert ist, was ziemlich cool ist.

So, jetzt können wir so HTTPS-Traffic aufzeichnen. Jetzt ist das Problem, wir zeichnen alles auf. Und so ein Android-System, das hat ziemlich viel Hintergrundrauschen. Und wir möchten aber nicht den Traffic haben vom Hintergrund oder vom System selber, sondern von den Apps selber, um eine Aussage über die Apps treffen zu können. Und was machen wir dagegen?

Beziehungsweise erst mal, ich möchte euch zeigen, wie so ein Hintergrundrauschen aussehen könnte. Zum Beispiel gibt es ja dieses Uhr-Widget, was euch irgendwie die Uhrzeit anzeigt auf eurem Bildschirm mit den ganzen Apps. Und auch das POSTet gerne mal zu Google Analytics oder der sogenannte Connectivity Check, der von eurem Handy regelmäßig gemacht wird, um euch gegebenenfalls oben rechts anzeigen zu können, hey, das WLAN hat gerade gar kein Internet. Oder System-Apps tracken euch gegebenenfalls auch schon. Oder wenn ihr Sachen installiert im Play Store, dann gibt es auch Logs. Das wollen wir aber alles gar nicht sehen.

Und was wir dagegen tun, ist den Emulator tagelang laufen lassen, ohne etwas damit zu machen und dabei zeichnen wir wieder alles auf. Und am Ende erstellen wir per Hand einen Filter, der alles rausschmeißt, was in diesen paar Tagen passiert ist. Das heißt, wir wollen das ganze Hintergrundrauschen rausfiltern. Und das ist ein bisschen finicky, denn viele der Endpunkte und APIs, die hier benutzt werden, werden auch von echten Apps benutzt. Deswegen haben wir da im Zweifelsfall lieber ein bisschen zu viel rausgeschmissen als zu wenig, damit wir später alles, was wir sehen können, wirklich den Apps zuschreiben können. Genau. Das heißt, wir erstellen so einen riesigen Filter und dann bleibt von unserem tagelangen Aufzeichnen des Rauschens nichts mehr übrig. Und diesen Filter können wir dann später anwenden auf andere Aufzeichnungen und dann haben wir nur noch den Traffic, den wir eindeutig der App zuordnen können.

Jetzt reden wir viel darüber, wie wir Apps analysieren können, aber wo kriegen wir Apps denn her? Erstmal müssen wir wissen, welche Apps wir anschauen möchten. Und da haben wir uns gedacht, wir nehmen uns einfach die populärsten Apps aus dem App Store, denn das sind vermutlich die Apps, die auch auf eurem Handy sein könnten. Und um das zu machen, nehmen wir einfach die Top-Listen aus den jeweiligen Stores. Und bei Google gibt es zum Beispiel online so 15 Apps, die man sehen kann pro Kategorie. Wir haben dann eine Library geschrieben, die die internen APIs reverse-engineered. Und dadurch können wir uns dann 660 Apps pro Kategorie anzeigen lassen. Das machen wir für mehrere Kategorien und dann haben wir relativ viele Apps, also die Namen der Apps. Die Library ist Open Source, die könnt ihr auf GitHub finden.

Und wenn wir so eine Liste an Namen haben, an Apps, dann müssen wir die noch runterladen. Und da gibt es ziemlich viele Tools für. Und je nach Tag, je nach Laune, klappt eins und das andere nicht. Da muss man so ein bisschen rumprobieren. Und am Ende hat man so eine APK in der Hand, das ist dann die App. Und wir haben dann zum Beispiel die folgenden Tools benutzt, also gplaycli und der PlaystoreDownloader und apkeep. Aktuell nutze ich gerne googleplay von dem Account, der hieß mal 89z. Der heißt es jetzt anders, rngh7r. Wird bald wieder anders heißen. Das ist eine lustige Geschichte. Das ist so ein Mensch, der hat seinen Account öfter gebannt gekriegt und macht ihn immer wieder neu. Aber das Tool funktioniert ganz gut. Genau. Allerdings sind hier gplaycli und PlaystoreDownloader aktuell auch abandoned. Also wenn man wirklich jetzt in einer Weile Apps downloaden muss, muss man so ein bisschen rumprobieren, welches Tool gerade funktioniert. Das ist unsere Erfahrung zumindest damit. Genau.

Jetzt haben wir Android abgegrast und jetzt wollen wir übergehen zu iOS. Da macht mein Kollege Benni weiter.

Benni: Ja, bei iOS ist das leider alles schwieriger. Das fängt schon bei der Auswahl des Geräts an. Im Gegensatz zu Android können wir hier keinen Emulator benutzen, der uns die Instrumentierung deutlich einfacher machen würde. Es gibt für iOS zwar den iOS Simulator. Da drin können wir aber keine Apps installieren, die wir aus dem App Store heruntergeladen haben. Und damit ist er für uns quasi wertlos. Das heißt, wir müssen ein physisches iPhone benutzen.

Etwas einfacher wird es dann hingegen beim Aufzeichnen des Netzwerk-Traffics. Hier können wir wieder genau wie bei Android auch mitmproxy benutzen. Und das Installieren unserer eigenen Certificate Authority im System ist dann tatsächlich sogar einfacher als bei Android. Um Certificate Pinning zu umgehen, benutzen wir dann SSL Kill Switch 2, anstatt von objection. Das hat vor allem den Vorteil, dass es die ganze Zeit im System im Hintergrund läuft und wir nicht während der Analyse in jede App immer Frida injizieren müssen.

Damit SSL Kill Switch 2 funktioniert, brauchen wir aber einen Jailbreak auf dem Gerät und das wäre bei Frida auch nicht anders. Dafür nutzen wir checkra1n. Das Problem ist, dass es aktuell zuverlässige Jailbreaks nur für iOS 14 gibt, während iOS mittlerweile die aktuellste Version 16 hat. Das heißt, da hinken wir leider deutlich hinterher und müssen hoffen, dass es da bald auch einen neueren Jailbreak gibt.

Ja, ähnlich problematisch wird es dann dabei, wenn wir an Apps kommen wollen. Da hatten wir bei Android ja eine große Auswahl an Tools, die es schon fertig gibt. Bei iOS ist das leider überhaupt nicht so. Es gibt im Wesentlichen drei offizielle Möglichkeiten, irgendwie an Apps zu kommen, ob nun offiziell so vorgesehen oder nicht.
Zunächst mal alte iTunes-Versionen. Die hatten offiziell tatsächlich eine vorgesehene Funktion, um Apps zu backuppen und in dem Zuge auch die Installationsdateien herunterzuladen. In neueren Versionen gibt es diese Funktion nicht mehr, aber man kann aktuell zumindest die alten Versionen auch immer noch verwenden und das funktioniert auch immer noch. Das Problem ist, dass ich mich dafür dann in jede App-Store-Seite von jeder App klicken muss und da auf den Download- Button klicken muss. Das ist ziemlich nervig zu automatisieren. Das ginge vielleicht irgendwie mit AutoHotkey oder so, ist aber auch nicht wirklich zuverlässig. Ich muss dann hoffen, dass während des Downloads nicht mittendrin dann irgendwas schief geht und es plötzlich nicht mehr weitergeht.
Als Alternative für die alten iTunes-Versionen bietet Apple mittlerweile Configurator 2 an. Das ist ein Tool, das sich vor allem an Unternehmen richtet, die Hunderte oder Tausende von iPhones verwalten müssen, dafür aber kein MDM, also kein Mobile Device Management benutzen wollen. Configurator 2 hat auch das Feature, dass ich auf mein Gerät bestimmte Apps vorinstallieren kann. Die Idee ist jetzt nicht, dass ich das dafür benutze, um Apps herunterzuladen, aber in dem Prozess werden die Apps temporär in irgendeinem Cache-Verzeichnis gespeichert und da kann ich sie mir dann rausholen. Also das funktioniert prinzipiell. Der Nachteil ist aber, dass Configurator 2 nur bereits gekaufte Apps herunterladen kann. “Gekauft”, der Begriff ist hier vielleicht ein bisschen missverständlich. Apple benutzt “gekauft” nicht nur für Apps, die kostenpflichtig sind, sondern auch für kostenlose Apps. Ich muss eben jede App einmal für die bestimmte Apple-ID registriert haben, bevor ich die mit Configurator 2 herunterladen kann.
Die dritte Möglichkeit ist, auf den neuen Macs mit ARM-Prozessor kann ich aus dem Mac App Store ja jetzt auch iPhone- und iPad-Apps herunterladen. Das hat aber auch ein Problem, nämlich die Auswahl an Apps ist sehr eingeschränkt. Entwickler_innen können festlegen, ob ihre Apps über diese Methode herunterladbar sein sollen oder nicht und bei vielen wichtigen Apps, zum Beispiel WhatsApp, ist das nicht möglich. Insofern ist das leider auch keine Option.

Jetzt gibt es aber nicht nur offizielle Tools, es gibt durchaus auch inoffizielle Tools für diesen Zweck. Das erste dafür wäre iMazing. Das kann auch Apps herunterladen und gibt mir dann eine IPA-Datei dafür. Also das wäre super. Das Problem ist, auch hier kann ich wieder nur bereits gekaufte Apps herunterladen. Das liegt daran, dass iMazing die internen APIs von Apple aus dem Configurator benutzt und damit dann natürlich dann das Problem auch erbt.

Dann aber gibt es noch 3uTools. Das ist so ein Allzweckwerkzeug für alle möglichen Sachen, die man mit einem iPhone machen können wollte… wollen könnte. Und das hat eben auch die Möglichkeit, Apps herunterzuladen. Und das ist tatsächlich deutlich vielversprechender als alles andere, was wir gesehen haben, denn das kann auch Apps herunterladen, die die Apple-ID vorher noch nie heruntergeladen und also noch nicht als gekauft markiert hatte. Und auch da kriege ich dann wieder eine IPA-Datei auf meinem Dateisystem und kann die später auf einem anderen iPhone installieren.

Leider hat das aber auch noch ein Problem. Die Auswahl an Apps, die ich herunterladen kann, ist nämlich irgendwie ziemlich willkürlich beschränkt. Ich hatte hier beispielsweise mal nach der Corona-Warn-App gesucht und aus irgendwelchen Gründen, obwohl die im App Store ist und auch unter diesem Namen im App Store ist, gibt es keine Möglichkeit, diese App herunterzuladen, sie wird als nicht gefunden angezeigt. Weil das jetzt aber die Möglichkeit war, die uns am nächsten an unser Ziel gebracht hat, haben wir uns das mal näher angeguckt. Wir hatten ja schon für iPhones und für Android mitmproxy eingerichtet, um uns den Netzwerk-Traffic zu capturen. Das funktioniert netterweise auch unter Windows, also habe ich mir mal den Netzwerk-Traffic von 3uTools angeguckt. Und als erstes ist mir aufgefallen, da sind ja zwei Anfragen an buy.itunes.apple.com. Das heißt, das Ding benutzt nicht etwa irgendwelche eigenen Server, um Apps herunterzuladen, sondern sie benutzen die offiziellen Apple-Endpunkte und das passiert auch alles tatsächlich auf meinem Gerät und mit meiner Apple-ID.

Wenn wir mal in eine der Anfragen reingucken, sehen wir, 3uTools gibt sich dabei als alte Version von iTunes aus. Das heißt, das ist genau der Grund, weshalb es im Gegensatz zu iMazing dann eben auch neue Apps herunterladen kann. Das heißt aber auch, dass es eigentlich gar keinen technischen Grund gibt, warum 3uTools nur bestimmte Apps herunterladen können sollte. Und gibt es auch tatsächlich nicht. Der Grund, warum es trotzdem so ist, ist, dass sie aus, warum auch immer, für alle Sachen die internen iTunes-Endpunkte benutzen – nur für das Auflisten der Apps haben sie ihren eigenen Endpunkt, der eben nur eine limitierte Liste an Apps zurückgibt. Naja, aber damit haben wir das Problem jetzt identifiziert und können das tatsächlich auch lösen.

Denn mitmproxy kann Anfragen nicht nur aufzeichnen, sondern es kann sie auch verändern. Ich kann mir ein Add-on schreiben, das einfach alle Anfragen an diesen Endpunkt abfängt, dann guckt, welcher Bereich von Apps gerade angefragt wird und das überschreibt mit den Apps, die aktuell in den Top-Listen des App Stores stehen, an der entsprechenden Stelle. Und dann gebe ich einfach mein Ergebnis statt des offiziellen 3u-Ergebnisses von deren Server zurück. Und tada, jetzt kann mein 3uTools plötzlich alle Apps herunterladen, von denen ich möchte, dass es sie herunterlädt. Und das funktioniert auch tatsächlich. Also auch die Apps, die vorher nicht herunterladbar waren, wenn ich jetzt auf Download klicke, funktioniert das tatsächlich. Also es gibt wirklich keinen Grund für diese Limitierung und ich habe auch keine Ahnung, warum die existiert.

Damit haben wir jetzt eine funktionierende Möglichkeit, um an ganz viele Apps zu kommen. Wir müssen halt nur dann, wenn wir 1000 Apps herunterladen wollen, 1000-mal in dieser Liste auf den Download-Button licken. Das haben wir in unserem ersten Forschungsprojekt so gemacht, von Hand. Es funktioniert, macht aber nicht wirklich viel Spaß natürlich und es wäre schön, wenn es besser geht. Das Problem ist auch, dass wir herausgefunden haben, wenn man zu viele Apps gleichzeitig in die Warteschleife steckt, dann hängt sich das gerne mal auf. Insofern muss man da immer mit einem halben Auge darauf sein und gucken, dass es irgendwie in einigermaßen funktioniert.

Zum Glück hat sich, seit wir dieses Projekt gemacht haben, aber etwas getan, nämlich es wurde das großartige IPATool veröffentlicht. Das ist das erste Kommandozeilentool, um inoffiziell Apps aus dem App Store herunterzuladen und damit natürlich viel besser geeignet für eine Automatisierung als diese ganzen fürchterlichen Klickibunti-Interfaces. Das Problem bei IPATool ist jetzt aber leider oder war leider, dass es eben auch nur Apps herunterladen konnte, die die Apple-ID schon gekauft hatte. Das heißt, eigentlich müssten wir unsere Betrachtung da jetzt auch wieder aufhören. Müssen wir aber zum Glück nicht wirklich, denn IPATool ist im Gegensatz zu all den anderen Tools auch open-source und damit haben wir die Möglichkeit uns den Code anzugucken und sogar zu verändern, was natürlich ein sehr sehr großer Vorteil ist.

Ich hatte vorher auch schon versucht, mein eigenes Tool zu schreiben, um diese Anfragen zu stellen, denn was in den Anfragen drinsteht, wusste ich ja. Bin da bisher aber immer dran gescheitert und habe das dann nicht weiter verfolgt. Aber dank IPATool hatte ich dann ein funktionierendes Tool, von dem ich den Quelltext einfach ändern konnte, was es natürlich viel einfacher macht. Und dann habe ich tatsächlich mal ziemlich viel Zeit damit verbracht und sehr viel mit Apples Servern gekämpft, mit dem Ziel, da auch den Support fürs Kaufen von neuen Apps hinzuzufügen. Die Problematik ist, dass eben wie schon gesagt, es Unterschiede gibt in den Endpunkten für iTunes und für Configurator 2. Und IPATool benutzt wenig überraschend die Endpunkte von Configurator 2.

Der erste Idee war jetzt, naja gut, vielleicht kann ich das ja einfach umschreiben, dass es stattdessen die iTunes-Endpunkte nutzt. Das ging aber leider nicht, denn um sich bei dem iTunes-Endpunkt anzumelden, braucht man neben der Apple-ID und dem Passwort und dem Two-Factor-Token noch gewisse Parameter in den Headern und die sind teilweise nicht einfach oder überhaupt zu generieren. Das größte Problem dabei ist der kbsync-Parameter. Das ist wohl irgendeine Art von kryptografischer Signatur oder so, mit der Apple eben genau das, was ich hier machen möchte, verhindern möchte und an der Stelle leider auch erfolgreich ist. Wenn man danach sucht, findet man irgendwelche Foren-Posts auf Chinesisch und Russisch von Menschen, die sagen, dass es ihnen irgendwie gelungen ist, diesen Parameter zu reverse-ingenieren. Sie verraten einem aber leider nicht, wie sie das geschafft haben.

Das heißt, das funktionierte nicht und dann habe ich eben mit, ach so, genau, wenn man sich über Configurator 2 einloggt, dann kann man aber den buyProduct-Endpunkt, der nötig ist, um ein Produkt zu kaufen, nicht aufrufen, sondern kriegt die Nachricht, dass der Login abgelaufen ist und man sich stattdessen nochmal neu einloggen soll mit dem implizierten Hinweis, dass man das doch bitte über den iTunes-Endpunkt machen soll, was aber leider nicht geht.

Also habe ich da ziemlich lange mit Apple gekämpft und alle möglichen Kombinationen der unterschiedlichen Endpunkte und Session-Cookies probiert und geguckt, welche Header davon wirklich nötig sind und welche Header man weglassen kann und am Ende habe ich es tatsächlich geschafft, mit einem Configurator-2-Session-Cookie den buyProduct-Endpunkt aufzurufen.

Und das habe ich dann als PR bei IPATool eingereicht, wurde mittlerweile auch gemergt und mittlerweile kann man dann also mit IPATool auch neue Apps, die man vorher noch nicht besessen hatte, über die Kommandozeile super automatisiert herunterladen in einem großen Stil. Das ist natürlich großartig. Ursprünglich hatte die Person, die dieses Tool entwickelt hat, das in Swift geschrieben und es lief nur unter macOS, mittlerweile hat sie das aber nach Go portiert und jetzt läuft es unter allen Systemen, was natürlich noch besser ist.

Gut, jetzt können wir Apps herunterladen, jetzt müssen wir die noch irgendwie installieren, auf dem Gerät. Da hilft uns dann tatsächlich Configurator 2, das bringt nämlich auch ein Kommandozeilen-Utility, das cfgutil mit, mit dem man Apps installieren und deinstallieren kann. Configurator 2 läuft nur unter macOS, aber unter Linux gibt es ein Open-Source-Tool, libimobiledevice, das ganz viele Funktionen hat zum Interagieren mit iPhones, unter anderem eben auch so ein Installieren- und Deinstallieren-Kommando.

Was wir jetzt noch brauchen, sind so verschiedene Kleinigkeiten. All diese Sachen, die wir unter Android einfach mit ADB gemacht hätten. Gibt es hier jetzt bei iOS leider nicht, aber zum Glück gibt es einen Jailbreak-Tweak, Activator heißt der. Der ist eigentlich dafür gedacht, dass man auf dem Gerät gewisse Automatisierung macht, also wenn Ereignis XY eintritt, führe Aktion Z aus automatisch. Praktischerweise bringt das aber auch ein kleines Terminal-Programm mit, mit dem man diese ganzen Aktionen auch übers Terminal aufrufen kann. Ich kann mir über einen weiteren Jailbreak-Tweak auf dem iPhone einen SSH-Server installieren und mich dann auch von meinem Computer darauf einloggen und diese Befehle ausführen. Damit kann ich dann zum Beispiel eine App starten oder den Home-Button automatisiert drücken.

Ein kleiner Tipp für alle, die sich auch mit diesem Thema beschäftigen wollen: Es gibt den sehr hilfreichen Befehl “activator listeners”, von dem ich mir echt gewünscht hätte, dass ich den früher gefunden hätte. Denn diese ganzen Aktionen, die man da ausführen kann, die sind nicht wirklich irgendwo dokumentiert. Da findet man ab und an mal in irgendeinem Blog-Artikel oder in irgendeinem GitHub-Repository zufällig einen Befehl und freut sich ganz doll darüber. Aber activator listeners gibt einem eben alle Befehle, die man darüber ausführen kann, aus und das ist natürlich dann super praktisch. Hat immer noch keine Dokumentation dazu, was die Befehle jeweils machen, aber häufig kann man das anhand des Namens erraten oder man probiert es eben einfach aus. Auf jeden Fall deutlich einfacher dadurch.

Was wir jetzt noch brauchen, ist eine Möglichkeit, den Apps die Berechtigung zu geben, denn wie Malte gesagt hat, wir wollen, dass die Apps alle Systemberechtigungen haben, mit der Idee, dass wir eben sehen, was die Apps im schlimmsten Falle, wenn sie die Rechte hätten, übertragen würden. Da gab es auch keine Prior Art für. Das hatte scheinbar noch niemand gemacht oder zumindest nicht dokumentiert und von Apple offiziell vorgesehen ist es natürlich sowieso nicht, das heißt, da muss ich auch wieder Reverse Engineering betreiben. Mein Ansatz war, dass es so ein Berechtigungssystem unter macOS ja auch gibt und viele Sachen oder zumindest einige Sachen sind zwischen macOS und iOS durchaus ähnlich und meine Hoffnung war, dass das hier vielleicht auch so sein könnte.

Das entsprechende Framework dafür heißt unter macOS TCC, das steht für Transparency, Consent and Control Framework und das hat so ein Kommandozeilenprogramm tccutil, mit dem man gewisse Sachen der Berechtigungen verwalten kann. Also wieder in das iPhone rein ge-ssh-t, das einmal ausgeführt – gibt es leider nicht. Na gut, unter macOS gibt es dann noch einen Daemon für dieses Framework, den tccd, gucken wir mal, ob es den unter iOS gibt. Nee, läuft da leider auch nicht. Ganz aufgegeben habe ich aber noch nicht ein letztes Ass hatte ich noch im Ärmel. Es ist auch bekannt, wie diese Daten für das TCC unter macOS gespeichert werden, nämlich in einer SQLite-Datenbank, die TCC.db heißt. Suchen wir mal danach. Aha, da sind jetzt tatsächlich Ergebnisse, das heißt, wir sind vielleicht doch auf dem richtigen Weg.

Gucken wir in die erste Datenbank mal einfach rein. So sieht die aus hier. Der Screenshot ist von einem iPhone, auf dem sehr wenige Apps nur installiert waren, dementsprechend ist hier relativ wenig los. Auf einem iPhone, das regelmäßig und aktiv genutzt wird, würde da sicherlich mehr los sein. Aber wir haben Spalten, die sehr vielversprechend aussehen. Wir haben eine client-Spalte, in der die App-IDs drinstehen. Wir haben eine service-Spalte, in der etwas drinsteht, das irgendwie so aussieht wie eine ID für die jeweilige Berechtigung. Und wir haben eine auth_value-Spalte, in der drinsteht, ob die jeweilige Berechtigung verweigert oder erteilt wurde. Also habe ich das einmal ausprobiert, da eine neue Zeile hinzugefügt, in einer anderen Zeile was geändert. Und tatsächlich, die entsprechenden Änderungen wurden dann auch in der Einstellungs-App reflektiert. Das heißt, das ist tatsächlich der Weg, wie iOS Berechtigungen speichert. Und damit haben wir dann auch eine Möglichkeit, das automatisiert zu machen, ohne da im iPhone in der Einstellungs-App rumdrücken zu müssen.

Problem ist jetzt aber noch, dass wir keine Liste der möglichen IDs für Berechtigungen haben, die natürlich super wichtig ist. Es geht sogar noch weiter. Wir haben nicht mal unbedingt eine Liste aller Berechtigungen, die überhaupt möglich zu setzen sind. Denn in der Einstellungs-App werden für eine App immer nur die Berechtigungen angezeigt, die sie tatsächlich angefragt hat. Das heißt, wenn wir da so eine Liste auf dem Wege zusammensuchen wollten, müssten wir erst mal herausfinden, welche Berechtigungen es überhaupt gibt und dann für jede Berechtigung auch noch eine entsprechende App finden, die diese Berechtigung anfragt, was natürlich super aufwendig sein würde und die Wahrscheinlichkeit, dass wir irgendwelche Berechtigungen verpassen, übersehen, wäre ziemlich hoch.

Zum Glück ist das aber auch nicht nötig, denn ich habe im Dateisystem noch diese großartige Datei gefunden. Das ist eine Übersetzungsdatei für das TCC-Framework und wenn wir da mal reingucken, haben die Keys jeweils als Suffix die ID der Berechtigung und der String ist dann die Übersetzung, die angezeigt werden würde, wenn die App die entsprechende Berechtigung anfragt. Das heißt, darüber weiß ich jetzt, dass kTCCServiceReminders für die Erinnerungsberechtigung da ist und dass kTCCServiceUserTracking eine Berechtigung ist, die es gibt, die ich aber vielleicht für diese Analyse doch lieber verweigern würde als erlauben, dass die Apps das dann als Consent ansehen.

Also kann ich aus dieser Datei mir eine Tabelle machen mit all den Berechtigungen, die es gibt, und habe das auch gemacht. Das ist die erste Seite davon. Es gibt noch eine zweite Seite. Auf der zweiten Seite sehen wir jetzt einige Berechtigungen, die etwas merkwürdig sind. Das ist dann zum Beispiel “Authorization to Test Service Proto3Right”. Wenn man die Berechtigung setzt oder verweigert, ändert sich in den Einstellungen der jeweiligen Apps nichts. Da sieht man nichts. Meine Vermutung ist, dass das irgendwelche internen Testsachen von Apple sind, die im eigentlichen System nicht enthalten sind, aber aus irgendwelchen Gründen haben sie es halt vergessen, die aus der Übersetzungsdatei herauszunehmen. Um da nicht aus Versehen irgendwas kaputt zu machen, lasse ich diese Berechtigungen aber natürlich in Ruhe und fasse sie nicht an.

Das heißt, damit haben wir jetzt wirklich die Möglichkeit einer App, zum Beispiel hier einer Taschenlampen-App, alle Berechtigungen zu geben. Alle Berechtigungen? Wer genau hinguckt, wird sehen, da fehlt leider eine Berechtigung und zwar eine relativ wichtige Berechtigung, die Standortberechtigung. Dabei ist es natürlich super interessant für uns zu wissen, wenn eine App den Standort abfragt und an einen Server gibt. Die Standortberechtigung wird aber leider wirklich nicht über dieses TCT-Framework verwaltet, das heißt, da kommen wir nicht weiter und ich hatte auch nirgendwo gesehen zu dem Zeitpunkt, dass irgendjemand anders herausgefunden hat, wie man die automatisiert setzen kann.

Also wieder ran ans Suchen. Meine Idee war, wir haben ja jetzt schon gesehen, dass Apple ganz offensichtlich ganz gerne mal Daten in der SQLite-Datenbank speichert. Vielleicht ist es hier wieder der Fall. Also habe ich mich in das iPhone wieder rein ge-ssh-t – wirklich ein super praktisches Feature, sollten die von Haus aus auch mitbringen – und ein kleines Skript geschrieben, das alle SQLite-Datenbanken im System sucht, darüber iteriert, dann über alle Tabellen in der jeweiligen SQLite-Datenbank iteriert und dann quasi einen grep darauf ausführt und nämlich guckt, ob die ID einer bestimmten App in der Datenbank vorkommt. Der entsprechenden App habe ich vorher über die Einstellungs-App die Standortberechtigung gegeben. Das heißt, die Erwartung ist natürlich, wenn die App die Berechtigung hat, muss sie irgendwie in der Datenbank stehen, wenn die Datenbank wirklich dafür verantwortlich ist.

Das Ding hat auch ein paar Ergebnisse geliefert, unter anderem wenig überraschend die Datenbank, die wir vorhin schon gefunden hatten, die TCC.db, aber leider ist keine von diesen Datenbanken wirklich verantwortlich für die Standortberechtigung, das war also leider eine Sackgasse. Die nächste Idee war, wer sich mit irgendwelchen internen Funktionen von iOS beschäftigen möchte, ist sicherlich immer gut aufgehoben, sich die Jailbreak-Community anzugucken, die da ganz ganz fleißig dabei ist, das System zu reverse-engineeren und ganz tolle Tweaks schreibt, die dem System neue Funktionen hinzufügen.

Ein Teil davon ist netterweise auch als Open Source veröffentlicht und so habe ich diesen Tweet hier gefunden, das ist irgendeine Jailbreak-App, ForceReset heißt die, die kann zwar keine Berechtigung für die Standortberechtigung setzen, aber sie kann sie immerhin auslesen und ich kann den Code sehen, der das tut. Und dadurch habe ich dann gelernt, dass es offensichtlich eine CLLocationManager-Klasse gibt und die irgendwelche Methoden hat, die mit dem zu tun haben, was ich suche. Zum Beispiel eben eine _authorizationStatusForBundleIdentifier-Funktion, um herauszufinden, ob eine App die Location-Permission hat. Und CLLocationManager klingt ja sowieso schon mal sehr nach dem, was ich suche, insofern wirkt das vielversprechend.

Das Problem ist, dass die ganzen spannenden APIs davon alle intern sind und Apple mir dafür natürlich keine Dokumentation gibt, das wäre ja viel zu einfach. Das heißt, da komme ich so einfach auch nicht weiter. Jetzt hatte Malte aber vorhin ja schon Frida vorgestellt, das wirklich super, super nützliche Tool und das hatte eben diese sehr praktische Funktion, dass es mir auch ein Autocomplete-Interface gibt. Also habe ich mich einfach mal in meine Taschenlampen-App wieder mit Frida reinjiziert und geguckt, was wird denn da autocomplete-mäßig angeboten auf dem CLLocationManager. Dabei unter anderem die sehr, sehr wundervoll klingende Funktion setAuthorizationStatusByType_forBundleIdentifier_. Das klingt ja wirklich nach genau dem, was ich machen wollte. Also das schnell einmal ausprobiert, kann ich meiner Taschenlampen-App damit die Standortberechtigung geben? Leider nicht. Kaum hatte ich den Befehl ausgeführt, ist Frida abgestürzt, die App auf meinem Handy ist auch abgestürzt und als ich in die Einstellungen geguckt habe, war leider die Berechtigung trotzdem nicht da. Ja Mist.

Aber zum Glück hat Frida noch ein paar andere sehr nützliche Tools, unter anderem das frida-trace-Tool. Das gibt einem eine Liste von allen Funktionen, die eine App aufruft, während sie so läuft. Und ich wusste ja, dass zumindest die Einstellungs-App das irgendwie hinkriegt, diese Berechtigung zu setzen. Das hatte ich ja schon mehrfach gemacht. Also mal die Einstellungs-App gestartet, frida-trace darauf gestartet mit einem Filter auf CLLocationManager, denn sonst wäre da wirklich eine riesenlange Liste an Methodenaufrufen gewesen, durch die kein Mensch hätte durchsteigen können. Genau und dann eben in der Einstellungs-App die Berechtigung für eine App gesetzt und dann kam diese Liste an entsprechenden CLLocationManager-Aufrufen. Und diese eine hier ist eben genau diese Funktion, die wir eben auch schon aufrufen hatten.

Wieso schafft es denn die Einstellungs-App, damit die Berechtigung zu setzen und wir schaffen es nicht? Ja, da war dann der Groschen gefallen. Ich hatte das bisher im Kontext der jeweiligen App, der ich die Berechtigung geben möchte ausgeführt, aber das ist natürlich nicht die Idee. Wenn jede App sich jede Berechtigung, die sie haben möchte, einfach selber geben könnte, wäre der ganze Mechanismus ja vollkommen witzlos. Dafür brauche ich schon bestimmte zusätzliche permissions oder elevated privileges. Deshalb kann die App selber das natürlich nicht machen. Die Settings-App, die diese privileges aber hat, kann diesen Befehl ausführen.

Und da funktioniert das dann tatsächlich auch, wenn ich das mit Frida selber mache. Das einzige, was jetzt noch übrig ist, da ist noch so ein Value-Parameter, der sagt, ob die Berechtigung gesetzt oder nicht gesetzt werden soll. Das ist natürlich auch nirgendwo dokumentiert gewesen, aber gut, das ist einfach ein Integer. Fangen wir mal bei Null an und probieren durch und das sind dann die Werte, die man setzen kann. Und das sind eben auch genau die Werte, die ich über die Einstellungs-App hätte setzen können. Auf dem gleichen Wege kann ich dann auch herausfinden, ob eine App die Location Permission hat oder nicht, sowohl für die jeweils laufende App als auch für eine beliebige App.

Damit haben wir es dann endlich tatsächlich geschafft, unserer Taschenlampen-App alle Berechtigungen zu geben, einschließlich der Standortberechtigung, die sie bestimmt wirklich dringend braucht.

Ja, auf dem gleichen Wege, auch über Frida, können wir auch etwas in die Zwischenablage schreiben, das dann eben mit dem Ziel, um später zu gucken, ob irgendeine App das ausgelesen hat und an einen Tracking-Server oder sonstwohin geschickt hat. Das würde uns natürlich interessieren.

Damit haben wir dann nicht nur Android bezwungen, sondern endlich auch iOS und haben die Möglichkeit, automatisierte Analysen über tausende von Apps zu machen, die sich den Netzwerk-Traffic angucken. Unsere Idee dabei war, dass wir keine Interaktion mit den Apps machen, sondern wir starten sie nur für eine Minute, lassen sie laufen ohne irgendwas damit zu tun, und gucken uns dann nachher den aufgezeichneten Netzwerk-Traffic an. Da haben wir mehrere Projekte zugemacht. Als allerletztes habe ich mir in meiner Masterarbeit fast viereinhalbtausend Apps angeguckt, relativ gleichmäßig verteilt über Android und iOS.

Und die Ergebnisse fangen schon mal sehr gut an. Fast 80 % der Apps, die ich mir angeguckt habe, haben mindestens einen Tracker kontaktiert. Und wie gesagt, das alles ohne dass ich irgendwas mit den Apps gemacht hätte.

Das sind die Tracker, die sich diese Apps kontaktiert haben, die 25 am meisten kontaktierten. Die Auflistung habe ich so gemacht, indem ich die DNS-Namen, die in meinem Netzwerk-Traffic drin standen, mit der Exodus-Tracker-Datenbank verglichen habe. Und das steht dann eben jeweils drin, welches Unternehmen dafür verantwortlich ist. Ganz oben die üblichen Verdächtigen, Google und Facebook. Die werden hier denke ich niemanden überraschen, aber vielleicht doch ein bisschen überraschend: Google ist nicht nur bei Android auf dem ersten Platz, sondern leider auch bei iOS. Das heißt, nur weil ich ein iPhone habe, werde ich damit dem Google-Tracking nicht entkommen können.

Neben den beiden dann aber auch noch eine lange Liste an anderen Trackern. Das sind jetzt hier nur die 25 am häufigsten kontaktierten. Die Liste geht aber noch deutlich weiter. Wenn ich mir angucke, wo die Tracker jeweils ihre Hauptniederlassung haben, das ist bei den allermeisten in den USA. Und das ist im Hinblick auf das Schrems-II-Urteil des EuGH von vor zwei Jahren ja doch rechtlich fragwürdig.

Diese Tracker sind auch sehr aktiv. Ein Drittel aller Anfragen, wie gesagt, ohne irgendeine Interaktion von unserer Seite, gehen an Trackingserver. Und da wollen wir jetzt natürlich wissen, was steht denn drin in diesen Anfragen? Welche Daten werden da übertragen? Den Netzwerk-Traffic haben wir aufgezeichnet, aber es fehlt noch eine Möglichkeit automatisiert eben diese Informationen daraus zu extrahieren.

Unser erster Ansatz war, wir machen ein Text-Matching. Wir suchen in den rohen übertragenen Daten nach Werten, die wir vorher schon kennen, also zum Beispiel die Werbe-ID des Gerätes, den Standort oder irgendwelche Daten, die wir vorher absichtlich auf dem Gerät platziert haben, in der Erwartung, dass vielleicht irgendwelche Apps die aufsaugen würden, also zum Beispiel irgendwelche Kontakte mit erkennbaren Namen oder Anrufe an bestimmte Nummern. Und das funktioniert tatsächlich auch. Wir können auf diese Weise natürlich diese Werte erkennen und das geht auch nicht nur in Plaintext, sondern es geht auch in base64-encodetem Text mit ein bisschen Aufwand.

Aber dieser Ansatz hat leider zwei Probleme. Problem eins ist, das funktioniert nur mit statischen Daten, die wir vorher eben kennen. Das heißt, so Sachen wie die RAM-Auslastung oder der Akkustand, der sich natürlich im Laufe der Benutzung des Handys ändern wird und die wir vorher nicht wissen können, die können wir damit nicht erkennen. Und, Spoiler, die werden aber sehr wohl doch übertragen und das würden wir dann natürlich eigentlich gerne mitkriegen. Und zusätzlich dazu müssen die Daten auch ausreichend eindeutig sein. Ich habe gerade schon gesagt, wenn wir einen Kontakt setzen, dann werden wir das nicht auf “Max” oder so setzen, sondern wir werden dann natürlich irgendwelche zufällig generierten Strings reinmachen, die ausreichend hohe Entropie haben, sodass wir uns, wenn wir das am Ende wiederfinden, tatsächlich sicher sind, dass das die Daten sind, die wir da hingemacht haben und nicht irgendwelche zufälligen Treffer. Das heißt dann aber auch, dass wir so Sachen wie die Betriebssystemversion auf dem Weg nie erkennen können werden. Denn nur weil “11” irgendwo in einem Traffic drin steht, können wir daraus nicht schließen, dass die App wirklich übertragen kann, dass ich gerade Android 11 als Betriebssystem benutze. Das ist einfach zu generisch und das wird zu viel zu vielen False-Positives führen.

Das zweite Problem ist, dass die Anfragen mit den Trackingdaten häufig absurd, also wirklich absurd, verschachtelt und/oder obfuskiert sind. Was meine ich damit? Zwei Beispiele. Hier eine Anfrage an das Unternehmen Supersonic. Da soll eine Werbeanzeige ausgespielt werden und wir sehen schon, in der URL sind schon ein paar Parameter. Da ist irgendwie eine Session-ID drin enthalten und es ist wohl auch irgendwie eine Information enthalten, um welche App es gerade geht. Aber der wirklich spannende Teil, der ist im Request-Body und da sehen wir jetzt irgendeinen Base64-String, aus dem wir aber so erst mal keine Informationen extrahieren könnten.

Versuchen wir mal nachzuvollziehen, was in dieser Anfrage drinsteht. Ich habe schon verraten, die erste Ebene ist Base64, die hätten wir auch noch automatisiert umgehen können, aber da ist jetzt leider noch nicht Schluss. Wenn wir das base64-dekodieren, kommt da irgendein binary blob raus, spätestens mit dem können wir dann aber nichts mehr anfangen. Das ist in dem Fall jetzt ein gzip-Archive, das heißt wir müssen das entzippen. Da kommt jetzt ein JSON heraus, das sieht schon mehr nach dem aus, was wir suchen, aber wirklich maschinenlesbar ist das auch noch nicht. Also müssen wir auch hier noch weitermachen. Wir müssen zunächst mal in das property “data” gehen und da haben wir jetzt einen String. Wenn wir genauer hingucken, sehen wir, dass das in Wirklichkeit kein String ist, sondern das ist eigentlich ein JSON-Objekt, das aber aus irgendwelchen Gründen stringifiziert wurde und dann jetzt eben als String übertragen wurde. Das heißt, da müssen wir dann noch mal ein JSON-Parse drüber laufen lassen und erst jetzt haben wir tatsächlich die maschinenlesbaren Daten, die da wirklich dahinter stehen. Und hier sehen wir jetzt, dass in dieser Anfrage tatsächlich relevante Daten übertragen wurden und dass die nämlich genauso aussieht wie eine der Anfragen, die Malte vorhin als Beispiel euch schon gezeigt hatte. Ja, das hätten wir aber eben mit so einem generischen Approach, der nur Plaintext-Daten oder nur base64-enkodierte Daten matchen kann, natürlich nicht gefunden.

Nächstes Beispiel, eine Anfrage an Facebook. Hier sehen wir, es ist irgendwie ein JSON-Objekt, aber natürlich auch nicht einfach maschinenlisbar, das wäre ja viel zu einfach. Sondern es gibt da irgendwie ein batch-Property. Wenn wir uns mal nur auf das batch-Property fokussieren, sehen wir, wir haben wieder so einen String, in dem ein JSON-Objekt drin ist. Also JSON-parsen wir das doch mal. Und jetzt haben wir ein Array von Objekten, die alle jeweils eine relative_url haben. Holen wir uns die mal alle raus und dann haben wir jetzt eine Liste von URLs und die GET-Parameter in diesen URLs enthalten nun die tatsächlichen Daten. Da muss man also wirklich auch erstmal drauf kommen. Das heißt, wir machen jetzt hier noch einen Query-String-Decoder drüber und jetzt kommen wir langsam dahin, dass wir Daten haben, die wir tatsächlich automatisiert analysieren können. Da kriegen wir jetzt nämlich diese Struktur und ihr seht, da ist irgendwie ein custom_events-Property, da geht genau diese Verschachtung nochmal weiter, aber das ist dann einfach Schema F, genau das, was wir jetzt schon zweimal gemacht haben. Deshalb erspare ich euch das. Aber ich denke, es wird klar, die Tracker sind da häufig wirklich erstaunlich und fragwürdig kreativ dabei, wie sie die Daten verschicken, in welchem Format sie die Daten verschicken. Und ich zumindest sehe keine Möglichkeit für alle diese Sachen, das waren ja jetzt nur zwei Beispiele für zwei Tracker und allein Facebook hat neben diesem einen Request-Format auch noch ganz viele andere Request-Formate, die ganz anders funktionieren und die wir dann auch noch handeln müssten. Ich sehe da keine Möglichkeit, einen generischen Decoder für zu schreiben, der ausreichend erfolgreich drin sein kann, all diese unterschiedlichen Formate zu dekodieren. Und, genau.

Insofern brauchen wir einen anderen Ansatz und das Gute ist, es ist auch möglich, einen anderen Ansatz dafür zu finden. Denn wir hatten ja vorhin schon gesehen, die Tracking-Unternehmen, es gibt zwar sehr viele Tracking-Unternehmen, die da vorkommen, aber ganz oben sind einige wenige Tracking-Unternehmen, die einen sehr großen Teil des Traffics abkriegen. Und das können wir uns zunutze machen, wenn wir uns nämlich statt der Tracking-Unternehmen mal die Endpunkte angucken. Das heißt quasi eine sehr ähnliche Betrachtung, aber feingranulierter. Das ist jetzt die Liste aller Endpunkte in meinem Datensatz, sortiert danach, wie oft die aufgerufen wurden. Da sehen wir hier genau das gleiche Muster. Wir haben ganz oben Endpunkte, die super oft aufgerufen wurden, von ganz ganz vielen Apps aufgerufen wurden und das fällt dann aber doch relativ schnell auch ab und die Endpunkte werden deutlich weniger häufig aufgerufen.

Das heißt, die Erwartung ist, dass wir, wenn wir irgendwie spezifische Handler schreiben, oder Adapter habe ich es genannt, die konkret wissen, wie man für so einen bestimmten Endpunkt die Daten extrahieren kann, dann haben wir eine gute Möglichkeit, dass wir zwar nicht allen Traffic damit handeln können, aber zumindest einen sehr großen Teil des Traffics. Genau, und das war eben auch das, was ich gemacht habe.

Ich habe 26 Adapter geschrieben, die spezifisch für einen bestimmten Endpunkt jeweils die Daten extrahieren können. Das heißt, ich musste mir für jeden dieser Adapter vorher ein bisschen Mühe machen, die Anfragen an den Endpunkt zu verstehen und dann halt auch noch zusätzlich ein Skript zu schreiben, das die Daten automatisiert extrahieren kann. Aber dafür konnte ich dann schon ganze 10 % mit nur 26 Adaptern des gesamten Traffics abdecken. Also das heißt, ein einigermaßen vertretbarer Aufwand, diese 26 Adapter zu schreiben, deckt schon 10 % des gesamten Traffics ab und “gesamter Traffic” meint nicht den Tracking-Traffic, sondern, ja, den gesamten Traffic von allen Apps, auch inklusive der App-Funktionalität. Das heißt, das ist durchaus ein viable approach, auf diesem Wege vorzugehen.

Damit kann ich mir dann also angucken, was die Apps so für Daten übertragen. Ich habe für die Endpunkte, für die ich einen Adapter geschrieben habe, den Adapter genutzt und für alles, wofür ich keinen Adapter habe, bin ich dann auf das String-Matching, also die einfachere Variante, zurückgefallen. Hier jetzt die Daten, die da übertragen werden. Ganz oben sehen wir relativ langweilige Daten. Die kann ich gut verstehen, dass die Apps, die wissen wollen, wie App-IDs, die benutzt werden, Betriebssystem-Version, App-Version und Modell. Da würde ich auch sagen, das sind jetzt nicht so die kritischen Daten, wegen derer wir uns Sorgen machen müssen.

Das Problem ist aber an einer anderen Stelle. Ich habe mir auch angeguckt, nicht nur werden diese Daten überhaupt übertragen, sondern werden die anonymisiert oder pseudonymisiert übertragen. Pseudonymisiert heißt hier, dass die Daten nicht einfach so übertragen wurden, sondern in Kombination mit einer eindeutigen ID für das Gerät oder sogar die Benutzer_in. Das heißt, wenn Daten pseudonymisiert übertragen werden, dann ist da nicht nur die Information, irgendjemand hat diese App-ID benutzt, hat diese App mit dem Betriebssystem benutzt oder was auch immer, sondern es ist konkret die Information für ein bestimmtes Gerät oder eine bestimmte Person. Das, wird Lorenz euch gleich noch erklären, hat auch rechtliche Bedeutung. Und wir sehen hier, orange heißt pseudonymisierte Übertragung, der weitaus überwiegende Teil der Übertragungen war jeweils pseudonymisiert, was dann das Ganze schon deutlich kritischer macht.

Dann muss man auch bedenken, dass wie gesagt, alle diese Übertragungen passiert sind ohne irgendeine Interaktion mit der jeweiligen App. Das limitiert natürlich die Daten, die überhaupt potentiell übertragen werden können. So Sachen wie Eingaben in der App oder so können da natürlich nicht übertragen werden, weil die gar nicht stattgefunden haben. Trotzdem sehen wir auch jetzt schon in diesem “ohne Interaktion"sstatus, dass so doch deutlich kritischere Daten wie der Standort auch von einigen Apps übertragen wurden. In dem Fall jetzt sogar wieder zur Hälfte nicht als anonymisierte Daten, sondern als pseudonymisierte Daten.

Lorenz: Okay, ja wir haben euch jetzt erzählt, wie allgegenwärtig Tracking ist und dass es eigentlich total schwer ist, irgendwie dem Tracking aus dem Weg zu gehen, weil es eigentlich überall zu finden ist. Aber wir wollen euch jetzt irgendwie keine Angst einjagen oder euch damit alleine lassen, dass Tracking überall ist, sondern wir wollen euch irgendwie auch Möglichkeiten an die Hand geben, sich dagegen zu wehren und euch deswegen jetzt mal so zwei Möglichkeiten vorstellen, die wir irgendwie sinnvoll und effektiv finden.

Und die eine Möglichkeit, die kennt ihr vielleicht schon und wenden vielleicht auch einige Leute schon von euch an, das sind einfach technische Maßnahmen gegen Tracking. Und als erstes ist es vielleicht sinnvoll, sich irgendwie mal anzugucken, mit wem haben wir es hier überhaupt zu tun. Und das könnt ihr alle zu Hause machen, nämlich mit Hilfe von Exodus. Das ist eine Datenbank, in der ganz viele verschiedene Apps drin sind, die von Exodus analysiert worden sind. Und da wurde einfach nur geguckt, sind in dem Code der App, sind da Codesignaturen von bekannten Trackern drin, also zum Beispiel irgendwie Google Analytics oder so. Und dann könnt ihr herausfinden, indem ihr den Namen von der App eingebt, ob die App diese Tracker einbindet und dann kann es zu einer Übertragung kommen. Exodus weiß aber natürlich nicht genau, ob es tatsächlich zu einer Übertragung gekommen ist.
Also es ist nur mal so eine Einschätzung, ob die App potentiell euch tracken kann oder nicht. Und das ist natürlich schon mal bei der Entscheidung, welche App möchte ich benutzen, erstmal eine gute Sache. Und außerdem kann euch Exodus auch verraten, an welche URLs diese Apps zum Beispiel sich melden. Und die könnt ihr dann nutzen, um Anfragen an diese URLs zu blocken.

Zum Beispiel mit einem Pi-hole. Das ist ein kleiner DNS-Server, den ihr auf einem Raspberry Pi oder einem vergleichbaren kleinen Computer oder was ihr denn noch so zu Hause rumliegen habt, einfach installieren könnt. Und der leitet dann einfach DNS-Anfragen an bekannte Tracking-Domains einfach ins Nichts. Und die Tracking-Anfragen kommen dann nicht an und eure Daten werden nicht an die Tracker übertragen. Und das ist eigentlich eine sehr einfache und effektive Art, vor allem weil es nicht nur euch schützt, sondern irgendwie auch alle anderen Leute in eurem Netzwerk, die den DNS-Server verwenden. Und dadurch schützt ihr dann nicht nur euch, sondern auch eure Familie, euer Hausprojekt oder euer Büro.

Und es gibt natürlich noch irgendwie ganz viele andere coole Möglichkeiten, sich gegen Tracking zu schützen. Und wir empfehlen da auf jeden Fall auch, sich da mal umzugucken. Wir sind auf jeden Fall nicht die besten Ansprechpartner dazu, was so technische Maßnahmen gegen Tracking angeht und verweisen deswegen gerne auf den Kuketz-Blog zum Beispiel, wo es sehr viele sehr gute Empfehlungen gibt. Und auch mit ein bisschen googeln lässt sich da viel herausfinden.

Aber klar, irgendwie ist das alles sehr voraussetzungsreich. Also das ist jetzt nichts, was so jede Person oder meine Oma oder so mal eben machen könnte, um sich gegen Tracking zu schützen. Und wir finden, dabei kann es eigentlich nicht bleiben. Tracking ist ein gesellschaftliches Problem. Es ist überall und die Geschäftsmodelle hinter dem Tracking, die sind es eigentlich, die man da angehen muss. Und deswegen finden wir, brauchen wir irgendwie eine gesellschaftliche Lösung. Und da haben wir zumindest einen Weg identifiziert, mit dem wir glauben, dass sich da was machen lässt und das ist rechtlich gegen das Tracking. Weil uns klar ist, irgendwie nicht alle Leute können auf einer individuellen Ebene sich irgendwie davor schützen, getrackt zu werden. Das ist teuer, das ist irgendwie aufwendig, das erfordert technisches Know-how.

Okay, was heißt rechtlich dagegen vorzugehen? Da haben wir erstmal das Glück, dass es in der EU die Datenschutz-Grundverordnung gibt und die erstmal grundsätzlich hohe Anforderungen stellt an die Verarbeitung von Daten. Aber als erstes mal die Frage, fällt überhaupt Tracking unter die Datenschutz-Grundverordnung?

So, klar ist, die Datenschutz-Grundverordnung, die gilt für die Verarbeitung von personenbezogenen Daten. Das sind natürlich jetzt wieder so Jurabegriffe, also lohnt es sich mal zu gucken, was bedeutet das eigentlich? Personenbezogene Daten sind Daten, die sich auf Personen beziehen, obviously, und zwar auf identifizierte oder identifizierbare Personen. Und das kann jetzt erstmal heißen, irgendwie Daten, die mit einem Namen verknüpft sind oder Daten, die mit einer E-Mail-Adresse verknüpft sind oder irgendeinem anderen Identifikationsmerkmal, eine Postadresse vielleicht, aber eben auch, und das sagt die Datenschutz-Grundverordnung auch sehr explizit, mit einer Kennnummer verknüpft sind. Und das ist das, was wir beim Tracking sehr häufig sehen. Also, auch wie sich Tracking-Anbieter öfter mal rausreden, dass sie sagen, oh, da ist aber gar nicht dein Name drin, deswegen kann das ja kein personenbezogenes Datum sein. Da hat die Datenschutz-Grundverordnung eigentlich im nächsten Satz direkt die Antwort “Kennnummern reichen aus” und wenn da eine ID drin steht, dann ist das auch ein personenbezogenes Datum.

Ja, und dann ist die Frage, was heißt denn Verarbeitung? Also, Verarbeitung, erstmal jeder Vorgang im Zusammenhang mit personenbezogenen Daten, sehr weit gefasst, aber auch da sagt die Datenschutz-Grundverordnung nochmal konkret, nämlich auch das Auslesen und das Übermitteln von Informationen von personenbezogenen Daten. Und das ist ja ganz klar der Fall beim Tracking, da geht es ja darum, eure personenbezogenen Daten auszulesen und dann an die Tracking-Unternehmen zu übermitteln. Also können wir schon mal sagen, okay, für Tracking-Daten, da gilt die Datenschutz-Grundverordnung, aber findet die überhaupt Anwendung bei Unternehmen?

Weil klar ist irgendwie natürlich also für die EU gilt die Datenschutz-Grundverordnung, ist ja ein EU-Gesetz, aber viele Tracking-Unternehmen, die sitzen ja gar nicht in der EU, die meisten sitzen in den USA, wie ihr vorhin gesehen habt, oder in China, Russland oder in anderen Ländern und deswegen müssen wir uns fragen, okay, gilt es auch außerhalb der EU? Und da sagt die Datenschutz-Grundverordnung auch klar, ja, sie gilt für Unternehmen außerhalb der EU, zumindest sofern diese Unternehmen Zugang zum europäischen Binnenmarkt haben wollen und das identifiziert die Datenschutz-Grundverordnung dann daran, dass sie entweder dir konkret oder eben anderen Europäer_innen Waren oder Dienstleistungen anbieten oder eben dein Verhalten beobachten und das ist beim Tracking ja auch klar der Fall. Also können wir eigentlich sagen, okay, wenn ein Unternehmen dich trackt, egal ob in oder außerhalb der EU, dann gilt da die Datenschutz-Grundverordnung. Also das Unternehmen ist innerhalb oder außerhalb der EU, für dich ist wichtig, dass du dich in der EU befindest.

Okay, dann ist jetzt aber die Frage, okay, ist denn Tracking überhaupt legal? Mit welcher Rechtsgrundlage? Klar, die Datenschutz-Grundverordnung gilt, aber welche personenbezogenen Daten dürfen überhaupt verarbeitet werden? Und da muss man erst mal wissen, okay, die Datenschutz-Grundverordnung, die verbietet erst mal grundsätzlich jede Form der Datenübertragung oder der Verarbeitung und erlaubt sie nur in speziellen Sonderfällen.

Einen von den Sonderfällen kennt ihr schon, nämlich, dass ihr eure Einwilligung gegeben habt, dann ist die Verarbeitung erlaubt. Aber es gibt auch andere Fälle, zum Beispiel, wenn es irgendwie darum geht, einen Vertrag zu erfüllen, etwa einen Kaufvertrag, wenn ihr online irgendwas gekauft habt, dann müsst ihr da eure Postadresse angeben oder so, damit man euch was zuschicken kann. Das ist dann irgendwie die Rechtsgrundlage dafür. Oder wenn ein Unternehmen eine rechtliche Verpflichtung hat, zum Beispiel, weil es irgendwie Belege für die Steuerunterlagen zehn Jahre aufbewahren muss, dann müssen die Daten deswegen gespeichert werden und können nicht einfach so gelöscht werden. Oder um eure lebenswichtigen Interessen zu schützen, auch klar, irgendwie, wenn der Rettungsdienst euch mitnimmt, dann muss er irgendwie auch eure Daten verarbeiten und darf das dann einfach, weil euer Leben in Gefahr ist. Und zur Ausübung öffentlicher Gewalt, das ist dann oft die Rechtsgrundlage, die für die Sicherheitsbehörden gilt, die mit öffentlicher Gewalt betraut sind, aber zum Beispiel auch das Einwohnermeldeamt, das auf dieser Grundlage eure Daten verarbeitet. Und die Lieblingsverarbeitung, die Lieblingsrechtsgrundlage von vielen Unternehmen ist das berechtigte Interesse. Denn wenn Unternehmen ein berechtigtes Interesse daran haben, eure Daten zu verarbeiten, dann dürfen die das. Aber, und das ist die wichtige Einschränkung, nur dann, wenn eure Interessen und eure Grundrechte nicht überwiegen. Und das ist eigentlich gar nicht so häufig der Fall, aber Unternehmen können sich eben oft auf diesen Grund beziehen, weil es erstmal schwammig ist und es eben um eine Abwägung geht.

Jetzt können wir hier schon mal eigentlich relativ viele Rechtsgrundlagen einfach so ausschließen für Tracking, denn es gibt keine rechtliche Verpflichtung zu tracken, es ist auch kein lebenswichtiges Interesse von euch, das da mit Tracking irgendwie, dem mit Tracking begegnet wird. Und die Ausübung öffentlicher Gewalt durch Tracking ist jetzt auch nicht gegeben. Man nennt das dann vielleicht Staatstrojaner, aber das ist eben das, womit wir uns hier gerade nicht befassen.

Das heißt, wir haben eigentlich nur noch drei Rechtsgrundlagen übrig und auch zu denen gibt es eigentlich schon relativ klare Äußerungen, weil das alles so Abwägungsfragen sind von den Datenschutzaufsichtsbehörden und die haben eigentlich alle durch die Bank weg gesagt, Tracking ist nur mit Einwilligung rechtlich überhaupt möglich. Also hier, das sagen zum Beispiel das European Data Protection Board, das ist der Zusammenschluss der europäischen Datenschutzorganisationen, das sagt auch die Datenschutzkonferenz, der Zusammenschluss der deutschen Datenschutzorganisationen und das sagen auch einzelne regionale Datenschutzbeauftragte. Also eigentlich sind sich zumindest auf der Seite der Aufsichtsbehörden, die auch die Gesetze durchsetzen und kontrollieren sollen, alle einig, dass Tracking nur mit Einwilligung möglich ist.

Und auch das zweite EU-Gesetz, das ich mit Tracking befasst, nämlich die ePrivacy-Richtlinie, ist eigentlich der Meinung, dass nur eine Einwilligung möglich sein kann. Also die ePrivacy-Richtlinie beschäftigt sich eigentlich nur am Rande mit Datenschutz und vor allem mit der Integrität eures Endgeräts. Aber da ist eben auch klar, wenn Zugriff auf irgendwelche Informationen eures Geräts passieren soll, wenn Informationen auf eurem Gerät gespeichert werden sollen, etwa ein Tracking-Cookie oder irgendein Tracking-Pixel, dann ist klar irgendwie, das geht nur, wenn ihr auch tatsächlich eingewilligt habt. Das heißt, da sind wir eigentlich schon auf der relativ sicheren Seite.

Bei der ePrivacy-Richtlinie ist jetzt noch das Problem, das ist halt eine Richtlinie und keine Verordnung und wer sich ein bisschen mit EU-Recht auskennt, die wird wissen, dass halt eine Richtlinie nicht so wie eine Verordnung in der ganzen EU einmal gilt, sondern eine Richtlinie muss in nationales Recht umgesetzt werden und das kann mitunter dauern und kann mitunter auch schief gehen. In Deutschland ist es zum Beispiel schiefgegangen. Da ist die ePrivacy-Richtlinie umgesetzt worden, aber unzureichend und falsch, dann gab es dagegen irgendwie ein Gerichtsverfahren und jetzt ist erst dieses Jahr das neue Telekommunikations-Telemedien-Datenschutzgesetz in Kraft getreten, das die ePrivacy-Richtlinie in ihrem vollen Umfang korrekt umsetzt. Das heißt, wenn man sich auf die ePrivacy-Richtlinie verlässt, ist es nicht immer ganz so einfach wegen der nationalen Gesetzgebung, aber grundsätzlich sind sich die Datenschutz-Grundverordnung und die ePrivacy-Richtlinie einig, Tracking ist nur mit Einwilligung möglich.

Jetzt ist natürlich die Frage, okay, nur mit Einwilligung, was heißt denn dann Einwilligung? Also wir kennen das ja alle, irgendwie Einwilligung im Internet, im World Wide Web, da müssen wir uns immer durch irgendwelche Cookie-Banner klicken oder dann ist da oben so ein Hinweis, wir informieren Sie, dass Cookies gesetzt werden, wenn Sie diese Seite benutzen, stimmen Sie dem zu.

Und die werden ganz oft auf die Datenschutz-Grundverordnung oder auf die ePrivacy-Richtlinie geschoben, irgendwie Cookie Law haben das ja auch einige Leute schon genannt und da wird dann oft behauptet, ja, die sind schuld, dass da diese Banner sind, aber da müssen wir ja eigentlich sagen, nee, das stimmt nicht. Also erstens ist die Datenschutz-Grundverordnung überhaupt nicht schuld daran, wenn Daten verarbeitet werden und man muss ja nicht tracken, also kann man das auch einfach mal weglassen, dann braucht man auch nicht nach Einwilligung fragen und zweitens sind die allermeisten Einwilligungsdialoge eigentlich nicht rechtskonform, weil wenn sie rechtskonform wären, dann sollten sie euch nicht oft angezeigt werden und leicht wegzuklicken sein, das ist aber selten der Fall.

Wir haben dazu mal einen Artikel geschrieben, falls ihr da ganz tief irgendwie eintauchen wollt, da könnt ihr den auf Bennis Webseite finden, genau, aber da gehen wir jetzt nicht alle genau durch, sondern wir schauen uns einfach mal ein paar Beispiele an, was eigentlich eine korrekte Einwilligung ist und was nicht.

Zum Beispiel ist eine Anforderung an eine Einwilligung, dass es eine eindeutige Handlung sein muss. Also, was nicht geht ist wie hier in dem Beispiel irgendwie, dass man einfach nur so swiped und irgendwo steht ja hier, wenn du weiter machst, dann dann stimmst du zu oder irgendwie so ein Button auf dem “Start Cooking” steht, da steht ja nicht “Start Tracking” und deswegen ist es irgendwie uneindeutig, was das jetzt eigentlich bedeutet.

Genauso gilt das, wenn eine Ablehnung nicht zu finden ist, also wenn es keinen Knopf gibt, um irgendwo eine Ablehnung zu machen oder die Ablehnung versteckt ist hinter mehreren Layern und das Akzeptieren gleich am Anfang ist, man darf das Ablehnen nicht schwerer machen als das Einwilligen.

Außerdem müssen die Buttons irgendwie, die die Ablehnung oder die Einwilligung ermöglichen, eindeutig sein, also es kann nicht sein, dass da irgendwie nur “OK” steht oder sowas, weil das kann alles mögliche heißen und so diese beliebten “Manage my choices” oder “Manage cookie settings” oder so, das sind auch keine zulässigen Ablehnknöpfe, sondern da muss klar hervorgehen, was passiert eigentlich, wenn ich den Knopf drücke.

Und ich darf auch nicht die Knöpfe irgendwie anders hervorheben, um Nutzer_innen dazu zu bewegen, dass sie irgendwie draufklicken, also weder farblich noch irgendwie durch Größe oder dass ich es irgendwie in die Seite verschiebe, wie hier dieser kleine Skip-Link da oben rechts.

Also solche Dark Patterns darf ich nicht einsetzen und ich darf auch nicht die Einwilligung verpflichtend machen für die Nutzung des Dienstes. Also ich darf nicht die App einfach schließen und nichts mehr anzeigen, wenn ich nicht eingewilligt habe, sondern ich muss irgendwie die Möglichkeit geben, dass ich mich frei dazu entscheide, ob ich eine Einwilligung geben will oder nicht.

Okay, also wenn eine App jetzt nur gegen ein einziges dieser Kriterien verstößt, dann können wir nicht von einer gültigen Einwilligung reden und dann ist eigentlich alle Datenverarbeitung, die auf Grundlage dieser nicht gültigen Einwilligung passiert, auch rechtswidrig. Das heißt, so Tracking erfolgt dann einfach illegal. Deswegen ist es wichtig, sich irgendwie anzugucken, wie ist das mit diesen Einwilligungsdialogen und wahrscheinlich habt ihr jetzt auch schon so ein bisschen das Gefühl, okay, ihr habt schon viele von diesen Einwilligungsdialogen durchgeklickt und die waren irgendwie alle so wie unsere Negativbeispiele, also irgendwas kann da nicht so richtig stimmen.

Das Gefühl hatten wir auch und deswegen haben wir uns das mal genauer angeguckt und Einwilligungsdialoge in Apps automatisiert überprüft. Da gibt es erstmal verschiedene technische Herangehensweisen. Im Web gibt es das sogenannte Transparency und Consent Framework. Das ist ein Framework, das sich so die Werbetreibenden in der EU gemeinsam ausgedacht haben, um Consent, den sie ja jetzt nach der Datenschutz-Grundverordnung offensichtlich abfragen müssen, miteinander teilen zu können. Also das ist im Grunde eine API, eine Programmierschnittstelle, wo die Consent Management Plattforms, also die Einwilligungsdialoge mit den einzelnen Tracking und Werbeskripten reden können und denen dann mitteilen können, wir haben hier Consent, wir haben Einwilligung erhalten.

Das funktioniert dann über so eine JavaScript Funktion, die hier _tcfapi heißt und da fällt dann so ein Objekt raus mit den ganzen Informationen, also zum Beispiel, wer jetzt hier die Einwilligung eingeholt hat, welches Consent Management System, das ist jetzt hier OneTrust zum Beispiel. Wir wissen irgendwie, okay, wird da gerade dieser Dialog angezeigt oder ist das schon durch? Wir wissen, in welchem Land befindet sich irgendwie der Publisher, also die Diensteanbieterin von der Webseite und wir haben eben hier diese Objekte, in die dann reingeschrieben wird, ob jetzt zugestimmt wurde oder nicht und das sehen wir dann im nächsten Schritt.
Wenn zugestimmt wurde, dann ändert sich hier der Status und dann stehen hier in diesen Objekten eben die Zustimmungen drin und das heißt, damit können wir jetzt relativ leicht überprüfen, wurde eine Zustimmung erteilt oder nicht.

Das ist in den Apps nicht ganz so verbreitet. Es gibt den TCF-Standard zwar auch für Apps, aber unsere Analysen zeigen, die sind nicht so häufig und auch bei den Webseiten nimmt das wieder ab, weil sich rausgestellt hat, dass obviously dieser Standard, mit dem man einfach so die Einwilligung einholen kann, nicht ausreichend ist und eben nicht den Anforderungen der Datenschutz-Grundverordnung entspricht. Da hat letztens eine belgische Behörde zu entschieden. Genau, aber wir stellen fest, okay, in Android-Apps, da ist es eigentlich nicht so verbreitet. In unserer Analyse haben wir jetzt erstmal in der groben Analyse erstmal nur 21 % irgendein Element angezeigt und dann haben von diesen Apps auch nur 3 % diese TCF-Einstellungen überhaupt gesetzt. Das heißt, wir sehen irgendwie eigentlich ist es nicht so verbreitet.

Da ist die Frage, okay, wie ist es mit anderen Consent-Management-Plattformen? Setzen die irgendwie vielleicht ihre eigene API ein? Aber da stellen wir auch fest, okay, eigentlich gibt es kaum Apps, die überhaupt eine Consent-Management-Plattform benutzen, um irgendwie ihren Consent abzufragen. Also nicht so häufig und deswegen haben wir uns auch nicht dazu entschieden, über so eine API zu gehen, sondern die Einwilligungsdialoge direkt zu parsen.

Dafür haben wir versucht, also haben wir eine Texterkennung gemacht und bekannte Phrasen oder Wörter in Regexe umgewandelt, um so Formulierungen erkennen zu können, die wir halt in Einwilligungsdialogen vermuten und dann haben wir noch eine Heuristik entwickelt, die halt für bestimmte Wörter und Phrasen Punkte vergibt, sodass wir verhindern können, dass wir zu viele False-Positives haben.

Genau, dann haben wir die Einwilligungselemente unterschieden. Das ist jetzt nicht ganz so wichtig, weil entscheidend ist vor allem, dass nur ein Dialog tatsächlich Einwilligung abfragen kann. Die anderen beiden, Link und Hinweis, das sind eigentlich nur so passive Sachen, wo man irgendwie daran erinnert wird, dass hier eine Verarbeitung stattfindet, aber wir haben ja schon klar gesagt, eine Einwilligung erfordert eigentlich eine aktive Aktion.
Und dann haben wir festgestellt, eigentlich die aller-, allermeisten Apps fragen überhaupt gar nicht. Also 80 % der Apps, die fragen überhaupt nicht nach irgendwas, die weisen auch auf irgendwie nichts hin, haben keinen Hinweis auf eine Datenschutz-Erklärung oder so, bevor man sie benutzt hat. Und dann weitere 10 %, die haben auch gar keinen aktiven Dialog, sondern die zeigen nur so einen Hinweis an oder nur einen Link und das bringt natürlich auch nichts, weil damit können sie auch keine Einwilligung einfordern. Also 90 % der Apps fragen schon mal gar nicht.

Und dann bleiben so grob 10 % übrig, die noch Dialoge haben und die haben wir uns dann auch nochmal angeguckt und festgestellt, okay, die Dark Patterns, die wir euch vorhin vorgestellt haben, die werden von über 90 % dieser Apps, die überhaupt einen Dialog anzeigen, auch noch verwendet. Das heißt, wir sehen eigentlich, durch die Bank weg wird überhaupt keine gültige Einwilligung abgefragt.

Welche Dark Patterns haben wir genau gefunden? Da haben wir hier so eine bisschen komplizierte Grafik, die ich euch jetzt nochmal kurz erkläre. Also hier links, da seht ihr sozusagen, welche einzelnen Verstöße wir jeweils aufgezeichnet haben. Also zum Beispiel, es gibt einen “Akzeptieren”-Knopf, aber keinen “Ablehnen”-Knopf. Das haben wir in 43 % der Fälle gefunden. Oder uneindeutige Beschriftungen von den jeweiligen Knöpfen. Also steht nicht “akzeptieren” oder “ablehnen” auf den Knöpfen drauf. Das haben wir ein bisschen seltener, aber doch noch sehr häufig gefunden, also fast 40 %. Dann, dass der “Akzeptieren”-Knopf farblich hervorgehoben ist, das haben wir auch noch ziemlich häufig gefunden. Und dann, dass die App stoppt, haben wir auch in ein paar Fällen gefunden, aber nicht ganz so oft. Und genau.

Und auf der rechten Seite von der Grafik seht ihr jetzt, welche Kombinationen wir jeweils gefunden haben, also welche Verstöße gemeinsam aufgetreten sind. Und wir sehen die allerschlechteste Kombination für die Nutzer_innen, nämlich dass der “Akzeptieren”-Knopf uneindeutig beschriftet ist. Also da steht irgendwie halt “Start Cooking” drauf oder sowas. Und es gibt auch keinen “Ablehnen”-Knopf, der irgendwie eindeutig zu sehen ist. Das sehen wir in 22 % der Fälle. Und das zweithäufigste ist, dass es keinen “Ablehnen”-Knopf gibt. Also die beiden schlechtesten Möglichkeiten sind auch die beiden häufigsten. Und was am dritthäufigsten ist, 14 %, dass irgendwie der “Akzeptieren”-Knopf hervorgehoben ist und dass irgendwie die Beschriftung von dem “Ablehnen”-Knopf irgendwie uneindeutig ist, also irgendwie sowas wie “Skip” oder so. Also ihr merkt schon, irgendwie euer Gefühl hat euch nicht getrügt. Die Daten geben genau das Gleiche her. Die meisten Apps, die wollen einen eigentlich hier nur reinlegen.

Und das wollen wir nicht mit uns machen lassen. Und deswegen machen wir Gebrauch von unserem Recht auf Beschwerde. Das gibt uns nämlich die Datenschutz-Grundverordnung auch, die Möglichkeit, uns bei der Aufsichtsbehörde zu melden und zu sagen, Moment mal, irgendwie, ich bin mir relativ sicher, dass da eine Verarbeitung stattgefunden hat, mit der bin ich nicht einverstanden und ich glaube auch, die verstößt gegen geltendes Recht. Dann kann ich mich kostenlos an die Aufsichtsbehörde wenden und sagen, ey, das geht so nicht klar. Und die müssen dann auch dann nachgucken und irgendwie überprüfen, okay, stimmt das? Die können ihre eigenen Analysen machen. Die können sich irgendwie auch die Server von den Tracking-Unternehmen nochmal genauer angucken. Und dann können sie eben bestimmte Verarbeitungen verbieten und Bußgelder verhängen und zwar auch nicht zu knapp, sondern 5 % des Umsatzes ist das maximale Bußgeld. Und das tut dann so einem Tracking-Unternehmen, glaube ich, schon ziemlich weh, wenn so ein Bußgeld verhängt wird. Also das ist eigentlich ein sehr mächtiges Recht.

Da muss man natürlich noch dazu sagen, so richtig in Gang kommt das nicht. Also die Aufsichtsbehörden sind heillos überlastet, weil klar, wir haben irgendwie festgestellt, eigentlich fast alles Tracking läuft illegal ab und die Aufsichtsbehörden kommen nicht hinterher, das tatsächlich zu überprüfen. Aber von alleine machen sie eben auch nichts und mit dem Recht auf Beschwerde können wir die Aufsichtsbehörden eben dazu zwingen, handeln zu müssen.

Das ist allerdings sehr aufwendig und man braucht einen sehr langen Atem, weil ja, dass sich eben lange, lange, lange nichts tun kann. Mehrere Jahre können solche Beschwerden dauern. Wir haben da mal einen Workshop zugemacht dieses Jahr beim Bits & Bäume, wo wir so ein bisschen das angerissen haben, wie kann das so funktionieren, wie geht man so eine Beschwerde grob an? Wenn euch das interessiert, dann könnt ihr euch da auch nochmal die Folien zu angucken und wir haben auch mal eine Beschwerde veröffentlicht, die eines unserer Mitglieder gegen Otto geführt hat, gegen Tracking in der Otto-App, wo das auch nochmal alles so haarklein und detailliert irgendwie aufgeführt ist, welche Verstöße wir aufgezeichnet haben, welche Analysen wir gemacht haben und eben eine genaue rechtliche Beweisführung gemacht haben gegen das Trackingverhalten von der Otto-App. Also wenn euch das interessiert, schaut euch das an, aber wir müssen sagen, also insgesamt ist es ein sehr aufwendiger Prozess, sehr langer Prozess und eben auch nichts, was man von den meisten Leuten erwarten kann.

Das wollen wir ändern. Unser nächstes Projekt ist es, diese Beschwerden zu automatisieren und gegen Tracking halt aktiv vorzugehen, indem wir das Ganze auf wenige Klicks runterbrechen. Als ersten Schritt werden wir jetzt demnächst den Forschungscode, wo wir euch jetzt die Ergebnisse vorgestellt haben, gut dokumentieren und dann kleinere Tools und Bibliotheken umbauen, sodass ihr das dann auch zu Hause machen könnt und eben zumindest der Teil von der Traffic-Analyse nicht mehr so kompliziert ist, sondern ihr einfach nur die App in das Tool schmeißt und am Ende kommt für euch eben ein Haufen Beweise raus, dass die App hier rechtswidrig vorgegangen ist.

Also wenn euch das interessiert, wenn ihr da irgendwie weiter mitmachen wollt und wenn ihr genauso wie wir am Ball bleiben wollt und gegen Tracking vorgehen möchtet, dann bleibt in Kontakt mit uns. Wir sind sehr aktiv auf Mastodon und posten immer mal wieder, wenn sich Sachen verändern oder wenn wir was Neues zu erzählen haben, da werden wir euch auch erzählen, wenn wir unser neues Projekt veröffentlichen und auch in unserem Blog, da gibt es immer mal wieder längere Artikel und Analysen. Also schaut da sehr gerne mal vorbei, meldet euch bei uns und wenn ihr richtig Bock habt, macht gerne auch mit.

Ansonsten war es das, vielen Dank, dass ihr zugehört habt, wir freuen uns auf eure Fragen und wenn ihr noch mal was nachlesen wollt, dann findet ihr die Folien auf unserer Webseite.

E: Ja, vielen Dank, Benni, Malte und Lorenz für den spannenden Vortrag. Wir kommen zu den Fragen. Hier nochmal der Hinweis, ihr könnt eure Fragen wie folgt loswerden: Unter dem Hashtag #FireShonks auf Mastodon und Twitter, IRC auf hackint.org mit fireshonks22 sowie in den Chats von YouTube und Twitch.

Es gab Fragen und zwar zu den Einwilligungsdialogen. Wie könnte mensch die Analyse der Einwilligungsdialoge machen?

B: Hmhm. Das muss man ganz stark unterscheiden zwischen dem Web und auf mobilen Systemen. Im Web hatte Lorenz ja schon erzählt, da gibt es dieses TCF-Framework, das gibt einem schon relativ viele Daten in einem maschinenlösbaren Format, an die man gut rankommen kann und ansonsten ist es da auch üblich, dass die Webseiten bestimmte Consent-Management-Plattformen nutzen. Das sind irgendwelche fertigen Systeme, die standardisiert sind und für die man dann auch wieder spezifische Adapter schreiben kann. Das hat zum Beispiel noyb, eine andere Organisation, die auch ganz viel auf dem Bereich macht, die haben eine Massenbeschwerde gegen solche Cookie-Banner im Web gemacht und die haben sich daran rangehangelt, dass sie die Consent-Management-Plattformen, konkret OneTrust, in dem Fall sich anguckt haben und da spezielle Skripte für geschrieben haben, die konkret mit diesen Einwilligungsdialogen von OneTrust umgehen können.

Mobil ist das leider deutlich schwieriger. Zum einen ist wie gesagt das TCF da nicht annähernd so verbreitet und auch Consent-Management-Plattformen haben wir zumindest deutlich weniger gefunden. Deshalb war mein Ansatz jetzt ein eigentlich relativ primitiver, aber doch gut funktionierender, dass wir uns nämlich angeguckt haben, was steht in diesen Einwilligungsdialogen üblicherweise drin, welche Elemente gibt es da drin üblicherweise und wie kann ich die erkennen. Das haben wir in dem Fall gemacht mit Appium, das ist ein Framework, das eigentlich dafür gedacht ist, dass man Apps automatisiert testen kann, wenn man Entwickler_in ist. Und das kann mir eben, so ähnlich wie im Web, eine DOM-ähnliche Struktur der App geben, was sehr praktisch ist, weil ich dann eine einigermaßen gut automatisierte Analyse des Ganzen machen kann. Man muss aber auch sagen, die ist nicht annähernd so gut und annähernd so flexibel wie der DOM. Zum Beispiel sind ganz viele Sachen in Spielen beispielsweise, dass der Text nicht als Text da drin gerendert wird, sondern quasi wie ein Bild gerendert wird, den ich dann nicht automatisiert auslesen kann oder viele Attribute werden darüber auch nicht angezeigt. Ich kann zum Beispiel nicht erkennen, was ein Link ist und schon gar nicht, auf welche URL dieser Link führt. Das heißt, da muss man dann eine ganze Reihe von Heuristiken einführen, um zu versuchen, False-Positives zu vermeiden.

Das ist jetzt leider noch nichts, was ich euch sagen könnte, das ist eine fertige Lösung, die wir euch geben können, die ihr auch selber ausführen könnt. Ich habe den Code dafür zwar veröffentlicht, aber das ist noch so Forschungscode, der so mäßig gut ist. Da werden Lorenz und ich in nächster Zeit jetzt aber daran arbeiten, da schöne Libraries daraus zu machen, sodass ihr den hoffentlich auch verwenden könntet.

E: Es geht auch hier nochmal um die technisch notwendigen Cookies. Was kann ich von so einer Phrase halten?

B: Ja, technisch notwendig? Ich würde sagen, das hat zwei Dimensionen, eine rechtliche und eine technische. Wenn in einem Einwilligungsdialog nach technisch notwendigen Cookies gefragt wird, dann bin ich da einmal ziemlich stutzig. Denn dafür braucht es eigentlich gar keine Einwilligung. Das kann man nach der DSGVO eigentlich problemlos unter das berechtigte Interesse stellen. Und dann gibt es nicht wirklich eine Notwendigkeit, danach zu fragen. Und technisch kann man da nur raten, was die Webseiten oder die Apps damit machen. Wenn sie wirklich technisch notwendig sind, dann ist das ja eigentlich nichts, was ich ausschalten kann, sonst würde die Webseite kaputt gehen, würde ich sagen.

M: Das Spannende bei diesen Dialogen ist ja auch, so ein bisschen ein Exkurs mal in die Security, Kollegen von mir haben rausgefunden, wenn ich irgendwie auf “akzeptieren” drücke in so einem Dialog, dann ziehe ich mir auch direkt irgendwie Code mit in die Webseite, der irgendwie auch Schwachstellen auslösen kann. Das heißt, es macht nicht nur aus Datenschutz Sinn, irgendwie eher auf “ablehnen” drücken zu wollen, sondern auch so aus einer Sicherheitsperspektive.

E: Ja. Eine vielleicht eher gesellschaftspolitische Frage. Welche technischen Lösungen des individualisierten Datenschutzes existieren und welche Probleme ergeben sich dann auch daraus, eben weil die nur individualisiert sind?

L: Ja, also ich habe ja schon so ein paar von diesen Lösungen vorgestellt. Also so ganz beliebt sind halt so DNS-Blocker oder generell irgendwelche Blocker, die so in den Netzwerkverkehr eingreifen und halt die Übertragung von den Daten zu den Tracking-Servern irgendwie blockieren. Dann gibt es im Web eben auch die Möglichkeit, die Skripte, also das Ausführen von den Tracking-Skripten irgendwie zu blockieren. Da gibt es auch so die ein oder andere Lösung für Android. Aber bei einem Android-Beispiel sieht man das vielleicht schon ganz gut. Da muss irgendwie das Handy für gerootet sein oder man braucht sogar noch ein Custom-ROM, das man da drauf irgendwie installiert hat, also irgendwie LineageOS oder so, gar nicht Android. Und irgendwie, also es ist so ein sehr hoher technischer Aufwand, einen Pi-hole aufzusetzen.

Manche Leute sagen vielleicht, ja, das ist irgendwie so eine Sache, das macht man in zwei Stunden und gut ist, weil einen Raspberry Pi habe ich eh rumliegen. Aber das gilt eben für die allerwenigsten Leute und Datenschutz ist ein Grundrecht und steht in der europäischen Menschenrechte-Charta nicht ohne Grund. Und ich finde es einfach total krass, dass der einzige Weg, sich dagegen zu wehren oder zumindest der einzige, der einem erstmal so einfällt, halt ist, dass man irgendwie so eine, ja halt irgendwelche Programme laufen lässt oder halt basically riesen Aufwand für IT-Security betreiben muss, weil das schützt einen am Ende eben nur selbst oder vielleicht halt noch die Leute im direkten Umfeld.

Und viele Leute können das nicht, viele Leute haben auch kein Geld dafür, so die Raspberry Pi sind so teuer im Moment, die kann man sich gar nicht leisten. Und also es gibt so verschiedene irgendwie Marginalisierungs-Kategorien, die auch doch dazu führen, dass es dann eben Leute noch viel stärker betrifft. Und ich würde auch sagen, das ist nicht völlig unabsichtlich so, also es ist halt so ein Prozess im Kapitalismus, das halt so wie an vielen anderen Orten auch, keine Ahnung, gesunde Ernährung oder sowas ist auch total teuer und können sich dann viele Leute wiederum nicht leisten und erfordert irgendwie auch eine gewisse Wissensbasis oder so, um sich damit beschäftigen zu können und Zeit auch, um irgendwie zu kochen.

Und genauso ist es eben beim individualisierten Datenschutz. Und deswegen finden wir eigentlich der einzige Weg, dagegen vorzugehen, ist halt diese Geschäftsmodelle anzugreifen und eben mit den aktuell rechtlichen Möglichkeiten, die wir haben, dagegen vorzugehen, aber das heißt natürlich auch nicht nur rechtlich dagegen vorzugehen, sondern sich auch irgendwie zu verknüpfen dazu und im Zweifel auf die Straße zu gehen, wenn diese Rechte irgendwie wieder in Gefahr sind. Genau.

E: Ja. Eine interessante Frage noch, die Hersteller von Apps betreffend. Wir haben ja jetzt die DSGVO, die setzt ja hohe Maßstäbe und hat das irgendeinen Einfluss darauf, wie Hersteller das Tracking-Verhalten ihrer Apps einstellen oder seht ihr das eher nicht so?

M: Also wir selbst haben jetzt keine Daten zu der Phase vor der DSGVO. Wir haben uns ja gewissermaßen zu DSGVO gegründet als Verein, aber die Kollegen von noyb, die haben sich das mal angeschaut im Internet und zwar haben die einmal, ich glaube, 2021 und ich glaube April diesen Jahres, sich mal so Dialoge angeschaut im Internet und da haben die festgestellt, dass es tatsächlich eine Verbesserung gibt, also dass es weniger Dark Patterns gibt und weniger Verstöße in diesen Dialogen. Also wenn man das übertragen kann auf Apps oder generell, scheint sich da doch ein bisschen was positiv abzuzeichnen.

B: Die Verbesserung da rührt aber dann vor allem daher, dass noyb da eben diese Beschwerdewelle, die ich eben auch schon erwähnt hatte, gestartet hatte. Und der Effekt, den sie beobachtet haben, war zum einen, dass das Beschweren und die rechtlichen Mittel, die damit aus der DSGVO kommen, funktionieren auf der rechtlichen Ebene, aber vor allem auch auf einer Einschüchterungsebene, dass man dieses Mittel hat, mit dem man gegen Entwickler_innen vorgehen kann und gegen Tracking vorgehen kann und dass sich das dann auch unter anderen Entwickler_innen, die nicht explizit eine Beschwerde von denen bekommen haben, sich das rumgesprochen hat und auch da zu Verbesserungen geführt hat. Also da zumindest ein indirekter Effekt durch die DSGVO.

E: Hmhm. Noch eine Frage, Apps betreffend, die halt ihre komplette Dienstleistung nur über ihre App anbieten. Ja.

B: Ich weiß, dass es bei den Webseiten, die solche PUR-Modelle, wo es dann die Option gibt, möchte ich Tracking haben und dafür die Webseite kostenlos nutzen oder möchte ich dafür bezahlen? Da geht die Überlegung in eine ähnliche Richtung. Da ist rechtlich die Position aktuell von den Aufsichtsbehörden noch überhaupt nicht klar ausgeprägt. Ich glaube, die sind sich da selber auch noch nicht so 100-prozentig sicher, was sie davon halten sollen. Ich habe teilweise die Argumentation gelesen von den Webseiten, die sagen, die Freiwilligkeit ist davon nicht betroffen, weil du musst ja nicht meine Webseite nutzen. Es gibt auch andere Webseiten, die ein sehr ähnliches Angebot haben, die kannst du alternativ nutzen. Da zumindest habe ich von den Aufsichtsbehörden Ansätze gesehen, dass sie sich dagegen wehren und dem nicht zustimmen.

E: Hmhm. Ja. Soweit ich das sehen kann, war es das nun auch mit den Fragen. Ihr habt das ja nun auch alles sehr ausführlich behandelt.

Ja, vielen Dank nochmal an Benni, Lorenz und Malte und auch an all diejenigen, die diesen Talk hinter den Kulissen ermöglicht haben.

Abspannmusik