➡ Wirf einen Blick in die Empfehlungsecke
Mike Kuketz
3. März 2021

Wie Tracking in Apps die Sicherheit und den Datenschutz unnötig gefährdet

1. Vermeidbare RisikenTracking in Apps

Ursprünglich war User-Tracking dazu gedacht, Webseitenbetreibern zu ermöglichen, die Aktionen eines Besuchers zu analysieren, um daraus Erkenntnisse zu gewinnen, wie die Webseite (weiter) optimiert/verbessert werden kann. Dieser Trend hat vor Smartphone-Apps bzw. Software generell keinen Halt gemacht – im Gegenteil. Um das Nutzungsverhalten bestmöglich zu analysieren bzw. interessenbezogene Werbung einzublenden, sind die meisten Apps vollgestopft mit Analytik- und/oder Werbe-Modulen (Tracking-Bibliotheken) von Drittanbietern, die eine lückenlose Aufzeichnung ermöglichen.

Grundsätzlich ist am Wunsch, die App stetig verbessern zu wollen, ja nichts auszusetzen. Durch die Einbindung externer Tracking-Bibliotheken in Apps gehen Entwickler bzw. Verantwortliche allerdings eine Vertrauensbeziehung ein, ohne sich womöglich mit den daraus resultierenden Risiken für die Sicherheit und den Datenschutz ausreichend auseinandergesetzt zu haben. Die Verbesserung/Optimierung des »Nutzererlebnisses« hat vielfach einen höheren Stellenwert als der Schutz des Nutzers bzw. seiner Daten. Insbesondere bei Apps aus dem Bereich Gesundheit, Finanzen, Sicherheit bzw. generell solchen, die sensible Daten verarbeiten, sendet die Integration von Tracking-Bibliotheken ein falsches Signal.

Es stellt sich also die Frage, weshalb dieser Trend von App-Entwicklern bzw. Verantwortlichen so vehement verteidigt wird, anstatt sich ehrlich zu machen und somit eine offene Diskussion über diese Thematik zu ermöglichen bzw. einen Ausweg aus dem Dilemma zu erarbeiten. Das sture Festhalten am Einbau externer Tracking-Bibliotheken erweckt zunehmend den Eindruck, dass Kommerzialisierung Vorrang vor Sicherheit und Datenschutz hat.

2. Tracking: Unterschiedliche Ziele

Von Tracking spricht man, wenn das Verhalten von Nutzern beobachtet und analysiert wird. (User-)Tracking verfolgt dabei ganz unterschiedliche Ziele. Grob lässt sich Tracking in drei Kategorien einteilen:

  • Technische Dienste (Analyse, Telemetrie, Absturzberichte): Mithilfe von Analyse- und Telemetriedaten erhoffen sich Entwickler/Designer etc. Auskunft darüber, wie ein Anwender eine App benutzt. Dadurch verspricht man sich Antworten auf Fragen wie: Welche Funktionen werden häufig genutzt? Wie lange verweilt der Anwender in einer App-View? Wie kann die App bzw. Usability weiter verbessert werden? Ergänzt wird diese Datensammlung dann meist von Absturzberichten, die Entwickler helfen sollen, ein Problem bzw. Bug zu beheben.
  • Werbung/Marketing: Bei diesen Trackern steht die Erhebung vermarktbarer Erkenntnisse an erster Stelle. Auf Basis dieser Erkenntnisse werden dem Nutzer anschließend perso­nali­sierte bzw. interessenbezogene Werbung in den Kontext einer App eingeblendet, um bspw. das Konsumverhalten zu beeinflussen. Über die Dauer entstehen aus den erhobenen Informationen Profile, die auf Interessen, Kaufkraft oder persönliche Vorlieben von Nutzern schließen lassen.
  • Betrugserkennung/Prävention: Betrügerische Bestellungen sind ein Ärgernis für jeden Händler. Bei der Vermeidung können Anbieter helfen, die bspw. Informationen wie die verwendete Kreditkarte oder IP-Adresse auswerten, die zur Bestellung genutzt wurde. Kurzum: Die Erkennung und Prävention macht die Übermittlung diverser Informationen erforderlich, die im App-Kontext vom Nutzer eingegeben werden oder als Meta-Daten anfallen.

Unabhängig von den unterschiedlichen Zielen haben alle Varianten im Kern eine Gemeinsamkeit: Es werden Daten erhoben und verarbeitet. Meist geschieht dieses Tracking durch die Einbindung fremder Tracking-Bibliotheken bzw. Module, die Entwickler in ihre Apps integrieren. Ebenjene Integration kann sich nachteilig auf die Sicherheit und den Datenschutz eines Anwenders bzw. seiner Daten auswirken.

3. Sicherheitsrisiko: Fremde Bibliotheken/SDKs

