Google geeft details over het SDK Runtime-ontwerpvoorstel voor de Android Privacy Sandbox

Onlangs hebben we gezien dat zowel Apple als Google ernaar streven een meer privacybewust ecosysteem te creëren als het om advertenties gaat. Bij Apple was dat met de introductie van een knop om te voorkomen dat apps je volgen, en bij Google was dat het geval Android Privacy Sandbox-initiatief. Hoewel informatie schaars was tijdens de aankondiging, zijn er meer details naar voren gekomen rond de "SDK Runtime", die een deel van Google's oplossing voor reclame en privacy omvat.

De Android Privacy Sandbox bestaat uit twee hoofdcomponenten – de SDK Runtime en Privacy-Preserving API’s – die zullen worden gedistribueerd als modulaire systeemcomponenten, die u zich wellicht herinnert als Project Hoofdlijn. Google heeft sindsdien ontwikkelaarsdocumentatie gepubliceerd over de SDK Runtime en hoe deze de privacy van gebruikers verder zal verbeteren. Het bedrijf zegt dat de SDK Runtime SDK's van derden in staat zal stellen om in een speciale runtime-omgeving te draaien

Androïde 13, weg van de code van een app.

In Android draait elke app in een sandbox met zijn eigen machtigingen en variërende toegang tot het systeem, afhankelijk van de verleende toegang. Zoals Google het stelt, "Als app A iets kwaadaardigs probeert te doen, zoals de gegevens van applicatie B lezen of zonder toestemming naar de telefoon bellen, wordt dit verhinderd omdat deze niet over de passende standaardgebruikersrechten." De SDK Runtime breidt die sandbox verder uit om SDK's van derden uit te voeren in een speciale runtime-omgeving, weg van een bepaalde app.

Waarom de SDK Runtime bestaat

Google wil voorkomen dat adverteerders-SDK's gegevens verzamelen waartoe het bedrijf geen kwaadwillige (of zelfs onbedoelde) toegang zou moeten hebben als gevolg van het delen van de sandbox van de host-app. Wanneer een advertentie-SDK in een app wordt uitgevoerd, heeft deze ook toegang tot alles wat de app doet, en een app-ontwikkelaar is zich mogelijk niet helemaal bewust van hoeveel toegang dat eigenlijk is. Door die adverteerderscode te verwijderen en in zijn eigen runtime uit te voeren, heeft deze alleen toegang tot de gegevens die de ontwikkelaar expliciet met hem deelt.

Als gevolg hiervan zegt Google dat de SDK Runtime de volgende sterkere waarborgen en garanties biedt rond het verzamelen en delen van gebruikersgegevens:

• Een aangepaste uitvoeringsomgeving
• Goed gedefinieerde machtigingen en gegevenstoegangsrechten voor SDK's

De eerste versie van de SDK Runtime is puur gericht op advertentiegerelateerde SDK's, waaronder SDK's die advertentieweergave, advertentiemeting, advertentiefraude en detectie van misbruik mogelijk maken.

Hoe de SDK Runtime werkt

Momenteel zal een app-proces zonder de SDK-runtime een SDK aanroepen en die SDK zal in dezelfde sandbox worden uitgevoerd als de rest van de code van de app. Google wil dat ontwikkelaars in plaats daarvan een interface hebben voor een SDK die werkt in het voorgrondproces van een app. en die interface kan vervolgens verbinding maken met en specifieke gegevens heen en weer delen met de SDK die wordt gebruikt benut.

Voor

Na

Het 'voor'-diagram (eerste) laat zien dat de SDK-aanroepcode, samen met de SDK's die de aanroepen van deze code ontvangen, zich allemaal in het proces van de app bevinden. Dit betekent dat de SDK toegang heeft tot alle gegevens die de app ook heeft. Het 'na'-diagram (tweede) laat zien dat, in het voorgrondproces van de app, de SDK-aanroepcode communiceert met SDK-interfaces. Deze interfaces overschrijden vervolgens een procesgrens naar het SDK Runtime-proces om de SDK's zelf aan te roepen. Dit betekent dat de gebruikte SDK niet zomaar toegang heeft tot wat hij wil, maar alleen kan worden voorzien van informatie uit de app waar hij naast draait.

Nieuw vertrouwd distributiemodel voor SDK's

