XPrivacy – Android ohne Google?! Teil6

1. Behebung eines »Designfehlers«XPrivacy

Mit den letzten beiden Beiträgen haben wir euch u.a. aufgezeigt, wie ihr ungewollte Datenverbindungen mit der App AFWall+ verhindert und mittels Network Log selbst überprüfen könnt, zu welchen Zieladressen Apps Verbindungen aufbauen wollen. Oftmals mag es praktikabel sein, mit der AFWall+ bzw. iptables bestimmten Apps den Internet-Zugang zu verbieten. Diese Praxis lässt sich jedoch nicht für alle Apps durchhalten, weil einige Apps nur dann ordentlich funktionieren, wenn sie die benötigten Informationen aus dem Internet beziehen. Allerdings sollten wir uns in diesem Zusammenhang immer vor Augen führen, dass sich viele Apps nicht ausschließlich auf den Abruf von Informationen aus dem Internet beschränken. Vielmehr agieren sehr viele Apps nach der Devise »Geben und Nehmen«. Daher versenden sie neben dem Abruf aus dem Internet auch (sensible) Informationen an die App-Anbieter oder sonstige Dritte. Gesteuert und ermöglicht wird diese Informationssammlung und der Versand dieser Informationen durch das Android-Berechtigungskonzept, dem bereits in der Vergangenheit einige Beiträge gewidmet wurden.

Der erste Beitrag diesbezüglich war in der Artikelserie »Datenschutz für Android« zu lesen. Dort habe ich euch Tools wie PDroid, LBE Privacy Guard und SRT-AppGuard vorgestellt, die es ermöglichen, den Zugriff auf sensible Daten zu beschränken. In weiteren Beiträgen haben sich neue Tools wie OpenProid, PDroid 2.0 und XPrivacy dazugesellt. All diese Apps sind heutzutage zwar noch verfügbar, doch hat sich insbesondere XPrivacy aufgrund seiner mannigfaltigen Einstellungsmöglichkeiten zum unangefochtenen »Klassenprimus« entwickelt. Da diese App für unser Projekt »Your phone – Your data« eine unverzichtbare Komponente darstelle, wollen wir diese mit dem vorliegenden Beitrag besonders würdigen.

Um nachvollziehen zu können, weshalb ein Tool wie XPrivacy für unser Projekt so unerlässlich ist, empfehlen wir euch an dieser Stelle den etwas älteren Beitrag »Android Berechtigungen – Alles oder nichts«, der sich kritisch mit dem Android-Berechtigungsmodell beschäftigt. Aufgrund von »Modifikationen« von Google an diesem Modell, ist die in diesem Beitrag behandelte Thematik aktueller denn je. Nach unserer Auffassung wird durch den verlinkten Beitrag insbesondere deutlich, welches dubiose Geschäftsmodell einige App-Entwickler verfolgen, um sich zugunsten des eigenen Geldbeutels ungefragt an unseren sensiblen Daten zu bereichern. Diese durchaus sehr fragwürdige Geschäftspraxis wird durch das intransparente Android-Berechtigungsmodell und Googles eigenem Interesse an unseren gesammelten, teils hoch sensiblen Daten, noch weiter begünstigt.

Dieser Beitrag ist Teil einer Artikelserie:

Update

März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert. Sie lässt sich inklusive Android 6.x (Marshmallow) einwandfrei umsetzen.

2. Das Dilemma mit den Berechtigungen

Androids Plattform-Sicherheit basiert auf diversen Komponenten. Hierbei ist eine der Schlüsselfunktionen, das sog. »Sandboxing«. Der Name »Sandbox« leitet sich daraus ab, dass sich die entsprechende App bildlich gesprochen, wie ein kleines Kind in einem »Sandkasten« befindet. Es kann zwar in diesem Sandkasten »spielen«, hat aber Probleme aus diesem Sandkasten »auszubrechen« und in der Umgebung außerhalb des Sandkastens, Schaden anzurichten. Bei einer App ist das praktisch das Gleiche. Während der Laufzeit befindet sich eine App innerhalb eines isolierten (Speicher-) Bereiches, in dem ihre Aktionen im Idealfall keine Auswirkung auf die Umgebung haben. Standardmäßig kann daher eine App die Daten und Funktionalitäten von anderen Apps nicht beeinflussen bzw. hat lediglich begrenzten Zugriff auf bestimmte Bereiche des Betriebssystems. Jeder Android-App wird vom System eine eindeutige ID (UID) zugewiesen und anschließend als separater Prozess ausgeführt.

Android Berechtigungsmodell

Möchte eine App auf eine Ressource bzw. auf Funktionalitäten (Kamera, GPS-Position usw.) außerhalb ihres Sandkastens zugreifen, benötigt sie hierfür entsprechende Berechtigungen. Das Sandbox-Modell basiert deshalb auf einem zweistufigen Prozess: Auf der ersten Stufe entscheidet der Entwickler der App, auf welche Informationen eine App zugreifen soll bzw. welche Rechte ihr eingeräumt werden müssen, damit sie ordnungsgemäß funktioniert. Da jedoch dieses alleine, einer missbräuchlichen Verwendung von Vornherein Tür und Tor öffnen würde, muss der Informationszugriff in einem zweiten Schritt vom Anwender bestätigt werden. Er muss letztendlich final darüber entscheiden, ob er den Wünschen der App-Entwickler nachkommen will oder nicht. Lehnt er das Ansinnen der Entwickler ab, weil er bspw. der Meinung ist, dass die App zu viele Rechte außerhalb ihres Sandkastens begehrt, ist es ihm grundsätzlich auch nicht möglich, die entsprechende App zu installieren bzw. zu nutzen. An dieser Stelle sei jedoch auf ein weiteres »Phänomen« hingewiesen, dessen sich ein Anwender immer bewusst sein sollte. Hat ein Nutzer den angeforderten Berechtigungen bei der Installation einmal zugestimmt, hat er auf einem herkömmlichen Androiden grundsätzlich nicht mehr die Möglichkeit, seine erteilen Berechtigungen im Nachhinein noch zu beeinflussen bzw. zu verändern. Es gilt das allseits bekannte Prinzip »Friss oder stirb«.

Genau dieser Umstand wird von vielen App-Entwicklern, Unternehmen und anderen Trittbrettfahrern ausgenutzt, um an eure sensible Daten zu gelangen, die zu allem Ärger oftmals aber gar nicht für die eigentliche App-Funktionalität benötigt werden. So sammeln und versenden Apps zuweilen mehr Daten, als sie zur Erfüllung ihrer Aufgabe brauchen. Aus datenschutzrechtlicher Sicht ist dieses ein klarer Verstoß u.a. gegen die Grundsätze:

  • der Zweckbindung und
  • der Datensparsamkeit.

Eine verantwortliche Stelle wie bspw. ein App-Anbieter soll nach dem Willen des Bundesverfassungsgerichtes bzw. der Gesetzgeber nach diesen beiden Geboten grundsätzlich immer nur so viele Daten sammeln und verarbeiten, wie es zur Erreichung des (legitimen) Zweckes wie bspw. zur Gewährleistung der ordnungsgemäßen Funktionsfähigkeit der entsprechenden App notwendig ist. 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. Vielmehr ist ein Verstoß gegen diese Gebote unter App-Anbietern quasi schon zu einem »Volkssport« geworden, was uns auch unzählige Beiträge in diversen Medien tagtäglich eindrucksvoll vor Augen führen. Die nachfolgende Auflistung ist nur ein kleiner Ausschnitt aktueller Berichterstattungen, die zu diesem Problem Stellung nehmen:

Diese Artikel sollten unseres Erachtens jedem Nutzer als Ansporn dienen, sich näher mit dem Android-Berechtigungsmodell auseinanderzusetzen und den bestehenden Möglichkeiten, sich gegen die intransparente Datensammlung entgegenzustellen zu beschäftigen. Bevor wir uns näher mit XPrivacy beschäftigen wollen wir die aktuelle Lage kurz darstellen.

Der Kuketz-Blog ist spendenfinanziert!

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 ➡

2.1 Symbiose aus »Intransparenz« und Anwender-Naivität

Jeder von uns kennt das Prozedere, dass vor jeder App-Installation immer erst ein Hinweisfenster eingeblendet wird, das uns aufzeigt, welche Berechtigungen eine App einfordert (siehe Zwei-Stufen-Sandbox-Modell). Die wenigsten setzen sich jedoch intensiv damit auseinander, was eine App eigentlich so alles bei ihrer Installation anfordert und ob die begehrten Zugriffe für die Funktionalität der Apps überhaupt erforderlich sind. Darüber hinaus ist das Sammelsurium an Berechtigungen für den Otto-Normalverbraucher oftmals auch ein undurchschaubares Konstrukt. Meist aus Bequemlichkeit wollen sich die meisten Anwender nicht mit diesem »lästigen« Prozedere herumschlagen und klicken das Hinweisfenster einfach weg, um die App endlich nutzen zu können.

