A Google részletesen ismerteti az SDK Runtime tervezési javaslatát az Android Privacy Sandboxhoz

A Google közölt néhány részletet az SDK Runtime tervezési javaslatával kapcsolatban. Az SDK Runtime az Android Privacy Sandbox részét képezi.

A közelmúltban azt láttuk, hogy az Apple és a Google is törekszik a magánélet-tudatosabb ökoszisztéma létrehozására, amikor a hirdetésekről van szó. Az Apple esetében ez egy gomb bevezetésével történt, amely megakadályozza, hogy az alkalmazások nyomon kövessék Önt, a Google esetében pedig Android Privacy Sandbox kezdeményezés. Noha a bejelentés során kevés információ állt rendelkezésre, több részlet is napvilágot látott az "SDK Runtime" körül, amely a Google hirdetési és adatvédelmi megoldásának egy részét foglalja magában.

Az Android Privacy Sandbox két fő összetevőből áll – az SDK Runtime-ból és a Privacy-Preserving API-kból –, amelyek moduláris rendszerkomponensekként lesznek terjesztve, amelyekre úgy emlékezhet. Projekt fővonal. A Google azóta közzétette az SDK Runtime-ot övező fejlesztői dokumentációt, és azt, hogy az hogyan erősíti tovább a felhasználók adatvédelmét. A vállalat azt állítja, hogy az SDK Runtime lehetővé teszi a harmadik fél SDK-inak dedikált futtatókörnyezetben való futtatását

Android 13, távol egy alkalmazás kódjától.

Androidon minden alkalmazás egy homokozóban fut, saját engedélyekkel és a rendszerhez való hozzáféréstől függően, a megadott hozzáféréstől függően. Ahogy a Google mondja, "ha az A alkalmazás valami rosszindulatú tevékenységet próbál végrehajtani, például beolvassa a B alkalmazás adatait, vagy engedély nélkül tárcsázza a telefont, a rendszer megakadályozza, hogy ezt tegye, mert nem rendelkezik a megfelelő alapértelmezett felhasználói jogosultságokkal." Az SDK Runtime tovább bővíti ezt a sandboxot, hogy harmadik féltől származó SDK-kat fusson egy dedikált futási környezetben, minden konkréttól távol. kb.

Miért létezik az SDK Runtime?

A Google meg akarja akadályozni, hogy a hirdetői SDK-k olyan adatokat gyűjtsenek, amelyekhez nem szabadna rosszindulatúan (vagy akár véletlenül) hozzáférnie a gazdagép alkalmazás homokozójának megosztása következtében. Ha egy hirdetési SDK-t egy alkalmazáson belül hajtanak végre, akkor mindenhez hozzáfér, amit az alkalmazás is, és előfordulhat, hogy az alkalmazásfejlesztők nincsenek teljesen tisztában azzal, hogy ez valójában mekkora hozzáférést jelent. Ha eltávolítja a hirdetői kódot, és a saját futási idejében végrehajtja, akkor csak azokhoz az adatokhoz férhet hozzá, amelyeket a fejlesztő kifejezetten megosztott vele.

Ennek eredményeként a Google azt állítja, hogy az SDK Runtime a következő erősebb biztosítékokat és garanciákat nyújtja a felhasználói adatok gyűjtése és megosztása kapcsán:

  • Módosított végrehajtási környezet
  • Jól definiált engedélyek és adathozzáférési jogok az SDK-khoz

Az SDK Runtime első verziója kizárólag a hirdetésekkel kapcsolatos SDK-kra összpontosít, beleértve a hirdetésmegjelenítést, a hirdetések mérését, a hirdetésekkel való csalást és a visszaélések észlelését lehetővé tevő SDK-kat.

Hogyan működik az SDK Runtime