Wanneer u momenteel een applicatie downloadt met SDK's van derden, worden deze door de ontwikkelaar opgenomen in de app die wordt geüpload en gedistribueerd in de Google Play Store. Google wil in plaats daarvan dat wanneer u een app op uw telefoon installeert die deze SDK's gebruikt, deze worden gedownload afzonderlijk vanuit de app zelf. Dat betekent dat SDK-ontwikkelaars permanente wijzigingen kunnen aanbrengen (dat wil zeggen, geen wijzigingen aan API's of hun semantiek) naar hun SDK's en distribueren deze naar apparaten zonder enige tussenkomst van de app ontwikkelaars.

Op hun beurt konden permanente SDK-wijzigingen worden geïmplementeerd of teruggedraaid, zonder noodzakelijkerwijs te hoeven wachten voor app-ontwikkelaars om hun apps opnieuw te bouwen met de nieuwe SDK's, of te wachten tot eindgebruikers hun apps updaten apps. Brekende wijzigingen die API's en hun semantiek veranderen, zouden nog steeds moeten worden bijgewerkt door app-ontwikkelaars, maar SDK-ontwikkelaars zouden hun nieuwste niet-brekende kunnen krijgen wijzigingen en oplossingen sneller en uniformer voor meer mensen tegelijk, zonder afhankelijk te zijn van een app-ontwikkelaar om hun app en pakket bij te werken in de nieuwe SDK.

Voor

Na

Het 'voor'-diagram laat precies zien hoe apps nu met SDK's worden gedistribueerd. Ze zijn verpakt in een app en de app wordt verzonden naar de Google Play Store. In het 'na'-diagram zouden SDK-ontwikkelaars hun SDK's niet langer rechtstreeks in apps plaatsen; in plaats daarvan zouden de SDK-ontwikkelaars een SDK uploaden en deze publiceren in de Google Play Store. De Google Play Store zou dan de distributie van apps, samen met eventuele SDK-afhankelijkheden, naar apparaten van eindgebruikers afhandelen. Google gebruikt ook opzettelijk de term 'app store' in zijn diagrammen, omdat het een open en algemene oplossing is die in andere winkels kan werken.

Wijzigingen in de manier waarop SDK's en apps worden gebouwd, uitgevoerd en gedistribueerd

Het oorspronkelijke voorstel voor de SDK Runtime stelt een reeks wijzigingen voor op vijf belangrijke gebieden:

• Toegang
• Executie
• Communicatie
• Ontwikkeling
• Verdeling

Google wil de volgende set machtigingen definiëren voor de SDK Runtime:

• INTERNET: Toegang tot internet om te kunnen communiceren met een webservice.
• ACCESS_NETWORK_STATE: toegang krijgen tot informatie over netwerken.
• Machtigingen voor toegang tot de privacybeschermende API's, die kernadvertentiemogelijkheden bieden zonder dat er toegang nodig is tot cross-app-ID's. De namen van de machtigingen zijn nog niet definitief, maar deze API's zouden worden geblokkeerd door de toegang van de app tot deze machtigingen.
• AD_ID: Mogelijkheid om de advertentie-ID op te vragen. Dit zou ook worden beperkt doordat de app toegang heeft tot deze toestemming.
• BIND_GET_INSTALL_REFERRER_SERVICE: Mogelijkheid om de Google Play Install Referrer-API om de bron van de installatie van een app toe te wijzen.

Het bedrijf wil ook de toegang die SDK's hebben tot het geheugen van een actieve app beperken, maar ook voorkomen dat een app toegang krijgt tot de eigen gegevens van een SDK. Een app zou geen directe toegang hebben tot de SDK-opslag, en omgekeerd zou externe opslag dat niet zijn open voor SDK's, en er zou zowel opslagruimte zijn die toegankelijk is voor alle SDK's als opslagruimte die privé is voor een bepaalde SDK.

Wat betreft de manier waarop SDK’s zullen werken, deze zullen met een iets lagere prioriteit werken dan de app zelf. Dat wil zeggen dat het zeer waarschijnlijk is dat een app wordt beëindigd kort nadat een SDK Runtime is beëindigd als de situatie zich voordoet dat deze door het systeem moet worden gesloten. Indien de overeenkomst niet tegelijkertijd wordt beëindigd, of indien er een andere reden is, wordt het voorstel biedt gerelateerde callback-methoden voor de levenscyclus aan app-ontwikkelaars, zodat zij deze uitzondering kunnen afhandelen en de SDK opnieuw kunnen initialiseren Looptijd. Runtime SDK's kunnen de API's voor meldingen op geen enkel moment gebruiken om gebruikersmeldingen te verzenden.

Tot slot merkt Google op dat dit een algemeen voorstel is dat niet uniek is voor een bepaalde app store. Hoewel het vermoedelijk in de Google Play Store zal worden ingebouwd, is er geen reden waarom andere app-winkels niet een vergelijkbare structuur zouden kunnen integreren. Google zegt dat de volgende voordelen duidelijk zijn:

• Zorg voor de kwaliteit en consistentie van SDK's.
• Stroomlijn publicatie voor SDK-ontwikkelaars.
• Versnel de uitrol van secundaire versie-updates van de SDK voor geïnstalleerde apps.

De Android Privacy Sandbox ziet er veelbelovend uit

De tijdlijn van Google voor release is dat het eerste kwartaal van 2022 de eerste ontwerpvoorstellen, ontwerpfeedback en iteraties omvat. Previews voor ontwikkelaars komen later dit jaar, met een bèta aan het eind van het jaar. Ten slotte zal in 2023 het testen op schaal beginnen. Deze previews en bèta's zijn onafhankelijk van de releasefrequentie van Android 13. Er zullen ook gebruikersgerichte bedieningselementen zijn in de instellingen-app, zodra deze is uitgerold.

Naar mijn mening de Android Privacy Sandbox ziet er uit veelbelovend, maar we zullen moeten afwachten hoe het bedrijf het implementeert. Het is heel goed mogelijk dat ontwikkelaars het niet leuk zullen vinden, of dat het feitelijk meer problemen zal veroorzaken dan het oplost. Ontwikkelaars worden aangemoedigd om de documentatie te lezen die Google heeft gepost om een ​​beter idee te krijgen van wat er gaat komen in de toekomst van Android-privacy.

Dit is momenteel een voorstel en geen definitieve visie op wat precies zal gebeuren in een toekomstige Android-versie, maar het is waarschijnlijk dat het redelijk dichtbij zal komen. Wij houden eventuele verdere ontwikkelingen in de gaten!

---

Bron: Documentatie voor Android-ontwikkelaars