Google schränkt Sideloading unter Android ein

 (puri.sm)
4 Punkte von GN⁺ 2025-06-06 | 3 Kommentare | Auf WhatsApp teilen
  • Google hat kürzlich eine Richtlinie zur Einschränkung des Sideloadings von Android-Apps eingeführt, was die Debatte über die digitale Autonomie der Nutzer und die Offenheit des mobilen Ökosystems verschärft hat
  • In einem Pilotprojekt in Singapur wurden die Regeln verschärft, indem die Installation von Apps, die über Web, Messenger oder Dateimanager bezogen wurden und sensible Berechtigungen (SMS, Bedienungshilfen usw.) anfordern, blockiert wird
  • Mit der Einführung der Play Integrity API können Entwickler Funktionen von per Sideloading installierten Apps einschränken und so eine geschlossene, auf den Google Play Store zentrierte Vertriebsstruktur stärken
  • Diese Maßnahmen können zwar zu mehr Sicherheit beitragen, stoßen aber auf Kritik, weil sie Innovation und Wettbewerb schwächen und die Offenheit von Android beeinträchtigen
  • Purism präsentiert mit PureOS und Librem 5 eine Alternative in Form von Open-Source- und datenschutzorientierten mobilen Lösungen, die Datensouveränität und eine freie App-Installationsumgebung für Nutzer gewährleisten

Google führt Einschränkungen für Android-Sideloading ein

  • Google hat vor Kurzem unter Verweis auf Sicherheitsprobleme damit begonnen, neue Beschränkungen für per Sideloading installierte Apps unter Android anzuwenden
  • Die Pilotregelung in Singapur wurde in Zusammenarbeit mit einer Cybersicherheitsbehörde eingeführt und beschränkt insbesondere die Installation von Apps, die sensible Berechtigungen wie SMS-Zugriff oder Bedienungshilfen anfordern, wenn sie über Webbrowser, Messaging-Apps oder Dateimanager verteilt werden
  • Ziel dieser Maßnahme ist es, Kriminalität durch Betrug und Malware zu verhindern

Play Integrity API und Abhängigkeit vom App-Store

  • Durch die Einführung der Play Integrity API ermöglicht Google App-Entwicklern, bestimmte Funktionen einzuschränken, wenn eine App per Sideloading installiert wurde
  • Diese Richtlinie setzt Nutzer unter Druck, Apps nur noch über den offiziellen Weg des Google Play Store zu installieren
  • Nach außen wird zwar das Ziel einer höheren Sicherheit betont, tatsächlich führt dies jedoch zu einer stärkeren Kontrolle des Android-Ökosystems durch Google
  • Damit werden erneut Bedenken hinsichtlich digitaler Autonomie, Innovation und Nutzerrechten laut

Kritik und Auswirkungen

  • Kritiker weisen darauf hin, dass die Richtlinie zwar wirksam gegen bösartige Apps sein kann, gleichzeitig aber den Wettbewerb einschränkt und die Wahlfreiheit der Nutzer verringert
  • Die für Android typische Offenheit der Plattform und Freiheit beim Sideloading wird geschwächt, wodurch sich das System letztlich in eine Richtung bewegt, die dem geschlossenen Ökosystem von Apple iOS ähnelt
  • Dieser Trend könnte zu weniger Innovation und einem Monopol bei der App-Verbreitung führen

Purisms Alternative: PureOS und Librem Phone

  • Purism präsentiert als Reaktion auf die zunehmende Überwachung und Unternehmensdominanz einen datenschutzorientierten Ansatz
  • PureOS ist ein Debian-basiertes Linux-Betriebssystem, das auf Librem 5 und Liberty Phones läuft und vollständige Nutzerautonomie sowie Datensouveränität gewährleistet
  • In dieser Umgebung werden nur Open-Source-Sicherheits-Apps unterstützt, die keine zielgerichtete Werbung, kein Data Mining, keine suchterzeugenden Algorithmen und keine Verhaltensmanipulation einsetzen
  • Nutzer sind nicht auf unternehmenseigene App-Stores oder invasive APIs angewiesen und erhalten so ein transparenteres und sichereres Computing-Erlebnis

Fazit: Die Bedeutung offener Alternativen

  • Während Google das Android-Ökosystem zunehmend geschlossener gestaltet, setzt Purism auf eine ethische, sichere und offene mobile Computing-Umgebung
  • Alternativen mit Fokus auf Nutzersouveränität und Datenschutz entwickeln sich zu einer wichtigen Option für die Tech-Branche und Entwickler

