Was für das Eine oder das andere Projekt spricht ist grundsätzlich
Ansichtssache des Nutzers. Ich kann an der Stelle nur ein wenig
Hintergrundinformation beitragen. Es muss Jeder selbst entscheiden, was
er damit macht.
Zunächst einmal muss man folgende Timeline kennen: Epigraulet → AkDeniz
→ Raccoon → Yalp Store → Aurorastore.
Epigraulet war ein Python Projekt und meines Wissens nach die
ursprüngliche Grundlagenforschung zu Google Play. Das Projekt wurde
aufgegeben und ist nicht mehr relevant.
AkDeniz war ein Java Port von Epigraulet. Das Projekt wurde ebenfalls
(bereits vor Raccoon) aufgegeben und ist auch nicht mehr relevant.
Raccoon basiert (bis version 4.x) auf AkDeniz und wird ab v5.x einen
völlig neuen Unterbau erhalten, da der AkDeniz Code alles andere als
wartungsfreundlich ist.
Yalp Store war ein Quick&Dirty Fork von Raccoon (hauptsächlich der alte
AkDeniz Code mit einigen Raccoon Aktualisierungen, ohne die sich nicht
mehr auf Play zugreifen lies). Ohne Yalp hätte es eine Raccoon App
gegeben. Das (Haupt)Problem war damals einfach, dass AkDeniz das gesamte
ProtocolBuffer Schema in einer Datei untergebracht hatte und der daraus
generierte Code eine riesige Klasse enthielt, mit der Eclipse
überfordert war. Es hat Zeit gekostet, das alles auseinander zu rupfen
(wir reden hier über eine 35kb Schema Datei, die auf ca. 178 Dateien
aufgeteilt werden musste, plus das Umschreiben von jeder Menge Code).
Der Autor von YalpStore war halt einfach schneller damit, ein UI um den
Tech Debt zu bauen und als eigene Android App zu veröffentlichen. Er hat
darüberhinaus ein sehr beliebtes, sehr fragwürdiges und auch sehr
gefährliches Feature eingeführt, welches dann in Aurorastore übernommen
wurde (mehr dazu später). Eine andere Sache, die eine Raccoon App
verzögert hat war dem Umstand geschuldet, dass Raccoon immer einen
starken Fokus auf Backups hatte. Zum einem gab es mit HumbleBundle
damals eine sehr interessante Quelle für Android Spiele (die man
vielleicht nicht im Downloadfolder aufbewahren wollte), zum Anderem
begannen desillusionierte App Entwickler damals damit, ihre Apps zu
verkaufen. Ein sehr prominentes Beispiel hier war Chainfire, der sein
SuperSU an Cheetah Mobile verkaufte. Raccoon sollte in solchen Fällen
die Möglichkeit bieten, zu einer alten App Version zurück zu kehren
(natürlich war dieser Backup Gedanken aus Speicherplatzgründen in einer
Android App undenkbar). Im Nachhinein betrachtet muss die Konzentration
auf diesen Aspekt allerdings als strategische Fehlentscheidung gewertet
werden.
Aurora Store ist eine feindliche Übernahme von YalpStore: Yalp hing, aus
Kompatibilitätsgründen an Holo (Android 4.x UI) fest, welches dem Autor
von Aurora aber zu altbacken erschien. Man kann darüber spekulieren, ob
es der vorher angesprochene Tech Debt in Yalp war, der ein neues/zweites
UI Design verhinderte oder ob sich da einfach nur jemand mit wenig
Aufwand ein Vanity Projekt für den Lebenslauf zulegen wollte. Fakt ist,
Aurora war zunächst lediglich ein Yalp mit Makeup und besagter
Entwickler hat sich nie damit hervorgetan selbstständig Lösungen zu
finden, wenn Google mal wieder das Wire Protocol geändert hat.
Entsprechende Fixes kamen üblicherweise von microG und Raccoon (you’re
welcome). Nebenbei bemerkt wurde Aurora mittlerweile komplett von Java
nach Kotlin portiert, wobei man, aus welchen Gründen auch immer, den
alten Tech Debt einfach mit portiert hat (die oben erwähnte Schema Datei
ist jetzt halt 60kb groß - soviel zur code quality). Der Vollständigkeit
halber sollte noch erwähnt werden, dass man an das Projekt CO2
Zertifikate (aka Cryptocurrency) spenden kann. Das Positive daran ist,
dass man an den Wallets sehen kann, wie chronisch unterfinanziert Open
Source Projekte sind. Was in diesem Fall eine Erklärung dafür sein
könnte, warum der ursprüngliche Hauptentwickler über ein Jahr lang
abgetaucht und Aurora praktisch abandonned war. Es erklärt auch, warum
Auroras Server notorisch instabil sind: einige/alle(?) Token Dispenser
scheinen auf privaten Maschienen zu Hause zu laufen, die ständig
überlastet sind. Und das bringt uns zum Elefanten im Raum, dem oben
erwähntem Antifeature, welches Yalp Store und Aurora Store vereint,
sowie beide Apps zu einem potentiellem Sicherheitsrisiko für Nutzer und
Entwickler macht: anonyme Accounts.
Ein „anonymer Account“ ist zunächst einmal ein Oxymoron, denn der
ureigentliche Sinn eines Kontos ist die Identifizierbarkeit. Man kann
sich an der Stelle natürlich darüber streiten, ob man mit diesen
Accounts identifizierbar ist (Spoiler: das wäre jetzt eine gute Stelle,
nicht weiter zu lesen), aber der Punkt hier ist, dass dieses Feature
(bereits in Yalp), vermutlich aus Schlampigkeit, falsch benannt wurde.
Es handelt sich eben nicht um anonyme, sondern um geteilte Accounts (die
vom Aurora Team für die allgemeine Nutzung registriert wurden) und das
ist in gleich zwei Dimensionen gefährlich.
Zunächst einmal muss darauf hingewiesen werden, dass der Code von Aurora
unter GPL v3 Lizenz steht. Der Kern jeder Open Source Lizenz ist der
Haftungsausschluss, d.h. der Nutzer kriegt die Software gratis und
akzeptiert im Gegenzug, dass der Autor keine Verantwortung für die
Folgen der Nutzung übernimmt.
Was den meißten Menschen nicht bewusst ist, ist dass ein Nutzerkonto
(egal bei welchem Service) einen rechtsverbindlichen Vertrag darstellt
(die lästige Box mit den AGB, die jeder sofort ungelesen weg klickt). Um
es in aller Deutlichkeit zu sagen: wer seinen Google Account weiter
gibt, der haftet für Schindluder, den Dritte damit anstellen (Anmerkung:
nur weil das Aurora UI es selbst nicht her gibt, heißt nicht, dass man
in den App Reviews keine Liebesgedichte an Hitler, im Namen des Aurora
Teams, veröffentlichen könnte). Auf die Problematik angesprochen war die
Antwort des Yalpstore Entwicklers damals übrigens nur lapidar: „Ich bin
Russe, Google’s Rechtsabteilung kann mich mal“. Und damit hatte Yalp
dann halt ein Feature, das Raccoon nicht bieten konnte und die Open
Source Welt einen Präzedenzfall der den Sinn der GPL komplett auf den
Kopf stellte…
Als Aurora/Yalp Nutzer kann man sich natürlich (mit einigem Recht) auf
denselben Standpunkt stellen: wenn ein (unbezahlter) App Entwickler
freiwillig seinen Kopf für seine Nutzer in die Schlinge stecken möchte,
um sich eine Community aufzubauen, dann ist das halt sein Problem, wenn
es deswegen Ärger gibt - welche Art von Ärger das sein könnte, dazu
später mehr. Wichtig ist an dieser Stelle erstmal einige technische
Details des Wireprotocols zu kennen, wie/wo einem besagter Ärger als
Nutznieser dann doch auf die Füße fallen kann.
Zunächst einmal muss man wissen, dass besagte „anonyme“ Accounts von
einem Service namens „Tokendispenser“ bereit gestellt werden. Dabei
handelt es sich um einen kleinen Webserver mit einer
Benutzername/Passwortdatenbank von Accounts aus der Community. Wenn
Aurora einen Account benötigt, loggt der Tokendispenser zufällig einen
aus seinem Pool ein und und schickt der App den Sessioncookie
(Anmerkung: Aurora Store erhält nicht das Passwort und die Sitzung ist
auf den Playstore eingeschränkt. Weitere Anmerkung: auch damit kann man
bereits Schindluder treiben. Extra Anmerkung: Schindluder wurde/wird
getrieben; Konten wurden/werden gesperrt - weswegen die Tokendispenser
eben so unzuverlässig sind, dass gefühlt jeder Dritte Bugreport sich um
sie dreht).
Desweiteren muss man wissen, dass Android aus zwei Gründen existiert: 1.
Google hatte nach den Browserwars Angst, dass Microsoft sie, wie
Netscape, am ausgestreckten Arm verhungern lassen könnte. 2. Google war
es leid, ständig Trackingdata zu verlieren, weil Nutzer ihre Cookies
löschten. Man wollte eine eigene Platform, bei der Trackingcookies ins
Betriebssystem integriert waren und nur mit erheblichem Aufwand gelöscht
werden konnten. Die erste Iteration dieses OS based Cookies war die
Android ID, eine 64 Bit Hexzahl, die ein Gerät zufällig bei jedem
Factory Reset auswürfelte. Warum das eine schlechte Idee war muss hier
nicht aufgeführt werden. Wichtig ist nur, dass es fehl schlug und die
Android ID durch die GSF ID (Google Services Framework ID) ersetzt
wurde. Auch dies ist eine 64 Bit Hex Nummer mit dem Unterschied, dass
sie das Gerät nicht selber auswürfelt, sondern dass die Playstore App
sie während der Geräteinstallation serverseitig registriert.
Die GSF ID ist, vereinfacht gesagt, ein Verzeichnisname (oder etwas
genauer: ein Key in Google’s Bigtable Database). In dieses „Verzeichnis“
lädt die Playstore App zwei „Dateien“ hoch, die eine besteht aus dem
Gerätedatenblatt, die andere enthält den Benutzernamen des Accounts, der
mit dem Gerät verbunden ist.
Zur Playstore App muss man wissen, dass sie praktisch ein Webbrowser
ist. Google hat hier das Rad komplett neu erfunden (nur etwas eckiger).
Wenn man eine Suchanfrage (oder überhaupt irgendeine Anfrage) an Play
sendet, müssen zwei HTTP Header mitgeschickt werden: „Authorization:“
(mit dem „Sessioncookie“ - aus dem Tokendispenser) und
„X-DFE-Device-ID:“ (mit der GSF ID). Anhand der GSF ID kann Play dann
das Datenblatt nachschlagen und die Suchergebnisliste serverseitig nach
kompatiblen Apps filtern.
Mit anderen Worten: dank der GSF ID ist man als Aurora Nutzer eben nicht
anonym/non-trackable unterwegs. Da diese immer in Verbindung mit dem
Sessioncookie steht kann Google selbstverständlich sehen, welche Nutzer
sich einen Account teilen und wenn man noch die IP Adresse als weiteres
Kriterium heran zieht dann lässt sich auch eine Verbindung zu anderen
Geräten im Haushalt (z.B. das Smartphone eines Familienangehörigen, der
kein Aurora nutzt) ziehen. Ein ähnliches Problem kann/könnte man
kriegen, wenn man zwischen anonymen und eigenen Accounts hin und her
wechselt, Play Protect am laufen hat, oder allgemein nicht so genau
weiss, was Android eigentlich intern so treibt (Anmerkung: selbst Google
Ingeneure haben da mittlerweile den Überblick verloren).
Als verantwortungsbewusster Entwickler muss man sich an dieser Stelle
folgende Frage stellen: Haftungsausschluss hin oder her, kann dies
meinen Nutzern (gegebenenfalls in der Zukunft) auf die Füße fallen, wenn
ja, wie?
Es ist ein Fakt, dass Google Konten sperrt (und das ist dem Aurora Team
auch bekannt, da dies immerhin ein Hauptproblem der Tokendispensern
ist). Google hat halt auf der einen Seite kein Interesse an einer
anonymen Nutzung seiner Dienste und auf der anderen Seite ein enormes
Spam Problem (in Bezug auf Android: mit Fake Reviews im Playstore). Wo
Google allerdings absolut keinen Spaß versteht ist Kreditkartenbetrug.
Stornierte Zahlungen kosten einen Händler richtig Geld. Wird
beispielsweise ein „geborgter“ Account benutzt, um zu testen ob
gestohlene Kartennummern noch gültig sind, dann ist Jagdsaison. Als
Tokendispenser Nutzer weis man nie, was andere Nutzer (respektive der
Accountinhaber) vorher (und auch nachher!) mit dem Account getrieben
haben und welches automatische System bei Google als nächstes über die
Strenge schlägt. Hier gilt einfach: mitgefangen, mitgehangen. Man glaubt
seine Privatsphäre zu schützen, spielt aber eigentlich russisches Roulette.
Mit den Suchbegriffen „reddit banned google account“ kann man jedenfalls
in ein wunderbares Rabbithole fallen oder man kann sich statt dessen
einen schönen Nachmittag machen, indem man einfach einsieht, dass
Accountsharing ein Klasse Feature ist, um das man aus Sicherheitsgründen
(auch im Interesse seines Umfeldes und seiner Zukunft) besser einen sehr
weiten Bogen macht…
)