Das unüberlegte Wegklicken kann allerdings unkalkulierbare Folgen bzw. Risiken nach sich ziehen, denn im Sekundenbruchteil könnt ihr damit ungewollt zum Produkt werden. Die Vorgehensweise des Android-Berechtigungsmodells ist daher in unseren Augen ein wohl kalkulierter »Designfehler«. Zwar kommt Google damit im Prinzip in diesem Punkt der Forderung nach Transparenz nach und legt die Verantwortung wie eigentlich auch von den Gesetzen intendiert, in die Hände der Nutzer. Dennoch ist auch wahrscheinlich, dass Google bzw. die App-Anbieter auf die Bequemlichkeit der Nutzer zählen bzw. mit dieser kalkulieren, um ihre Datensammlung immer weiter ausbauen zu können. Was man sich auch noch vor Augen führen sollte ist nämlich auch die Tatsache, dass der Nutzer oftmals auch komplett darüber im Unklaren gelassen wird, was eigentlich nach der Übermittlung seiner Daten geschieht.

Es lässt sich damit festhalten, dass der Otto-Normalverbraucher ohnmächtig und berauscht von den Möglichkeiten moderner Smartphones die Sammlung und Verknüpfung privater Daten hinnimmt, obwohl jegliche Transparenz, was damit eigentlich passiert, vollkommen auf der Strecke bleibt. Angesichts dieses Umstands kann man das eingeblendete Hinweisfenster, das über die angeforderten Berechtigungen informiert, durchaus als »Veralberung« bezeichen, das uns Transparenz und Kontrolle lediglich vorgaukelt.

Wer auf Besserung hofft, wird bitter enttäuscht. Vielmehr lässt sich durchaus sagen »schlimmer geht immer«. Seit einem Update auf die Play Store-Version 4.8.20 hat sich Google nämlich für eine »Vereinfachung« des Berechtigungssystems entschieden. Kern dieses (neuen) Systems ist nämlich, dass sich automatisch aktualisierende Apps ungefragt erweiterte Berechtigungen einholen können. Das bedeutet mithin konkret: Vor der Installation einer neuen App werden euch im Normalfall alle erforderlichen Berechtigungen aufgelistet. Hattet ihr bis zur Version 4.8.20 des Play Stores die automatische Update-Funktion einer App aktiviert, so wurdet ihr gewarnt, falls die bereits installierte App auf einmal Zugriffsrechte auf die Kontakte oder dergleichen erlangen wollte. Ihr konntet dann während dem Update-Vorgang entscheiden, ob ihr diesen neuen Berechtigungen zustimmt oder die Aktualisierung ablehnt. Ab Version 4.80.20 ist bei einer automatischen App-Aktualisierung nicht mehr ersichtlich, ob sich eine App neue Berechtigungen »genehmigt«, die ihr wiederum für bedenklich haltet. Das bedeutet letztendlich noch weniger Kontrolle und Transparenz. Eine bisher eher harmlos wirkende App kann sich über die automatische Update-Funktion weitreichende Berechtigungen »erschleichen«.

Mit XPrivacy können wir dieser ungewollten Datensammelei ein Ende bereiten. Damit können wir gezielt beeinflussen auf welche Informationen eine App zugreifen darf oder nicht.

2.2 Android 6.x

Seit Android 6.x (Marshmallow) erlaubt Google mehr Kontrolle über die App-Berechtigungen. Nach unserer Auffassung ist dies leider noch immer unzureichend. Dennoch wird die Berechtigungskontrolle als großer Schritt in Sachen Sicherheit und Privatsphäre gefeiert. Leider zu unrecht. Denn noch immer ist das Modell zu löchrig, bietet zu wenig Kontrolle und erlaubt es App-Entwicklern nach wie vor Informationen abzufragen, die für die tatsächliche Diensterbringung nicht notwendig sind. Auch unter Android 6.x ist die Installation von XPrivacy weiterhin notwendig.

3. Einführung XPrivacy

Der Berechtigungsmanager XPrivacy wird von Marcel Bokhorst (M66B) seit Juni 2013 für die Android-Gemeinde als OpenSource Projekt entwickelt. Mit Hilfe des Tools könnt ihr Apps und dessen Services an der Sammlung und Weitergabe eurer sensiblen Informationen hindern. Ist eine App aufgrund ihrer Berechtigungen bspw. in der Lage euren GPS- oder ungefähren WLAN-Standort auszulesen, könnt ihr entscheiden, wie XPrivacy mit dieser Anfrage verfahren soll:

  1. Blockieren: Der Zugriff auf die angeforderte Information wird durch XPrivacy verhindert bzw. die anfragende App bekommt einen leeren Datensatz geliefert, der keinerlei Informationsgehalt bietet.
  2. Falsche Informationen: Die zurückgelieferten Informationen an eine App können ebenfalls manipuliert bzw. verfremdet werden. Damit könnt ihr bspw. einer App die GPS-Koordinaten vom Nordpol übermitteln und so falsche Identitäten bzw. Angaben vortäuschen.
  3. Zulassen: Falls die betreffende Information von der App tatsächlich für ihre Funktionalität benötigt wird, könnt ihr den Zugriff darauf erlauben.

Letztendlich bleibt es euch überlassen, welchen Apps ihr Zugriff auf eure sensiblen Informationen gestattet. Für die Installation und den Betrieb von XPrivacy muss euer System jedoch ein paar Voraussetzungen erfüllen, auf die wir im Folgenden eingehen.

3.1 Xposed Framework

Besonders unter »Moddern« ist das Xposed Framework sehr geschätzt, da es nahezu uneingeschränkte Möglichkeiten bietet, das Android-System nach den eigenen Wünschen anzupassen, ohne dafür ein Custom-ROM zu benötigten. Das Framework bildet die Grundlage für eine Reihe von Tweaks und Modifikationen, mit denen ihr nicht nur das Aussehen eures Systems beeinflussen könnt. Im XDA-Forum findet ihr eine eigene Kategorie für das Framework, wo ständig neue Module bzw. Erweiterungen für Xposed vorgestellt werden. Allerdings sind diese Module mit Vorsicht zu genießen, denn sie kommen oft aus unbekannten Quellen und greifen über Funktionen teilweise tief in das System ein. Insbesondere hinsichtlich der damit möglichen »böswilligen« Veränderungen eures Androiden raten wir grundsätzlich von der Verwendung weiterer Module ab – einzige Ausnahme bildet XPrivacy.

Noch während des Bootvorgangs klinkt sich das Xposed Framework in euer Android-System ein und dient ab diesem Zeitpunkt als Vermittler bzw. Schnittstelle zwischen den installierten Apps und der Systemumgebung. Diese Vermittler-Funktionalität macht sich XPrivacy zunutze und fängt Methoden, Receiver- und Service-Abfragen einer App ab, um euch letztendlich die Entscheidung zu überlassen, ob eine App tatsächlich Zugriff auf die angeforderten Information erhält. Im Vergleich mit Apps wie LBE Privacy Guard oder OpenPDroid besitzt XPrivacy durch diese Herangehensweise umfangreichere Möglichkeiten, um sensible Informationen von den Zugriffen neugieriger Apps zu schützen.

3.2 Installation

Mit Hilfe des APK-Downloaders könnt ihr den Installer auch ohne gültigen Google Account beziehen.

Alternativ könnt ihr ebenfalls eine manuelle Installation von XPrivacy und dem Xposed Framework vornehmen. Auf der GitHub Projektseite von XPrivacy findet ihr eine stets aktuelle Beschreibung des Installationsvorgangs. Im Folgenden sind nochmal alle wichtigen Schritte zusammengefasst.

3.2.1 Voraussetzungen

  • Ihr benötigt ein Android ab der Version 4.x bis 6.x. Neben Custom-ROMs werden ebenfalls Stock-ROMs unterstützt.
  • Euer Gerät muss gerootet sein. Wie das funktioniert haben wir bereits im zweiten Teil der Artikelserie beschrieben.
  • Ihr solltet euch vor der Installation ein Backup mit dem in ClockworkMod integrierten NANDroid erstellen.

3.2.2 Installation des Xposed Frameworks

  • Über das XDA-Forum oder den Direktlink könnt ihr die aktuelle Version von Xposed beziehen.
  • Für die Integration in euer Android-System müsst ihr kurzfristig die Installation fremder APK-Quellen unter »Einstellungen -> Sicherheit -> Unbekannte Herkunft« erlauben.

3.2.3 Installation von XPrivacy

  • Ladet die aktuellste Version von XPrivacy herunter und installiert die App über den Dateimanager.
  • Anschließend müsst ihr das XPrivacy-Modul über die »Xposed Installer« App aktivieren. Navigiert hierfür in der App auf »Module« und setzt ein Häkchen hinter XPrivacy.
  • Nach einem Geräte-Neustart ist sowohl das Xposed Framework, als auch XPrivacy einsatzbereit.
  • Ihr könnt jetzt das Häkchen bei »Installation von Apps aus unbekannten Quellen zulassen« wieder entfernen.

4. Datensparsamkeit mit XPrivacy