Niemand muss das Rad ständig neu erfinden, sondern bestehendes Wissen kann einfach genutzt bzw. weitergegeben werden. Dieses Prinzip machen sich Programmierer zunutze, wenn sie Bibliotheken/Software Development Kits (SDK) in ihren Quellcode integrieren. Eine (Programm-)Bibliothek ist eine Art Hilfsmodul, das den Funktionsumfang eines Programms erweitert, aber alleine nicht lauffähig ist. Möchte ein Entwickler seinen Messenger bspw. um die Möglichkeit der Echtzeitkommunikation über Video- bzw. Sprachanrufe erweitern, kann er dazu die WebRTC-Bibliothek in seinen Quellcode integrieren. Beliebt ist ebenfalls der Einbau bestehender Krypto-Bibliotheken wie dem Signal-Protokoll, das eine sichere Ende-zu-Ende-verschlüsselte Kommunikation zwischen einem oder mehreren Teilnehmern ermöglicht.

Zusammengefasst: Bibliotheken/SDKs ermöglichen den bestehenden Funktionsumfang einer App (Synonym für Anwendung) zu erweitern – ohne sich erneut mit der Problemstellung befassen zu müssen.

Unterstütze den Blog mit einem Dauerauftrag!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

3.1 Vertrauensbeziehung

Die Qualität von fremdem Code bzw. Bibliotheken/SDKs sind ganz unterschiedlicher Natur. Grob geschätzt produziert ein Entwickler auf 1000 Codezeilen zwischen 0,5 und 3 Programmierfehler. Viele der in den teilweise Millionen Zeilen Code enthaltenen Fehler werden jedoch nie entdeckt oder wirken sich nicht negativ auf die Sicherheit bzw. Funktion aus. Manche Fehler erzeugen jedoch schwerwiegende Sicherheitslücken, ohne jedoch direkt die Funktion der Software zu beeinträchtigen. Je nach verwendeter Programmiersprache, Fähigkeit, Umsicht und Qualitätssicherung der Entwickler, schlummern in Bibliotheken/SDKs also Risiken, die sich nachteilig auf die Sicherheit der eigenen App auswirken kann.

Wenn ich also anfange Fremdcode bzw. Bibliotheken/SDKs von Dritten in meine App zu integrieren, dann gehe ich als Entwickler unweigerlich eine Vertrauensbeziehung ein. Der bereitgestellte (proprietäre) Code wird meist nicht geprüft, sondern eben für einen bestimmten Zweck in die App integriert. Mit jeder Funktionalitätserweiterung bzw. integrierten Bibliothek/SDK wächst gleichzeitig jedoch die Komplexität und damit das Risiko für mögliche Sicherheitslücken der eigenen App an. Nach dem in der IT-Sicherheit geltenden Prinzip »Keep it small and simple/Keep it simple, stupid!« (KISS) ist es daher sinnvoll die Komplexität möglichst überschaubar zu halten. Das bedeutet: Alles Unnötige wird weggelassen.

Mit der Integration von Fremdcode bzw. Bibliotheken/SDKs gehen Entwickler eine Vertrauensbeziehung ein:

Tracking-Bibliothek

3.2 Tracker-Bibliotheken

Nun kann man sich aus Entwicklersicht trefflich darüber streiten, ob der Einbau von Tracking-Bibliotheken/-SDKs unnötig ist oder für den Funktionsumfang bzw. die »Verbesserung des Nutzererlebnisses« unbedingt erforderlich ist. Fakt ist: Mit jedem Einbau von Fremdcode bzw. externen Tracker-Bibliotheken/-SDKs steigt die Komplexität der App. Damit geht nicht nur ein Risiko für die Sicherheit einher, sondern zwangsläufig auch eine nicht zu beherrschende Intransparenz der Datenverarbeitung. Als App-Entwickler muss ich dem Anbieter der Tracker-Bibliotheken/-SDKs also vertrauen. Welche Daten diese Module allerdings sammeln und an die Drittanbieter übermitteln, das wissen teilweise nicht einmal die App-Entwickler selbst, die diese Module in ihre Apps integrieren.

Es gibt einige prominente App-Beispiele, die User-Tracking bzw. der grafischen Aufbereitung der erhobenen Daten in Form von Kuchendiagrammen für interne Auswertungszwecke einen höheren Stellenwert beimessen, als dem Schutz des Nutzers bzw. seiner Daten. Aus nicht nachvollziehbaren Gründen wird unbeirrt an der Integration von (proprietären) Tracker-Bibliotheken festgehalten und dieses Vorgehen auch noch vehement verteidigt.

Die LastPass-App für Android integriert bspw. sieben Tracker – für eine App, die sensible Informationen (Passwörter usw.) verarbeitet sind das genau sieben Tracker zu viel. Als Reaktion auf meinen Beitrag »LastPass Android: Drittanbieter überwachen jeden Schritt« hat LastPass in einem Blog-Beitrag zu diesem Vorgehen Stellung bezogen. Zitat:

Q. Does LastPass use analytics?

A. Yes. LastPass uses industry-standard analytics to collect limited and high-level user analytics data designed to help us to better understand product trends, usage and aggregate patterns. It is important to note that, due to LastPass’ zero-knowledge security model, tracking technologies and providers utilized within LastPass do not have access to decrypted sensitive vault contents like passwords and secure notes.

Anstatt die Karten offen auf den Tisch zu legen, dass mit der Integration von externen Tracker-Bibliotheken ein unnötiges Risiko für die Sicherheit und den Datenschutz einhergeht, wird der Nutzer mit Floskeln und Bullshit-Bingo abgespeist. Letztendlich ist es genau jener »Industrie-Standard« bzw. Kommunikationsstil, den ich infrage stelle.

