IzzyOnDroid Twitter


Say Thanks:
Flattr this!
↓ Your product here? ↓
Das Inoffizielle Android-HandbuchAndroid kennenlernen, Tipps & TricksDas Inoffizielle Android-Handbuch
Android kennenlernen, Tipps & Tricks
Für EUR 16,99 bei Amazon kaufen
Das Inoffizielle Android SystemhandbuchTiefer ins System einsteigenDas Inoffizielle Android Systemhandbuch
Tiefer ins System einsteigen
Für EUR 10,00 bei Amazon kaufen
Die besten Android-AppsDen Androiden austattenDie besten Android-Apps
Den Androiden austatten
Für EUR 10,00 bei Amazon kaufen
 
enhelp

Warum verlangen manche Apps zu viele Permissions?

Snapped DOM SKG Euro Cylinder and Bump Key
Snapped DOM SKG Euro Cylinder and Bump Key; © Dennis van Zuijlekom (CC-BY)
Quelle: Flickr

In den meisten Fällen ergeben die von einer App verlangten Permissions durchaus Sinn: Sie benötigt INTERNET für den Zugriff auf in der Cloud / bei einem Web-Dienst gespeicherte Daten, VIBRATE zur Erlangung der Aufmerksamkeit des Anwenders, sogar der Zugriff auf den Standort lässt sich meist erklären. Doch hin und wieder erscheint eine der Permissions doch recht merkwürdig: Entweder bleibt unbegreiflich, wozu die App sie benötigt – oder der Anwender hat nicht einmal eine Vorstellung davon, was diese überhaupt bedeuten soll. Letzteres ist besonders ärgerlich, wenn der „fragliche Kandidat“ auch in der Liste Android Permissions erklärt bei IzzyOnDroid nicht aufgeführt ist. Was geht hier vor? Welche Gründe könnten dahinterstehen?

Da IzzyOnDroid für die App-Listen seit etwa einem Jahr die Metadaten der Apps (u. a. auch die verlangten Permissions) sammelt und aktualisiert, konnte ich in einigen Fällen einen genaueren Blick in den Kontext werfen. Insbesondere in den Fällen, in denen Permissions nicht in der genannten Liste verzeichnet waren – und ich wissen wollte, was es mit diesen auf sich hat. Die Nachforschungen für sowie die Erstellung der Liste ergänzten das Bild. Dieser Artikel versucht daher, etwas Licht in die Sache zu bringen.

Werbe-Module

Lookout Ad-Network Scanner
Lookout Ad-Network Scanner

Geht es um „Permissions, die für die Funktionalität der App nicht benötigt werden“, führen Werbe-Module fraglos die Liste der „üblichen Verdächtigungen“ an. Da viele Anwender nicht bereit sind, auch nur einen schlappen Euro in Apps zu investieren, kann man den Entwicklern nicht verdenken, dass sie „alternative Methoden der Aufwandsentschädigung“ einsetzen – schließlich steckt eine Menge Arbeit in der Erstellung einer guten App. In den meisten Fällen können wir uns ja durch den Erwerb einer „Pro-Version“ für ein „kleines Taschengeld“ von den unliebsamen Qälgeistern freikaufen. Aber dieser Teil der Gleichung soll hier nicht diskutiert werden.

Eine Permission, die generell mit Werbe-Modulen einhergeht, ist INTERNET – denn von dort kommen schließlich die Werbe-Inhalte. Während einige Module damit bereits zufriedengestellt sind, wollen die meisten natürlich mehr1. Ein etwas aktuellerer Artikel bei EtonDigital zeigt: Von den Topp-400 gratis und Bezahl-Apps...

Obwohl diese Zahlen nicht ausschließlich auf Werbe-Module zurückzuführen sind, wollen die meisten dennoch Zugriff auf den Standort (ACCESS_COARSE_LOCATION). Einige Module machen es gar erforderlich, den Zugriff auf Kontakte (READ_CONTACTS), Anruflisten (READ_CALL_LOG), Browserverlauf und Lesezeichen (READ_HISTORY_BOOKMARKS), und mehr zu gewähren. Da die Module Teil der App werden, erben sie überdies alle Permissions, welche diese für ihre Funktionalität zusätzlich benötigt. Nicht selten sind Entwickler sich gar nicht bewusst, was die dahinter stehenden Werbe-Netzwerke tun (insbesondere mit den gewonnenen Daten) – daher kann ein entsprechender Hinweis durchaus dazu führen, dass in einer neuen Version der App „besonders dreiste Module“ durch „weniger aggressive“ ersetzt werden, die dann auch weniger Permissions erfordern.

