Android Permissions – Apps und ihre Berechtigungen

Jedesmal wenn wir eine App aus dem Android Market installieren, informiert uns dieser über die Rechte die diese App benötigt und wir müssen dieser Liste zustimmen bevor die App installiert wird. Grundsätzlich darf eine App erstmal gar nichts und deshalb benötigt sie eben diese Rechte, um auf Resourcen, Verbindungen und Daten zugreifen zu dürfen.

Aktuell gibt es 116 verschiedene Rechte für Android Apps. Deshalb ist es meist nicht ganz einfach den Überblick zu behalten, welches Recht was bedeutet und ob eine App ein gewisses Recht auch wirklich benötigt, oder ob ein gewisses Recht möglicherweise ein Hinweis auf eine ungewollte oder schädliche Funktion der Applikation sein könnte.

Um etwas Licht in die ganze Sache zu bringen, werde ich hier nun über die gängisten, wichtigsten und “gefährlichsten” Permissions von Android Apps berichten und erläutern wozu sie genau gut sind und warum eine App sie benötigen könnte.

Standortdaten

Viele Applikationen benötigen Rechte, um auf den aktuellen Standort zuzugreifen. Hierbei unterscheidet Android zwischen ACCESS_COARSE_LOCATION (grobe Standortbestimmung) und ACCESS_FINE_LOCATION (genaue Standortbestimmung).

Die Coarse-Location wird mittels Cell-ID, also mittels der Position der Funkmasten, oder über WLAN Access Points mit Standortdaten bestimmt und ist somit nicht sehr präzise, funktioniert dafür aber auch in geschlossenen Räumen. Dieses Recht benötigen Applikationen, die uns zum Beispiel Daten an Hand der aktuellen Postleitzahl liefern möchten (Restaurants in der Nähe, etc..)

Die Fine-Location erlaubt Zugriff auf die GPS Daten und somit auf sehr viel genauere Positionsbestimmung. Applikationen zur Navigation oder zum Geocachen werden um diese Permission nicht herumkommen. Es kann natürlich auch sein, dass beide Rechte verlangt werden. Das tritt meist dann auf, wenn die App einfach die bestmöglichen Standortdaten braucht (egal ob GPS verfügbar ist oder nicht). Solche Applikationen wollen zum Beispiel unseren Standort auf einer Karte darstellen und das so genau wie es eben gerade geht.

Ein besonderes Recht in Bezug auf Positionsdaten ist ACCESS_MOCK_LOCATION. Dieses Recht erlaubt es einer Applikation eine GPS Position vorzugauckeln. Dieses Recht sollte es in einer fertigen Applikation im Market eigentlich nicht mehr geben. Es dient nämlich eigentlich dem Entwickler dazu, während der Entwicklung GPS Daten testen zu können, ohne mit dem Gerät im Freien herumlaufen zu müssen.

Verbindungen

Viele Applikationen nutzen Webservices, um ihre Funktionalität zu erweitern. Damit eine Applikation aber auf das Internet zugreifen darf, benötigt sie die Permission INTERNET. Dieses Recht wird aber auch für nicht ganz so offensichtliche Zwecke wie das Verbinden mit einem Webservice benötigt.

Eine Applikation mit Werbung zum Beispiel benötigt dieses Recht auch um die Werbung darstellen zu können, da die Werbeeinschaltungen zum Beispiel direkt von Admob gezogen werden. Auch Applikationen welche Facebook oder Twitter integrieren, werden nicht ohne Internet auskommen.

Neben Internet gibt es da aber auch noch andere Verbindungen wie zum Beispiel Bluetooth. Wenn eine Applikation also Permission BLUETOOTH benötigt, darf sie sich mit anderen bereits gepaarten Bluetooth Geräten verbinden und Daten tauschen. Etwas mächtiger ist die Permission BLUETOOTH_ADMIN. Diese erlaubt es nämlich der Applikation sich mit neuen Geräten zu paaren und das möglicherweise ohne, dass der Benutzer es merkt. Dieses Recht sollte man genau hinterfragen, ob es wirklich für die Funktionalität der App nötig ist.

Kostenpflichtige Dienste

Manche Applikationen erwarten Rechte wie CALL_PHONE (Anrufe tätigen ohne die Dialer Applikation zu nutzen und ohne, dass der Benutzer etwas tun muss) und CALL_PRIVILEGED ( Wie CALL_PHONE nur, dass auch Notrufnummern gewählt werden können). Diese Rechte sollte man immer mit Vorsicht genießen, denn um aus einer Applikation einen Anruf zu tätigen, könnte man auch eine Nummer einfach an den Dialer Intent weitergeben, welcher sich öffnen würde und der Benutzer müsste dann selbst auf “Anrufen” klicken. Diese Variante wäre ohne eigene Permission lösbar, da ja eine Standardapplikation für den eigentlichen Anruf geöffnet werden würde und der Benutzer den Anruf sieht und selbst einleiten muss.

