Google detailliert SDK Runtime-Designvorschlag für die Android Privacy Sandbox

In letzter Zeit haben wir gesehen, dass sowohl Apple als auch Google bestrebt sind, ein datenschutzbewussteres Ökosystem in Bezug auf Werbung zu schaffen. Bei Apple war es mit der Einführung einer Schaltfläche, die verhindert, dass Apps Sie verfolgen, und bei Google war es so Android Privacy Sandbox-Initiative. Während es bei der Ankündigung nur wenige Informationen gab, sind weitere Details zum „SDK Runtime“ aufgetaucht, das einen Teil von Googles Lösung für Werbung und Datenschutz umfasst.

Die Android Privacy Sandbox besteht aus zwei Hauptkomponenten – der SDK-Laufzeit- und der Privacy-Preserving-API – die als modulare Systemkomponenten verteilt werden, an die Sie sich vielleicht erinnern Projekt Mainline. Google hat seitdem eine Entwicklerdokumentation rund um die SDK Runtime veröffentlicht und erklärt, wie diese die Privatsphäre der Nutzer weiter verbessern wird. Das Unternehmen gibt an, dass die SDK Runtime die Ausführung von SDKs von Drittanbietern in einer dedizierten Laufzeitumgebung ermöglichen wird

Android 13, weg vom Code einer App.

In Android läuft jede App in einer Sandbox mit eigenen Berechtigungen und unterschiedlichem Zugriff auf das System, je nachdem, welcher Zugriff gewährt wird. Wie Google es ausdrückt, „Wenn App A versucht, etwas Bösartiges zu tun, z. B. die Daten von Anwendung B zu lesen oder das Telefon ohne Erlaubnis anzurufen, wird sie daran gehindert, weil sie nicht über die Erlaubnis verfügt.“ entsprechende Standardbenutzerrechte.“ Die SDK Runtime erweitert diese Sandbox weiter, um SDKs von Drittanbietern in einer dedizierten Laufzeitumgebung auszuführen, getrennt von einem bestimmten App.

Warum die SDK Runtime existiert

Google möchte verhindern, dass die SDKs von Werbetreibenden durch die gemeinsame Nutzung der Sandbox der Host-App Daten sammeln, auf die das Unternehmen in böswilliger Absicht (oder sogar unbeabsichtigt) keinen Zugriff haben sollte. Wenn ein Werbe-SDK innerhalb einer App ausgeführt wird, hat es auch Zugriff auf alles, was die App tut, und ein App-Entwickler ist sich möglicherweise nicht vollständig darüber im Klaren, wie viel Zugriff das tatsächlich ist. Indem dieser Werbetreibendencode entfernt und in seiner eigenen Laufzeit ausgeführt wird, kann er nur auf die Daten zugreifen, die der Entwickler explizit mit ihm teilt.

Daher gibt Google an, dass die SDK Runtime die folgenden stärkeren Schutzmaßnahmen und Garantien für die Erfassung und Weitergabe von Benutzerdaten bietet:

• Eine modifizierte Ausführungsumgebung
• Klar definierte Berechtigungen und Datenzugriffsrechte für SDKs

Die erste Version der SDK Runtime konzentriert sich ausschließlich auf werbebezogene SDKs, einschließlich SDKs, die die Anzeigenbereitstellung, Anzeigenmessung, Anzeigenbetrug und Missbrauchserkennung ermöglichen.

So funktioniert die SDK-Laufzeit

Ohne die SDK-Laufzeit ruft ein App-Prozess derzeit ein SDK auf und dieses SDK wird in derselben Sandbox wie der restliche App-Code ausgeführt. Google möchte, dass Entwickler stattdessen eine Schnittstelle für ein SDK haben, das im Vordergrundprozess einer App funktioniert. und diese Schnittstelle kann sich dann mit dem vorhandenen SDK verbinden und bestimmte Daten hin und her teilen verwendet.

Vor

Nach