Mit XPrivacy lässt sich das Konzept der Datensparsamkeit bzw. Datenvermeidung hervorragend umsetzen. Durch den bedachten Einsatz von XPrivacy werden Apps nur so viele personenbezogenen Daten zur Verfügung gestellt, wie für den jeweiligen Zweck unbedingt erforderlich sind. Mit XPrivacy halten wir also den Schlüssel zur Datensparsamkeit in unseren Händen, auch wenn die anfängliche Bedienung und das User-Interface zunächst sehr gewöhnungsbedürftig sind.

XPrivacy Startbildschirm

Unmittelbar nach dem Start seht ihr eine Auflistung eurer installierten Apps, sortiert in alphabetischer Reihenfolge. Direkt neben dem App-Icon findet ihr drei unterschiedliche Symbole, deren Funktion bzw. Aussage ihr besser versteht, wenn ihr eine der aufgelisteten Apps selektiert.

  • Gelbes Warndreieck [1]: Sobald eine App während ihrer Laufzeit auf eine Information eures Android-Geräts zugreift, wird dies von XPrivacy protokolliert und in der App-Ansicht mit einem gelben Warndreieck dargestellt. Ihr könnt damit erkennen, welche Informationen im Einzelnen von einer App abgefragt werden.
  • Blaue Weltkugel [2]: Mit der blauen Weltkugel erkennt ihr, ob eine App Internet-Zugriff besitzt. Sobald sie über diese Fähigkeit bzw. Berechtigung verfügt, ist sie theoretisch in der Lage alle gesammelten Informationen von eurem Gerät an die App-Entwickler bzw. dritte Parteien zu übersenden.
  • Grüner Schlüssel [3]: Während der App-Installation fordert eine App bestimmte Berechtigungen an. Diese werden mit dem grünen Schlüssel symbolisiert. Eine App kann nämlich über eine Berechtigung verfügen, während ihrer Laufzeit allerdings niemals davon Gebrauch machen. Im Gegensatz zum gelben Warndreieck soll euch der grüne Schlüssel also lediglich aufzeigen, dass die App über diese Berechtigungen verfügt aber nicht zwangsläufig darauf zugegriffen wird. Entscheidender ist demnach das gelbe Warndreieck, was den tatsächlichen Zugriff auf Informationen aufzeigt.

Bevor wir uns der weiteren Bedienung und Einstellungen von XPrivacy widmen, werfen wir zunächst einen Blick auf den »Berechtigungsjungle«.

4.1 Berechtigungsjungle

Wie bereits dargestellt hat Google in einem Update des Play Stores auf Version 4.8 eine »Vereinfachung« des Berechtigungsmodells vorgenommen. Insgesamt sind 13 verschiedene Gruppen/Kategorie entstanden, die unterschiedliche Berechtigungen zusammenfassen und den Apps damit gleichzeitig mehr »Spielraum« beim Abgriff sensibler Daten einräumen. Zu allem Ärgernis ist die Berechtigung »Internetzugriff« komplett unter den Tisch gefallen, da laut Google »Apps normalerweise auf das Internet zugreifen«. Ab sofort ist die Berechtigung unter »Sonstiges« unter der Bezeichnung »Daten aus dem Internet abrufen« auffindbar. Werfen wir zunächst einen Blick auf die 13 Berechtigungsgruppen:

  • In-App-Käufe
  • Geräte- und App-Verlauf
  • Einstellungen für Mobilfunkdaten
  • Identität
  • Kontakte/Kalender
  • Standort
  • SMS
  • Telefon
  • Fotos/Medien/Dateien
  • Kamera/Mikrofon
  • WLAN-Verbindungsinformationen
  • Geräte-ID & Anrufinformationen
  • Sonstiges

Facebook Datensammler

Im Beispiel der Facebook-App wird die angedeutete Problematik ersichtlich. Die Berechtigung »Internetzugriff« tarnt sich ab sofort unter »Daten aus dem Internet abrufen« [1]. Zumindest bei der Facebook-App wäre »Daten an das Internet senden« die wohl treffendere Bezeichnung, da insgesamt 42 Berechtigungen bei der Installation angefordert werden. Eine kostenlose und umfassendere Anwender-Spionage auf einem Android-Gerät ist mit einer offiziellen App wohl kaum mehr möglich. Weiterhin darf sich die App bei Updates weitere Berechtigungen von diversen Kategorien automatisch und ohne Anwender-Bestätigung [2] »erschleichen«.

Weiterhin sind in jeder Kategorie mehrere Berechtigungen zusammengefasst. Beispielweise umfasst die Gruppe »Kontakte/Kalender« folgende Berechtigungen:

  • Kontakte lesen
  • Kontakte ändern
  • Kalendertermine sowie vertrauliche Informationen lesen
  • Ohne Wissen der Eigentümer Kalendertermine hinzufügen oder ändern und E-Mails an Gäste senden

Damit nicht genug, die Gruppe »Telefon« umfasst folgende Berechtigungen:

  • Telefonnummern direkt anrufen
  • Anrufliste bearbeiten
  • Anrufliste lesen
  • Ausgehende Anrufe umleiten
  • Telefonstatus ändern
  • Anrufe ohne Ihr Zutun

Während zuvor bei einer App-Installation noch die einzelnen Berechtigungen aufgeführt wurden, erhaltet ihr ab sofort lediglich einen Hinweis, dass eine App die Kategorie »Kontakte/Kalender« einfordert. Zwei hypothetische Beispiele aus der Praxis sollen aufzeigen, warum die »Vereinfachung« in Kategorien im Zweifelsfall die Intransparenz fördert und durch die »Hintertür« weiteren Datenmissbrauch ermöglichen:

  • Erlaubt ihr einer App bspw. den Zugriff auf die »Identität«, erteilt ihr damit Zugriff, um Konten auf dem Gerät zu suchen, neue Konten anzulegen, die eigenen Kontaktinformationen auszulesen oder die eigene Kontaktkarte zu ändern.
  • Wird euch vor der Installation einer Messenger-App wie WhatsApp oder Threema die Kategorie »Kontakte/Kalender« aufgelistet, hat eine App damit theoretisch nicht nur Zugriff auf eure Kontakte, sondern kann ebenfalls den Kalender auslesen bzw. bearbeiten. Selbst wenn eine App während der Installation nicht über eine Berechtigung der jeweiligen Kategorie verfügt, kann sie mit einem automatischen App-Update »nachhelfen«.

Gewissheit erlangt ihr lediglich dann, wenn ihr die Installation nicht direkt bestätigt sondern im Hinweisfenster ganz herunter scrollt. Dort könnt ihr weiterhin einsehen, welche Berechtigungen eine App im Detail anfordert – tatsächlich werden die meisten Anwender dies nicht tun und die Google Änderung als »Erleichterung« empfinden und damit noch öfter in die Falle der Datensammler tappen. Zu allem Übel können sich Apps mit der automatischen Updatefunktion weitere Berechtigungen einer Kategorie erschleichen, ohne dass ihr als Anwender dies mitbekommt.

4.2 XPrivacys Zugriffsbeschränkungen

Vereinfacht ausgedrückt sorgt das Android-Berechtigungsmodell für eine Zugriffsbeschränkung auf jene Informationen, die eine App bei ihrer Installation von euch einfordert. XPrivacy ist allerdings in der Lage nicht nur die Standard-Berechtigungen zu reglementieren, sondern kann weitere Zugriffsbeschränkungen auf eurem Gerät durchsetzen, die vom herkömmlichen Berechtigungsmodell nicht in dieser Ausführlichkeit und Tiefe erfasst werden. Im Folgenden ein paar Beispiele:

  • Browser: Rückgabe einer leeren Bookmark Liste
  • Browser: Rückgabe einer leeren Suchhistorie
  • Clipboard: Reglementierung des Zugriffs auf den Zwischenspeicher (Kopieren/Einfügen/Ausschneiden)
  • E-Mail: Rückgabe einer leeren E-Mail Account Liste
  • Identification: Rückgabe einer gefälschten Google Werbe-ID
  • Identification: Rückgabe eines gefälschten Namens für das verbundene USB-Gerät
  • Location: Rückgabe einer leeren Liste mit Wi-Fi Scan Resultaten
  • Media: Meldung von XPrivacy, falls eine App versucht Audio/Video/Bilder aufzunehmen
  • Network: Rückgabe von falschen, privaten IP-Adressen
  • Network: Rückgabe falsche MAC-Adressen
  • usw.

XPrivacy ist also in der Lage den Zugriff auf sensible Informationen in einem Maß zu reglementieren, wie es das herkömmliche Android-Berechtigungsmodell nicht vorsieht. Damit können wir Googles »Designfehler« korrigieren und gleichzeitig weitaus mehr Informationen vor dem Zugriff neugieriger Apps schützen, als ursprünglich angedacht.

5. XPrivacy im Praxisgebrauch