Verwandte Beiträge

3 Kommentare

 
spp00 2025-06-07

Tatsächlich könnte man beim Sideloading zumindest prüfen, ob es sich um eine vertrauenswürdige APK handelt, wenn man nur ein „System vertrauenswürdiger Signierer“ einführt und dieses für Drittanbieter-Zertifizierer wie DigiCert öffnet. Das Problem ist, dass Google das so aufgebaut hat, dass dies faktisch dem Play Store überlassen wird. Aber ob der Google Play Store schädliche Apps wirklich gut erkennt, ist fraglich, und bei Apps, die gegen die Google-Play-Richtlinien verstoßen, ...
 
ndrgrd 2025-06-06

Der Artikel selbst wirkt, als sei seine Absicht fragwürdig, aber in der tatsächlichen Nutzung wird es tatsächlich zunehmend lästig.
Auf Galaxy-Geräten haben sie es bereits so gemacht, dass man Funktionen wie das Blockieren mutmaßlich schädlicher Apps gar nicht mehr deaktivieren kann. Es gibt zwar Umgehungsmethoden, aber solche Einschränkungen werden nach und nach immer weiter ausgebaut.
Für Gelegenheitsnutzer, die Sideloading kaum verwenden und bei denen sich so die Ausführung von Schadcode verhindern lässt, kann das eine gute Funktion sein, aber sollte man sie zumindest nicht abschalten können?

Ich hatte gehofft, dass das Pixel offiziell eingeführt wird, aber wenn Google etwas Ähnliches macht ...
 