Wer herausfinden möchte, inwieweit er/sie betroffen ist, der sollte einen Blick in meine App-Liste für Werbemodule und Privacy-Checker werfen – wo die von mir empfohlenen Kandidaten auch als solche kenntlich gemacht sind. Beispielsweise gibt Lookout’s Ad-Network Scanner & Detector gute Hintergrund-Informationen zu den jeweiligen Werbe-Netzwerken selbst, und der AppBrain Ad Detector erkennt zusätzlich auch „Social SDKs“ und Entwickler-Toolkits. Was uns direkt zum nächsten Kapitel bringt:

Andere Bibliotheken und Implementierungen

Mit READ_PHONE_STATE zugreifbare Informationen
Mit READ_PHONE_STATE zugreifbare Informationen

Warum das Rad neu erfinden? Für viele Funktionalitäten gibt es „Bibliotheken“, welche diese bereits umsetzen. Einige haben es sicher bereits erraten: Eine solche Bibliothek liefert i. d. R. mehr als nur die Funktionalitäten, welche der Entwickler für seine App gerade benötigt. Was dann u. U. auch weitere Permissions nach sich ziehen könnte2. Das kann man meist als „Kollateralschaden“ abtun, und lässt sich nicht immer vermeiden. Zum Glück zieht dies in den meisten Fällen keine größeren Abhängigkeiten nach sich (eher gar keine – hier ist mir auch kein Fall bekannt).

Bibliotheken sind eine Sache – Implementierungen eine andere. Besonders Entwickler, die neu in der Android-Welt sind, müssen sich erst einmal über „best practice” informieren – bekommen jedoch meist Antworten zum Thema „meist genutzt”. Ein klassisches Beispiel: Wie stellt man sicher, dass die App sich nicht mit eingehenden Anrufen „ins Gehege kommt“ (also etwa das Spiel/den Song pausiert)? Google empfiehlt dazu, einen „Listener“ für den Event onCallStateChanged („Anrufstatus geändert“) zu registrieren, was jedoch die Permission READ_PHONE_STATE erfordert3 – eine Permission, die besonders verdächtig wirkt, gewährt sie doch auch Zugriff auf Identitäts-Daten wie IMEI, IMSI, die eigene Telefonnummer, und „kontaktierte Telefonnummern“4. Aber dies ist bei weitem nicht die einzige Möglichkeit – wenn auch die bekannteste und meist genutzte. Wie Arno Wetzel aufzeigt, gibt es einen weit eleganteren und datenschutzfreundlicheren Weg, dasselbe Ziel zu erreichen, der nicht eine einzige Permission erfordert. Er nutzt die Tatsache, dass ein eingehender Anruf per Klingelton signalisiert wird – was „den Audio-Fokus ändert“5. Also registriert man einfach einen „Listener“ auf diesen Event.

Das war nur ein Beispiel – und ich bin sicher, da gibt es weit mehr. Der Screenshot zeigt übrigens, auf was sich mit der Permission READ_PHONE_STATE so alles zugreifen lässt – oder vielmehr, worauf man ohne selbige nicht zugreifen kann, denn ich habe der App diese zuvor entzogen. Es gilt daher, im Screenshot auf die „Lücken“ zu achten.6 Klar erkennen lässt sich dabei: Der CallState ist auch ohne sie ersichtlich, was sich Arno’s Methode zunutze macht.

Ungenügende und sogar fehlerhafte Dokumentation

Davon kann ich aus meinen Erfahrungen bei Erstellung der Permissions list selbst ein Lied singen: Die offizielle Referenz listet nicht einmal alle „Core-Permissions“ auf, von Erklärungen ganz zu schweigen. Die „Google Suche“ nach einer Permission resultiert häufig ausschließlich in einer Liste von Manifest Dateien, in denen Apps deren Verwendung deklarieren. Irgend ein Hinweis darauf, was sich hinter der Permission verbirgt? Fehlanzeige. Wie bekommt man also heraus, welche Permissions man für seine App anfordern muss? Ich frage mich, wie Entwickler das tun. In vielen Fällen vermute ich, „gutes Raten“ gehört zu diesen Methoden. Einmal habe ich gar in den Quellcode-Kommentaren einer App gelesen: „Keine Ahnung, was genau wir hier benötigen – also verlangen wir einfach alles“. Noch Fragen? Seiteneffekte sind hier eindeutig falsche Schlussfolgerungen und Faulheit, siehe unten.