Abgesehen von der generellen Verwendung von Tracking-Bibliotheken im sensiblen App-Kontext muss auch die Frage beantwortet werden, wie viele Tracker eigentlich notwendig sind, um das Produkt bzw. die App zu verbessern. Sind dazu tatsächlich sieben Tracker notwendig, wie es bei der LastPass-Android-App der Fall ist?

4. Datenschutz: Die Mär von pseudonymisierten/anonymisierten Daten

Die Integration von Trackern kann sich allerdings nicht nur nachteilig auf die Sicherheit, sondern insbesondere auf die Privatsphäre bzw. den Datenschutz des Nutzers auswirken. Die DSGVO beschreibt in Art. 25 die Einhaltung des Datenschutzes durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen – kurz: Privacy by Design. Dahinter steckt der Gedanke, dass der Datenschutz bei Datenverarbeitungsvorgängen am besten eingehalten wird, wenn er bei deren Erarbeitung bereits technisch berücksichtigt wird. Daraus könnte man auch ableiten: Der Einbau von Tracking-Bibliotheken schlägt genau die entgegengesetzte Richtung ein. Getreu dem Mantra:

Ist doch ein Industrie-Standard!

werden Nutzer auf Schritt und Tritt verfolgt, um Erkenntnisse über das Nutzungsverhalten zu erlangen. Die DSGVO bleibt dabei meist auf der Strecke.

4.1 Personenbezogene Daten

Unter dem Begriff personenbezogene Daten versteht man alle Daten (Art. 4 Nr. 1 DSGVO), die eindeutig einer bestimmten natürlichen Person zugeordnet werden können. Beispiele:

  • Max Mustermann hat die Augenfarbe blau
  • Erika Musterfrau hat die E-Mail-Adresse erika-musterfrau@mailbox.org
  • Heribert Heinrich ist in Hintertupfingen geboren

Tracking-Bibliotheken übermitteln regelmäßig personenbezogene Daten direkt an die Hersteller der Analyse-Tools – meist ohne um Erlaubnis zu fragen:

Und selbst wenn ein direkter Personenbezug auf den ersten Blick nicht herstellbar ist, so beinhalten die Datenübermittlungen meist genügend Identifier (IMEI, MAC-Adresse, Seriennummer Gerät etc.) und Meta-Daten, die genau dies ermöglichen. Denn durch die Korrelation mit anderen Datenbeständen lässt sich häufig ein Personenbezug mittelbar herstellen (personenbeziehbare Daten), wie etliche Beispiele belegen:

  • 2012: Big Brother Award (2012) für IMS Health für »Die vollständige Analyse und Vermarktung des gläsernen Patienten«. Begründung der Jury:

    Da es sich um Daten wie Geschlecht, Geburtsjahr, Krankenscheinart, Diagnose, Medikamente, Dosierung, Therapie oder Laborwerte handelt, die »anonymisiert« an IMS Health geliefert werden, lassen sich allein damit Rückschlüsse auf einzelne Personen ziehen.

  • 2013: Die Studie »Re-Identifies Anonymous Volunteers In DNA Study« zeigt, dass sich allein aus der Kombination aus Geschlecht, Geburtsdatum und der Postleitzahl zwischen 84 und 97% der Teilnehmer eines DNA-Projekts identifizieren lassen.
  • 2013: In der Studie »Riding with the Stars: Passenger Privacy in the NYC Taxicab Dataset« zeigt ein Master- Student, wie Personen anhand der Taxinummer, Koordinaten von Anfangs- und Endpunkt, Datum, Uhrzeit und Preis der Fahrt, unter Verwendung von Zusatzinformationen aus Presse oder Facebook, deanonymisiert werden können.
  • 2016: Der vom NDR aufgedeckte Datenskandal »Nackt im Netz« demonstriert, wie Millionen von Internet-Nutzern, darunter Manager, Richter und Journalisten, im Netz ausgespäht wurden. Das Browser-Addon WOT (Web of Trust) hat die gesammelten Surf-Daten nicht ausreichend anonymisiert und dennoch weiterverkauft.

Wie schwierig es ist Daten korrekt zu anonymisieren, zeigt unter anderem der EU-Bericht »Opinion 05/2014 on Anonymisation Techniques«. Darin wird auch deutlich herausgestellt, dass Pseudonymisierung ungleich Anonymisierung ist. Das bedeutet: Selbst wenn jemand beteuert, er würde personenbeziehbare Daten vor der Speicherung bzw. Weitergabe ausreichend »anonymisieren«, so sieht die Realität oftmals wohl ganz anders aus.

4.2 Personenbezug herstellbar

Wie einfach es ist über einen Identifier wie die Google-Advertising-ID einen Personenbezug herzustellen, möchte ich anhand eines realen Beispiels zeigen. Die Google-Advertising-ID ist eine eindeutige ID für Werbezwecke, die von den Google-Play-Diensten bereitgestellt wird. Für den Zugriff benötigen Apps lediglich die Berechtigung »Zugriff auf alle Netzwerke« – welche fast alle Apps anfordern.