GN⁺ 2025-06-06
Hacker-News-Kommentare

  • Es wird als sehr seltsames Timing empfunden, ausgerechnet jetzt einen Blogpost zu veröffentlichen; es wird die Frage aufgeworfen, ob der Artikel vielleicht schon vor Monaten vorbereitet und erst jetzt publiziert wurde. Zudem wird darauf hingewiesen, dass dieses Pilotprogramm bereits vor 1 Jahr und 4 Monaten in Singapur angekündigt wurde. Betroffen seien nur Apps in Singapur, die bestimmte Berechtigungen benötigen, etwa RECEIVE_SMS, READ_SMS, BIND_NOTIFICATIONS oder Bedienungshilfen. Es gehe nur um Apps, die direkt außerhalb eines App-Stores heruntergeladen werden; Installationen über F-Droid oder adb seien offenbar weiterhin möglich. Durch Deaktivieren von Play Protect ließe sich möglicherweise eine Umgehung versuchen, ob das in Singapur tatsächlich funktioniere, wisse man aber selbst nicht. Bemerkenswert sei, dass Google verhindert habe, Play Protect während eines Anrufs abzuschalten, was als kluge Entscheidung gelobt wird. Zitiert wird außerdem eine Mitteilung der singapurischen Polizei, wonach dieser Ansatz in der Praxis keine besonders gute Wirkung erzielt habe: Opfer würden angewiesen, Google Play Protect vor der Installation von APK-Dateien abzuschalten und sogar VPN-Apps zu installieren, damit Betrüger Schutzmechanismen von Banken umgehen können. Link dazu: https://police.gov.sg/media-room/news/…

    • Es werden Daten erwähnt, nach denen Menschen in Singapur besonders anfällig für Betrug seien: Im vergangenen Jahr seien Zehntausende betroffen gewesen und insgesamt 1,1 Milliarden Singapur-Dollar verloren gegangen, ein Anstieg von 70 % gegenüber dem Vorjahr. Laut Statistiken der Global Anti-Scam Alliance dürfte die tatsächliche Zahl noch höher liegen als die gemeldeten Fälle. Als Gründe, warum Singapur gezielt ins Visier gerät, werden Wohlstand, Digitalisierung und eine Kultur der Regelbefolgung genannt. (https://archive.is/fCmW1)

    • Es wird die Meinung geäußert, dass unklar sei, warum der Purism-Blogpost gerade jetzt erschienen ist, und dass es sich wohl nur um marketinggetriebenes FUD handele. Librem 5 und Liberty Phones auf PureOS-Basis werden direkt erwähnt, und es wird infrage gestellt, ob sie überhaupt APKs ausführen können. Nur Sailfish biete so etwas, sei aber wegen Lizenzfragen ein Sonderfall. Zwar wird anerkannt, dass Purism viel in die Entwicklung berührungsoptimierter Linux-Umgebungen wie Phosh investiert, zugleich wird betont, dass Linux-Touch-Umgebungen insgesamt noch sehr schwach seien. Der Eindruck sei, dass hier eine Mainstream-Alternative absichtlich schlecht dargestellt werde, obwohl das Problem die eigenen Produkte gar nicht direkt betrifft, um das eigene Marketing zu stützen.

    • Es wird betont, dass der zeitliche Kontext vor und nach Googles ungünstigem Urteil im App-Store-Verfahren wichtig sei. Es sei schwierig, eine Balance zu finden, bei der Nutzer geschützt werden und zugleich Freiheit behalten. Wenn Nutzer sich an Sicherheitswarnungen gewöhnen, ignorieren sie sie am Ende ohnehin. Auch der Play Store sei nicht vollständig sicher; selbst veröffentlichte GPS-Daten von Android-Nutzern würden bösartiges Verhalten offizieller Apps belegen. Als Alternative wird vorgeschlagen, dass für besonders gefährdete Nutzer eine kluge und vertrauenswürdige Drittpartei Geräteadministratorrechte haben sollte.

  • Es gibt die Ansicht, dass der Beitrag ohne viel Substanz eher wie Werbung für Purism wirkt.

    • Sobald man erkannt habe, dass es Werbung sei, sei der gesamte Inhalt bedeutungslos geworden; es wird nach besseren Links gefragt.

    • Gemessen an den Upvotes, so die Einschätzung, seien viele Menschen über die Richtung von Android besorgt und an Alternativen interessiert.

  • Es wird gefragt, ob dieses Thema nicht bereits aus dem Jahr 2024 sei. (https://techcrunch.com/2024/02/…)

  • Zum zuerst in Singapur eingeführten Pilotprogramm wird erläutert, dass nur Apps blockiert werden, die bestimmte Berechtigungen wie SMS oder Bedienungshilfen anfordern und über Webbrowser, Messenger oder Dateimanager installiert werden. Da es viele Detailbedingungen gebe, könnten fortgeschrittene Nutzer wahrscheinlich weiterhin die Apps installieren, die sie wollen. Die Maßnahme sei offenbar darauf ausgerichtet, Durchschnittsnutzer daran zu hindern, riskante Sideloading-Apps mit SMS- oder Bedienungshilfen-Rechten allzu leicht zu installieren. Hervorgehoben wird, dass dies in Zusammenarbeit mit der Cyber Security Agency of Singapore zur Betrugs- und Malware-Prävention erfolge, was auch den auf Singapur begrenzten Einsatz erkläre.

    • Es wird darauf hingewiesen, dass solche Einschränkungen im Massenmarkt sehr wohl wettbewerbswidrig wirken können: Eine kleine technisch versierte Minderheit könne zwar weiterhin installieren, die große Mehrheit bleibe aber innerhalb des von Google kontrollierten „Walled Garden“. Google und Apple nutzten zudem abschreckende Formulierungen gegenüber Drittanbieter-Apps, um psychologische Hürden aufzubauen. Das sei eine Form von „Gedankenkontrolle“, die regulatorisch beendet werden müsse.

    • Es wird betont, dass „nur in Singapur“ kein besonders beruhigender Grund sei. Browser und Dateimanager seien ganz gewöhnliche Mittel zum Verschieben von Dateien, daher schaffe auch diese Bedingung wenig Vertrauen.

    • Solange nicht auch ADB blockiert werde, sei die Formulierung „Sideloading blockieren“ eigentlich nicht ganz korrekt. Letztlich müsse eine Balance zwischen dem Schutz vor Malware und der Freiheit, gewünschte Apps zu installieren, gefunden werden.

    • Es wird die Erinnerung geteilt, dass man bei Geschäften mit singapurischen Kunden einmal eine Integration mit SingPass, dem nationalen digitalen Identitätssystem, liefern musste; inzwischen sei man kein Kunde mehr, aber irgendwo im Codebestand sei das wohl noch vorhanden.

    • Die Beschränkung auf eine Region könne jederzeit ausgeweitet werden, daher dürfe man sich von „nur Singapur“ nicht beruhigen lassen. Besser wäre es vielleicht, wenn Google in Richtung „gefälschter Berechtigungen“ für Apps ginge; sonst würden Kriminelle eben andere Umgehungswege finden.

  • Unter Verweis auf die in den Kommentaren populäre Aussage „Sideloading-Probleme löst man durch die Installation von GrapheneOS“ wird kritisiert, dass diese Antwort an der Lebenswirklichkeit der meisten normalen Nutzer vorbeigehe. HN-Nutzer könnten vielleicht sogar Hardware-Debugging betreiben, aber gewöhnliche Menschen könnten solche systemnahen Einstellungen nicht handhaben.

    • Es wird eine frühere Erfahrung in Linux-Foren geschildert, wo man von Antworten überrascht gewesen sei, die komplexe CLI-Nutzung als selbstverständlich betrachteten. Gerade bei Anfängern, die einfache und knappe Lösungen wollen, könne die voreingenommene Sicht von Experten die Verbreitung eher behindern.

    • Es wird diagnostiziert, dass die meisten Menschen kaum noch ein realistisches Bild davon hätten, wie „durchschnittliche“ Nutzung aussieht. In Experten-Communitys sei diese Verzerrung noch stärker, sodass Meinungen entstünden, die weit von der Realität der Mehrheit entfernt seien.

    • Die Analyse lautet, dass die meisten Menschen normalerweise gar kein Sideloading betreiben, sondern nach der einmaligen Installation einer benötigten App immer wieder dieselben Apps nutzen.

    • Es wird darauf hingewiesen, dass normale Nutzer in der Regel nicht beurteilen können, ob eine sideloaded App, die SMS- oder Bedienungshilfen-Rechte verlangt, legitim ist. Deshalb sei das Blockieren solcher Funktionen im Kern ein Schutz vor Fehlbedienung durch Durchschnittsnutzer.

    • Es wird die Sorge geäußert, dass Google durch zusätzliche DRM-Techniken und APIs künftig selbst die Installation von GrapheneOS als realistische Alternative entwerten könnte. Dann bliebe für alternative Betriebssysteme womöglich nur noch der vollständige Ausstieg aus dem Android-Ökosystem.

  • Jemand schildert, früher eher der Haltung angehangen zu haben: „Es ist mein Handy, also will ich damit machen können, was ich will“, sei aber schockiert gewesen, dass DJI bei Drohnen und Air Units Nutzer faktisch zum Sideloading zwinge. Als Grund, warum DJI die App nicht in den Play Store bringen könne, wird genannt, dass die App ihren eigenen Code verändern könne. Es wird davor gewarnt, dass bei politischen Konflikten staatlich gelenkte Malware die Kontrolle über die Drohne übernehmen könnte. Zugleich wird betont, dass Millionen Menschen die App installiert hätten, ohne das Problem richtig zu erkennen.

    • Als Lösung für dieses Problem wird nicht eine nur scheinbare Malware-Prüfung durch Google gesehen, sondern stärkere Kontrollmechanismen darüber, welche Berechtigungen und Funktionen die DJI-App tatsächlich ausüben kann. Googles Hauptmotiv sei in Wahrheit nicht Sicherheit, sondern mehr Kontrolle.

    • In diesem Zusammenhang wird argumentiert, dass echte Freiheit im Sinne von „ich will machen, was ich will“ auch für Software gelten müsse. Richard Stallmans 1988 formulierte Freiheit, den Quellcode zu erhalten und selbst ändern zu können, sei bis heute aktuell. Tatsächlich entwickle sich die Realität eher dahin, dass Software die Nutzer kontrolliert. Wenn staatliche Akteure Softwarecode beherrschen, entstünden Gefahren, die weit über eine bloße Beeinträchtigung von Verbraucherrechten hinausgingen.

    • Es wird die Analyse vertreten, dass Regierungen diese Funktion über OEMs ohnehin bereits eingebaut hätten. Ein Sideloading-Verbot helfe Hackern letztlich nur dabei, Nutzer daran zu hindern, solche eingebettete Malware zu deaktivieren.

    • Dass eine App ihren eigenen Code verändere, sei letztlich kein besonders bedeutender Punkt; mit einer eingebetteten V8-Engine lasse sich Code ohnehin beliebig verändern. Umso ironischer sei es, dass Google gegen solche Ansätze nichts unternehme.

    • Es wird Unverständnis darüber geäußert, warum der ursprüngliche Kommentar, der vor den Risiken der DJI-Drohnen-App warnte, Downvotes erhalten habe. Als Beispiel wird auf kürzlich entdeckte Kill-Switches in chinesischen Solarpanels verwiesen; daraus wird abgeleitet, dass chinesische Unternehmen mit enger Staatsnähe durchaus verdächtige Funktionen in Hardware oder Software einbauen könnten. (https://reuters.com/sustainability/climate-energy/…, https://rickscott.senate.gov/2025/6/…)

  • Zwar könne man Sideloading-Beschränkungen durch die Installation von GrapheneOS umgehen, doch verstärke Google derzeit den Trend, App-Funktionen über die Play Integrity API an Installationen aus dem Play Store zu binden. Selbst wenn man auf GrapheneOS mit gesperrtem Bootloader den Play Store verwende, blockiere Google die Nutzung hardwaregestützter Attestierungs-APIs, sodass Banking-Apps, Google Wallet und ähnliche Funktionen ausfielen. Kritisiert wird, dass Google mangelhafte Hersteller mit verspäteten Sicherheitsupdates toleriere, zugleich aber ein sicherheitsstarkes Open-Source-OS ausgrenze. Die Zusammenarbeit mit der Cyber Security Agency of Singapore wird eher als Vorwand gesehen. Zudem wird gefragt, warum dann nicht auch Apps wie Facebook oder Instagram blockiert würden. (https://localmess.github.io, https://grapheneos.social/@GrapheneOS/112878070618462132)

    • Es wird die Ansicht vertreten, dass Google bei Dritten schlechte Sicherheitspraktiken dulde und es in Wahrheit nicht um Sicherheit, sondern um Kontrolle selbst gehe.

    • Als größtes Problem von GrapheneOS wird genannt, dass es nur sehr wenige Geräte unterstützt. Benötigt werde eine Alternative, die nicht an bestimmte Hardware gebunden ist und dennoch ein gewisses Sicherheitsniveau bietet.

    • Es wird klargestellt, dass die Android-Schlüsselattestierungs-API auch auf GrapheneOS unterstützt wird und von Entwicklern integriert werden kann. (https://grapheneos.org/articles/attestation-compatibility-guide)

    • Auf die Behauptung, die Installation von GrapheneOS löse das Problem, werde bereits an anderer Stelle direkt geantwortet; dafür wird ein Referenzlink geteilt. (https://news.ycombinator.com/item?id=32496220)

  • Es wird die Sorge geäußert, dass diese Maßnahme die Community blinder und sehbehinderter Nutzer schwer treffen könnte. In Ländern, in denen Android beliebt und das iPhone teuer ist, sei der Screenreader Commentary (Jieshuo) eine bessere Alternative zu TalkBack, befinde sich aber als von einem einzelnen chinesischen Entwickler stammende App nicht im Play Store. Solche Apps benötigten sehr weitreichende Berechtigungen, um den gesamten Bildschirm zu lesen und die System-UI zu steuern. Wenn der Zugriff für sensible Apps blockiert werde, verliere der Screenreader seinen eigentlichen Zweck. Google-Mitarbeiter könnten argumentieren, die Nutzung sei laut WebAIM-Statistik gering, doch diese basiere weitgehend auf wohlhabenden englischsprachigen Stichproben und bilde das globale Nutzungsverhalten nicht ab. (https://webaim.org/projects/screenreadersurvey10/)

  • Es gibt auch die Ansicht, dass diese Designentscheidung im Gegenteil vernünftig und naheliegend sei. Zwar bleibe Malware-Installation über ADB weiterhin möglich, doch durch die höhere Hürde wirke das für Durchschnittsnutzer wie eine Geschwindigkeitsbremse. Man kenne auch keine typischen Sideloading-Apps, die dadurch ungerecht benachteiligt würden.

    • Es wird daran erinnert, dass es durchaus große alternative App-Stores gibt, etwa im Zusammenhang mit Epic v. Google, und dass Android traditionell für Offenheit und Nutzerwahl stand. Die Nutzung von ADB als Ausweg schränke die Freiheit der Nutzer womöglich stärker ein als Apples Sideloading-Modell. Wenn Apple dafür kritisiert wurde, gelte hier im Grunde ein ähnliches Problem.

  • Abschließend wird erklärt, warum das Blockieren von Apps, die Datenschutz- und Zugriffsrechte wie SMS oder Bedienungshilfen anfordern, grundsätzlich wichtig ist: Mit SMS-Berechtigungen lassen sich OTPs und andere Login-Informationen aus nahezu allen Diensten stehlen, und mit Bedienungshilfen lassen sich kritische Funktionen in Banking-Apps und anderswo fernsteuern. In Singapur sei der Handel mit Identitätsdaten so problematisch, dass Warnhinweise existierten wie: „Wenn eine unbekannte Person Ihre Telefonnummer oder andere Identitätsdaten kaufen will, drohen 5 Jahre Haft.“ Dasselbe gelte für Bankkonten und Kreditkarten. Da missbrauchte Identitätsdaten letztlich mit einer realen Person verbunden sind, führe Mitwirkung zu verschärfter Strafbarkeit.