Nicht unbedingt eine Folge ungenügender/fehlender Dokumentation, aber zum Thema passend: Permissions, die es bereits seit Ewigkeiten nicht mehr gibt. Wie beispielsweise ACCESS_LOCATION und ACCESS_GPS, beide aus der pre-1.0-Android-Zeit und lange obsolet7, sollte ihr auftauchen definitiv den Entwicklern zur Bereinigung präsentiert werden. Das ist keine Frage der „Kompatibilität“: Zum Einen ist es recht unwahrscheinlich, dass jemand noch ernsthaft eine pre-1.0 Android Version verwendet (oder die App damit laufen würde), zum Anderen wurde pre-1.0 nie „in die freie Wildbahn“ entlassen8. Daher finden sich diese „antiken Kandidaten“ auch nicht bei IzzyOnDroid – weder in der Liste der Permissions, noch bei den Apps selbst. Da das Android-System sie nicht mehr kennt, können sie auch keinen Schaden anrichten.

Eine sehr interessante Quelle zum Thema „Android Permission System“ im Allgemeinen, und „ungenügende/fehlerhafte Dokumentation“ im Speziellen ist Android Permissions Demystified9. Obwohl das Dokument aus dem Jahr 2011 stammt, und sich auf Android 2.2 „Froyo“ bezieht: Zum Thema unvollständiger, ungenügender, fehlender, und fehlerhafter Dokumentation trifft es nach wie vor ins Schwarze. Einige Auszüge möchte ich an dieser Stelle „frei übersetzt“ wiedergeben:

Wir studieren Android-Anwendungen um zu ermitteln, ob Android Entwickler mit ihren Permission-Requests dem Prinzip geringsmöglicher Privilegien-Anforderungen folgen. Wir entwickeln Stowaway, ein Tool zur Erkennung von Überprivilegierung in kompilierten Android-Applikationen. Stowaway ermittelt die von einer App genutzten API-Aufrufe, und bildet diese Aufrufe sodann auf Permissions ab. Wir verwendeten automatische Test-Tools an der Android-API, um eine „Permission Map“ zur Erkennung von Überprivilegierung zu erstellen. Wir setzen Stowaway auf 940 Apps an und stellen fest, dass etwa ein Drittel überprivilegiert sind. Wir untersuchen die Gründe dieser Überprivilegierung und stellen fest, dass Entwickler dem Prinzip geringsmöglicher Privilegien-Anforderungen zu folgen versuchen, jedoch manchmal aufgrund unzureichender API-Dokumentation damit scheitern.

[ … ]

Android bietet eine Dokumentation für Entwickler, doch deren Permission-Information ist beschränkt. Das Fehlen verlässlicher Information zu Permissions kann zu Entwickler-Fehlern führen. Die Dokumentation zeigt Permission-Requirements lediglich für 78 Methoden auf, wohingegen unsere Tests Requirements für 1.259 Permissions zutage förderten (eine 16-fache Steigerung gegenüber der Dokumentation). Außerdem identifizieren wir 6 Fehler in der Dokumentation der Permissions. Diese Ungenauigkeit veranlasst Entwickler, das Referenz-Material mit Raten und Foren zu ergänzen. Die Verwirrung der Entwickler kan zu Überprivilegierung der Anwendungen führen, weil sie unnötige Permissions hinzufügen, um das korrekte Funktionieren ihrer Apps sicherzustellen.

[ … ]

Von den 78 mit Permissions geschützen API-Aufrufen in der Dokumentation zeigen unsere Tests, dass 6 API-Aufrufe falsch dokumentiert sind. Es ist uns unbekannt, ob die Dokumentation oder die Implementierung falsch sind; ist es die Dokumentation, könnten diese Diskrepanzen Security-Fehler sein.