Hinweis

Die Google-Advertising-ID kann über Einstellungen -> Google -> Werbung -> Werbe-ID zurückgesetzt werden.

Eben jene Advertising-ID wird vom Facebook-SDK ausgelesen, die ca. in einem Drittel aller Android-Apps integriert ist. Sobald man eine App startet, erfährt Facebook, welche Apps ein Nutzer verwendet und wann. Der Nutzer selbst erfährt davon nichts. Er wird nicht gefragt und er kann dieses Verhalten meist auch nicht deaktivieren. Am Beispiel der Menstruations-App Clue möchte ich das kurz erläutern.

Unmittelbar nach dem Start der Clue-App wird Facebook kontaktiert. Unter anderem werden folgende Informationen übermittelt [graph.facebook.com]:

  • Google-Advertising-ID: advertiser_id = c3639f11-626a-4692-9574-6a0f632e1ea3
  • Ob Ad-Tracking aktiviert/erlaubt ist: advertiser_tracking_enabled = true
  • Ein Identifier: anon_id = XZce953baa-18a8-42e0-82ad-2d1b3866fe63
  • Ob das App-Tracking aktiviert/erlaubt ist: application_tracking_enabled = true
  • Weitere Informationen:
    • Paketname der App: com.clue.android
    • Versionsnummer der App: 6.0
    • Android-Versionsnummer: 10
    • Gerätemodell: Mi A1
    • Länderkennung: de_DE
    • Zeitzone: MESZ, Europe/Berlin
    • Displayauflösung: 1080×1920

Die Übermittlung der Google-Advertising-ID genügt im Grunde genommen, dass Facebook nun eine Verknüpfung zwischen Facebook-Nutzerin und den übermittelten Daten herstellen kann. Der Grund: Auch die Facebook-App (sofern installiert) liest die Google-Advertising-ID aus. Damit hat Facebook anschließend einen Identifier, den sie einer Person exakt zuordnen können.

Mit dem Server »graph.facebook.com« kommuniziert die App im Verlauf der App-Nutzung übrigens regelmäßig – auch wenn man überhaupt kein Facebook-Konto hat. Facebook erfährt also unter anderem, in welcher View (Ansicht in der App) sich die Nutzerin gerade befindet.

Anbei eine grafische Darstellung, wie Facebook anhand der Google-Advertising-ID einen Personenbezug herstellen kann:

Facebook Tracking

Nach der Installation der Facebook-App wird die Google-Advertising-ID vom Gerät ausgelesen und an Facebook übermittelt [1]. Facebook verknüpft die Google-Advertising-ID anschließend mit der Person [2] und 98 Datenpunkten (Stand 2016) wie Alter, Geschlecht, Wohnort, Arbeitgeber etc. Aufgrund der Integration des Facebook-SDKs in die Clue-App wird die Google-Advertising-ID erneut an Facebook übermittelt [3] – unmittelbar nach dem Start der App, ohne Nutzereinwirkung. Auf den Servern von Facebook passiert nun Folgendes: Die Google-Advertising-ID wird mit dem Datenbestand abgeglichen. Im Falle eines Hits (Treffers) [4] kann Facebook nun einen Personenbezug herstellen und die neu gewonnenen Daten aus der Clue-App mit dem bestehenden Facebook-Profil verknüpfen [5].

Facebook bzw. das Facebook-SDK ist hier keine Ausnahme. Aus Erfahrung kann ich sagen: Nahezu alle Tracking-Bibliotheken übermitteln solche Identifier, die es grundsätzlich ermöglichen, einen Personenbezug herzustellen. Niemand kann letztendlich sagen, auf welchem Datenschatz Analyse-Unternehmen wie Adjust, AppsFlyer, Mixpanel und Co. sitzen. Mobilsicher.de hat eine stattliche Liste an solcher Drittanbieter zusammengestellt, die in Apps integriert werden.

Fazit: Die Behauptung, über Identifier bzw. Meta-Daten sei kein Personenbezug herstellbar bzw. es handele sich dabei »lediglich« um pseudonymisierte/anonymisierte Daten, ist schlichtweg unehrlich.

4.3 Informierte, freiwillige, aktive und vorherige Einwilligung: Fehlanzeige

Bei Webseiten gilt: Vor der Einbindung Elemente Dritter, wie zum Beispiel Tools zur Reichweitenmessung oder Social-Media-Plugins, muss der Webseitenbetreiber vom Besucher (Betroffener) eine Einwilligung in die konkrete Datenverarbeitung einholen. Eine solche Einwilligung muss ausdrücklich, informiert, freiwillig, aktiv und vor der eigentlichen Übermittlung der Daten erfolgen.

Ebendiese Anforderung gilt ebenso für Apps auf dem Smartphone oder Software auf dem Desktop-Rechner. Es ist ein offenes Geheimnis, dass sich Webseitenbetreiber und auch App-Entwickler damit äußerst schwertun und nur eine verschwindend geringe Minderheit diese Anforderungen tatsächlich auch zufriedenstellend erfüllt.