Die Benutzung von XPrivacy erfordert zunächst Geduld und das Kennenlernen des umfangreichen Funktionsumfangs. Wir können euch dies nicht vollständig abnehmen, aber den Einstieg in die Benutzung und Bedienung etwas vereinfachen. In diesem Kapitel stellen wir dar, wie XPrivacy den Zugriff auf Informationen reglementiert und empfehlen euch abschließend eine Handhabung, die sich aus unserer Sicht bewährt hat und gerade für Neueinsteiger einen Mehrwert bietet.

Es sei an dieser Stelle noch erwähnt, dass ihr nicht alle Apps auf eurem Smartphone mit XPrivacy reglementieren müsst, sondern nur solche, denen ihr den Zugriff auf das Internet über AFWall+ erlaubt habt. Nur jene Apps sind theoretisch in der Lage vom Smartphone gesammelte Informationen zu übertragen.

5.1 On-Demand Modus

Nach der Installation agiert XPrivacy im sogenannten »On-Demand« Modus. Sobald eine App Zugriff auf eine Information anfordert, erhaltet ihr ein Hinweisfenster, dass euch wiederum erlaubt den Zugriff auf die Information zu beschränken, indem ihr die komplette Kategorie reglementiert oder etwas differenzierter den entsprechenden Funktionsaufruf.

XPrivacy Auswahl

Im dargestellten Beispiel wird die komplette Kategorie »Identifikation (Gerät)« reglementiert. Die Entscheidung betrifft demnach alle Informationen, die von der Kategorie Identifikation erfasst werden. Diese sind im Folgenden aufgelistet:

  • Android ID
  • Serienummer des Geräts
  • Hostname des Geräts
  • Google Service Framework ID
  • Zugriff auf den /proc Ordner
  • Google Werbe-ID
  • usw.

Entfernt ihr allerdings das Häkchen bei »Auf die gesamte Kategorie anwenden« gilt eure Entscheidung lediglich für die Funktion »Srv_Android_ID« bzw. reglementiert ihr damit den Zugriff auf die eindeutige Android ID, welche zur Kategorie »Identifikation (Gerät)« gehört.

Weiterhin stehen euch drei verschiedene Optionen zur Auswahl:

  • Zulassen [1]: Damit bestätigt ihr den dauerhaften Zugriff auf die Kategorie bzw. Funktion.
  • Ich weiß nicht [2]: Der Zugriff auf die Information wird in Abhängigkeit von den aktuellen Einstellungen entweder blockiert oder erlaubt. Habt ihr bisher noch keine Einstellungen vorgenommen, so gelten die Vorschläge aus dem Standard-Template. Bei einem erneuten Zugriff erhaltet ihr erneut ein Hinweisfenster mit den unterschiedlichen Auswahlmöglichkeiten.
  • Blockieren [3]: Damit blockiert ihr dauerhaft den Zugriff auf die Kategorie bzw. Funktion.
  • Nur einmalig für eine gewisse Zeitspanne [4]: Der Zugriff auf die Information wird einmal erlaubt. Sobald die App erneut auf die Information zugreift, erhaltet ihr erneut ein Hinweisfenster und könnt eine Entscheidung treffen.

All eure Entscheidungen könnt ihr übrigens wieder vollständig widerrufen, falls ihr euch vertippt oder doch anders entscheiden solltet. Dazu startet ihr einfach die XPrivacy App und selektiert dort die entsprechende App. Tippt ihr eine der Kategorien an, erscheinen alle von XPrivacy überwachten Funktionsaufrufe. Die Checkbox [1] am Ende einer Zeile kann für eine Kategorie drei unterschiedliche Zustände annehmen:

  • Unchecked: Keine der Funktionen innerhalb der Kategorie sind verboten. Folglich hat eine App Zugriff auf alle darunter zusammengefassten Informationen.
  • Ausgefülltes Quadrat: Einige, aber nicht alle Funktionen der Kategorie sind durch XPrivacy reglementiert. In der Detailansicht könnt ihr erkennen, welche dies sind.
  • Checked: Alle Funktionen der Kategorie sind verboten und damit ist die App nicht in der Lage auch nur eine Information aus der entsprechenden Kategorie abzufragen.

Ist in der gleichen Zeile ebenfalls ein Fragezeichen in der Checkbox [4] gesetzt, wird euch XPrivacy mit einem Hinweisfenster benachrichtigen, sobald ein Zugriff auf die Kategorie stattfindet.

XPrivacy Selektion

Tippt ihr am Anfang einer Zeile auf das Buchsymbol [2] werdet ihr direkt auf die Google Entwicklerseiten umgeleitet und erhaltet dort ausführliche Informationen über den jeweiligen Funktionsaufruf. Diese sehr technische Beschreibung ist für einen durchschnittlichen Anwender wenig benutzerfreundlich, da es sich hierbei immerhin um Informationen handelt, die hauptsächlich für App-Entwickler von Interesse sind. Doch gerade im Hinblick auf die Nutzung von XPrivacy müssen wir dieser Informationsquelle eine neue Bedeutung beimessen, die zur Entscheidungsfindung über »blockieren« bzw. »erlauben« beitragen kann.

Analog zu den Kategorien befinden sich am Ende einer Zeile ebenfalls zwei Checkboxen. Die erste Checkbox [3] kann wiederum die Zustände »Checked« bzw. »Unchecked« annehmen und damit den Zugriff auf die betreffende Information reglementieren. Noch einmal der Hinweis: Ein Häkchen bedeutet, dass der Zugriff blockiert wird. Setzt ihr zusätzlich in der danebenliegenden Checkbox das Fragezeichen, wird euch XPrivacy mit einem Hinweisfenster benachrichtigen, sobald ein Zugriff auf die Funktion erfolgt.

Da die Bedienung und das Verhalten von XPrivacy zwangsläufig Fragen aufwirft hat Marcel Bokhorst auf der GitHub Projektseite einen FAQ-Bereich eingerichtet. Solltet ihr Fragen zu XPrivacy haben, sollte dies die erste Anlaufstelle sein.

5.2 Was muss ich reglementieren?

Pauschal lässt sich darauf leider keine Antwort geben, zumal jede App bei der Installation andere Berechtigungen anfordert. Oftmals empfiehlt es sich auszuprobieren, welche Informationen eine App für die Erbringung ihrer Funktionalität tatsächlich vom Android-Gerät benötigt. Alle anderen Zugriffe auf Informationen können dann getrost durch XPrivacy reglementiert werden. Wir möchten euch im Folgenden einen bewährten Ansatz vorstellen:

Das Verhalten von XPrivacy wird maßgeblich vom Standard-Template beeinflusst, welches einer App unmittelbar nach der Installation zugewiesen wird. Dort ist genau definiert, welche Kategorie- bzw. Funktionsbeschränkungen für App-Neuinstallationen gelten. Ein unverändertes Standard-Template aktiviert für beinahe alle überwachten Kategorien und deren Funktionen den »On-Demand« Modus. Sobald eine App über das Berechtigungsmodell auf Informationen zugreift erhaltet ihr folglich ein Hinweisfenster, bei dem ihr anschließend entscheiden könnt, ob der Zugriff darauf erlaubt bzw. verboten wird.

Nach der Installation einer neuen App müsst ihr zunächst ausloten, welche Berechtigungen tatsächlich für die Funktionserbringung benötigt werden. Nachdem ihr die App zum ersten Mal startet wird euch XPrivacy beim Zugriff auf eine Kategorie bzw. Funktion ein Hinweisfenster einblenden. Ihr solltet alle Anfragen zunächst mit einem »Blockieren« bestätigen und damit den Zugriff auf die Information verweigern. Diese Vorgehensweise wiederholt ihr so lange, bis die App entweder abstürzt oder eine von euch gewünschte App-Funktion nicht korrekt ausgeführt wird. Um anschließend herauszufinden, welche Kategorie bzw. Funktion den Absturz verursacht hat, startet ihr XPrivacy und ruft dort den »Aktivitätslog« der App auf, der folgende Bedeutung hat:

  • Rote Zeilen: Bei den rot eingefärbten Zeilen handelt es sich um Informationen bzw. Funktionsaufrufe, die Apps oftmals zum Absturz bringen, falls sie durch XPrivacy blockiert werden. Ihr könnte diese zwar dennoch reglementieren, allerdings ist dies im Standard-Template nicht vorgesehen. Wollt ihr den Zugriff auf »kritische« Funktionen ebenfalls kontrollieren, so müsst ihr euch ein eigenes Template erstellen. Dieses Template könnt ihr dann allen bereits installierten Apps zuweisen und ebenfalls für Neuinstallationen aktivieren. Alternativ könnt ihr je nach App auch händisch jede einzelne »kritische« Funktion reglementieren.
  • Weiße Zeilen: Im Gegensatz zu den rot markierten Zeilen handelt es sich hierbei um unkritische Funktionsaufrufe. Einen Zugriff darauf könnt ihr meist bedenkenlos blockieren, falls die App die betreffende Information nicht für ihre Diensterbringung benötigt.
  • Zusätzlich ein rotes Warnschild: XPrivacy hat den Zugriff auf die Information verweigert.