Drei der Dokumentations-Fehler weisen eine andere Permission aus, als die Tests ermittelten. In einem Fall behauptet die Dokumentation, ein API-Aufruf sei mit der gefährlichen Permission MANAGE_ACCOUNTS geschützt, während er tatsächlich mit der niedriger privilegierten normalen Permission GET_ACCOUNTS durchführbar ist. Ein weiterer Fehler gibt an, der API-Aufruf benötige die Permission ACCESS_COARSE_UPDATES, welche überhaupt nicht existiert10. Als Ergebnis verlangen 5 der 900 von uns in §6.2 studierten Apps diese nicht-existente Permission. Ein dritter Fehler erklärt, eine Methode sei mit der Permission BLUETOOTH geschützt, während sie tatsächlich mit BLUETOOTH_ADMIN versehen ist.

[ … ]

Wir fanden auch einige von der Plattform definierte, aber in der API nirgends genutzte Permissions. Zum Beispiel wird die Permission BRICK nirgendwo verwendet, obwohl sie oft genug als Beispiel besonders katastrophaler Permissions aufgeführt ist. Ihre einzige Referenz findet sich in totem Code, der dem Gerät keinerlei Schaden zufügen kann. Unsere Tests ergaben, dass 15 der 134 von Android selbst definierten Permissions ungenutzt sind.

(Hervorhebungen, Links, und Fußnoten von mir)

Dieses Dokument bestätigt also auch meine Annahme, „gutes Raten“ sei Teil der Methoden, mit denen Entwickler die benötigten Permissions ermitteln. Vom „Klang“ abgeleitet etwa, greifen sie auf MOUNT_UNMOUNT_FILESYSTEMS zurück, um den Intent MEDIA_MOUNTED zu verfolgen. Schon haben wir unser Beispiel einer „Überprivilegierung“, denn die beiden haben nichts miteinander zu tun.

Nebenbei: Einige der Dokumentations-Fehler wurden dem zugehörigen Bug-Tracker bereits 2011 mitgeteilt. Sie existieren noch immer: Im Bug-Tracker, und in der Dokumentation …

Falsche Schlussfolgerungen

Extra Permissions
Extra Permissions

Nicht selnten gehen mit unzureichender Dokumentation auch falsche Schlussfolgerungen einher. Ein häufiges Beispiel: Da gibt es eine Permission namens WRITE_EXTERNAL_STORAGE. Ich kann ihr Gegenstück in der Dokumentation nicht finden, aber es muss ja da sein. Also deklariere ich einfach WRITE_INTERNAL_STORAGE. Klingt richtig – aber eine solche Permission gibt es überhaupt nicht11. Dennoch wird sie von zahlreichen Apps verlangt. Das wirft zwar eine Warnung im Logcat bei der Installation der App (W/PackageManager( 782): Unknown permission android.permission.READ_INTERNAL_STORAGE in package …) – doch der Anwender bekommt dies selten zu Gesicht. Weitere Auswirkungen hat es keine: Es hilft der App nicht, schadet ihr aber ebensowenig. Dass dies bei Veröffentlichung der App noch beibehalten wird, kann zweierlei bedeuten: Entweder wurde nicht richtig getestet – oder eine entsprechende Permission wurde nie benötigt. Das Schlimme daran ist, dass einige Entwickler-Communities und Blogs diese Permission sogar empfehlen.12

Bei AppBrain finden sich solche Permissions im Reiter „Permissions & Concerns” unter „Extra“ (siehe Screenshot). Dieser Abschnitt listet jedoch auch andere (selten benutzte, oder von Apps selbst deklarierte) Permissions auf – nicht nur solche, die gar nicht existieren. Dennoch kann es kaum schaden, in solchen Fällen beim Entwickler nachzufragen – insbesondere, wenn er deren Verwendung nirgends erklärt hat.

Faulheit

Bereits bei ungenügender Dokumentation angeschnitten („Keine Ahnung, was genau wir hier benötigen – also verlangen wir einfach alles“), kann dieser Punkt alles obige zusammenbringen. Code wird (nicht notwendigerweise aus verschiedenen Quellen) einfach kopiert, die möglichen Fehler werden kombiniert. Beim Versuch, etwas zu „fixen“, werden lediglich weitere Permissions verlangt. Zusätzliche Requirements bedeuten nicht zwangsläufig größere Funktionalität, daher sind die Resultate im Regelfall, hm, eben nicht „simply the best“. Wird eine ganze App auf diese Weise konstruiert, darf man sicher davon ausgehen, der einzige Grund war, mit Werbung Geld zu machen. Qualität war garantiert keines der Ziele. Solche Apps sind nicht unbedingt das, was wir brauchen: Sie fördern lediglich die Unübersichtlichkeit der App-Listen. Weshalb sie bei IzzyOnDroid üblicherweise „durchs Raster fallen“, und gar nicht erst in die App Listen aufgenommen werden.