Abgesehen von den rechtlichen Anforderungen ist die Integration von Tracking-Bibliotheken und der damit einhergehenden, ungefragten Übermittlung von Daten an Analyse-Unternehmen noch etwas anderes: Respektlos gegenüber dem Nutzer. Auch die nachträgliche Möglichkeit, ein Opt-Out aus dem Tracking vornehmen zu können, ist nur eine kleine Wiedergutmachung. Bis zu diesem Zeitpunkt sind oftmals schon (personenbeziehbare) Daten an Analyse-Unternehmen abgeflossen.

Bei vielen App-Entwicklern bzw. Verantwortlichen fehlt offenbar schlichtweg das Bewusstsein bzw. die Kenntnis über die rechtlichen Anforderungen. Dieser Umstand spiegelt sich dann meist in der Datenschutzerklärung wider, in der das User-Tracking entweder unvollständig oder gar nicht erwähnt wird. Getreu dem Motto:

Was Hänschen nicht weiß, macht ihn nicht heiß

wird der Nutzer einfach ungeniert getrackt. Das jüngste Beispiel für dieses Vorgehen ist die LastPass-App mit ihren sieben Trackern, zu denen in der dazugehörigen Datenschutzerklärung jeglicher Hinweis fehlt. Ist es Unkenntnis, ist es Unvermögen oder schlichtweg Ignoranz und Skrupellosigkeit so zu handeln?

5. Apps, die sensible Daten verarbeiten

Die Integration von proprietärem und intransparentem Fremdcode in Form von Tracking-Bibliotheken ist nicht gerade ein Indiz dafür, dass Sicherheit und der Datenschutz einen hohen Stellenwert einnehmen. Und dennoch binden Entwickler massenhaft Analyse- bzw. Tracking-Module in ihre App ein – gerade dann, wenn sensible Daten verarbeitet werden, ist das schlichtweg ein NoGo.

Im Android-Universum lässt sich mithilfe von Exodus Privacy bei kostenlosen Apps schnell feststellen, ob und wie viele Tracker diese integriert haben – inkl. Versionshistorie, die einen Blick auf die Vergangenheit ermöglicht. Nachfolgend eine illustre Auswahl an Apps, bei denen die Integration von Tracking-Bibliotheken als verantwortungslos bezeichnet werden kann.

Hinweis

Wenn Exodus Privacy eine Klasse mit Java-Tracking-Code identifiziert, dann bedeutet das nicht zwangsläufig, dass der Tracker auch aktiv ist. Mit Exodus Privacy können wir also nur sagen: Ja, entsprechender Tracking-Code bzw. der Tracker ist vorhanden. Ob dieser allerdings aktiv trackt, darüber lässt sich mit Exodus Privacy keine Aussage treffen – dazu muss die App manuell geprüft werden.

5.1 Banking-Apps

Banking-Apps verarbeiten sensible Informationen bzw. Zahlungsvorgänge ihrer Kunden. In diesem Rahmen halte ich die Integration von Trackern, die das Nutzerverhalten innerhalb einer App analysieren, für vollkommen unangebracht. Leider beinhaltet fast jede Banking-App einen oder mehrere Tracker:

Insbesondere N26 sticht hier mit sage und schreibe 12 Trackern hevor. Getreu dem Motto

Digital first – Bedenken second

werden Bedenken zu Sicherheit und Datenschutz offenbar elegant beiseite gewischt. Zum Glück ist man an seine Bank nicht gebunden und es gibt Alternativen.

5.2 Passwort-Manager

Im Beitrag »LastPass Android: Drittanbieter überwachen jeden Schritt« habe ich die folgende Aussage getätigt:

Für eine App, die äußerst sensible Daten (Passwörter) verarbeitet, ist das schlichtweg ein Armutszeugnis. Werbe- und Analytik-Module haben darin schlichtweg nichts verloren – es ist vollkommen indiskutabel, diese in Passwort-Manager-Apps zu integrieren.

Daran halte ich fest. Anbei eine Übersicht der gängigen Passwort-Apps:

5.3 Steuererklärung-Apps

Die Steuererklärung ist für die meisten Deutschen ein sensibles Vorhaben. Dabei ständig beobachtet zu werden empfinden wohl die meisten Nutzer als unangenehm:

5.4. Gesundheits-Apps

Gesundheitsdaten fallen nach Art. 9 EU-DSGVO unter die Kategorie der besonders schützenswerten Daten. Daher sollten bei der Verarbeitung von Gesundheitsdaten die höchsten Maßstäbe an IT-Sicherheit und Datenschutz gelten und auch eingehalten werden. Vor der Nutzung von Gesundheits-Apps sollte man sich Folgendes vor Augen führen: Gesundheitsdaten begleiten einen das ganze Leben und nicht nur einen kurzen Zeitraum.

5.5 VPN-Apps

Ein Virtual Private Network (VPN) steht sinnbildlich für Privatsphäre und »Anonymität« – leider zu Unrecht. Viele Anwender fallen auf die haltlosen Werbeversprechen der VPN-Anbieter rein und wiegen sich in falscher Sicherheit. Daneben fallen VPN-Anbieter auch immer mal wieder durch fahrlässige Sicherheitsmaßnahmen auf. Ganz zu schweigen von den angebotenen VPN-Apps für mobile Endgeräte, die mit Trackern geradezu vollgestopft sind – in einem solch sensiblen Umfeld sollte es eigentlich eine Selbstverständlichkeit sein, darauf zu verzichten:

Hinweis

Übrigens: Lasst die Finger von VPN-Vergleichsportalen. Das sind meist dubiose Anbieter, die gutgläubige Nutzer mit Affiliate-Links abzocken. Mehr dazu im Beitrag: VPN-Vergleichsportale: Finger weg von diesen Seiten.

6. Fragen die wir uns stellen sollten

Es ist an der Zeit, dass wir anfangen, über die Allgegenwärtigkeit und die potenzielle Übergriffigkeit gängiger Analysetools bzw. Tracking-Bibliotheken zu diskutieren – ohne die üblichen Marketing-Floskeln und Nebelkerzen. Dabei gilt es unter anderem die folgenden Fragen zu beleuchten:

  • Wem nutzt das App-Tracking überhaupt und welcher Mehrwert wird daraus generiert?
  • Wie kann verhindert werden, dass Tracker personenbezogene bzw. personenbeziehbare Daten übermitteln, die für eine Analyse unerheblich sind?
  • Wie viele Tracker bzw. Analysetools in einer App sind sinnvoll?
  • Genügen Lösungen wie Sentry, Crashy, Matomo oder ACRA nicht (die sich selbst hosten lassen), um das Nutzungsverhalten zu analysieren bzw. die App zu verbessern?

Das sind nur eine handvoll von Fragen, die in einem offenen Diskurs über die Problematik des User-Trackings in Apps beleuchtet werden sollten. Über die Kommentarfunktion dürft ihr gerne weitere Anregungen ergänzen.

6.1 Lösungsvorschläge

Mit dem vorliegenden Beitrag möchte ich nicht nur Kritik am Status quo üben, sondern eine dringend notwendige Diskussion über die Tracking-Thematik anstoßen. Anbei ein paar konkrete Vorschläge, die Teil einer Lösung sein können:

  • Qualitative Fehlerverbesserung: Telemetrie und die für eine Fehlerverbesserung notwendigen Daten sollten standardmäßig (by Design and Default) deaktiviert sein und können bei Bedarf bzw. beim Auftreten eines Fehlers durch den Benutzer aktiviert werden. Das vereinfacht die Reproduktion des Fehlers erheblich und reduziert die Datenflüsse auf die reine Funktionserbringung bzw. das notwendige Maß. Derart qualitativ erfasste Fehlerberichte sind nicht nur einfacher zu beheben, sondern wirken sich insgesamt positiv auf das gegenseitige Vertrauen zwischen Anwender und App-Hersteller aus.
  • App-Analytics: Hersteller und App-Verantwortliche mögen sich die Sinnfrage stellen. Welche funktionalen oder qualitativen Verbesserungen bewirkt ein App-Analytics? Was will man verbessern und anhand welcher Kriterien/Kennzahlen lässt sich dies messen? In den meisten Fällen werden Daten »auf Halde« gesammelt, ohne dass jemals eine Auswertung erfolgt. Gleichzeitig wird damit die positive Erfahrung eines Anwenders zunichtegemacht, ein langsames Endgerät noch weiter verlangsamt, unnötig Datenvolumen verbraucht, Akkulaufzeiten verringert etc. Es zeugt von gegenseitigem Respekt, einen Anwender mit dem ersten Start einer App um Zustimmung zum Tracking zu bitten. Besser noch: By Design und Default sollte dies gänzlich deaktiviert sein und Anwender bspw. durch Anreize (Invcentives) persönlich zur freiwilligen Mitarbeit bewegt werden. Insbesondere bei »Power-Usern« entstehen durch dieses Vorgehen qualitativ höherwertige Auswertungsdaten, die dazu beitragen, das Problem bzw. den Bug zeitnah zu beheben.
  • Eigene Infrastruktur: Einem App-Hersteller stehen in der Regel verschiedene (JSON-)Schnittstellen zur Verfügung, über die eine App ihre Daten abruft oder darüber kommuniziert. Die Server-Logs dieser Schnittstellen sind ein geeigneter Ansatzpunkt, um genauere bzw. gleichwertige Auswertungen (bspw. Matomo) zu generieren, wie dies mit den gängigen Analyse-Tools möglich ist. Wer bereits im Entwicklungsprozess diese Möglichkeit berücksichtigt, erhält nicht nur qualitativ höherwertige Daten, sondern kann das Tracking rechtskonform und ohne die Einbindung Dritter/Auftragsverarbeiter gestalten.
  • Vertrauensbildung: Vertrauen beruht auf Gegenseitigkeit. Das ist nicht gegeben, wenn App-Hersteller sich nicht auf Augenhöhe mit ihren Anwendern begegnen. Wer intransparent alles mitloggt was »bei drei nicht auf den Bäumen ist« und an Dritte/Auftragsverarbeiter weiterreicht, nimmt unweigerlich eine Machtposition ein. Das zarte Pflänzchen des Vertrauens braucht Zeit und Raum. Dies steht im Konflikt mit der kurzfristigen, meist pseudo-agilen Arbeitsweise vieler Projektteams. Der erste Schritt zur Vertrauensbildung kann nur vom Hersteller einer App ausgehen.