Jelenleg az SDK futtatókörnyezete nélkül az alkalmazásfolyamatok SDK-t hívnak, és az SDK ugyanabban a sandboxban fut le, mint az alkalmazás többi kódja. A Google azt akarja, hogy a fejlesztők ehelyett rendelkezzenek egy olyan felülettel az SDK számára, amely az alkalmazás előtérben működő folyamatában működik, és ez az interfész ezután csatlakozhat az aktuális SDK-hoz, és oda-vissza megoszthat bizonyos adatokat hasznosított.

Előtt

Után

Az „előtte” diagram (első) azt mutatja, hogy az SDK-hívó kód, valamint az ebből a kódból érkező hívásokat fogadó SDK-k mind az alkalmazás folyamatában vannak. Ez azt jelenti, hogy az SDK hozzáférhet az összes adathoz, amelyet az alkalmazás tud. Az „utána” diagram (második) azt mutatja, hogy az alkalmazás előtérbeli folyamatában az SDK-hívó kód kommunikál az SDK-felületekkel. Ezek az interfészek ezután átlépnek egy folyamathatáron az SDK futásidejű folyamatába, hogy magukba az SDK-kba hívják be. Ez azt jelenti, hogy a használt SDK nem csak ahhoz férhet hozzá, amit csak akar, hanem csak az általa futtatott alkalmazásból származó információkkal látja el.

Új megbízható terjesztési modell SDK-khoz

Jelenleg, amikor letölt egy alkalmazást harmadik féltől származó SDK-kkal, ezeket a fejlesztő belefoglalja a Google Play Áruházba feltöltött és terjesztett alkalmazásba. A Google ehelyett azt akarja, hogy amikor olyan alkalmazást telepít a telefonjára, amely ezeket az SDK-kat használja, akkor azok letöltődnek. külön magából az alkalmazásból. Ez azt jelenti, hogy az SDK fejlesztői törésmentes változtatásokat hajthatnak végre (azaz nem módosíthatják az API-kat vagy szemantikája) az SDK-kba, és az alkalmazás közreműködése nélkül terjesztheti azokat eszközökre fejlesztők.

A törésmentes SDK-módosítások pedig üzembe helyezhetők vagy visszaállíthatók anélkül, hogy feltétlenül várni kellene az alkalmazásfejlesztőknek, hogy újjáépítsék alkalmazásaikat az új SDK-kkal, vagy várják, hogy a végfelhasználók frissítsék alkalmazásokat. Az API-kat és azok szemantikáját módosító törést okozó módosításokat az alkalmazásfejlesztőknek továbbra is frissíteniük kell, de az SDK-fejlesztők megkaphatják a legújabb, nem törésmentes verziójukat. gyorsabban és egységesebben módosítja és javítja ki egyszerre több ember számára, anélkül, hogy egy alkalmazásfejlesztőre kellene támaszkodnia, hogy frissítse az alkalmazást és a csomagot az új verzióban. SDK.

Előtt

Után

Az „előtte” diagram pontosan megmutatja, hogyan jelennek meg az alkalmazások az SDK-kkal. Egy alkalmazásba vannak csomagolva, és ez az alkalmazás a Google Play Áruházban. Az „utána” diagramon az SDK-fejlesztők többé nem helyezik el SDK-jaikat közvetlenül az alkalmazásokba; ehelyett az SDK fejlesztői feltöltenek egy SDK-t, és közzéteszik a Google Play Áruházban. Ezután a Google Play Áruház kezeli az alkalmazások végfelhasználói eszközökre való terjesztését, valamint az SDK-függőségeket. A Google szintén szándékosan használja az "app store" kifejezést diagramjaiban, mivel ez egy nyílt és általános megoldás, amely más üzletekben is működhet.

Változások az SDK-k és alkalmazások felépítésében, futtatásában és terjesztésében

Az SDK Runtime kezdeti javaslata egy sor változtatást javasol öt kulcsfontosságú területen:

  • Hozzáférés
  • Végrehajtás
  • Kommunikáció
  • Fejlesztés
  • terjesztés