Das „Vorher“-Diagramm (zuerst) zeigt, dass sich der SDK-aufrufende Code zusammen mit den SDKs, die die Aufrufe von diesem Code empfangen, alle im Prozess der App befinden. Das bedeutet, dass das SDK auf alle Daten zugreifen kann, auf die auch die App zugreifen kann. Das „Nachher“-Diagramm (zweite) zeigt, dass im Vordergrundprozess der App der SDK-Aufrufcode mit SDK-Schnittstellen kommuniziert. Diese Schnittstellen überschreiten dann eine Prozessgrenze in den SDK-Laufzeitprozess, um die SDKs selbst aufzurufen. Das bedeutet, dass das verwendete SDK nicht einfach auf alles zugreifen kann, was es will, sondern nur mit Informationen von der App versorgt werden kann, die es parallel ausführt.

Neues vertrauenswürdiges Verteilungsmodell für SDKs

Wenn Sie derzeit eine Anwendung mit SDKs von Drittanbietern herunterladen, werden diese vom Entwickler in die App eingebunden, die im Google Play Store hochgeladen und vertrieben wird. Stattdessen möchte Google, dass bei der Installation einer App auf Ihrem Telefon, die diese SDKs verwendet, diese heruntergeladen werden separat aus der App selbst. Das bedeutet, dass SDK-Entwickler nicht-unterbrechende Änderungen vornehmen könnten (d. h. keine Änderungen an APIs oder (deren Semantik) in ihre SDKs übertragen und ohne Beteiligung der App an Geräte verteilen Entwickler.

Im Gegenzug könnten nicht unterbrechende SDK-Änderungen bereitgestellt oder rückgängig gemacht werden, ohne dass unbedingt gewartet werden muss für App-Entwickler, die ihre Apps mit den neuen SDKs neu erstellen müssen, oder darauf warten, dass Endbenutzer ihre Apps aktualisieren Apps. Breaking Changes, die APIs und ihre Semantik ändern, müssten weiterhin von App-Entwicklern aktualisiert werden, aber SDK-Entwickler könnten ihre neuesten Non-Breaking-Änderungen erhalten Änderungen und Korrekturen werden schneller und einheitlicher an mehrere Personen gleichzeitig weitergegeben, ohne dass ein App-Entwickler seine App und sein Paket auf das Neue aktualisieren muss SDK.

Vor

Nach

Das „Vorher“-Diagramm zeigt genau, wie Apps jetzt mit SDKs verteilt werden. Sie werden in eine App gepackt und die App wird an den Google Play Store übermittelt. Im „Nachher“-Diagramm würden SDK-Entwickler ihre SDKs nicht mehr direkt in Apps integrieren; Stattdessen würden die SDK-Entwickler ein SDK hochladen und im Google Play Store veröffentlichen. Der Google Play Store würde dann die Verteilung der Apps zusammen mit etwaigen SDK-Abhängigkeiten an Endbenutzergeräte übernehmen. Google verwendet in seinen Diagrammen auch bewusst den Begriff „App Store“, da es sich um eine offene und allgemeine Lösung handelt, die auch in anderen Stores funktionieren kann.

Änderungen an der Art und Weise, wie SDKs und Apps erstellt, ausgeführt und verteilt werden

Der ursprüngliche Vorschlag für die SDK Runtime sieht eine Reihe von Änderungen in fünf Schlüsselbereichen vor:

• Zugang
• Ausführung
• Kommunikation
• Entwicklung
• Verteilung

Google möchte den folgenden Satz von Berechtigungen für die SDK-Laufzeit definieren:

• INTERNET: Zugriff auf das Internet, um mit einem Webdienst kommunizieren zu können.
• ACCESS_NETWORK_STATE: Zugriff auf Informationen über Netzwerke.
• Berechtigungen für den Zugriff auf Datenschutz-erhaltende APIs, die zentrale Werbefunktionen bereitstellen, ohne dass Zugriff auf App-übergreifende Kennungen erforderlich ist. Die Berechtigungsnamen stehen noch nicht fest, aber diese APIs würden durch den Zugriff der App auf diese Berechtigungen eingeschränkt.
• AD_ID: Möglichkeit, die Werbe-ID anzufordern. Dies würde auch durch den Zugriff der App auf diese Berechtigung eingeschränkt.
• BIND_GET_INSTALL_REFERRER_SERVICE: Fähigkeit, das zu verwenden Google Play Install Referrer API um die Quelle der Installation einer App zuzuordnen.

Das Unternehmen möchte außerdem den Zugriff von SDKs auf den Speicher einer laufenden App einschränken, aber auch verhindern, dass eine App auch auf die eigenen Daten eines SDKs zugreift. Eine App wäre nicht in der Lage, direkt auf den Speicher ihres SDKs zuzugreifen, und umgekehrt wäre dies auf den externen Speicher nicht möglich offen für SDKs, und es gäbe sowohl Speicher, auf den alle SDKs zugreifen können, als auch Speicher, der für ein bestimmtes Unternehmen privat ist SDK.

Was die Ausführung von SDKs betrifft, so werden diese mit einer etwas niedrigeren Priorität ausgeführt als die App selbst. Das heißt, es ist sehr wahrscheinlich, dass eine App kurz nach der Beendigung einer SDK-Laufzeit beendet wird, wenn die Situation eintritt, dass sie vom System geschlossen werden muss. Für den Fall, dass er nicht gleichzeitig gekündigt wird oder ein anderer Grund vorliegt, gilt der Antrag bietet App-Entwicklern entsprechende Lifecycle-Callback-Methoden, damit diese diese Ausnahme behandeln und das SDK neu initialisieren können Laufzeit. Laufzeit-SDKs können die Benachrichtigungs-APIs zu keinem Zeitpunkt zum Senden von Benutzerbenachrichtigungen verwenden.

Abschließend weist Google darauf hin, dass es sich hierbei um einen allgemeinen Vorschlag handelt, der nicht nur für einen bestimmten App Store gilt. Obwohl es vermutlich in den Google Play Store integriert wird, gibt es keinen Grund, warum andere App Stores nicht eine ähnliche Struktur integrieren könnten. Laut Google liegen folgende Vorteile klar auf der Hand:

• Stellen Sie die Qualität und Konsistenz der SDKs sicher.
• Optimieren Sie die Veröffentlichung für SDK-Entwickler.
• Beschleunigen Sie die Einführung von SDK-Nebenversionsaktualisierungen für installierte Apps.

Die Android Privacy Sandbox sieht vielversprechend aus

Googles Zeitplan für die Veröffentlichung sieht vor, dass das erste Quartal 2022 die ersten Designvorschläge sowie Design-Feedback und -Iterationen umfasst. Entwicklervorschauen werden später im Jahr verfügbar sein, mit einer Beta am Ende des Jahres. Im Jahr 2023 wird schließlich mit groß angelegten Tests begonnen. Diese Vorschauen und Betas werden unabhängig vom Veröffentlichungsrhythmus von Android 13 sein. Nach der Einführung wird es in der Einstellungs-App auch benutzerorientierte Steuerelemente geben.

Meiner Meinung nach die Android Privacy Sandbox sieht aus vielversprechend, aber wir müssen abwarten, wie das Unternehmen es umsetzt. Es ist durchaus möglich, dass es den Entwicklern nicht gefällt oder dass es tatsächlich mehr Probleme verursacht als es löst. Entwicklern wird empfohlen, die von Google veröffentlichte Dokumentation zu lesen, um ein besseres Gefühl für die Zukunft des Android-Datenschutzes zu bekommen.

Dies ist derzeit ein Vorschlag und kein endgültiger Ausblick darauf genau wird in einer zukünftigen Android-Version passieren, aber es ist wahrscheinlich, dass es am Ende ziemlich nah dran sein wird. Wir werden die weiteren Entwicklungen im Auge behalten!

---

Quelle: Dokumentation für Android-Entwickler