7. Fazit

Anhand des Facebook-Beispiels sollte deutlich geworden sein, wie unscheinbare Informationen (Google-Advertising-ID) genutzt werden können, um einen Personenbezug herzustellen. Beteuerungen, es würden beim Einbau von Tracking-Bibliotheken lediglich pseudonymisierte/anonymisierte Daten übermittelt, sind schlichtweg irreführend und unehrlich. Denn selbst wenn ein direkter Personenbezug auf den ersten Blick nicht herstellbar ist, so beinhalten die Datenübermittlungen meist genügend Identifier und Meta-Daten, die genau dies ermöglichen.

Der vorliegende Beitrag wird sicherlich nicht dafür sorgen, dass App-Entwickler bzw. Verantwortliche nun massenhaft damit beginnen, die Tracking-Bibliotheken aus ihren Apps zu entfernen. Aber vielleicht kann der Beitrag die Tür zu einer Diskussion aufstoßen, die dringend notwendig ist. Anstatt die Nutzer mit Marketing-Floskeln abzuspeisen, sollte man die Tatsachen ehrlich ansprechen und evaluieren, wie eine Verbesserung erzielt werden kann, mit der sich sowohl Entwickler als auch Nutzer arrangieren können. Der Status quo ist jedenfalls nicht tragbar – insbesondere aus Nutzersicht.

Bildquellen:

Delivery Box: Freepik from www.flaticon.com is licensed by CC 3.0 BY

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Ähnliche Beiträge
Elektroauto-Ladeapp-Test
10. September 2023

Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test

Manche Ladeapps sind eine Datenschutzkatastrophe. Wir haben 41 Apps getestet und geben Tipps für datensparsames Laden.
Booking.com
11. Mai 2023

Booking.com: Datenschutzrechtliche Bruchlandung mit Ansage – App-Check Teil4

Die Datenschutzverletzungen von Booking.com sind vergleichbar mit einem verheerenden Verkehrsunfall, bei dem man einfach nicht wegsehen kann.
Virenscanner-App
29. November 2021

Trügerische Sicherheit: Virenscanner-Apps sind schlichtweg überflüssig

Die Sicherheitsarchitektur von Android/iOS schränkt die Funktionsweise von Virenscanner-Apps stark ein und macht sie im Grunde nutzlos. Schlimmer: Die vermeintlichen Sicherheits-Apps sind Datenschleudern.
Microblog
20. Februar 2021

LastPass Android: Drittanbieter überwachen jeden Schritt

LastPass ist ein weit verbreiteter Passwort-Manager. Allein im Google Play Store verzeichnet die App über 10 Millionen Installationen. Mit Exodus…
eBay Kleinanzeigen
24. Oktober 2022

eBay Kleinanzeigen: Datenschutz: Was letzte Preis? – App-Check Teil3

Der Datenschutz verkommt bei eBay Kleinanzeigen zur Ramschware. Am Ende heißt es »Datenschutz: Was letzte Preis?«.
Weitere Themen
AndroidAuditAutonomieBackupBezahlenBrowserCloudDatenschutzDatensendeverhaltenDigitalpolitikDSGVOE-MailFirewallHackingHärteniOSKuketz-BlogLinuxmacOSMessengerOpenWrtPasswortPentestRaspberryPiRechtSicherheitslückeSicherheitsmaßnahmeTorTrackingTTDSGÜberwachungVerschlüsselungWindowsWordPressXMPP
Diskussion