XPrivacy Aktivitätslog

Im dargestellten Beispiel verweigert XPrivacy durch das Blockieren der Kategorie »Internet« allen darunter zusammengefassten Funktionen den Zugriff auf Informationen von eurem Gerät. In diesem Fall kann die Funktion »internet/NetworkInfo.isConnected« nicht in Erfahrung bringen, ob euer Android-Gerät aktuell über eine aktive Internetverbindung verfügt. Als Reaktion erscheint bei der betroffenen App eine Meldung der Art »Netzwerk ist nicht erreichbar – Sie sind derzeit offline«. Ihr könnt nun entweder die komplette Kategorie Internet zulassen oder für jeden Funktionsaufruf einzeln entscheiden, ob der Zugriff notwendig ist. Diese Vorgehensweise ist zugegebenermaßen aufwendig und muss für jede App wiederholt werden. Als Resultat erhaltet ihr allerdings auch die größtmögliche Kontrolle über eure Daten.

5.3 Weitere Funktionen

XPrivacy verfügt über einen beachtlichen Funktionsumfang, der auf den ersten Blick nicht sofort sichtbar ist. An dieser Stelle möchten wir auf vier Funktionen eingehen, die wir für besonders erwähnenswert halten:

  • Aktivitätslog: Über den Aktivitätslog könnt ihr genau nachvollziehen, zu welchem Zeitpunkt eine App auf eine Information auf eurem Gerät zugegriffen bzw. dies versucht hat. Ein rotes Warnschild symbolisiert den blockierten Zugriff durch XPrivacy.
  • Templates: Über die Template-Funktion könnt ihr verschiedene Vorlagen erstellen und nach euren Vorstellungen entscheiden, auf welche Informationen eine App zugreifen darf oder nicht. Anschließend könnt ihr dieses Template einer oder mehreren Apps zuweisen. Ihr erspart euch damit das mühselige Zuweisen einzelner Zugriffsbeschränkungen.

XPrivacy Template

  • Einstellungen: Über das Einstellungsmenü könnt ihr diverse Optionen beeinflussen. Interessant ist die Aktivierung der Option »Parameter der Nutzungsdaten zeigen«. Über den Aktivitätslog bekommt ihr anschließend für viele der Funktionsaufrufe ebenfalls den Abfragewert mit angezeigt. Beispielsweise wird die Funktion »internet/InetAddress.getByName« um die IP-Adresse ergänzt, zu welcher sich die App verbinden möchte.

Update

12.11.2014: Seit XPrivacy Version 3.2.3 hat Marcel die neue Funktion »Werte der Nutzungsdaten zeigen« ergänzt. Sobald ihr diese Funktion aktiviert könnt ihr über den Aktivitätslog unmittelbar nachvollziehen, welche Informationen eine App von eurem System abfragt. Dies eignet sich hervorragend, um »Datensammler« zu entlarven und Entwickler kritisch mit der zweifelhaften Monetarisierung ihrer Arbeit zu konfrontieren.

XPrivacy Einstellungen

  • Daten manipulieren: Wollt ihr einer App falsche Informationen beim Zugriff auf sensible Daten zurückgeben, könnt ihr dies global für alle Apps über »Einstellungen« tun. Dies funktioniert auch für jede App einzeln, indem ihr die »Einstellungen« aus dem Untermenü der App aufruft.

6. Alternativen

Neben XPrivacy existieren weitere Lösungen, um die Zugriffe auf bestimmte Informationen zu reglementieren. Allerdings gelingt dies bei keiner anderen App in dieser Ausführlichkeit. So bietet bspw. auch das CyanongenMod einen »Privacy Guard« an mit dem sich einzelne Berechtigungen reglementieren lassen, allerdings ist der Umfang der Beschränkungsmöglichkeiten im Vergleich mit XPrivacy deutlich geringer.

Aktuell befindet sich DonkeyGuard in Entwicklung. Ebenso wie XPrivacy nutzt der Berechtigungsmanager das Xposed Framework, um den Zugriff auf sensible Informationen zu reglementieren. Unklar ist ob der Quellcode veröffentlicht werden soll. Da sich das Tool in einem frühen Alpha-Zustand befindet haben wir es noch keiner Prüfung unterzogen.

7. Fazit

Dank der Artikelserie »Your phone – Your data« müssen wir nicht auf eine »Datenschutz-Offensive« von Google und Co. hoffen. Diese wird nicht kommen, ganz gleich welche medienwirksamen Versprechungen von Apple oder Google dahingehend gemacht werden. Wer ein Smartphone von Apple, Google, Microsoft oder anderen IT-Riesen aus den USA nutzt, der muss sich im Klaren sein, dass Unmengen an sensiblen Informationen gesammelt, ausgewertet und miteinander verknüpft werden. Mit diesem Geschäftsmodell stehen diese Unternehmen heute nicht alleine da, doch gerade im Hinblick darauf, dass wir unseren Smartphones einen Großteil von sensiblen Informationen anvertrauen, ist dies eine beängstigende Entwicklung.

In Anbetracht der zunehmenden Begierde auf unsere Daten ist eine App wie XPrivacy unvermeidlich. Damit können wir genau kontrollieren, auf welche Informationen eine App zugreifen darf. Anfangs ist die Bedienung zugegebenermaßen gewöhnungsbedürftig und vor allem neue Anwender sind zunächst mit dem Funktionsumfang überfordert. Alle die sich davon nicht abschrecken lassen, erhalten mit XPrivacy ein ausgezeichnetes Tool, dessen Entwicklung ihr mit dem Kauf der Pro-Version unterstützen könnt.

Der kommende Beitrag wird die Artikelserie »Your phone – Your data« abschließen. Wir möchten euch Dienste und Apps vorstellen, die nach unserer Vorstellung dazu beitragen können, damit ihr die Herrschaft und Kontrolle über euer Android-Geräte bzw. eure Daten auch in Zukunft behaltet.

Autoren:

Gerald Spyra
Mike Kuketz

Bildquellen:

XPrivacy: „Logo“, https://www.xprivacy.eu/
Android Security: „Sandbox“ https://source.android.com/security/
OpenClips: „Tux“, https://pixabay.com/en/tux-alcohol-alcoholic-animal-bird-161391/

Ü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 ➡


Diskussion

