Google har givet nogle detaljer om SDK Runtime-designforslaget. SDK Runtime udgør en del af Android Privacy Sandbox.
For nylig har vi set både Apple og Google stræbe efter at skabe et mere privatlivsbevidst økosystem, når det kommer til annoncer. Med Apple var det med introduktionen af en knap til at forhindre apps i at spore dig, og med Google har det været Android Privacy Sandbox-initiativ. Mens information var sparsom under meddelelsen, er der dukket flere detaljer op omkring "SDK Runtime", der omfatter en del af Googles løsning til annoncering og privatliv.
Android Privacy Sandbox består af to hovedkomponenter - SDK Runtime og Privacy-Preserving API'er - som vil blive distribueret som modulære systemkomponenter, som du måske husker som Projekt Hovedlinje. Google har siden udgivet udviklerdokumentation omkring SDK Runtime, og hvordan det yderligere vil forbedre brugernes privatliv. Virksomheden siger, at SDK Runtime vil tillade tredjeparts SDK'er at køre i et dedikeret runtime miljø i Android 13, væk fra en apps kode.
I Android kører hver app i en sandkasse med sine egne tilladelser og varierende adgang til systemet afhængigt af den adgang, der er givet. Som Google udtrykker det, "hvis app A forsøger at gøre noget ondsindet, såsom at læse applikation B's data eller ringe til telefonen uden tilladelse, er den forhindret i at gøre det, fordi den ikke har passende standardbrugerrettigheder." SDK Runtime udvider denne sandkasse yderligere til at udføre tredjeparts-SDK'er i et dedikeret runtime-miljø, væk fra et bestemt app.
Hvorfor SDK Runtime eksisterer
Google ønsker at forhindre annoncør-SDK'er i at indsamle data, som det ikke burde have adgang til ondsindet (eller endda utilsigtet) som følge af deling af værtsappens sandkasse. Når en annonce-SDK køres inde i en app, har den adgang til alt, hvad appen også gør, og en app-udvikler er muligvis ikke helt klar over, hvor meget adgang det faktisk er. Ved at fjerne denne annoncørkode og udføre den i sin egen runtime, kan den kun få adgang til de data, som udvikleren eksplicit deler med den.
Som et resultat siger Google, at SDK Runtime giver følgende stærkere sikkerhedsforanstaltninger og garantier omkring indsamling og deling af brugerdata:
- Et modificeret eksekveringsmiljø
- Veldefinerede tilladelser og dataadgangsrettigheder for SDK'er
Den første version af SDK Runtime er udelukkende fokuseret på annonceringsrelaterede SDK'er, herunder SDK'er, der muliggør annoncevisning, annoncemåling, annoncesvindel og registrering af misbrug.
Sådan fungerer SDK Runtime
I øjeblikket, uden SDK-runtime, vil en app-proces kalde et SDK, og det SDK vil køre inde i den samme sandbox som resten af appens kode. Google ønsker, at udviklere i stedet skal have en grænseflade til et SDK, der fungerer i en apps forgrundsproces, og den grænseflade kan derefter oprette forbindelse til og dele specifikke data frem og tilbage med det SDK, der er udnyttet.
Før
Efter
"Før"-diagrammet (først) viser, at SDK-kaldekoden sammen med de SDK'er, der modtager opkaldene fra denne kode, alle findes i appens proces. Det betyder, at SDK'et kan få adgang til alle de data, som appen kan. "Efter"-diagrammet (andet) viser, at i appens forgrundsproces kommunikerer SDK-kaldekoden med SDK-grænseflader. Disse grænseflader krydser derefter en procesgrænse ind i SDK Runtime-processen for at kalde ind i selve SDK'erne. Det betyder, at det SDK, der bruges, ikke bare kan få adgang til, hvad det vil, det kan kun forsynes med information fra den app, det kører sammen med.
Ny pålidelig distributionsmodel for SDK'er
I øjeblikket, når du downloader en applikation med tredjeparts-SDK'er, inkluderes disse af udvikleren i den app, der er uploadet og distribueret i Google Play Butik. Google ønsker i stedet, at det skal være sådan, at når du installerer en app på din telefon, der bruger disse SDK'er, downloades de separat fra selve appen. Det betyder, at SDK-udviklere kan foretage ubrudte ændringer (det vil sige ingen ændringer til API'er eller deres semantik) til deres SDK'er og distribuere dem til enheder uden involvering fra app udviklere.
Til gengæld kan ubrudte SDK-ændringer implementeres eller rulles tilbage uden nødvendigvis at skulle vente for appudviklere til at genopbygge deres apps med de nye SDK'er eller vente på, at slutbrugere opdaterer deres apps. Brydende ændringer, der ændrer API'er og deres semantik, skulle stadig opdateres af app-udviklere, men SDK-udviklere kunne få deres seneste ubrudte ændringer og retter hurtigere og mere ensartet til flere mennesker på én gang uden at være afhængig af, at en app-udvikler opdaterer deres app og pakke i det nye SDK.
Før
Efter
"Før"-diagrammet viser præcis, hvordan apps distribueres med SDK'er nu. De er pakket ind i en app, og appen er det, der sendes til Google Play Butik. I "efter"-diagrammet ville SDK-udviklere ikke længere sætte deres SDK'er direkte ind i apps; i stedet ville SDK-udviklerne uploade et SDK og udgive det til Google Play Butik. Google Play Butik vil derefter håndtere distributionen af apps, sammen med eventuelle SDK-afhængigheder, til slutbrugerenheder. Google bruger også med vilje udtrykket "app store" i sine diagrammer, da det er en åben og generel løsning, der kan fungere på tværs af andre butikker.
Ændringer i, hvordan SDK'er og apps bygges, køres og distribueres
Det oprindelige forslag til SDK Runtime foreslår en række ændringer på tværs af fem nøgleområder:
- Adgang
- Udførelse
- Kommunikation
- Udvikling
- Fordeling
Google ønsker at definere følgende sæt tilladelser for SDK Runtime:
-
INTERNET: Adgang til internettet for at kunne kommunikere med en webtjeneste. -
ACCESS_NETWORK_STATE: Få adgang til oplysninger om netværk. - Tilladelser til at få adgang til privatlivsbevarende API'er, som giver kerneannonceringsmuligheder uden behov for adgang til cross-app identifikatorer. Tilladelsesnavnene er ikke færdiggjort, men disse API'er vil blive lukket af appens adgang til disse tilladelser.
-
AD_ID: Mulighed for at anmode om reklame-id. Dette ville også være lukket af appens adgang til denne tilladelse. -
BIND_GET_INSTALL_REFERRER_SERVICE: Evne til at bruge Google Play Install Referrer API at tilskrive kilden til en apps installation.
Virksomheden ønsker også at begrænse den adgang, SDK'er har til hukommelsen på en kørende app, men også at forhindre en app i at få adgang til en SDK's egne data. En app ville ikke være i stand til at få direkte adgang til sin SDK-lagerplads, og omvendt ville ekstern lagring ikke være det åben for SDK'er, og der ville være både lager tilgængeligt for alle SDK'er og lager, der er privat for en given SDK.
Med hensyn til hvordan SDK'er vil køre, vil de køre med en lidt lavere prioritet end selve appen. Det vil sige, at det er meget sandsynligt, at en app ville blive afsluttet kort efter en SDK Runtime blev afsluttet, hvis den situation opstod, at den skulle lukkes af systemet. I tilfælde af at det ikke opsiges samtidig, eller hvis der er en anden årsag, vil forslaget tilbyder relaterede livscyklus-tilbagekaldsmetoder til app-udviklere, så de kan håndtere denne undtagelse og geninitialisere SDK'et Runtime. Runtime SDK'er vil ikke kunne bruge notifikations-API'erne til at sende brugermeddelelser på noget tidspunkt.
Endelig bemærker Google, at dette er et generelt forslag, der ikke er unikt for nogen bestemt app-butik. Selvom det formentlig vil blive indbygget i Google Play Butik, er der ingen grund til, at andre app-butikker ikke kunne inkorporere en lignende struktur. Google siger, at følgende fordele er klare:
- Sikre kvaliteten og konsistensen af SDK'er.
- Strømline udgivelse for SDK-udviklere.
- Fremskynd udrulningen af SDK-mindre versionsopdateringer til installerede apps.
Android Privacy Sandbox ser lovende ud
Googles tidslinje for udgivelse er, at 1. kvartal af 2022 involverer de indledende designforslag og designfeedback og gentagelser. Forhåndsvisninger af udviklere kommer senere på året, med en betaversion i slutningen af året. Endelig vil skalerede tests begynde i 2023. Disse forhåndsvisninger og betaversioner vil være uafhængige af Android 13-udgivelseskadencen. Der vil også være brugervendte kontroller i indstillingsappen, når den er rullet ud.
Efter min mening, Android Privacy Sandbox udseende lovende, men vi må vente og se, hvordan virksomheden implementerer det. Det er fuldt ud muligt, at udviklere ikke vil kunne lide det, eller at det faktisk vil forårsage flere problemer, end det løser. Udviklere opfordres til at læse den dokumentation, som Google har udgivet, for at få en bedre fornemmelse af, hvad der kommer i fremtiden for Androids privatliv.
Dette er i øjeblikket et forslag og ikke et endeligt syn på hvad Nemlig vil ske i en fremtidig Android-version, men det er sandsynligt, at det ender ret tæt på. Vi holder øje med den videre udvikling!
Kilde: Android-udviklerdokumentation