8 Ergänzungen zu “Wie Tracking in Apps die Sicherheit und den Datenschutz unnötig gefährdet”

  1. Comment Avatar Izzy sagt:
    3. März 2021 um 20:35 Uhr

    Will man eine App analysieren, die weder bei F-Droid noch frei im Play Store verfügbar ist (die Exodus also nicht herunterladen kann), geht das auch lokal mit recht einfachen Mitteln – siehe meinen Artikel Module in Apps identifizieren.

    Von Angriffen auf unsere Privatsphäre sowie Abschnüffelung von Daten einmal ganz abgesehen, ist der Sicherheits-Aspekt definitiv nicht zu vernachlässigen: Was nicht da ist, kann auch keine Sicherheitslücken einschleusen. Auch von daher kann das KISS-Prinzip nicht oft genug betont werden.

    Wie Analytics auch unter voller Berücksichtigung der Privatsphäre geht, beschreibt beispielsweise Hans vom Guardian-Project in seinem gestrigen Artikel New insights into clean analytics: Was nicht gebraucht wird erst gar nicht erheben. Dann muss man es zum einen nicht erst später mühsam ausfiltern, es kann nichts „versehentlich durchrutschen“ – und kommt ein „unautorisierter“ an die Datensammlung, ist das kein „Malheur“ für die (dann überhaupt nicht betroffenen) Nutzer.

  2. Comment Avatar amjjma sagt:
    3. März 2021 um 21:38 Uhr

    Um Tracker in Android Apps zu identifizieren und unschädlich zu machen ist folgende App super: https://gitlab.com/AuroraOSS/AppWarden/

    Mike hat dazu einen Artikel verfasst: https://www.kuketz-blog.de/warden-tracker-aus-android-apps-entfernen/

  3. Comment Avatar Stephan sagt:
    4. März 2021 um 10:20 Uhr

    Oben im Artikel wird beschrieben, dass es durchaus valide Gründe fürs Tracking gibt, wenn die Entwickler zum Beispiel die App verbessern wollen.
    In der DAK App wird ein Tracker als „Crash Reporting“ klassifiziert.

    Ist das jetzt akzeptabel oder gut oder sollten solche Tracker auch verschwinden?
    Ich kann es selber nachvollziehen, wenn Bugs gemeldet werden und nicht reproduziert werden können, weil Logs und genauere Angaben fehlen.
    Auf der anderen Seite bekomme ich aber auch Bauchschmerzen, wenn ich sehe, dass irgendwelche Tracker verwendet werden…

    • Comment Avatar Mike Kuketz sagt:
      4. März 2021 um 12:02 Uhr

      Nach den Regeln sind eigentlich nur »Ergänzen« erlaubt. Ich mache hier aber mal eine Ausnahme, da die Antwort darauf vermutlich für einige Leser interessant sein dürfte.

      Wie aufzeigt, ist jede Integration von Dritt-Bibliotheken mit einem Risiko für Sicherheit und Datenschutz verbunden. Das gilt auch für Crash-Reporting-Bibliotheken. Auch diese übermitteln (und nicht nur im Falle eines Absturzes) Identifizierungsmerkmale und Meta-Daten an die Anbieter: Android: Crashlytics ein gigantisches Datengrab

      Anstatt die Daten einem Drittanbieter/Auftragsverarbeiter anzuvertrauen, sollten Entwickler das Self-Hosting solcher Lösungen bevorzugen. Siehe dazu 6.1 Lösungsvorschläge.

      • Comment Avatar R.S. sagt:
        29. März 2021 um 15:50 Uhr

        Weitestgehend mit allem einverstanden. Aber, bitte präzise bleiben und nicht Drittanbieter und Auftragsverarbeiter gleichsetzen! Ein Auftragsverarbeiter mit fehlerhafter Software ist natürlich ein Sicherheitsproblem – aber in besagter Funktionalität ggf. immer noch ein besserer Profi als ich selbst, der ich da versuche alles mit Matomo nachzubauen. Ein Auftragsverarbeiter kann aber kein Datenschutzproblem sein – andernfalls wäre er kein Auftragsverarbeiter im Sinne des Begriffes – was uns wiederum dazu führt, dass eine ganze Menge Drittanbieter niemals als Auftragsverarbeiter eingesetzt werden können.
        Was FÜR den Einsatz von Drittanbietern mit eigener Infrastruktur in Auftragsverarbeitung auch spricht, ist der Umstand, dass dadurch auch meine Infrastruktur und deren Performance mit „getrackt“ wird. Wenn ich alles nur mit eigenen Mitteln versuche – wie und wo bekomme ich denn eine unabhängige Messung dafür her, die zusätzlich auch den Endpunkt beim Benutzer einbezieht?

        • Comment Avatar Mike Kuketz sagt:
          30. März 2021 um 08:25 Uhr

          Es spielt keine Rolle, ob wir das rechtlich/sprachlich trennen. Auftragsverarbeiter oder Drittanbieter, es sind Quellen Dritter. Und diese können, wie aufgezeigt, eine Gefahr darstellen.

  4. Comment Avatar F. sagt:
    11. März 2021 um 10:09 Uhr

    Ein Punkt der in diesem Artikel nicht adressiert wird, aber schon oft in vielen anderen von Mikes Artikeln erwähnt wurde, ist Tracking in Apps der öffentlichen Hand, die aus Steuermitteln finanziert werden. Auf der eigentlich gleichen Ebene sehe ich auch Apps / Angebote des öffentlichen Rundfunks oder der Krankenkassen. Schließlich bezahlen wir für deren Dienste durch den Rundfunkbeitrag bzw. unseren Versicherungsbeitrag ja für diese Dienste, die Frage der Finanzierung sollte hier also gesichert sein und kann kein Argument sein Nutzertracking zu betreiben.

    Was die Lösungen angeht, muss man wahrscheinlich (mindestens) zwei Fälle differenzieren:
    – professionelle Anbieter
    – private Anbieter
    Gerade für private Anbieter bzw. Leute die in ihrer Freizeit eine App, Webseite oder sonstigen Service erstellen und pflegen, fehlen leichtgewichtige Einstiege die in einer privatsphärefreundlichen Ausgestaltung münden (oder sind mir zumindest unbekannt).

    Dies könnte auch privatsphärefreundlichen Nutzern helfen, wenn es eine Übersicht gäbe auf die man verweisen kann, wenn eine z.B. eine Webseite fragwürdige Dienste einbindet. Es ist eben immer besser direkt eine Lösung aufzugzeigen als nur die Missstände zu kritisieren, auch wenn die Kritik absolut berechtigt ist.

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
⬆