Fazit

Jetzt kennen wir zwar einige Gründe für „überflüssige Permissions“ – doch was hilft uns das? Gibt es etwas, das wir dagegen tun können? In der Tat: Den jeweiligen Entwickler damit konfrontieren. Die Details können zu einer Verbesserung der App führen. Wie bereits bei den Werbe-Modulen ausgeführt, sind sich einige Entwickler der Implikationen nicht einmal bewusst13 – daher könnten (und sollten!) sie für derartige Hinweise dankbar sein. Gleiches gilt für verlangte nicht existierende oder falsch dokumentierte Permissions: Für diejenigen, die sich „besser auskennen“, lassen solche nämlich eine App „unprofessionell“ erscheinen. Gegen Faulheit werden wir kaum etwas ausrichten können – doch bei derartigen Apps hält man ohnehin besser nach dem Original Ausschau ;)

appsprivacysecurity


  1. Tieferen Einblick gewährt u. a. der Artikel Android apps and advertising bei TechRepublic, oder Android ad networks found accessing users’ private data bei FirstPost 

  2. Ich bin kein Android-Entwickler – aber vermutlich ist dies gar nicht der Fall. Wenn die entsprechenden Methoden nicht aufgerufen werden, muss die App auch die jeweiligen Permissions nicht anfordern; nur wie steht es um die Dokumentation dazu

  3. Siehe beispielsweise Detecting incoming and outgoing phone calls on Android 

  4. d.h. die angerufenen und anrufenden Nummern 

  5. Android verwendet mehrere „Audio Kanäle”, z. B. einen für Alarme, einen für Multimedia-Wiedergabe – und einen für „Klingeltöne“. 

  6. Aus meiner Antwort zu Why do so many applications require permission to read the phone state and identity? (bei Stack Exchange) 

  7. Für Details, siehe Stackoverflow: Where can I get a list of Android permissions 

  8. Die erste „kommerzielle“ Android-Version war Android 1.5 (Cupcake) 

  9. Das 11-seitige PDF-Dokument Android Permissions Demystified von Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, und David Wagner hat seinen Ursprung in der „ACM Conference on Computer and Communications Security“ (CCS) 2011, und ist an verschiedenen Quellen verfügbar: bei ACM.ORG (paywalled), bei GoogleCode, sowie verlinkt von Adrienne Porter Felt’s Homepage (Ich führe hier mehrere Quellen auf für den Fall, dass eine davon „verschwindet“). 

  10. Beispiel ACCESS_COARSE_UPDATES: Issue 19192, geöffnet 8/2011 von Adrienne Porter Felt selbst, von einem Mitglied des Android-Projekts am 7.12.2014 für „obsolete“ erklärt (was in 12/2014 wohl so manches Issue betraf, auch wenn es nach wie vor ungelöst ist), von einem anderen Anwender am 20.12.2014 als „still there“ aktualisiert. Hey, liebes Android Team: Bugs verschwinden nicht, indem man einfach die zugehörigen Issues für obsolet erklärt ;) 

  11. Das Gegenstück zu WRITE_EXTERNAL_STORAGE wäre WRITE_MEDIA_STORAGE 

  12. Beispiele: Stack Overflow14, Blogspot. Eine Google Suche nach dieser Pseudo-Permission ergibt über 220,000 Ergebnisse. 

  13. Beispielsweise schreibt Spiegel unter Berufung auf eine FireEye-Untersuchung von 10/2013: Die Entwickler wussten vermutlich nicht, in welchem Ausmaß die eingebundenen Progammbibliothek die Privatsphäre von Nutzern verletzt, Daten überträgt und dabei leicht von Dritten missbraucht werden kann. 

  14. Post gelöscht. Stack Exchange macht einen guten Job beim Entfernen von Falschangaben! Ich habe diesen Post gerade vor ein paar Stunden als „falsch” markiert – und bevor ich diesen Artikel hier publizieren konnte, war der „Falsch-Post” bereits verschwunden. 

2015-01-01