1. Marshmallow
Google hat mit Android 6 einen der wohl größten Kritikpunkte der vorherigen Android Versionen adressiert, nämlich die nachträgliche Verwaltung von Berechtigungen. Dieses bedeutet zunächst einmal mehr Kontrolle über die eigenen Daten und lässt sich als ein erfreulicher Schritt nach vorne ansehen, denn hierdurch wurde (vordergründig) die Autonomie des Nutzers gestärkt. Doch bei näherer Betrachtung wird leider auch klar: Ein Großteil der alten Schwächen wurden übernommen und darüber hinaus wurden weitere, neue Features eingebaut, die das Recht auf informationelle Selbstbestimmung des Nutzers, weiter gefährden.
Im vorliegenden Beitrag möchte ich die Schwächen des Android Berechtigungmodells aufzeigen. Dieses fragwürdige Modell hat in vergangenen Jahren entschieden dazu beigetragen, dass Durchschnittsnutzer geradezu entmündigt wurden und nicht annähernd mehr wissen, was sich im Hintergrund auf ihrem Gerät überhaupt noch abspielt. Denn es fehlt die Transparenz, um zu sehen, was eigentlich bei der Smartphonenutzung geschieht.
Zugegeben, der Beitrag ist ein Bollwerk an Informationen. Ich kann dem interessierten Leser nur ans Herz legen: Durchhalten – es lohnt sich! Manche werden in den Beitrag vielleicht sogar eine »Abrechnung mit Google« reininterpretieren. Aber darum geht es hier nicht: In erster Line möchte ich auf einen Missstand aufmerksam machen. Ihr habt nach dem Lesen des Beitrags dann die Wahl: Ihr könnt die vorhandenen Probleme weiter ignorieren bzw. ausblenden – oder die eigene Bequemlichkeit überwinden und bspw. »Your phone – your data« umsetzen. Es liegt ganz bei euch.
2. Das Smartphone im Alltag
Mobile Endgeräte wie Smartphones und Tablets erfüllen heutzutage die unterschiedlichsten Aufgaben und sind kaum noch aus dem Alltag wegzudenken. Kommunikationszentrale, Datenspeicher, Mediaplayer, Spielkonsole und Navigationsgerät sind nur einige Beispiele für die vielfältigen Anwendungszwecke eines mobilen Endgeräts. Man könnte auch sagen: Ein mobiles Endgerät wie ein Smartphone dient als Schnittstelle bzw. »Mittler« zwischen analoger und digitaler Welt. Dieses wiederum hat zur Konsequenz, dass es zunehmend zu einer Vermischung der beiden »Welten« kommt, was sich in den unterschiedlichsten Alltagssituationen bemerkbar macht:
- Bezahlvorgänge: Bargeld wird zunehmend durch kontaktloses Bezahlen mit dem Smartphone (Google Wallet, Apple Pay) abgelöst.
- Navigation: Die ursprüngliche Navigation mittels Karten wurde längst durch die »smarte« GPS-Navigation auf Basis von Smartphone-Apps ersetzt.
- Kommunikation: Verabredungen und Terminabsprachen erfolgen zunehmend über sogenannte Messenger-Apps.
- Konsum: Eintrittskarten, Gutscheine oder Bahntickets werden vermehrt papierlos bzw. digitialisiert – Online mittels Smartphone bestellt.
Angesichts der fortschreitenden Vermischung dieser zwei Welten beinhalten mobile Endgeräte heute die persönlichsten und intimsten Informationen von Personen. Die Informationsvielfalt reicht von Zahlungsinformationen, Kontaktdaten, E-Mail Korrespondenzen bis hin zu Sucheingaben im Browser, metergenauen Standortinformationen u.V.m.. Insbesondere aus kommerziellen Interessen versuchen die unterschiedlichsten Protagonisten, wie zum Beispiel die Werbe- und Medienbranche, Zugang zu diesen Information zu erhalten, um daraus vermarktbare Erkenntnisse über eine Person zu gewinnen.
Insofern ist es im Zeitalter der Digitalisierung essentiell, sich vor Augen zu führen, dass diese Informationen bzw. Daten nicht umsonst als das »Öl des 21. Jahrhunderts« bezeichnet werden. Mitunter sind die sozialen, ökonomischen aber auch kulturellen Folgen der systematischen »Förderung« von Daten durch modernste Technologien heute nicht absehbar. Insbesondere mobile Endgeräte dienen den unterschiedlichsten Protagonisten als eine der zuverlässigsten »Daten-Quellen« – denn sie beinhalten wie vorstehend dargestellt, eine Vielzahl an Informationen über den Nutzer. In diesem Zusammenhang gilt es zu beleuchten, warum es den Protagonisten gerade auf mobilen Endgeräten und insbesondere auf Android vergleichsweise einfach gemacht wird, dieses Informationspotenzial für ihre Zwecke ausnutzen. Von der grafischen Oberfläche eines Smartphones, die durch »Tippen und Wischen« handhabbar ist, müssen wir uns an dieser Stelle verabschieden und ein Blick hinter die Kulissen werfen. Denn um zu verstehen, welche Mechanismen im Hintergrund wirken, gilt es das Android Berechtigungsmodell von seiner technischen Seite zu analysieren.
3. Das Android Berechtigungsmodell
Eine zentrale Komponente der Android Sicherheitsarchitektur ist das Berechtigungsmodell. Es überwacht und steuert den Zugriff auf diverse Ressourcen, wie bspw. die der Smartphone- Kamera eines Android Systems. Das Berechtigungsmodell ist ein zentraler Bestandteil der Android Sicherheitsarchitektur, die auf unterschiedlichen Mechanismen basiert. Jeder dieser Mechanismen spielt eine entscheidende Rolle, wenn es um die Kontrolle und Einhaltung der Systemsicherheit des Android-Systems geht.
Abstrakt dargestellt, tauschen diese Mechanismen untereinander Informationen über Subjekte (Apps, Nutzer), Objekte (Dateien, Geräte) und Zugriffsrechte (Lesen, Schreiben, Löschen, etc.) aus. Dieses anerkannte Prinzip ist in der Informatik unter dem Begriff Zugriffskontrollmodell (bspw. ACL, MAC, etc.) bekannt. Neben dem Berechtigungsmodell existieren weitere Komponenten der Android Sicherheitsarchitektur, wie die Geräte-Verschlüsselung und Verified Boot, die jedoch aufgrund ihrer Komplexität nicht Bestandteil des vorliegenden Beitrags sind.
Eine Ressource in Android ist ein Objekt, auf das ein Subjekt (App, Nutzer) zugreift – die jeweils vergebenen Berechtigungen kontrollieren / limitieren diesen Zugriff. Auf einem Android Gerät existieren unterschiedliche Ressourcen, die sich grob in die zwei folgenden Kategorien einteilen lassen:
- API-Ressourcen: Über die Android-API (Programmierschnittstelle) kann ein Entwickler Zugriff auf unterschiedliche Ressourcen erhalten, falls die dafür notwendige Berechtigung vom Smartphonenutzer (zuvor) erteilt wurde. Als Beispiel sei hier die Berechtigung »Telefonstatus und Identität abrufen« genannt, die den Zugriff auf unterschiedliche Informationen der Ressource »Telefon« ermöglicht. Die Erteilung des Zugriffs führt deshalb u.a. dazu, dass eine App die International Mobile Equipment Identity (IMEI) oder die Seriennummer der SIM-Karte auslesen kann. Die IMEI ist eine eindeutige 15-stellige Seriennummer, anhand derer ein Smartphone weltweit eindeutig identifiziert werden kann. Es handelt sich daher bei der IMEI aufgrund des damit einhergehenden »Missbrauchspotenzials« um ein sehr sensibles, unbedingt schützenswerte Information.
- Datei-System Ressourcen: Dateien stellen unter Android ebenso Ressourcen / Objekte dar, deren Zugriff grundsätzlich reglementiert und kontrolliert wird. Nach Vorbild des Unix-Dateisystems existieren die Berechtigungen Lesen, Schreiben und Ausführen. Gestattet sind die Zugriffe jedoch immer nur dann, wenn auch der entsprechende Nutzer bzw. die Gruppe dazu berechtigt ist. Standardmäßig hat nach dem Android-Berechtigungsmodell eine App lediglich Zugriff auf die eigenen Dateien im Dateisystem. Realisiert wird dies über einen eindeutigen Identifikator (ID bzw. UID), der einer App während der Installation vom System zugewiesen wird. Jede Datei einer App wird anschließend mit der zugewiesenen UID markiert, die stellvertretend für die Nutzer und Gruppen bei Unix-Systemen steht.
In Android sind (streng genommen) zwei getrennte Berechtigungsmodelle implementiert, die jedoch eng zusammenwirken und somit auch als eines »großes Ganzes« angesehen werden können. Gemeinsam überwachen und steuern die Sandbox und das Berechtigungsmodell auf Anwendungsebene den Zugriff auf unterschiedliche Ressourcen des Smartphones. Insbesondere das Berechtigungsmodell auf Anwendungsebene gilt jedoch in seiner Konstruktion als weithin unzureichend, um die teils hochsensiblen Ressourcen bzw. die darüber abrufbaren Informationen ausreichend zu schützen.
Du kannst den Blog aktiv unterstützen!
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.
3.1 Berechtigungsmodell auf Anwendungsebene
Android Apps sind zur Laufzeit in einer Sandbox eingesperrt. Das Prinzip verhindert den Zugriff auf Ressourcen, falls einer App die entsprechende Berechtigung fehlt. Die Bezeichnung Sandbox leitet sich daraus ab, dass sich Apps bildlich gesprochen, wie ein kleines Kind in einem »Sandkasten« befinden. Sie können in diesem Sandkasten »spielen«, werden durch unterschiedliche Mechanismen allerdings davon abgehalten aus dem Sandkasten »auszubrechen« und in der Umgebung außerhalb des Sandkastens »Schaden« anzurichten. Zur Funktionserbringung benötigen Apps allerdings oftmals Zugriff auf die unterschiedlichsten Ressourcen. An dieser Stelle kommt das Berechtigungsmodell auf Anwendungsebene ins Spiel – es schlägt sozusagen eine Brücke zwischen der App und den Ressourcen des Geräts bzw. des Benutzers.
In ihrer Grundidee sollen Berechtigungen auf Android gewährleisten, dass Apps ohne explizite Rechte keinen Zugriff auf Ressourcen haben. Apps sind dann in ihrer Sandbox eingesperrt und die Interaktionsmöglichkeit mit der Außenwelt ist auf das Notwendigste beschränkt. Vor der Installation einer neuen App wird dem Benutzer daher ein Hinweisfenster eingeblendet, welches den Benutzer über die angeforderten Berechtigungen informiert. Dieses Hinweisfenster generiert das System auf Basis der Informationen, die ein Entwickler in der »AndroidManifest.xml« hinterlegt hat. Zum Zeitpunkt der Installation wird die Verantwortung über den Zugriff auf die unterschiedlichsten Ressourcen komplett auf den Benutzer abgewälzt. Doch dieser verfügt weder über die Kompetenz, noch das notwendige Wissen, um solch eine folgenschwere Entscheidung überhaupt treffen zu können. Der durchschnittliche Benutzer kapituliert an dieser Stelle bereits, wirft höchstens einen oberflächlichen Blick auf die angeforderten Berechtigungen, um die App-Installation anschließend zu bestätigen.
Das Android Berechtigungsmodell bzw. seine Konstruktion ist mitverantwortlich für den Kontrollverlust über die eigenen, teils hochsensiblen Daten. Aus datenschutzrechtlicher Sicht verstoßen viele App-Entwickler und Unternehmen unter anderem gegen die Grundsätze der Zweckbestimmung und Datensparsamkeit. Apps sammeln und versenden zuweilen mehr Daten, als sie zur Erfüllung ihrer Aufgabe bzw. Funktionalität überhaupt benötigen. Beispiele für diesen Missbrauch gibt es zur Genüge:
- Untersuchungsbericht zu Apps, Projekt »Verbraucherrechte in der digitalen Welt«, Verbraucherzentrale Bundesverband, März 2014
- »Schnüffeln verboten«, Zeit Online, April 2014
- App-Rezensionen, Projekt »mobilsicher.de«, gefördert vom Bundesministerium für Justiz und Verbraucherschutz, Januar – * 2016
- […]
Der verantwortungsbewusste Umgang mit Daten wird durch viele App-Anbieter einfach ausgehebelt. Es werden häufig nicht nur jene Daten gesammelt und verarbeitet, die zur Erreichung des (legitimen) Zweckes wie bspw. zur Gewährleistung der ordnungsgemäßen Funktionsfähigkeit der entsprechenden App notwendig sind. Sollen personenbezogene Daten des Nutzers zu Zwecken der Werbung genutzt bzw. kommerzialisiert werden, ist dieses grundsätzlich nur – ohne eine wirksame Einwilligung des Nutzers – unter engen Voraussetzungen möglich. Diese essenziellen datenschutzrechtlichen Vorgaben werden jedoch heutzutage in der Praxis leider allzu gerne mit Füßen getreten. Das Android Berechtigungsmodell begünstigt die fragwürdigen Geschäftspraktiken vieler Unternehmen, die sich auf die Sammlung und Auswertung von personenbezogenen Daten spezialisiert haben.
Die konzeptionellen Schwächen des Android Berechtigungsmodells und die damit einhergehende Problematik wird nachfolgend für das bis Android 5 vorherrschende Prinzip der Berechtigungsverwaltung dargestellt. In einem späteren Kapitel wird die von Android 6 neu eingeführte Rechteverwaltung analysiert.
4. Bis Android 5: Paradies für Datensammler
Bis Android 5 hatte der Nutzer keine Möglichkeit, die einmal von ihm erteilten Berechtigungen nachträglich zu reglementieren und damit der App den Zugriff auf bestimmte Ressourcen, nachträglich zu verbieten. Vielmehr galt / gilt das bekannte, umgangssprachliche Prinzip: »Friss oder stirb«. Oder um es ein wenig unplastischer zu formulieren: Entweder der Nutzer ist mit den angeforderten Berechtigungen einer App einverstanden oder er kann die App erst gar nicht installieren.
Auf welche Ressourcen die von ihm installierte App tatsächlich während der Laufzeit zugreift und welche Daten sie an wen eigentlich übermittelt und was daraus für Konsequenzen für den Nutzer erwachsen können, darüber wird der Anwender im Unklaren gelassen. Das bedeutet letztendlich auch: Niemand weiß eigentlich wohin die Daten übermittelt werden und was damit geschieht bzw. zu welchen Zwecken sie wie weiterverarbeitet werden.
Hinweis
Die im folgenden aufgeführten Schwächen des Android Berechtigungsmodells betreffen nicht nur Apps, die sich der Nutzer selbst installiert, sondern im Grunde genommen sind davon alle Apps auf dem Android-System betroffen. Also demnach auch System-Apps und Apps die bereits vorinstalliert sind.4.1 Erste Schwäche: Berechtigungsdschungel
In Android existieren über hundert verschiedene Berechtigungen, die den Zugriff auf die unterschiedlichsten Ressourcen steuern. Mit jeder neuen Android Version werden neue Berechtigungen ergänzt, bestehende modifiziert oder nicht mehr benötigte entfernt. Aufgrund der Vielfalt an Berechtigungen ist es einem Nutzer kaum möglich, eine rationale Entscheidung zu treffen, ob die angeforderten Berechtigungen einer App tatsächlich auch »erforderlich« für die Funktionsweise der App sind und ob er den Zugriff auf die Ressourcen tatsächlich erlauben möchte. Das bedeutet auch: Die damit einhergehenden Risiken kann ein Nutzer kaum abschätzen. Ein Beispiel:
- Genauer Standort (GPS- und netzwerkbasiert
- Beschreibung: Ermöglicht der App, die genaue Position anhand von GPS-Daten oder über Netzwerkstandortquellen wie Sendemasten oder WLAN zu ermitteln. Diese Standortdienste müssen auf dem Gerät verfügbar und aktiviert sein, damit die App sie verwenden kann. Apps können den Standort anhand dieser Daten ermitteln, verbrauchen dadurch aber oftmals zusätzliche Akkuleistung.
- Mögliches Risiko: Die ständige Übermittlung von Standortdaten ermöglicht es Unternehmen, detaillierte Bewegungsprofile zu erstellen. Aus den damit gesammelten Daten lässt sich ableiten, wo ein Nutzer lebt, wo und wann er regelmäßig arbeitet, einkauft, seine Freizeit verbringt oder übernachtet. Es entstehen somit umfangreiche Nutzerprofile, die professionell vermarktet / verkauft werden und den Nutzer sowie dessen Kontakte zu Adressaten gezielter Werbung machen können. Ferner sind noch weitere Missbrauchsszenarien mittels dieser Daten möglich, die noch weiter Rechte des Nutzers eingreifen, auf die jedoch aufgrund der Komplexität nicht weiter eingegangen werden soll. Insbesondere Standortdaten gelten daher als äußert sensible Information, die aus Datenschutzgründen nicht jederzeit für eine App -ohne Einwilligung des Nutzers- abrufbar sein sollten.
4.2 Zweite Schwäche: Unzureichende Informationspolitik
Bei der Installation einer App über den Google Play Store wird dem Nutzer bis einschließlich Android 5 ein Hinweisfenster eingeblendet, in dem (vermeintlich) alle Berechtigungen aufgelistet werden – so zumindest die weit verbreitete Meinung. Tatsächlich wird dem Nutzer jedoch eine verkürzte, komprimierte Darstellung der Berechtigungen angezeigt. Um alle, tatsächlich angeforderten Berechtigungen einer App einzusehen, muss der Nutzer den Google Play Store im Browser öffnen, die entsprechende App auswählen und unter »Berechtigungen« auf den Link »Details ansehen« klicken. Anhand des nachfolgenden Beispiels sollen die beiden vorstehend angesprochenen, unterschiedlichen Darstellungsformen visualisiert werden:
Aufgrund der verkürzten Darstellung während der App-Installation werden dem Nutzer essentielle Informationen praktisch vorenthalten, an die er nur auf umständliche Art, bzw. weitere Schritte gelangen kann. Doch so provozierend es auch klingen mag: »Jeder weitere Schritt, sich zu informieren, rückt das Nutzungsvergnügen der App in immer weitere Ferne«, weshalb die Einholung weiterer Informationen in das Praxis nicht gegangen wird.
4.3 Dritte Schwäche: Grobgranularität
Wie bereits dargestellt arbeitet das Android Berechtigungsmodell (theoretisch) mit über hundert verschiedenen Berechtigungen / Berechtigungsarten. Man könnte daher annehmen, dass diese Vielfalt es ermöglicht, eine feingranulare Zugriffsteuerung auf Ressourcen vornehmen zu lassen. Doch dieses entspricht leider nicht der Realität. Denn einige Android Berechtigungen sind so konzipiert, dass es mit einer Berechtigung möglich wird, auf eine Fülle von Ressourcen bzw. Informationen zuzugreifen, was wiederum das Missbrauchspotenzial dieser Funktionen weiter wachsen lässt. So wird etwa die Berechtigung »Telefonstatus und Identität abrufen« von vielen Spielen und Medienanwendungen benutzt, um das Spielgeschehen oder das Video/Audio beim Eingang eines Anrufs zu pausieren. Doch so sinnvoll diese Funktion auf den ersten Blick erscheint, umso kritischer ist sie auf dem zweiten Blick. Denn auch wenn man es nicht erwarten würde, lassen sich mittels dieser Berechtigung, einige eindeutige Identifikationsmerkmale des Smartphones erfassen, was wiederum die Personalisierung des jeweiligen Nutzers, inklusive der damit verbundenen Konsequenzen, zulässt. So ermöglicht diese Berechtigung unter anderem das Auslesen der (hochsensiblen) IMEI, der Seriennummer der SIM-Karte, der Telefonnummer eines eingehenden Anrufs, der eigenen Telefonnummer und den Namen des Telefonproviders. Diese äußert sensiblen Informationen gilt es eigentlich, alleine aus Respekt vor dem Anrufenden, vor einem Zugriff unbedingt zu schützen.
Das bedeutet: Android nimmt eine unzureichende Trennung zwischen den unterschiedlichen Ressourcen vor und schützt insbesondere Informationen, die als eindeutige Identifikationsmerkmale herangezogen werden können, nur unzureichend vor einer missbräuchlichen Verwendung. Diese Versäumnisse sorgen zwangsläufig für einen Kontrollverlust über die eigenen Daten.
4.4 Vierte Schwäche: Fehlende Transparenz
Allgemein wird das Android Berechtigungsmodell gelobt. Insbesondere wird dabei hervorgehoben, dass es Transparenz für den Nutzer schaffe und es den entsprechenden »datenhungrigen« Apps den Zugriff auf Ressourcen, die vom Nutzer bei der Installation nicht erlaubt wurden, erschwere. Wie in vorstehend schon angedeutet, bleibt jedoch bei näherer Betrachtung der tatsächlichen Begebenheiten von der so oft gelobten »Transparenz« wenig übrig. So fehlt es eigentlich bereits an der entsprechenden Transparenz für die App-Entwickler.
Um neue Apps zu entwickeln, sind detaillierte Beschreibungen hinsichtlich Schnittstellen (API-Referenzen) bzw. Entwickler Hinweise zwingend notwendig. Dieses insbesondere deshalb, um die Entwickler in die Lage zu versetzen, nur die wirklich für die App-Funktionalität benötigten Berechtigungen vom Nutzer einzufordern. Doch gerade im Hinblick auf das Berechtigungsmodell ist die von Google herausgegebene, offizielle Beschreibung der einzelnen Berechtigungen und die Darstellung wie, auf welche Ressourcen damit zugegriffen werden kann, durchaus »ergänzungsbedürftig«. Diese Ergänzungsbedürftigkeit hat letzten Endes zur Konsequenz, dass App-Entwickler in der »AndroidManifest.xml« oftmals (mit bzw. ohne böse Hintergedanken) den Zugriff auf die unterschiedlichsten Berechtigungen definieren, ohne dass dafür eigentlich eine Notwendigkeit bestehen würde. Daher ist es eher die Regel als die Ausnahme, dass Apps, zu viele Berechtigungen einfordern.
Aus Nutzersicht wiederum bedeutet das: Ein Nutzer kann vor bzw. nach der Installation zwar einsehen, welche Berechtigungen eine App einfordert. Allerdings weiß er aber zu keinem Zeitpunkt, wann der entsprechende Zugriff auf die entsprechende Ressource tatsächlich erfolgt und welche Daten / Informationen von der App dabei tatsächlich abgefragt werden. Das ist insofern kritisch, als dass aufgrund der Grobgranularität für den Nutzer dabei auch nicht ersichtlich ist, ob eine App womöglich auf sensible Informationen, wie die eindeutige Geräte-ID oder die IMSI-Nummer zugreift und diese anschließend an etwaige, dem Nutzer unbekannte Dritte übersendet. Dieses skizzierte Dilemma, lässt sich anhand einiger Taschenlampen-Apps gut verdeutlichen: So benötigt eine »normale« Taschenlampen-App theoretisch nur die Berechtigung »Bilder und Videos aufnehmen«. Ohne eine solche Berechtigung wäre die App nicht in der Lage, die intern im Smartphone verbaute LED-Leuchte anzusteuern, um sie dann auf Knopfdruck an- bzw. auszuschalten. Für den Nutzer ist allerdings zu keinem Zeitpunkt ersichtlich, ob die App auch wirklich nur die LED ansteuert oder womöglich sogar (verdeckt) Bilder und Videos aufnimmt. Die Grobgranularität von Berechtigungen sorgt demnach nicht nur für einen Kontrollverlust über die eigenen Daten, sondern dürfte die vielgelobte Transparenz des Android Berechtigungsmodells durchaus wieder relativieren.
4.5 Zwischenfazit
Betrachtet man die vorstehend aufgeführten Probleme individuell, dürfte man zum Ergebnis kommen, dass das Android Berechtigungsmodell zwar nicht perfekt ist, doch sich durch kleine Anpassungen eine deutliche Verbesserung hinsichtlich der Transparenz und Kontrollmöglichkeit erzielen ließe.
Doch diese Einschätzung greift nach meiner Ansicht viel zu kurz. Vielmehr kommt man nicht umher, die vorstehend aufgeführten Probleme als großes Ganzes zu betrachten, bei dem sich die einzelnen Probleme, gegenseitig bedingen. Dieses wiederum hat zur Konsequenz, dass die Unzulänglichkeiten des Android Berechtigungsmodell weitaus weitreichender sind und sich gerade nicht durch »kleine« Anpassungen beheben lassen dürften. Ferner ist auch der Smartphone-Nutzer nicht in der Lage selbstständig, die vorstehend aufgeführten Probleme aus der Welt zu schaffen, bzw. seine »Mündigkeit« zurückzuerlangen.
Nutzer müssen sich darüber im Klaren sein, dass die einmal erteilte Berechtigung einer App so lange anhält, wie die App auf dem Smartphone installiert ist. Dieses wiederum bedeutet in Konsequenz, dass die erteilten Berechtigungen erst aufgehoben werden, wenn die App vom Nutzer deinstalliert bzw. vom Gerät entfernt wird. Daher kann die App während dieses Zeitraums beliebig auf die Ressourcen der Geräts zugreifen, die der Nutzer ihr vermeintlich »freiwillig« erteilt hat.
5. Ab Android 6: Noch immer unzureichend
Wie im vorherigen Kapitel dargestellt, mussten bis Android 5 alle angeforderten Berechtigungen vom Nutzer akzeptiert werden – oder er konnte die App nicht installieren. Mit Android 6 änderte Google dieses Konzept. Der Nutzer hat nun die Möglichkeit die Zugriffsrechte (im Nachhinein) zu reglementieren – jedenfalls für einen Teil der Berechtigungen. Folgende Änderungen hat Google in das überarbeitete sog. »Marshmallow Berechtigungsmodell« einfließen lassen:
- Installationsvorgang: Bei der Installation einer neuen App werden dem Nutzer nicht mehr alle Berechtigungen aufgelistet, sondern die App wird direkt (ohne die »störende« Abfrage) installiert.
- Rechteverwaltung: Als Hauptargument für einen Wechsel auf Android Marshmallow wird oftmals die Möglichkeit der neuen Rechteverwaltung angeführt. Damit ist es dem Nutzer möglich, den Zugriff auf gewisse Ressourcen (nachträglich) zu steuern. Somit wird der Nutzer (vermeintlich) in die Lage versetzt, eigenverantwortlich / »mündig« darüber zu entscheiden, welche Berechtigungen eine App erlangen können soll. Über »Einstellungen → Apps« lassen sich die Zugriffsrechte bzw. die Berechtigungen für jede App verwalten.
- Automatische Updates: Erhält eine App neue Zugriffsrechte bei einem Update, wird bei der ersten Nutzung dieser Berechtigung die Zustimmung des Nutzers eingeholt. Vor Android 6 konnten sich wie vorstehend dargestellt, Apps ohne Genehmigung neue Zugriffsrechte verschaffen, wenn sie über den Google Play Store automatische Updates erhielten.
- Normal / Gefährlich: Mit Android-Marshmallow wird nun versucht, dem Nutzer eine »Kategorisierung« in »normal« und »gefährlich« entsprechend der eingeholten Berechtigungen an die Hand zu geben. Die Unterteilung der Berechtigungen in »normal« und »gefährlich« ist aber eigentlich nichts neues, sondern war eine gängige Kategorisierung für App-Entwickler. Jede Berechtigung in Android erhält entweder den Hinweis »normal« oder »gefährlich«. Google erklärt die unterschiedliche Relevanz folgendermaßen: Berechtigungen mit dem Zusatz »normal« stellen für die Privatsphäre des Nutzers kein »großes Risiko« dar. Ab Android 6 muss der Nutzer den Berechtigungen aus der Kategorie »normal« nicht mehr zustimmen. Sie werden der App während der Installation automatisch vom System eingeräumt.
Ist eine App bereits mit Android 6 kompatibel, fordert sie die Zugriffsrechte nach dem ersten Gebrauch über ein Hinweisfenster an. Der Nutzer hat dann die Wahl: Er kann die Berechtigung bzw. den Zugriff auf die Ressource zulassen, oder verweigern. Einmal gewährte Rechte können im Nachhinein auch wieder entzogen werden.
Für Apps die noch nicht für Android 6 angepasst wurden gilt indessen: Ein Hinweisfenster beim Zugriff auf eine Ressource bleibt aus. Über »Einstellungen → Apps → App → Berechtigungen« lassen sich die Zugriffsrechte bzw. die Berechtigungen jedoch für jede App einzeln verwalten – und das ist auch notwendig, denn standardmäßig wird einer App zunächst jeglicher Zugriff auf die angeforderten Ressourcen erlaubt.
5.1 Erste Schwäche: Eingeschränkte Kontrolle
Die Rechteverwaltung unter Android 6 soll den Nutzer in die Lage versetzen, den Zugriff der Apps auf Ressourcen des Smartphones zu verwalten. So die Theorie. In der Praxis sieht es jedoch so aus, dass der Nutzer bei weitem nicht die Möglichkeit hat, alle Berechtigungen, feingranular zu setzen. Vielmehr besteht für den Nutzer nur die Möglichkeit, sehr eingeschränkt Berechtigungen zu vergeben bzw. zu entziehen. Über »Einstellungen → Apps« werden nämlich nicht die einzelnen Berechtigungen einer App dargestellt, sondern es werden lediglich die übergeordneten Rechtegruppen angezeigt. Genaugenommen können daher Nutzer unter Android 6 keine Einzelberechtigungen reglementieren, sondern nur die übergeordneten Rechtegruppen. Im Nachfolgenden sind die wichtigsten dieser Gruppen dargestellt:
- Körpersensoren
- Kalender
- Kamera
- Kontakte
- Standort
- Mikrofon
- Telefon
- SMS
- Speicher
Anhand des nachfolgenden Beispiels »SMS« soll dieses vorstehend beschriebene Problem konkret adressiert werden. So beinhaltet die Rechtegruppe »SMS« folgende Berechtigungen:
- SMS empfangen
- SMS oder MMS lesen
- MMS empfangen, zum Beispiel Bilder oder Videos
- SMS oder MMS bearbeiten
- SMS senden, hierfür können Gebühren anfallen
- WAP-Nachrichten empfangen
Die Rechteverwaltung erlaubt dem Nutzer lediglich die Verwaltung der Rechtegruppe »SMS«. So ist es bspw. nicht möglich einer App nur das Lesen, nicht aber das Schreiben von einer SMS zu gewähren. Die Entscheidung eine Berechtigung zu erlauben bzw. zu verbieten gilt folglich immer für die gesamte Rechtegruppe. Das bedeutet letztendlich auch, dass die Funktionsweise einer App eventuell einer Beeinträchtigung unterliegt, falls der Nutzer den Zugriff auf eine Rechtegruppe verwehrt. Somit steht der Nutzer vor einem Dilemma: Aus Angst die Funktionsfähigkeit einer App nicht zu beeinträchtigen wird er wohl »in den sauren Apfel beißen« und im Zweifelsfall den Zugriff auf eine Rechtegruppe und alle darunter befindlichen Berechtigungen erlauben.
Google nimmt ferner wie im vorherigen Kapitel beschrieben, eine Kategorisierung der Berechtigungen in »normal« und »gefährlich« vor. Unter die Kategorie »gefährlich« fallen daher all jene Berechtigungen, die aus Sicht von Google ein Risiko für die Privatsphäre des Nutzers darstellen könnten.
Wie bereits dargestellt, besteht über die Rechteverwaltung »Einstellungen → Apps« die Möglichkeit, einzelne Rechtegruppen einer App zu verwalten. All die dort aufgeführten Rechtegruppen, inklusive der dazugehörigen Berechtigungen, zählen nach Googles Einordnung zur Kategorie »gefährlich«. Wie vorstehend auch schon angesprochen, fehlt eine derartige explizite Aufführung der Berechtigungen jedoch bei den Berechtigungen, bei denen Google das Risiko für die Privatsphäre der Nutzer als »normal« einstuft. Denn diese Berechtigungen werden systemseitig automatisch bei der Installation der App eingeräumt und werden dem Nutzer nicht mehr in der Rechteverwaltung angezeigt. Das bedeutet somit, dass eine Verwaltungsmöglichkeit dieser Berechtigungen entfällt.
Zur Kategorie »normal« gehören fast alle Berechtigungen, die es Apps ermöglichen, Verbindung über das Internet, Bluetooth oder NFC aufzunehmen. Nach meiner Auffassung dürften jedoch einige dieser Berechtigungen für die Privatsphäre des Nutzers ein vergleichsweise ähnlich hohes Risiko darstellen, wie die Berechtigungen die Google der Kategorie »gefährlich« zugeordnet hat. Daraus folgt, dass man die Einteilung der Berechtigungen in »gefährlich« und »normal« in Anbetracht des folgenden Auszugs aus der Kategorie »normal« und den damit verbundenen Missbrauchsszenarien, sehr kritisch hinterfragen sollte:
- Netzwerkverbindungen abrufen
- WLAN-Verbindungen abrufen
- NFC-Verbindung aufbauen
- Zugriff auf alle Netzwerke
- WLAN-Konfiguration ändern, WLAN-Verbindung aufbauen, beenden
- Bluetooth-Verbindung aufbauen
Die gelobte Android 6 Rechteverwaltung entpuppt sich bei näherer Betrachtung als zu grobgranular und wenig flexibel. Die eingeschränkten Einstellungsmöglichkeiten vermitteln den Eindruck, nicht die Apps, sondern der Nutzer selbst soll eingeschränkt werden – nämlich in seiner Entscheidungsfreiheit.
5.2 Zweite Schwäche: Verschlechterte Informationspolitik
Wie in den vorherigen Kapiteln aufgezeigt, wurde ursprünglich (vor Android 6) dem Nutzer vor Installation einer neuen App ein Hinweisfenster mit den angeforderten Berechtigungen angezeigt – zumindest in gekürzter Form. Ab Android 6 wird der Nutzer jedoch, wie aufgezeigt, nicht mehr über die angeforderten Berechtigungen informiert, sondern die App wird vielmehr mit einem Drücken auf »Installieren« direkt installiert. Über die »Einstellungen → Apps« sind wie auch schon aufgezeigt wurde, nicht alle der einzelnen Berechtigungen einer App dargestellt, sondern vielmehr nur die übergeordneten »gefährlichen« Rechtegruppen. Auf welche Ressourcen eine App aber tatsächlich zugreifen kann, erfährt der Nutzer erst über ein Untermenü in »Einstellungen → Apps → App → Berechtigungen → … → Alle Berechtigungen«. Der Blick in diese »Kategorie« dürfte möglicherweise bei manchen Nutzern die installierte App in einem anderen »Licht« erscheinen lassen…
Gerade im Hinblick auf die nicht vorhandene Kontrollmöglichkeit für Berechtigungen der Kategorie »normal«, wäre es jedoch unbedingt weiterhin notwendig, den Nutzer schon vor der Installation über die angeforderten Berechtigungen aufzuklären.
Mit Android 6 hat die Informationspolitik von Google einen neuen Tiefpunkt erreicht. Der Nutzer erfährt nämlich erst über ein Untermenü, auf welche Berechtigungen und damit welche Ressourcen eine App tatsächlich zugreifen kann. Das ist insofern fatal, als dass ihm eine (vollständige) Berechtigungskontrolle mehr oder weniger vorgegaukelt wird, er aber in der Realität immer weniger Kontrolle über sein Gerät / über die entsprechende App hat.
5.3 Übernommene Schwächen
Bis einschließlich Android 5 galt / gilt bei der Installation bzw. Nutzung einer App wie vorstehend ausgeführt die Prämisse: »Ganz oder gar nicht« oder ein wenig drastischer ausgedrückt »friss oder stirb«. Insbesondere deshalb ist das bis dahin vorherrschende Android Berechtigungsmodell für den Schutz der Ressourcen bzw. der »produzierten Daten« und den daraus ableitbaren Informationen gänzlich ungeeignet. Die Installation einer App bzw. die Bestätigung der Zugriffsrechte ist daher, um es klar zu sagen, mit einem Kontrollverlust zu beschreiben. Dieses insbesondere deshalb, weil man ab diesem Zeitpunkt jegliche »Macht« über die Ressourcen in die Hand der jeweiligen App legt. Will ein Nutzer der App diese Berechtigungen entziehen, bleibt ihm praktisch nichts anderes übrig als die »Notbrems« zu ziehen, indem er die App deinstalliert und ihr damit sämtliche Berechtigungen nimmt.
Bei Android 6 hat Google zwar Verbesserungen am Berechtigungsmodell vorgenommen, aber gleichzeitig neue Schwächen geschaffen und bestehende übernommen.
An dieser Stelle rufen wir uns nochmal die Schwächen des »alten« Berechtigungsmodells in Gedächtnis und bewerten sie in Bezug auf Android 6 nochmal neu:
- Erste Schwäche – Berechtigungsdschungel: In Summe hat Android 6 nicht weniger Berechtigungen als seine Vorgänger nämlich über hundert verschiedene. Auf den Nutzer mag dieses zwar, u.a. aufgrund des neuen »Designs« des Betriebssystems anders wirken, denn das Hinweisfenster vor der App-Installation wurde vollständig entfernt und die kontrollierbaren Berechtigungen in »übersichtliche« Gruppen zusammengefasst. Der angesprochene »Berechtigungsdschungel« im Hintergrund ist jedoch nach wie vor vorhanden, und wurde durch ein entsprechendes Design »entverkompliziert«.
- Zweite Schwäche – Unzureichende Informationspolitik: Wie bereits dargestellt, hat sich die Informationspolitik beim Android-Betriebssystem nach und nach weiter verschlechtert. Der Nutzer erfährt daher in Android 6 erst über ein umständlich zu erreichendes Untermenü, auf welche Berechtigungen und damit Ressourcen eine App tatsächlich zugreifen kann / darf.
- Dritte Schwäche – Grobgranularität: Die Trennung zwischen den unterschiedlichen Ressourcen hat sich in Android 6 nicht zum Besseren gewandelt. Daher können Apps zum Beispiel weiterhin ohne Probleme die Berechtigung »Telefonstatus und Identität abrufen« ausnutzen, um sensible Informationen wie die IMEI oder die Seriennummer der SIM-Karte auszulesen. Dem Nutzer gegenüber wird die Notwendigkeit für diesen Zugriff dann oftmals als »Feature« verkauft, um die aktuelle Tätigkeit einer App für die Dauer eines Anrufs zu pausieren.
- Vierte Schwäche – Fehlende Transparenz: Die mit Android 6 neu eingeführte Rechteverwaltung ermöglicht erstmals eine eingeschränkte Kontrolle über die Berechtigungen. Sofern eine App für Android 6 angepasst wurde, wird dem Nutzer beim Zugriff auf eine Ressource ein Hinweisfenster eingeblendet und aufgezeigt, welche Berechtigungen von der App eingefordert werden. Der Nutzer erfährt also dadurch zumindest »grob«, auf welche Information eine App zugreifen möchte. Da die Rechteverwaltung allerdings keine Reglementierung von Einzelberechtigungen erlaubt, bleibt weiterhin unklar auf welche (individuelle) Ressource eine App tatsächlich zugreifen möchte. Gemeinsam mit der weiter vorhandenen Grobgranularität der Zugriffsmöglichkeiten fehlt daher auch in Android 6 die Transparenz, auf welche (Nutzer-)Daten eine App tatsächlich zugreift, geschweige denn, wofür die gesammelten Daten weiter verwendet werden.
6. Fazit
Mobile Endgeräte wie Smartphones beinhalten eine Vielzahl an detaillierten Informationen über den Nutzer und seine Aktivitäten. Das fängt beim Namen des Nutzers an, geht über diverse eigene, aber auch fremde Kontaktdaten wie bspw. Telefonnummer, Adresse(n), E-Mail bis hin zum aktuellen Aufenthaltsort und seinen Plänen für die nächste Zeit. Darüber hinaus gehören dazu aber auch eine Reihe von eindeutigen Identifikationsmerkmalen (des Smartphones), wie etwa die IMEI-, MAC-Adresse oder die Geräte-ID. Werden diese Informationen mit anderen auf dem Gerät bereits gespeicherten Daten, installierten Anwendungen, Nutzerkonten oder den aktuellen Standorten verknüpft und über eine lange Zeit – in allen »Lebenssituation« des Nutzers – »mitgeschnitten«, entsteht nach und nach »der gläserne«, vollständig transparente Mensch. Insbesondere aus wirtschaftlichen Interessen werden Daten für Werbung, Analyse und Tracking-Zwecke kommerzialisiert und dabei die Privatsphäre der Nutzer weitgehend ignoriert. Darüber hinaus werden immer mehr »Missbrauchsszenarien« dieser Daten bekannt, die weit über die »vermeintliche« harmlose Datensammlung für Werbezwecke hinausgehen.
Angesichts der aufgezeigten Schwächen eignet sich das Android Berechtigungsmodell nach meiner Auffassung nicht, das Recht auf informationelle Selbstbestimmung des Nutzers und der Rechte der mit dem Nutzer in Verbindung stehenden weiteren Betroffenen zu wahren. Vielmehr hat dieses stetig fortentwickelte Modell dazu beigetragen, dass Smartphone-Nutzer die Möglichkeit zur Bewertung der Relevanz ihrer eigenen Daten immer mehr verloren haben. Daher gilt: Wer seine Freiheit und Autonomie zurückerlangen möchte, dabei aber nicht auf alle Vorzüge eines Smartphones bzw. Androids verzichten möchte, dem kann ich nur die Artikelserie »Your phone – your data« an Herz legen. Eigentlich alternativlos. ;-)
Hinweis: Die komplette Analyse mit mehr Details und Ausführungen wird demnächst unter dem Titel »Die Schwächen des Android Berechtigungsmodells« im Werk Information Security Management erscheinen.
Über den Autor | 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.
Unterstü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.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
XPrivacy – Android ohne Google?! Teil6
Android Berechtigungen – Alles oder nichts
F-Droid und App-Alternativen – Android unter Kontrolle Teil3
F-Droid und AFWall+ – Android ohne Google?! Teil4
35 Ergänzungen zu “Das Android Berechtigungsmodell: Ein perfides Konstrukt”
Wenn 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-ForumAbschließ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.
Danke für den, mal wieder, genialen Artikel.
Die Fragen die sich mir stellen:
a – Welche Alternativen OS gibt es für Smartphones die wirklich was taugen? Nicht nur was die Qualität, Stabilität und Sicherheit betrifft, sondern auch die genügen Apps bieten um von Android weg zu kommen? Mein Traum wäre immer noch ein vollständiges Linux-OS für mein Smartphone. Ubuntu kann man ja angeblich inzwischen vergessen?
b – Bringen die super Tutorials hier in dem Blog bzgl. Absichern des Smartphones was wenn es im Kern des OS schon Sicherheitslücken gibt? Sind die Apps zum absichern nicht nur ein kratzen an der Oberfläche?
ad a)
Zu Android gibt es zur Zeit noch keine Alternative. Das beste was wir zurzeit haben sind Custom-Roms (CopperheadOS, OmniROM, Cyanogenmod, selbst kompilierter Rom aus AOSP etc). Vorerst also Custom-ROMs bis wir irgendwann hoffentlich Linux am Smartphone läuft.
ad b)
Ich glaube hier müssen wir zwischen Privacy und Security unterscheiden.
Aus Privacysicht bringt einem die Artikelserie zum Thema „Android ohne Google“ sehr sehr viel. Ein Custom-ROM, keinerlei Googledienste, das Sperren der Google Adressräume und das Beschränken der Internetverbindung und der Rechte der Apps mit Hilfe von Afwall+ und Xprivacy sind ein enormer Gewinn an Privatsphäre.
Sicherheit ist ein anderes Thema.
Das Hauptproblem bezüglich der Sicherheit in Android ist die sogenannte Android Fragmentierung. Google veröffentlicht am Anfang des Monats für seine Geräte Sicherheitsupdates, doch die meisten Hersteller sind zu faul diese regelmäßig auszuliefern und wollen sich den Aufwand dieses Supports nicht leisten.
Dies führt jedoch zu weit klaffenden Sicherheitslücken in allen nicht Nexus Geräten. Abhilfe schafft hier nur ein CustomROM.
Die Artikelserie von Mike hilft bezüglich der veralteten Androidversion und gibt dir eine deutlich freingranularere Kontrolle über die Android-Sandbox, was sowohl in Punkten Privacy als auch Security etwas bringt.
Es bleiben jedoch noch ein paar Securityprobleme übrig.
Ein Problem ist der veraltete Linux Kernel. Die meisten Android Versionen laufen mit dem Kernel 3.4 oder 3.10. Wegen dem Aufwand des Portierens der Treiber, wird eine veraltete Kernelversion eingesetzt die jedoch „Privilege-Escalation“-Vulernabilities enthalten. Diese Sicherheitslücken erlauben es uns auch unsere Androidgeräte zu rooten.
Weiters hat die JavaVM von Android einen besch***** Zufallzahlengenerator, deshalb wurden 2013 relativ viele Bitcoin Börsen ausgeraubt. Ich weis jedoch nicht ob dieser Zufallszahlengenerator mittlerweile verbessert wurde. Vielleicht hat ja Mike ein paar Infos diesbezüglich.
Ein weiteres Sicherheitsproblem ist das proprietäre HiddenOS. Zusätzlich zum normalen Betriebssystem (Android, iOS etc) existiert ein weiteres verstecktes Betriebssystem, welches für die Steuerung des Basebandprozessors zuständig ist. Dieses Betriebssystem ist proprietär und niemand weis was es im Detail macht. Hier würde uns auch eine Linuxversion and Smartphone nicht helfen.
Einen interessanten Ansatz bietet CopperheadOS, was sich zur Zeit in der Beta befindet und diverse Sicherheitsprobleme in Android behebt. Hier der Artikel von Mike zu dem Thema: https://www.kuketz-blog.de/copperhead-os-sicheres-open-source-android/
Somit zu Fazit:
Mit einer aktuellen Androidversion ist man halbwegs sicher. Jedoch würde ich meinem Smartphone zB niemals meinen PGP Private-Key anvertrauen. CopperheadOS ist zurzeit die beste Lösung die wir haben, jedoch hoffe ich, dass wir bald Linux Distros auf unseren Smartphones haben.
Wow… Vielen Dank für die sehr ausführliche und auch leichtverständliche Antwort.
CoperheadOS werde ich mir mal unbedingt näher ansehen.
Allerdings würde ich mir, so wie Du auch, am liebsten ein Linux auf dem Smartphone wünschen, dass sich genau so bedienen lässt wie auf nem PC.
Immer wieder halten mich die Artikel Ihres Blogs erfolgreich davon ab, mit der Nutzung eines Smartphones zu beginnen. Aus dem vorliegenden Beitrag schließe ich, dass sich daran auch mit der neuen Androidversion nichts ändern wird.
Damit bin ich ein Beispiel dafür, dass >Your phone – your data< nicht "alternativlos" ist – auch in einem Umfeld, in dem das Smartphone flächendeckend genutzt wird.
Vielen Dank für Ihre kritischen Artikel, ich werde das Thema weiter verfolgen.
Schon mal CopperheadOS angeschaut? Ist für die aktuellen Nexus-Smartphones verfügbar.
https://copperhead.co/android/
Ja hier: CopperheadOS: Sicheres Open-Source Android!?
Aber das löst die angesprochene Problematik nicht.
Bleiben wir bitte beim Thema: Das Android Berechtigungsmodell.
Traurig und wahr.
Dem Artikel hier kann ich nur zustimmen.
Ich verwende seit Android 4.3 den versteckten App Ops, auch wenn das nur eine kleine Hilfe ist, aber daran seh ich schon, wie Google-Play-Dienste über 140 000 Mal versucht hatten den Standort abzufragen, obwohl jede Standortbestimmung, auch die von Google, „abgestellt“ ist.
Wem seine Daten und Privatspähere Wert ist, sollte nur Apps installieren die WIRKLICH benötigt werden.
… und Google komplett vom Gerät verbannen. ;-)
@Niemand
Was Mike meinte ist, dass in Android Geräten bereits Apps vorinstalliert sind, die sehr viele Berechtigungen haben und sich nicht deinstallieren lassen. Zumindest nicht ohne root.
Die scheinheilige Vorgabe, READ_PHONE_STATE würde (alternativlos) benötigt, um eine Aktivität bei eingehendem Telefonanruf zu pausieren, ist auch ausschließlich der Bequemlichkeit geschuldet. Und natürlich der Tatsache, dass die entsprechenden Entwickler-Dokumentationen genau dies behaupten.
Dass es auch anders geht, kann man u.a. bei Stack Exchange unter https://android.stackexchange.com/questions/605/why-do-so-many-applications-require-permission-to-read-the-phone-state-and-ident/62968#62968 zum Thema „Why do so many applications require permission to read the phone state and identity?“, relativ am Ende unter „Updates“ finden:
> And yes, there’s a way to achieve the same (detecting incoming calls) without the READ_PHONE_STATE permission, as e.g. pointed out by Arno Welzel². As an incoming phone call would trigger the ringer, that event could be used with onAudioFocusChange(), which does not require any special permission: if triggered by that, the app could check the CallState (again, without any special permission required) to see whether there’s an incoming call.
² https://arnowelzel.de/en/android-and-read_phone_state
Danke Izzy. Das war mir bisher nicht bekannt! :)
Immer gern, Mike! Ist den wenigsten bekannt – weshalb sich diese perfide Situation ja auch so hartnäckig hält. Google hat da auch kein besonders großes Interesse an Aufklärung, und wird den entsprechenden Eintrag in der Entwicklerdoku kaum in näherer Zukunft entsprechend anpassen. Und somit tappen immer weitere (unschuldige) Entwickler in diese Falle – da sie von der Alternative kaum etwas erfahren.
Oder zu bequem sind, den etwas schwereren Weg zu gehen: Mit der Permission registriert man einfach einen Listener, und fertig. Ohne registriert man zwar auch einen Listener, muss dann aber noch selbst prüfen, was eigentlich los ist (ist der AudioFocus jetzt auf dem Rington-Kanal? Wenn ja, liegt ein eingehender Anruf an?) – es sind also grob zwei zusätzliche Schritte nötig. Die allerdings für mehr Privatsphäre sorgen.
Super Artilel! Vielen Dank für die Mühe.
Schade ist, daß Cyanogenmod seinen Installer eingestellt hat bzw. nicht weiterentwickelt für aktuelle Geräte. Ich fürchte, daß es eine Großzahl interessierter Anwender bereits am Einstiegspunkt außerordentlich überfordert das ROM zu installieren. Der seinerzeit via Play Store verbreitete Installer von Cyanogenmod war eigentlich eine ideale Abhilfe.
Eigentlich ein guter Vergleich zum Linux-Desktop. Wenn ein Anfänger versuchen soll Gentoo oder Slackware zu installieren, dürfte das ähnliches Resultat liefern. Hier fehlt ein ROM, welches, ähnlich einfach wie bei z.B. Ubuntu, Mint oder OpenSuse, eine einfach verständliche grafische Installationsmöglichkeit bietet. Hier hinken die ROMs m.W.n. hinter dem Linux-Desktop hinterher.
Der Installer hat aber auch gleich Gapps mitinstalliert, dessen Entfernung den Standardnutzer wahrscheinlich vor die größere Herausforderung stellt.
Den Vergleich mit Gentoo finde ich etwas übertrieben. Bei einem Google Nexus oder Oneplus sind es genau 2 befehle in der Konsole um den Bootloader zu unlocken und das Recovery zu flashen, danach Backup, full wipe und CustomROM installieren.
Die Installation und Wartung von Gentoo ist hier im Vergleich doch etwas aufwändiger ;-)
Das schlimmste an der Grobkörnigkeit der Berechtigungen ist die Einstufung der Berechtigung: ,,Voller Netzwerkzugriff“ (Internetzugriff) als ,,normal“ und die Tatsache, dass diese Berechtigung nicht mal in den Einstellungen zu finden ist.
Der Internetzugriff ist die mit Abstand mächtigste Berechtigung, da die App nur dadurch Daten versenden kann.
( Eine App, die auf alle Api- und Datei-Resourcen zugreift, aber kein Internetzugriff hat ist vergleichsweise sehr sicher)
Super Beitrag Herr Kuketz, danke für Ihre Mühe!
Aber eins möchte ich hier noch loswerden. Ich habe das Gefühl, die Thematik wird sehr stark aus der Perspektive des „IT-Profis vom Elfenbeinturm“ behandelt. 99% der Menschen dürften z.B. mit der hier vorgestellten Problematik, aufgrund fehlender Alternativen und „IT-Kompetenzen“, einen neuen Weg (ohne Google) nicht ohne weiteres einschlagen (können/wollen).
Vielleicht sollte man das Fazit/die Lehre in zwei Kategorien teilen. Eins für Experten, eins für Laien.
Bezogen auf dieses Thema hätte ich mit meinen bescheidenen „Kenntnissen“ für die Laien vorgeschlagen, wenigstens eine Firewall (NetGuard ohne Root) zu verwenden, wenn man denn schon nicht auf Googles Android verzichten kann und so den Abfluss der Daten wohlmöglich zu begrenzen (wenn die Annahme denn stimmen sollte).
Gruß Citizen X
Vom Elfenbeinturm bin ich nicht. Kennst du jemand, der da wohnt? ;-)
Spaß beiseite. Die Einteiligung des Fazits in zwei Kategorien ist eine gute Idee. Vielleicht hole ich das noch nach. Ansonsten muss man aber ganz klar sagen, das Hauptproblem ist bei vielen nicht die fehlende IT-Kompetenz, sondern schlichtweg die eigene Bequemlichkeit.
Nicht ganz.
Für die Installation von custom roms und das Verwenden von Xprivacy sind gewisse
technische Kenntnisse notwendig. Zudem könnten kleine Fehler bei der Installation das Gerät unbrauchtbar machen. Man musst nicht nur die eigene Bequemlichkeit überwinden, sondern viel Mühe und Zeit investieren. Nicht jeder hat viel Zeit und Freunde, die auf Whatsapp verzichten:-)
Alles richtig. Es gibt aber auch schon Geräte, wie zum Beispiel das Fairphone, das ohne GAapps und Co. auskommt. Und XPrivacy ist nicht zwangsläufig notwendig. Viel wichtiger ist die Auswahl datenschutzfreundlicher Apps.
Der Aufwand lässt sich also auch geringer halten. Aber man muss sich eben damit beschäftigen. Und das mit der fehlenden Zeit ist einfach eine Ausrede, die meine Theorie der Bequemlichkeit nur stützt. Zeit hat jeder, es ist nur eine Frage wofür er diese verwendet.
In der Tat spielen Bequemlichkeit, Desinteresse für Privatssphäre/Datenschutz und/oder mangelnde IT-Kenntnisse eine große Rolle, ob man sich mit diesem Themengebiet befasst. Jeder hat Zeit für Pokemon Go und Zombie Shooter, aber keine Zeit sich mal zu fragen, wohin die eigenen Daten auswandern. Wie Sie sagten Herr Kuketz, man muss seine Zeit sinnvoll verwenden ;)
Mike, wo ist hier der „+1 Button“?
Allerdings gesellt sich zur Bequemlichkeit oft auch das „mir doch egal“ sowie das „nicht zu verbergen“ (letztere Gruppe möge sich bitte eine 360° Cam mit Mikrofon in Schlafzimmer sowie Bad installieren, die Ports freischalten, und die Web-Adresse breitflächig kommunizieren – vorher glaube ich ihr das „nichts zu verbergen“ einfach nicht ;)
Wären diese Punkte nicht, würde zumindest so manche App nach dem Lesen der angeforderten Berechtigungen (etwa bei AppBrain, wo das weit bequemer geht als bei GPlay – und man auch gleich noch sieht, welche flurrigen Werbemodule mit drin hängen) gar nicht mehr installiert. Aber wer liest die schon! Wer sowas liest, liest am Ende auch noch AGBs und anderes „Kleingedrucktes“, wo kämen wir da hin…
‚So benötigt eine »normale« Taschenlampen-App theoretisch nur die Berechtigung »Bilder und Videos aufnehmen«. Ohne eine solche Berechtigung wäre die App nicht in der Lage, die intern im Smartphone verbaute LED-Leuchte anzusteuern, um sie dann auf Knopfdruck an- bzw. auszuschalten‘.
Hallo Mike, erstmal großen Dank für Deinen aufschlusssreichen Aritkel! Die App ‚Lampe de Poche‘ benötigt die o.g. Berechtigung allerdings offensichtlich nicht, denn die habe ich unter Android 4.1.2 mit X-Privacy gesperrt und die App funktioniert trotzdem problemlos.
Wie ist das zu erklären?
Das liegt vermutlich an XPrivacy, das den Zugriff bzw. die Java-Methode »enable_fashlight« (vereinfacht dargestellt) erlaubt, aber den Zugriff auf weitere Kamerafunktionen verbietet.
Danke für den Tip! Hab die Lampe getauscht :-)
Sehr schön!
Ich wüsste gern noch, ob GCM (Google Cloud Messaging, neu nun: FCM)
https://en.wikipedia.org/wiki/Google_Cloud_Messaging
und/oder Apples APN nicht dafür sorgt, dass die sowieso alle möglichen Metadaten auf ihre Server bekommen, weil fast jede App, auch die Telefon/Dialer-App, diese „Services“ doch nutzt?
Daher ist es auch empfehlenswert komplett auf GCM und andere Google Services auf dem Gerät zu verzichten. Wie das funktioniert ist der Artikelserie »Your phone – your data« zu entnehmen.
Und ja, es gibt haufenweise Apps, die ohne GCM und Co. auskommen.
Danke für deine Arbeit im allgemeinen!
Thematisch am Rande dieses Artikels habe ich eben mal die Geräteliste von CyanogenMod überflogen. Mir fällt auf, daß aktuelle Geräte kaum auf der Liste zu finden sind. Weichen die Hersteller zunehmend auf eigenentwickelte Prozessoren ab, was es CM schwer macht das ROM für das Gerät anzubieten?
Welche einigermaßen aktuelle Geräte könnt Ihr mit CM empfehlen?
Habe mir auch die Geräte mit CyanogenOS angesehen. Aber wer weiß ob und wann mal Aktualisierungen für die Wilyfox- oder BQ-Geräte mit CyanogenOS kommen. Aufgrund der jüngsten Entwicklung bei CyanogenOS ist hier die künftige Versorgung leider ungewiss.
Auch scheint mit Android 7 durch verified boot [1], [2] das rooten und die Erstellung von CustomROMs deutlich erschwert zu werden. Eine bedenkliche Entwicklung im Androidumfeld m.E. nach.
[1] https://www.zdnet.de/88275111/android-7-0-nougat-erzwingt-sicherheitsfunktion-verified-boot/?PageSpeed=noscript
[2] https://winfuture.de/news,93244.html
Man braucht Device Tree Blobs ja nicht nur für die Prozessoren, sondern für die sämtliche Hardware des Smartphones (Touchscreen, etc). Besonders Samsung wehrt sich immer wehementer gegen Modifikationen und rückt auch keine Device Trees etc raus.
Auf der Prozessorseite sind Qualcom Prozessoren anzuraten. Für die Samsung eigenen Exynos und die HiSilicon Kirin (Huawei) ist es extrem schwer Custom ROMs zu entwickeln.
Welche Geräte:
Die Google Nexus Reihe ist aus Sicht von Custom ROMs immer empfehlenswert, da man sich dafür selbst AOSP kompilieren kann und auch CustomROMs quasi sofort bereitstehen. Von daher Nexus 5X oda Nexus 6P oder noch besser auf die neue Generation warten, die mittlerweile kurz vor Release steht.
Aus Privacysicht ist wahrscheinlich CopperheadOS oder Omnirom interessanter als CM, wenn sowieso ein neues Gerät angeschafft wird. Copperhead unterstützt jedoch nur die Nexus Modelle und Omnirom unterstützt die Nexus Modelle + das LG G4 und ein paar Oppo Geräte.
Kurz vor dem Marshmallow Release wurde auch gesagt, dass kein dauerhaftes Root mehr möglich sein wird. Dies war jedoch nur von sehr kurzer Dauer. Abwarten, Chainfire findet sicher einen Weg ;-)
Hallo,
generell braucht Cm immer die Treiber für das Device X, wenn die Hersteller wie zb. Samsung diese nicht bereitstellen, ja dann wird es schwer. Gibt es keinen Aosp build von dem Device (wo man zb die Treiber extrahieren könnte) muss man andere Wege finden.
Cm hat m.m nach Fehlentscheidungen begangen, die Partnerschaft mit MS ist mehr als fragwürdig und der Streit mit den Entwicklern von OnePlus One hat dazu geführt, dass diese ihr eigenes Android Rom entwickelt haben.
Wegen deiner Frage: CM Smartphone, kauf dir ein Nexus 5x, günstig und die Treiber sind lange verfügbar!
Wenn man einmal vergleicht eine Nexus S – wo die Hw sehr betagt ist, kann noch passabel mit Android 4.4 und den neuesten Android Patchlevel betrieben werden. Wenn man vergleicht wie schlecht die HW von diesen Gerät ist dann erkennt man, wie viel Potenzial in Android steckt (1ghz Einkerner mit 256mb ram, durch den optimierten CM Kernel sind knappe 410 mb ram möglich, + Ram-kompremierung)
Schauen wir uns nun noch die anderen Geräte der Nexus Serie an, das Galaxy Nexus wird schon lange nicht mehr von Google supported, es gibt aber einen haufen von roms mit aktuellen android 6.Das Nexus 4 hat von google her aber den Todesstoß bekommen, kann aber passabel mit einem
x beliebigen anroid 6 rom betrieben werden!
Zu deinen Bedenken wegen „verified Boot“ – es hat Sinn wie vieles in Linux nur es wirft dir beim customizing steine in den weg. Wenn der Bootloader offen ist dann, erkennt das Rom dies und „verified Boot“ wird nicht scharf gestellt. Somit wird auch ein ungültiger code booten und Xposed in Verbindung mit einem Custom rom wird sehr wohl funktionieren.
Wenn man aber den Bootloader nicht entsperren kann, treten sehr essenzielle Problem auf.
„verified Boot“ Ist eben nur scharf gestellt (strikt) wenn eben der Bootloader gesperrt ist, dann bietet dir das rom bei fehlerhaften Boot Vorgängen die Wahl, in einem Safemode zu wechseln.
Das heißt, hat man ein gerootetes Geräte wo eine gesperrter Bootloader vorliegt, wird „verified Boot“ ein grobes Problem in dieser Hinsicht werden. (Bei manchen Geräten lässt sicher der Bootloader nicht entsperren)
Wie gesagt Nexus-Geräte sind sehr leicht zu rooten und die Entsperrung des Bootloaders ist immer möglich. So lange googel die Marke „Nexus“ nicht, Zahnlos macht ist man mit diesen Geräten auf der sichersten Seite!
Grüße Master of Disaster
Hi Fleischwolf,
Ich habe ein Wileyfox Swift, und bin von dem Teil begeistert (eine Akkuladung reicht bei mir normalerweise fast eine Woche – und alles reagiert flüssig). Klar kommt es mit CyanogenOS daher – aber das Team dahinter ist das gleiche, welches auch an CyanogenMod arbeitet. Somit stehen letzterem sämtliche notwendigen Quellen für das Gerät automatisch zur Verfügung. Daher gibt es natürlich auch ein passendes CyanogenMod für das Swift (Marshmallow steht damit schon bereit – bzgl. Nougat habe ich noch nicht geschaut): Man ist also weder von der kommerziellen Variante abhängig, noch muss man mit den „zusätzlichen Apps“ leben.
Vielen Dank für diesen aufschlussreichen Artikel. Es ist super dass diese Informationen hier geteilt werden und auch noch kostenlos dazu.
Hier geht es jetzt explizit um Android 6.x aber wäre es möglich einen Artikel über den Datenschutz bei IOS 9.x zu verfassen? Gerade im Hinblick auf das offensive Statement von Tim Cook zu diesem Thema? Das wäre sehr interessant. Ich habe zu einigen Fragen den Datenschutzbeauftragten von Apple angeschrieben z.B welche Apps auf die Nachrichten API zugreifen dürfen. Dies ist nach Aussage von Apple keiner anderen App gestattet. Leider fehlt mir das Know How diese Analysen selbst durchzuführen Der letzte Post hier im Blog behandelt ja noch iOS 6.. Vlt. hat ja jemand auch schon einen Artikel darüber gefunden und könnte diesen hier verlinken. Vielen Dank im Voraus. Gruß Olaf
Auf heise war neulich eine Abhandlung in verbindung mit whatsapp und ios:
https://www.heise.de/security/artikel/Analysiert-Spioniert-die-undokumentierte-WhatsApp-Umstellung-3295090.html
Beantwortet zwar Deine Frage vermutlich nicht ganz, in diesem Zusammenhang jedoch durchaus interessant.
Vielen Dank. Der Artikel ist mir „durchgerutscht“ . Ist auf jeden Fall lesenswert.
Bis Android 4.4 habe ich mit wachsender Begeisterung SRT AppGuard verwendet. Das kann die Berechtigungen sehr granular steuern, und wenn man 5 € investiert, hat man auch gleich noch eine Black- und Whiteliste für die Hostnamen/IPs pro App. Damit kann man alle Apps von Werbung befreien.
Leider funktioniert es mit 5.x und höheren Versionen nicht mehr richtig.
http://www.srt-appguard.com/