Hallo,
ist der Bezug (respektive der „Umweg“) von Apps mit Aurora Store eigentlich nur von Vorteil, falls die GPlay App ohne die 3 Google Services (GrapheneOS) läuft?
Hallo,
ist der Bezug (respektive der „Umweg“) von Apps mit Aurora Store eigentlich nur von Vorteil, falls die GPlay App ohne die 3 Google Services (GrapheneOS) läuft?
Die Frage ist leider nicht so leicht zu verstehen. Wenn du mit GPlay den Play Store meinst - es ist nicht vorgesehen, „nur“ den Play Store zu installieren ohne die anderen Apps, das führt sehr wahrscheinlich zu Problemen. Ebenso ist der Aurora Store keine allzu gute Lösung, da das Konzept mit den geshareten Accounts recht wackelig ist und eigene Privatsphäre-/Sicherheitsprobleme mit sich führt.
Empfohlen sind seitens GrapheneOS im Prinzip drei Lösungen:
Wenn diese Antwort an deiner Frage vorbeigeht, müsstest du nochmal neu formulieren, was du überhaupt meinst, und auch definieren, was du mit „Vorteil“ meinst.
Der Aurora Store dient hauptsächlich dazu, auf nonGoogle Systemen, eine wesentliche Einschränkung (weniger Apps) abzumildern.
Bei einem Android mit Google Services/Play Store, hat der Aurora Store keine Vorteile.
Nicht nur das. Sondern auch, Apps aus dem Play Store laden zu können, ohne sich dafür mit einem Google Account anmelden zu müssen.
Auch Aurora muss sich mit einem Google Account anmelden.
(nur nicht der eigene)
Und ich sehe nicht, weshalb das ein Vorteil des Aurora Stores sein soll.
Inwiefern?
Was nützt dir die Sandbox, wenn die größte Bedrohung in Sachen „Privatsphäre“ mit dir im Sandkasten sitzt?
Sie sitzt eben nicht im gleichen Sandkasten.
Ooh, dann hab ich es offensichtlich nicht richtig verstanden.
Nehmen wir mal ein Beispiel:
auf GrapheneOS sind die sandboxed Google Dienste installiert und eine App, die diese Dienste benötigt, z.B. DB Navigator .
Ich sehe also drei Instanzen:
GrapheneOS,
Google Dienste,
die App DB Navigator.
Wer wird jetzt von wem abgeschottet? Und wer sitzt eventuell mit wem gemeinsam im Sandkasten?
Ich würde mich freuen, wenn du mir das erklären kannst.
Grob vereinfacht kann man es sich ungefähr so vorstellen:
Auf Android ist jede App in einer App-Sandbox. Jede App kann zunächst nur auf auf ihre eigenen Daten im privaten App-Speicher zugreifen, nicht auf die Daten anderer Apps oder des Benutzerprofilspeichers. Benutzerprofildaten, wie Kontakte, sind erst nach expliziter Genehmigung durch den Benutzer zugänglich. Innerhalb eines Benutzerprofils kann eine App allerdings via IPC mit anderen Apps kommunizieren. Dabei gilt: eine Kommunikation findet nur statt, wenn beide Apps einvernehmlich zustimmen. Wenn nur eine App dem nicht zustimmt, findet es schon nicht statt. Aus Threat Model-Sicht macht das bei Android Sinn. Freiwillig kooperierende Apps könnten das auch ohne diese Möglichkeit tun, z.B. über das Netzwerk. Dieser Zustand ist also viel besser als unter Windows oder vielen Linux-Desktop-Distros, bei der die meisten Apps unbeschränkten Zugriff auf die Daten innerhalb des Benutzerkontos haben.
Unter „normalem“ Android ist es nun so, dass die Play Services diesen Beschränkungen nicht unterliegen und privilegiert sind. Die Play Services haben also Zugang zu allen möglichen sensiblen Informationen, auch ohne Nutzerfreigaben und sogar auf Daten, die man einer App gar nicht freigeben könnte wie Hardware-IDs. Im Gegensatz dazu ist es bei GrapheneOS so, dass auch die Play Services innerhalb der Sandbox laufen und zunächst keinen Zugang zu Nutzerdaten hat. Wenn die App DB Navigator unter GrapheneOS Daten an die Play Services weitergibt oder anfordert, geht das nur, wenn beide dem zustimmen. Der DB Navigator könnte aber auch ohne separat installierte Play Services Daten mit Google austauschen, da jede App die mit Play Services interagiert sowieso schon Google Code enthält und dieser dazu fähig wäre, siehe z.B. für Ads, also hat man durch die Installation der Sandboxed Play Services kaum etwas verloren. Wenn man das komplett verhindern will, muss man nicht nur auf Play Services verzichten, sondern auch auf Apps die Google’s Services in irgendeiner Weise verwenden.
Super erklärt, vielen Dank.
Man könnte das ins Unterforum Tutorials aufnehmen.
Wird das nicht vorher in der Manifest Datei in den Abschnitten mit android:exported
definiert?
Soweit ich weiß wird dort gesteuert, ob eine Komponente für andere Apps zugänglich ist.
android:exported="true"
→ Komponente ist für andere Apps aufrufbar.android:exported="false"
→ Komponente nur innerhalb der App zugänglich.Und über den Intent-Filter kann man z.B. Dateitypen mitgeben.
Bei Android gibt es eine ganze Reihe an IPC-Mechanismen. Bezüglich Deklaration von „android:exported“ gibt es auch Ausnahmen. Beispielsweise kann man das weg lassen. Das Problem ist dann, dass der Default-Wert nicht bei jedem Gerät gleich ist. Auch bei „false“ kann in bestimmten Fällen IPC stattfinden, z.B. wenn die „user ID“ die selbe ist, oder privilegierte Systemkomponenten darauf zugreifen.
Okay, unter „zustimmen“ hatte ich was anderes im Kopf.
War immer der Meinung Aurora sei eine „Wunderwaffe“
Immerhin wird doch mit Aurora (via Rethink + VPN) die IP meines Anschlusses und mein
GPlay Account-Name nicht an Google „weitergegeben“ ?