A Google a következő engedélykészletet szeretné meghatározni az SDK Runtime számára:

  • INTERNET: Hozzáférés az internethez a webszolgáltatással való kommunikációhoz.
  • ACCESS_NETWORK_STATE: Hálózati információk elérése.
  • Hozzáférési engedélyek a adatvédelmi API-k, amelyek alapvető hirdetési lehetőségeket biztosítanak anélkül, hogy hozzáférésre lenne szükségük az alkalmazások közötti azonosítókhoz. Az engedélyek nevei még nincsenek véglegesítve, de ezeket az API-kat az alkalmazásnak ezekhez az engedélyekhez való hozzáférése korlátozza.
  • AD_ID: Lehetőség a hirdetési azonosító kérésére. Ezt az alkalmazásnak az engedélyhez való hozzáférése is korlátozza.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Képes használni a Google Play Install Referrer API az alkalmazás telepítésének forrásának hozzárendeléséhez.

A vállalat emellett korlátozni kívánja az SDK-k hozzáférését egy futó alkalmazás memóriájához, de azt is, hogy egy alkalmazás ne férhessen hozzá az SDK saját adataihoz. Egy alkalmazás nem tudna közvetlenül hozzáférni az SDK-tárhelyéhez, és fordítva, a külső tárhely nem nyitott az SDK-k számára, és az összes SDK számára elérhető tárhely és egy adott tárhely privát tárhelye is lenne SDK.

Ami az SDK-k futását illeti, valamivel alacsonyabb prioritással fognak futni, mint maga az alkalmazás. Ez azt jelenti, hogy nagyon valószínű, hogy egy alkalmazás röviddel az SDK Runtime leállítása után leáll, ha olyan helyzet állna elő, hogy a rendszernek be kell zárnia. Abban az esetben, ha nem szűnik meg egyidejűleg, vagy ha más oka van, az ajánlat kapcsolódó életciklus-visszahívási módszereket kínál az alkalmazásfejlesztőknek, hogy kezeljék ezt a kivételt és újrainicializálják az SDK-t Futásidő. A futásidejű SDK-k nem fogják tudni használni az értesítési API-kat felhasználói értesítések küldésére bármikor.

Végül a Google megjegyzi, hogy ez egy általános javaslat, amely nem egyedi egyetlen alkalmazásboltban sem. Noha feltehetően beépül a Google Play Áruházba, nincs ok arra, hogy más alkalmazásboltok ne építhetnének be hasonló szerkezetet. A Google szerint a következő előnyök egyértelműek:

  • Biztosítsa az SDK-k minőségét és konzisztenciáját.
  • Egyszerűsített kiadvány SDK-fejlesztők számára.
  • Gyorsítsa fel az SDK kisebb verzióinak frissítéseit a telepített alkalmazásokban.

Az Android Privacy Sandbox ígéretesnek tűnik

A Google kiadásának ütemezése szerint 2022 első negyedéve tartalmazza a kezdeti tervezési javaslatokat, valamint a tervezési visszajelzéseket és az iterációkat. A fejlesztői előzetesek az év későbbi részében, bétaverzióval pedig az év végén jelennek meg. Végül 2023-ban megkezdődik a méretezett tesztelés. Ezek az előnézetek és béták függetlenek lesznek az Android 13 kiadási ütemétől. A bevezetést követően a beállítások alkalmazásban is lesznek felhasználói vezérlők.

Véleményem szerint az Android Privacy Sandbox úgy néz ki ígéretes, de várnunk kell, és meglátjuk, hogyan valósítja meg a cég. Teljesen lehetséges, hogy a fejlesztőknek nem fog tetszeni, vagy valójában több problémát okoz, mint amennyit megold. A fejlesztőket arra biztatjuk, hogy olvassák el a Google által közzétett dokumentációt, hogy jobban átérezhessék, mi várható az Android adatvédelmi jövőjében.

Ez jelenleg egy javaslat, és nem egy végleges kilátás, hogy mit pontosan egy jövőbeli Android-verzióban fog megtörténni, de valószínű, hogy a végén elég közel lesz. Figyelni fogjuk a további fejleményeket!


Forrás: Android fejlesztői dokumentáció