Ähnliches gilt für das Recht String SEND_SMS. Dieses Recht erlaubt es der Applikation SMS zu versenden ohne, dass der Benutzer etwas dazu tun muss und das vielleicht sogar an kostenpflichtige Mehrwertnummern. Als Entwickler täte man besser daran, einfach einen Text an die Standard SMS Applikation weiterzugeben und diese dem Benutzer bereits vorbefüllt zu öffnen, er aber selbst auf Abschicken drücken muss. So bleibt das Vorgehen transparent für den Benutzer und man spart sich diese Rechte für die Applikation.

Natürlich gibt es Applikationen, die diese Rechte wirklich brauchen. Dazu gehören vor allem alternative Dialer und SMS Applikationen. Denn diese müssen selbst anrufen und SMS verschicken können, da sie die Standard Applikationen ersetzen sollen.

Persönliche Daten

Viele Applikationen wollen auf persönliche Daten wie SMS (READ_SMS), Kontakte (READ_CONTACTS) oder Termine (READ_CALENDAR) zu greifen. Dies sind zwar alles nur lesende Zugriffe, aber auch hier sollte man immer überlegen, ob dies für die Funktionalität der Applikation wirklich nötig ist. Wenn eine Applikation ein Backup aller meiner SMS erstellen soll, ist READ_SMS voll ok.

Zu diesen Berechtigungen gibt es aber auch schreibende Varianten (also WRITE_CONTACTS..). Diese werden zum Beispiel von Applikationen benötigt, die es erlauben, aus der Applikation einen Termin anzulegen oder auf Grund einer abfotografierten Visitenkarte einen Kontakt zu erstellen.

Etwas gefährlicher ist USE_CREDENTIALS. Das Bedeutet, dass die Applikation am System gespeicherte Accounts (zB. Google Account) nutzen kann, um sich an diesem Service automatisch anzumelden. An sich ist das ein praktisches Feature, aber auch mit Vorsicht zu genießen. Denn wenn diese App eigentlich nicht meine Daten bei einem Service manipulieren können muss, um zu funktionieren, ist hier wohl etwas faul. Wichtig hierbei ist auch noch, dass die Applikation nicht meine Anmeldedaten bekommt, sondern sich das System anmeldet und nur den AccessToken weitergibt. Mein Passwort ist also sicher. So gesehen ist diese Art des Zugriffs auf Services eigentlich sicherer als, dass man in der Applikation selbst User und Passwort hinterlegt.

Speicher

Viele Applikationen wollen Daten auf der SD Karte speichern (Fotos, Backups, …). Dazu ist die Permission WRITE_EXTERNAL_STORAGE notwendig.

Mehr Aufmerksamkeit sollte man den Permissions MOUNT_FORMAT_FILESYSTEMS und MOUNT_UNMOUNT_FILESYSTEMS schenken. Zwar kann mittels UMOUNT nur die SD-Karte zum sicheren Entfernen vom System getrennt werden, aber FORMAT erlaubt es den gesamten Inhalt der SD-Karte zu löschen. Diese beiden Permissions sollten nur von Applikationen zur Verwaltung von SD-Karten benutzt werden.

Konfiguration

Es gibt Applikationen, welche vereinfachten Zugriff auf Systemeinstellungen erlauben, also Applikationen zur Systemadministration. Bei diesen sollte man sich über Permissions, wie SET_PREFERRED_APPLICATIONS (setzen der bevorzugten Applikation für eine gewisse Aktion. zB. Standard Webbrowser), WRITE_SETTINGS (Setzen von Telefoneinstellungen) oder DEVICE_POWER (Zugriff auf das Power Management) nicht wundern.

INSTALL_PACKAGES und DELETE_PACKAGES erlauben das Installieren und Deinstallieren von Applikationen. Viele Filemanager dürfen das, um direkt aus ihnen heraus .apk Files zu installieren.

Fazit

Wenn man weiß, was die einzelnen Permissions bedeuten, hilft der gesunde Menschenverstand bei der Kontrolle, ob eine App ein Recht wirklich braucht oder nicht.

Denn wenn eine Diktiergerät-App RECORD_AUDIO benötigt, ist das normal. Benötigt diese App aber auch noch READ_CONTACTS und INTERNET ohne dafür Funktionen bereitzustellen, ist das ein Hinweis darauf, dass diese App vielleicht meine Kontaktdaten an Dritte weitergibt, ohne mich zu fragen. Wichtig ist es genau zu lesen und zu überlegen, ob eine App wirklich nur das darf, was sie braucht, um zu funktionieren.

Hier sind natürlich auch immer die Entwickler gefordert. Denn schließlich sind sie es, die die Permissions eintragen und dafür sorgen sollten, auch nur das einzutragen, was sie auch für die angegebene Funktionalität der App verwenden.

Eine vollständige Liste aller Permissions mit Erklärung findet ihr hier und wie ihr ohne Vorkenntnisse und ohne Root Apps Berechtigungen entziehen könnt, findet ihr hier.