48 Ergänzungen zu “XPrivacy – Android ohne Google?! Teil6”

  1. Comment Avatar Henry2o1o sagt:

    Eine weitere Alternative ist LBE Security Master

  2. Comment Avatar Clemens sagt:

    Hallo Mike!
    Ich freue mich über dein Engagement, uns mit deinem Blog von deinen Kenntnissen und Erfahrungen derart umfangreich zu nutzen und so dazu beizutragen, dass immer mehr Menschen ihre Daten und Smartphones schützen. Dafür danke ich dir!

    Ich hatte in 2010 ein Galaxy S2 gekauft, um meine umfangreichen Termine besser planen und auch sensible Daten speichern zu können, so weit ich diese oft unterwegs hätte brauchen können. Schon bei Inbetriebnahme des Galaxy wurden ohne meine Zustimmung alle Kontaktdaten aus der SIM-Card nach Google übertragen. Ich löschte die zwar sofort wieder. Aber mir wurde schlagartig klar, dass auf dieses Gerät ohne extreme Absicherungsmaßnahmen keine privaten Daten von mir selbst und erst Recht keine Daten meiner Klienten gehören (Ich arbeite als Heilpraktiker der Psychotherapie).

    Seither hatte ich keine Lust mehr, mich um die Nutzung des Geräts zu bemühen. Damals gab es einfach die Tools noch nicht, die du hier beschreibst. Da mir das alte Galaxy S2 noch immer technisch völlig ausreicht, könnte ich jetzt einen neuen Versuch wagen, es zumindest für eine Terminplanung ohne Namensnennungen im Kalender einzusetzen, z.B. über OwnCloud.

    Problematisch finde ich allerdings trotz all der von dir beschriebenen Maßnahmen, dass ja die Funkstrecken ebenfalls nicht wirklich abgesichert sind und per Man In the Middle (IMSI-Catcher usw.) alles mitgehört und mitgeschnitten werden kann.
    Deshalb frage ich:
    Welche Sicherheitsmaßnahmen kann ich geräteseitig denn selbst ergreifen, damit solche Angriffe auf dem Funkweg ebenfalls nahezu aussichtslos für Angreifer bleiben? Auch SSL ist ja nicht sicher, weil sogar Zertifikate gefälscht werden.

    Einen erfreulichen und lebendigen Tag
    wünsche ich dir
    Clemens

    • Comment Avatar Mike Kuketz sagt:

      Hallo Clemens,

      deine Anfrage hat nichts mit XPrivacy zu tun – ich antworte dennoch kurz darauf. Bitte weitere Fragen dazu per E-Mail.

      Wie bereits im ersten Beitrag der Artikelserie erwähnt ist es NICHT unser Ziel sich gegenüber der Überwachung durch Geheimdienste zu schützen. Dies können wir an dieser Stelle nicht leisten. Auch eine staatliche Überwachung durch IMSI-Catcher fällt darunter. Für Android existiert dafür zwar ein Projekt (https://www.kuketz-blog.de/imsi-catcher-erkennung-fuer-android-aimsicd/), allerdings sind wir lange noch nicht soweit, als dass dies einwandfrei funktionieren würde.

      Schau dir vielleicht nochmal den ersten Beitrag an, was unser erklärtes Ziel ist.

  3. Comment Avatar Big Brother sagt:

    Hallo,

    Ich habe einige Fehler in Xprivacy entdeckt. Und zwar gibt Xprivacy bei einigen Programmen an, die keine Internet-Berechtigung haben, dass sie eine Internet-Berechtigung haben. Wenn ich die App schließe und wieder öffne, ist aufeinmal die Internet-Berechtigung in der Liste für die selben App verschwunden.

    Wie kann das sein? Mal zeigt Xprivacy für eine App eine Internet-Berechtigung an und mal wieder nicht.

    Ich kann den Hype um diese App nicht verstehen, denn sie ist total verbugt und unzuverlässig! Der Bug lässt sich unendlich wiederholen und auch bei anderen Apps, die keine Internet-Berechtigung haben.

    Oder missverstehe ich da etwas?

    Grüße

  4. Comment Avatar Udo Dustyroad sagt:

    Hallo,

    vielen Dank für diesen ausführlichen und interessanten Blog, der endlich auf eine verständliche Art und Weise die ganzen Informationen zum Datenschutz beim Smartphone zusammenfasst und einordnet und erklärt!

    Macht es Sinn mit XPrivacy die Berechtigungen der Systemapps von Cyanogenmod einzuschränken, nachdem ich die proprietären Bestandteile entfernt habe, oder ist davon auszugehen, dass diese keine Daten senden? Mit welchen Einschränkungen oder Problemen müsste ich damit rechnen?

    Liebe Grüße,
    Udo

    • Comment Avatar Mike Kuketz sagt:

      Die System-Apps zu beschränken kann zu Boot-Loops und anderen Problemen führen. Es ist zwar durchaus möglich, aber nicht unbedingt empfehlenswert. Zudem sollte eine korrekt funktionierende AFWall+ dafür sorgen, dass System-Apps nicht ungewollt Daten versenden dürfen.

      Daher nochmals der Hinweis: Eine Beschränkung der Apps über XPrivacy ist nur dann sinnvoll, wenn die entsprechenden Apps über Internetzugang verfügen, den ihr über AFWall+ selbst erlaubt habt.

  5. Comment Avatar SecUpwN sagt:

    Wieder ein sehr gelungener Artikel – herzlichen Dank, mach weiter so! ;-)

  6. Comment Avatar Jonas sagt:

    Hallo,

    ich habe ein Problem mit Xprivacy und zwar nutze ich ein offline navigations Programm und möchte ihm erlauben, gps zu nutzen. In den Einstellungen von Xprivacy habe ich der app erlaubt, auf den Standort zuzugreifen. Das Problem das ich habe ist, dass mein Note 3 keine GPS-Daten findet. „GPS wird gesucht“ wird mir angezeigt aber nicht gefunden. Hat jemand eine Idee, was ich an den Einstellungen ändern muss?

    Beste Grüße

  7. Comment Avatar Tom sagt:

    Hallo Mike,

    erstmal vielen Dank für diese tolle Reihe über ein Google-freies Handy.
    Zwei Fragen hätte ich an Dich:

    1) Sehe ich es richtig, dass ich nur Berechtigungen mit einem grünen Schlüssel ändern braucht, da die anderen Berechtigungen von der App erst gar nicht angefragt werden?

    2) Was sagst Du dazu, dass XPrivacy anscheinend umgangen werden kann? Siehe: https://github.com/cernekee/WinXP
    Der Entwickler hat diea wohl auch bereits bestätigt, siehe: https://forum.xda-developers.com/showpost.php?p=54111452&postcount=10580

  8. Comment Avatar Stefan K sagt:

    Hallo Tom,

    witzigerweise kann es vorkommen, dass eine App versucht (warum auch immer) an Daten heranzukommen, für die sie keine Rechte hat und XPrivacy das abfängt, bevor Android selbst „nein“ sagt. Man kann also XPrivacy-Abfragen erhalten für Daten, auf die die App sowieso keinen Zugriff hat. Ich würde Deine Frage jedenfalls mit „Ja“ beantworten.
    Es hängt auch mit der Standardvorlage zusammen, die verwendet wird: Bei mir ist de facto alles erst einmal eingeschränkt und wird (teilweise im Trial-and-error-Verfahren) nach und nach freigegeben, je nachdem, was für eine funktionierende App nötig ist. Sollte also eine App auf ein Datenfeld zugreifen, für das sie keine Berechtigung hat, sorgt schon meine Vorlage dafür, dass dies abgelehnt wird. Siehe auch https://github.com/M66B/XPrivacy/blob/master/README.md#FAQ32

    Zu der von Dir beschriebenen Lücke: Seit Juli ist erstaunlich viel passiert. In XPrivacy 3 hat Marcel mittlerweile einen Weg gefunden, einige Funktionen besser abzufangen, sodass dieses Umgehen nicht möglich ist. Das betrifft einige der wichtigsten Daten wie Kontakte. Leider ist das nur auf Android 4.4 (KitKat)-Systemen möglich, zudem sollte der Hersteller des Smartphones Android nicht zu stark verändert haben. Näheres findest Du in der FAQ: https://github.com/M66B/XPrivacy/blob/master/README.md#FAQ68
    Ich selbst bin noch bei Android 4.2.2. Trotzdem ist mein Eindruck, dass XPrivacy noch (leider? glücklicherweise?) zu selten eingesetzt wird, als dass App-Entwickler aktiv versucht haben, XPrivacys Schutzfunktionen über den von Dir erwähnten Hook zu umgehen. Auch mit XPrivacy im alten Kompatibilitätsmodus ist im Moment also IMHO eine Sicherung der Privatssphäre möglich.

  9. Comment Avatar Gert sagt:

    Hallo,

    kann XPrivacy eigentlich mittlerweile auch eine Fake bzw. leere IPv6 Adresse bei Anfragen weitergeben?

    Gruß
    Gert

  10. Comment Avatar Julian sagt:

    Hallo, erstmal wieder vielen Dank für diese top Artikelserie :)
    Da in Kürze ja Android Lollipop veröffentlicht wird frage ich mich wie es dann um XPrivacy bzw. dem Xposed Installer steht, zumindest in den ersten Monaten nach dem Release. Der Entwickler des Xposed Frameworks hat ja bereits angekündigt an einer ART-kompartiblen Version zu arbeiten, sagt aber auch dass das noch einige Monate dauern könnte. Was machst du in der Zwischenzeit um deine Daten weiterhin zu schützen ? Einfach kein Android-Update oder oder andere Schutzmaßnahmen ? Wenigstens die AfWall+ wurde laut Entwickler schon auf Lollipop getestet und soll auch gut funktionieren. Wenigstens ein Lichtblick.

    Gruß

    • Comment Avatar Mike Kuketz sagt:

      Die Antwort ist einfach: So lange keine geeigneten Schutzmaßnahmen in Form von XPrivacy und Co. existieren wird kein Update durchgeführt. Mir persönlich ist der Schutz der Privatsphäre deutlich wichtiger, als neue Funktionen, neuer Schnickschnack, neues Design und neue »Überwachungsfunktionen«. ;-)
      Und so lange Android 4.x mit Sicherheits-Updates versorgt wird, gibt es auch aus diesem Blickwinkel betrachtet keine Notwendigkeit schnell auf den Lollipop Zug aufzuspringen.

  11. Comment Avatar Mark sagt:

    Moin. Benutze XPrivacy in Kombination mit der AF+Wall. Seh ich das richtig das die Internetberechtigungen in XPrivacy immer entscheiden ob es ne Inetberechtigung gibt für eine App oder nicht? Zb gebe ich Firefox über die AF+Wall keine Internetberechtigung über die Whitelist aber kann trotzdem ins Inet wenn ich die entsprechenden Berechtigungen in XPrivaxy gewähre. Damit umgeht man die AF+Wall ja quasi ? Grüße Mark

    • Comment Avatar Mike Kuketz sagt:

      AFWall+ hat das letzte Wort. Nicht XPrivacy.
      Falls das bei dir nicht so ist, funktioniert AFWall+ nicht korrekt bzw. ist nicht korrekt konfiguriert.

  12. Comment Avatar Stef sagt:

    Finde die Kombi von XPrivacy unf AF+Wall auch super. Aber die Bedienung macht mir nach wie vor Kopfschmerzen. Dennoch, die bisher beste Anleitung hier! Gibts bei XPrivacy nicht auch templates? Z.B. lehne ich die Frage nach IDs usw eigentlich immer ab.
    Was man beim Leben ohne GApps beachten muß, nicht alle Apps funktionieren danach. Manche nutzen Schnittstellen, die erst die PlayServices bieten. Allerdings gibt es z.B. von Öffi auch eine Variante die ohne funktioniert (auf der Homepage).

    • Comment Avatar Alex sagt:

      den Play Store und die notwendigen Play dienste kann man doch auch mit XPrivacy beschränken, oder? Dann dürften auch andere Apps wie Youtube funktionieren.
      Zusätzlich kann man mit Titanium Backup bestimmte apps „einfrieren“ und dann machen die auch nichts wenn man sie nicht braucht. Ich hab auf dem Homescreen ein Titanium Widget angelegt welches die Notwendigen Play Dienste und die Play app selbst per Knopfdruck „auftauen“ bzw. wieder einfrieren kann. Mit meinem CM 4.3 brauchen mein Play Store nur folgende Dienste zum funktionieren. Diese kann man , wie gesagt, beschränken und bei Bedarf auftauen. Andere Google Dienste sind nicht nötig damit der Play Store funktioniert
      Google-Accout-Manager
      Google Play Store
      Google Play Dienste
      Google Dienste-Framework

      • Comment Avatar Stefan K sagt:

        Vor fast einem Jahr bin ich auf das Nogapps-Projekt gestoßen, dass quelloffene Dienste und Programme entwickelt, um damit die Google-Dienste bzw. bequem Alternativen nutzen zu können.
        Besonders interessant (und bei mir installiert) ist der BlankStore, mit dem man auf den Play Store zugreifen kann, ähnlich wie beim apk-Downloader. Der Vorteil ist, dass das über eine gefälschte Geräte-ID geschehen kann (man kann ziemlich problemlos die Android-ID für ein Galaxy Nexus generieren), sodass man halbwegs anonym den Play Store nutzen kann. (Tatsächlich wird explizit die Benutzung eines gefälschten Google-Accounts empfohlen, auch weil man mit dem BlankStore gegen die Google-Richtlinien verstößt.)
        Bezahlte Apps kann man damit nicht kaufen; eine zukünftige Version soll die Möglichkeit bieten, über den Browser Apps zu kaufen und diese dann zu installieren. Zudem gibt es hin und wieder bei der aktuellen Version einen „Forced Close“, d.h. die App wird einfach beendet. Trotzdem ist das in meinen Augen eine interessante Möglichkeit, um halbwegs anonym den Play Store nutzen zu können.
        Das Projekt befindet sich noch in der Entwicklung. Am Schluss soll es sogar eine freie Implementierung der Google Play Services geben.
        Hier der Link: https://forum.xda-developers.com/showthread.php?s=36a69a6e018c8bcfd3f2f1fabba763cd&t=1715375

        • Comment Avatar Simon sagt:

          Soweit ich das sehe, wird der BlankStore aber nicht mehr weiterentwickelt, oder? :(

        • Comment Avatar Alex sagt:

          Sehr interessantes Projekt, danke. Offensichtlich soll der Blankstore von jGoogle bzw. jGooglePlay abgelöst werden. Aber so lange der Blankstore funktioniert ist’s ja wurscht.

          Trotzdem würde ich gerne wissen ob irgendwas dagegen spricht den Play Store (und die nötigen Services) mit Xprivacy maximal zu beschränken, so wie ich es oben (16. November 2014 um 14:52) beschrieben habe. Nur Updates würde ich von PlayStore noch gerne erhalten und, falls möglich, apps kaufen.

          Weis das jemand ? Spricht was dagegen den Play Store aus Datenschutzgründen so zu beschränken?
          Wenn nein wäre die Frage welche Kategorien nicht beschränkt werden dürfen damit der Play Store noch läuft.

          • Comment Avatar MrGlasspoole sagt:

            Du redest da von Apps (den GAPPS) und nicht Diensten.

            Google Play Store sind 22 Dienste
            Google Play Dienste sind 110 Dienste
            Google Dienste-Framework sind 12 Dienste

            Die Teile haben zugriff auf alles was geht.
            Und wo ist der Sinn sich um Privacy Gedanken zu machen aber dann einen Google Account zu haben und sich bei diesem mit seinem Gerät auch noch anzumelden?
            Ist nicht böse gemeint aber das passt nicht.

          • Comment Avatar Alex sagt:

            Naja, die Teile haben doch nur Zugriff auf das was man mit Xprivacy erlaubt.
            Ich hab mehrere Apps die ohne Google Play Dienste auch gar nicht laufen.
            Ansonsten kann man ja diese Google Apps einfrieren (z.B. mit Titanium) wenn man sie nicht braucht. Dann kann nicht gesammelt oder verschickt werden während dieser Zeit.
            In der Zwischenzeit hab ich das ganze am laufen und mit XPrivacy bis zum maximal möglich beschränkt. Einfach war es nicht , aber es geht. Theoretisch könnte ich jetzt ein XML mit den Einstellungen ins Netz hochladen und jemand anderes kann die Grundkonfiguration übernehmen und u.U. anpassen.
            Ich hab über 100 runtergeladene Apps. Die mit Updates (gelegentlich) aktuell zu halten ist eigentlich nicht machbar ohne Google Play da ich nicht nur Sachen von F-Droid habe.

  13. Comment Avatar Simon sagt:

    Hey Mike,
    großartiger Beitrag, vielen Dank! Bin erst vor ein paar Tagen auf deine Seite aufmerksam geworden und freue mich endlich einen Blog gefunden zu haben, dessen Autor ähnlich paranoid ist wie ich! :)

    Eine Frage: Weißt du, weshalb XPrivacy sich im Android Manifest Zugriff auf die Kontaktdaten einräumen lässt?

  14. Comment Avatar XYZ sagt:

    Die deutsche Übersetzung der App ist nicht so gut.

    Beispielsweise wurde in den Einstellungen „Randomize on access“ mit „Zufallswerte bei Zugriff“ übersetzt.

    Zufallswerte bei Zugriff bekommt man aber auch ohne den Haken zu setzen, die „Randomize on access“ Option bedeutet das man bei jedem Zugriff neue Zufallswerte bekommt.

    Auch etwas kryptisch finde ich bei dem anwenden der Vorlage „verschmelzen“ und „Invers verschmelzen“.
    Hier ist „merge set“ und „merge reset“ gemeint. Also ob man gesetzte Haken oder nicht gesetzte Haken übernehmen will.

    Das klingt vielleicht pingelig, aber ich musste wirklich erst in der englischen Anleitung nachgucken bis ichs kapiert habe. Und da hab ichs allein aufgrund von den Bildern schon kapiert. Daher hab ich Xprivacy jetzt mit dem Modul „App Settings“ auf Englisch umgestellt.

    • Comment Avatar Phylon sagt:

      Übersetzen ist auch gar nicht so einfach, besonders wenn der Platz begrenzt ist.
      Wie würde denn eine gute Übersetzung an den genannten Stellen lauten?

    • Comment Avatar MrGlasspoole sagt:

      Und ich muss immer die Einstellungen suchen wenn ich versuche etwas wie hier (Deutsch) zu verfolgen.
      Bei mir ist alles Englisch – 10 PCs usw…
      Hab schon vor Jahren umgestellt da mehr Tutorials/Bücher usw in Englisch im Web zu finden sind als das bisschen Deutsch. Hat man seine Systeme dann in Deutsch laufen, dann sucht man sich oft einen Wolf :-)

  15. Comment Avatar Wolfram W sagt:

    Hallo, mein Problem:
    Xposed Framework lässt sich auf meinem gerooteten, älteren Exoten-Tablet (4.0.3)nicht ausführen(Fehlermeldung mit Installationswarnhinweis), damit fällt leider das gewünschte XPrivacy auch weg.
    Gibt es eine halbwegs Alternative zu XPrivacy? Ich suche und suche, aber alles verweist nur darauf hin.

    Vielen Dank im Voraus,
    W.
    AFWall ist drauf

  16. Comment Avatar Wolfram W sagt:

    Danke für die schnelle Antwort.
    Ich habe heute Nacht mein Problem noch näher eingekreist: Vermutlich ist mein Root nicht 100%. Das liegt daran, das 2011, als mein Tabel Acer A100 rauskam, zwar ein Root entwickelt wurde, der aber 1 Jahr später durch ein Androidupdate nicht mehr ging. Dann wurde nochmal etwas nachgebessert (mein Root) und dann wandte sich das allgemeine Interesse neueren Modellen zu, von daher gabs auch keine Customroms-> kein PDroid. Aber ich bin schon froh, das ich AFWall und ein komplettes SDMaid raufbekommen habe.
    Ich habe mir auch zwischenzeitlich überlegt, das die XPrivacy-Problematik auf dem Tablett nicht so schlimm ist:
    Mein Handy SGS2 mit meinem Privatleben ist komplett abgesichert und GApps-frei.
    Dieses Tablett (ohne SIM) ist nur für schnelle WLAN-Internetaufrufe,Youtube-Filme und Autonavi im Ausland. Dank AF-Wall und der Einfrierfunktion von SDMaid habe ich vieles blockiert, die YT-App gelöscht (schaue ich etwas unkomfortabler über einen freien Browser), Tablet nicht personalisiert.
    Viel Wissenswertes kann aus dem Tablet nicht mehr entweichen, da z.B.keine Kontakte und keine Sozialen Netzwerke drauf sind.

  17. Comment Avatar Jensuwe sagt:

    Wie ist das, wenn man Xprivacy unter Cyanogenmod benutzt, muss oder soll man den CM privacy guard dann abstellen? Oder macht das Xprivacy vielleicht selbst? Danke!

    • Comment Avatar Alex sagt:

      standardmäßig sollte der Privacy Guard ausgeschaltet sein und auch nicht benutzt werden (soweit ich weis). Wozu sollte man den auch brauchen wenn man Xprivacy hat.
      Ich glaub nicht das Xprivacy den ausschaltet.
      Bei mir jedenfalls ist er ausgeschaltet weil es vermutlich zu Komplikationen kommen kann wenn beide apps laufen die ja was ähnliches tun.

    • Comment Avatar Stefan K sagt:

      Etwas off-topic: Der Entwickler von XPrivacy, Marcel Bokhorst, weist auf Inkompatibilitäten zum Security Center von MIUI und zu LBE Security Master hin (siehe https://github.com/M66B/XPrivacy#compatibility ). Zu Inkompatibilitäten zu Privacy Guard sagt er anscheinend nichts, doch vergleicht er die Möglichkeiten, die XPrivacy bietet mit denen von PG. Ich stimme Marcel zu, dass XPrivacy die mächtigere Lösung ist.
      Ich denke, dass Alex Recht hat; natürlich kannst Du auch einfach ausprobieren, ob es zu Komplikationen kommt, aber eigentlich kann man PG der Einfachheit halber auch abschalten, weil XPrivacy dessen Funktionen abdeckt.

  18. Comment Avatar Anonymous sagt:

    Gibt es empfehlenswerte Alternativen zu xprivacy, wenn das xposed framework nicht mit dem Gerät kompatibel ist?

  19. Comment Avatar junkher sagt:

    Aktuell gibt es für Android Lollipop Xposed Framework nur im Alpha-Stadium, die Bugs aufweisen. Des weiteren hat der Entwickler nicht vor, eine Xposed Framework Version für Android Marshmallow zu entwickeln. Sollte man mit Xprivacy bei Android 5.x.x ,, ausharren “ oder auf den 6.x.x Zug aufspringen und nach Alternativen suchen, wenn es keine vernünftige Xposed Version für Android 6.x.x gibt?

    • Comment Avatar Mike Kuketz sagt:

      Also auf 6.0.1 läuft das XPosed Framework mit XPrivacy bisher ohne Probleme – auch wenn es eine Alpha ist. Und die Entwicklung vom Framework wird sicherlich weitergehen. Ohne dieses Framework wäre vieles nicht möglich.

      Bei Zeiten muss ich auch mal die Artikelserie überarbeiten.

  20. Comment Avatar swieder sagt:

    Hallo,

    also zunächst mal vielen Dank für die unschätzbare Hilfe die diese Artikelserie für mich schon war! Ich hab an dieser Selle zum ersten Mal ein Problem :) ich habe die APK des XPosed framework heruntergeladen und möchte mit dem bei Cyanogenmod (CM11) enthaltenen Dateimanager die Installation starten, allerdings kommt dann sofort ein „Parsing“-Fehler? Die APK habe ich von zwei verschiedenen Download-Stellen probiert, beides Mal der gleiche Fehler.

    Für Hilfe schonmal vorab danke!

    • Comment Avatar Hermann sagt:

      Hallo Swieder, Hast du die APK umbenannt? Wenn ja, dann versuche der APK wieder den richtigen namen zu geben den es beim Download hatte.
      Hast du die installation von unbekannten Quellen zugelassen?
      Wird die Version von XPosed die du runtergeladen hast mit Android 4.4.4 unterstützt?
      Versuche einen anderen Datei-Manager (z.B. ES Datei Explorer)

      • Comment Avatar SWieder sagt:

        Hallo nochmal,

        habe leider die falsche Reihenfolge gewählt für meinen Beitrag hier: erst schreiben, dann nachforschen *facepalm* …sorry für die Umstände liebe Helfer. Ich habe heute nochmal alles wie bei GitHub durchgeführt und es hat geklappt! Ich verstehe nicht 100% wieso es ging, aber vermutlich hatte ich gestern Abend irgendeinen Pfosten im Auge, anders kann ich mir das nicht erklären…lief alles super glatt, mit denselben APK’s, dem gleichen Dateimanager.

        Nochmal sorry für die Umstände und danke für die tolle Artikelserie!

  21. Comment Avatar Olaf sagt:

    Hallo Mike

    Ich bin vor einigen Tagen auf diese tolle Artikelserie gekommen, da ich im Internet nach Root-Anleitungen gesucht habe.
    Habe mich dann, nachdem ich erst einmal verschiedene ROMs durchprobiert habe und jetzt bei Omnirom gelandet bin, intensiv mit diesem Blog beschäftigt und auch soweit alles eingerichtet.
    Klasse.
    In der Materie Android durchzusteigen, ist teilweise verdammt schwer. Zum Glück kenne ich mich etwas mit Linux aus und deswegen ist mir da nicht alles unbekannt.
    Ich kann nur jedem raten, sich damit zu beschäftigen, gleichwohl es z.T. eher was Freaks ist.
    Es ist schon schwierig genug, Android zu installieren. Diese leidvolle Erfahrung habe ich machen müssen. Z.b. hatte ich mit OdinLite zip-Dateien installiert, was danach auf dem selben System nicht mehr ging und er nur tar-Dateien korrekt installierte. Aber jetzt ist es einsatzfähig. Ich mußte mich allerdings sehr umgewöhnen, was z.b. Tastaturlayouts oder SMS/Kontakte Manager angeht.
    Aber mit der Zeit wird es klappen.
    Macht weiter so.
    Habe heute mal in einer Android-Zeitung geblättert und ein Artikel Android ohne Google gefunden. War aber schwer enttäuscht. Außer ein paar allgemeinen Sätzen, keine so tolle Führung wie hier.
    Werde den Blog bei mir in die Lesezeichen setzen.
    Habt Ihr ein Banner, was ich auf meine HP setzen kann?

  22. Comment Avatar Anonymous sagt:

    In wie fern kann eine App problematisch sein, wenn sie die Berechtigung: Anzeigen (mittels Browser) hat? Gibt es dabei ein Missbrauchspotential?

    • Comment Avatar Alex sagt:

      Theoretisch könnte eine Sicherheitslücke im Browser ausgenutzt werden wenn die App auch Internetzugriff hat. Das hat aber weniger mit Datenschutz zu tun sondern eher mit Sicherheit.

      Die App kann mit dieser Einstellung Webseiten laden. Zusätzlich muss, soweit ich weiß, auch Internet Adressen erlaubt werden damit die App etwas aus dem Internet laden kann.
      Soweit ich weiß kann man im Browser ja auch Internetseiten laden die auf dem Handy liegen und nicht im Internet.

  23. Comment Avatar Ein anonymer Kommentator sagt:

    Ich habe hier noch einen wertvollen Tipp auf Lager:
    Da es problematisch ist, mit XPrivacy Berechtigungen von System Apps zu reglementieren, kann man dies mit den Privacy Guard von Cyanogenmod tun. Instabilitäten und Bootloops kommen nicht vor.

    Daher sollte man mit:
    – XPrivacy, Benutzer-Apps reglementieren
    – Privacy Guard, System-Apps reglementieren

    Darüber hinaus kann man Berechtigungen wie ,,WLAN an-/ausschalten “ nicht mit XPrivacy reglementieren. Diese Lücken kann der Privacy Guard schließen. Es sei noch zu erwähnen, dass der Privacy Guard nicht alle, aber die meisten System-Apps reglementieren kann.

    Damit ergänzen sich XPrivacy und Privacy Guard hervorragend, um auch die letzten Lücken zu schließen.

  24. Comment Avatar Anonymous sagt:

    Hallo,

    eine sicherlich etwas dummer Frage, aber irgendwie bin ich nach längerer Recherche nicht auf die Antwort gestoßen.

    Ist es wirklich so, dass die App seit etwa einem Jahr keine Updates erhalten hat?

    Version Information https://forum.xda-developers.com/xposed/modules/xprivacy-ultimate-android-privacy-app-t2320783)
    ——————————————
    Status: Stable
    Current Stable Version: 3.6.19
    Stable Release Date: 2015-07-01
    ——————————————

    … oder verstehe ich da etwas falsch.
    Es kann natürlch auch sein, dass seit einem Jahr keine Veränderungen notwendig waren, was ich in der schnelllebigen IT Welt für relativ unwahrscheinlich halte.
    Wird das Projekt an anderer Stelle weiterentwickelt oder wie ist das zu erklären?
    Der Entwickler M66B ist ja durchaus noch aktiv im Forum.

    Für eine kurze Aufklärung vielen Dank!

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.