Google detaliază propunerea de design SDK Runtime pentru Android Privacy Sandbox

Google a oferit câteva detalii despre propunerea de design SDK Runtime. SDK Runtime face parte din Android Privacy Sandbox.

Recent, am văzut atât Apple, cât și Google străduindu-se să creeze un ecosistem mai conștient de confidențialitate atunci când vine vorba de reclame. Cu Apple, a fost cu introducerea unui buton pentru a împiedica aplicațiile să vă urmărească, iar cu Google, a fost Inițiativa Android Privacy Sandbox. Deși informațiile au fost limitate în timpul anunțului, au apărut mai multe detalii despre „SDK Runtime”, care cuprinde o parte a soluției Google pentru publicitate și confidențialitate.

Android Privacy Sandbox este compus din două componente principale -- SDK Runtime și API-urile de păstrare a confidențialității -- care vor fi distribuite ca Componente de sistem modulare, pe care le puteți aminti ca Linia principală a proiectului. De atunci, Google a publicat documentație pentru dezvoltatori despre SDK Runtime și despre modul în care acesta va îmbunătăți și mai mult confidențialitatea utilizatorilor. Compania spune că SDK Runtime va permite SDK-urilor terță parte să ruleze într-un mediu de rulare dedicat în

Android 13, departe de codul unei aplicații.

În Android, fiecare aplicație rulează într-un sandbox cu propriile permisiuni și acces variabil la sistem în funcție de accesul acordat. După cum spune Google, „dacă aplicația A încearcă să facă ceva rău intenționat, cum ar fi să citească datele aplicației B sau să formeze telefonul fără permisiune, este împiedicată să facă acest lucru deoarece nu are privilegii implicite adecvate de utilizator.” SDK Runtime extinde și mai mult acel sandbox pentru a executa SDK-uri terță parte într-un mediu de rulare dedicat, departe de orice anume aplicația.

De ce există SDK Runtime

Google dorește să împiedice SDK-urile agenților de publicitate să colecteze date la care nu ar trebui să aibă acces în mod rău intenționat (sau chiar din neatenție) ca urmare a partajării sandbox-ului aplicației gazdă. Atunci când un SDK publicitar este executat în interiorul unei aplicații, are acces la tot ceea ce face aplicația și este posibil ca un dezvoltator de aplicații să nu fie complet conștient de cât de mult este accesul de fapt. Înlăturând acel cod de advertiser și executându-l în timpul său de rulare, acesta poate accesa numai datele pe care dezvoltatorul le partajează în mod explicit.

Drept urmare, Google spune că SDK Runtime oferă următoarele garanții și garanții mai puternice în ceea ce privește colectarea și partajarea datelor utilizatorilor:

  • Un mediu de execuție modificat
  • Permisiuni bine definite și drepturi de acces la date pentru SDK-uri

Prima versiune a SDK Runtime se concentrează exclusiv pe SDK-uri legate de publicitate, inclusiv SDK-uri care permit difuzarea anunțurilor, măsurarea anunțurilor, frauda reclamelor și detectarea abuzurilor.

Cum funcționează SDK Runtime

În prezent, fără timpul de execuție SDK, un proces de aplicație va apela un SDK și acel SDK se va executa în același sandbox ca și restul codului aplicației. Google dorește ca dezvoltatorii să aibă în schimb o interfață pentru un SDK care funcționează în procesul de prim-plan al unei aplicații, iar acea interfață se poate conecta și poate partaja date specifice înainte și înapoi cu SDK-ul care există utilizat.

Inainte de

După

Diagrama „înainte” (prima) arată că codul de apelare SDK, împreună cu SDK-urile care primesc apelurile de la acest cod, se află toate în procesul aplicației. Aceasta înseamnă că SDK-ul poate accesa toate datele pe care le poate accesa aplicația. Diagrama „după” (a doua) arată că, în procesul de prim-plan al aplicației, codul de apelare SDK comunică cu interfețele SDK. Aceste interfețe trec apoi granița unui proces în procesul de execuție SDK pentru a apela la SDK-urile în sine. Aceasta înseamnă că SDK-ul utilizat nu poate accesa doar orice dorește, ci poate fi furnizat doar cu informații din aplicația cu care rulează.

Noul model de distribuție de încredere pentru SDK-uri

În prezent, atunci când descărcați o aplicație cu SDK-uri terță parte, acestea sunt incluse de dezvoltator în aplicația care este încărcată și distribuită în Magazinul Google Play. În schimb, Google dorește ca atunci când instalați o aplicație pe telefonul dvs. care utilizează acele SDK-uri, acestea să fie descărcate separat din aplicația în sine. Aceasta înseamnă că dezvoltatorii SDK-uri ar putea face modificări neîntrerupte (adică, fără modificări la API-uri sau semantica lor) către SDK-urile lor și le distribuie pe dispozitive fără nicio implicare din partea aplicației dezvoltatori.

La rândul lor, modificările SDK care nu se pot întrerupe ar putea fi implementate sau anulate, fără a fi neapărat nevoie să așteptați pentru dezvoltatorii de aplicații să-și reconstruiască aplicațiile cu noile SDK-uri sau să aștepte ca utilizatorii finali să-și actualizeze aplicații. Modificările finale care modifică API-urile și semantica acestora ar trebui în continuare actualizate de către dezvoltatorii de aplicații, dar dezvoltatorii de SDK-uri ar putea obține cel mai recent non-breaking. se modifică și se remediază mai rapid și mai uniform pentru mai multe persoane simultan, fără a vă baza pe un dezvoltator de aplicații pentru a-și actualiza aplicația și pachetul în noul SDK.

Inainte de

După

Diagrama „înainte” arată exact cum sunt distribuite aplicațiile cu SDK-urile acum. Sunt ambalate într-o aplicație, iar aplicația este ceea ce este trimis în Magazinul Google Play. În diagrama „după”, dezvoltatorii SDK-urile nu și-ar mai introduce SDK-urile direct în aplicații; în schimb, dezvoltatorii SDK ar încărca un SDK și îl vor publica în Magazinul Google Play. Magazinul Google Play se va ocupa apoi de distribuirea aplicațiilor, împreună cu orice dependențe SDK, către dispozitivele utilizatorilor finali. De asemenea, Google folosește în mod intenționat expresia „magazin de aplicații” în diagramele sale, deoarece este o soluție deschisă și generală care poate funcționa în alte magazine.

Modificări ale modului în care SDK-urile și aplicațiile sunt create, rulate și distribuite

Propunerea inițială pentru SDK Runtime propune o serie de modificări în cinci domenii cheie:

  • Acces
  • Execuţie
  • Comunicatii
  • Dezvoltare
  • Distributie

Google dorește să definească următorul set de permisiuni pentru SDK Runtime:

  • INTERNET: Acces la internet pentru a putea comunica cu un serviciu web.
  • ACCESS_NETWORK_STATE: Accesați informații despre rețele.
  • Permisiuni pentru a accesa API-uri care păstrează confidențialitatea, care oferă capabilități de publicitate de bază fără a avea nevoie de acces la identificatorii între aplicații. Numele de permisiuni nu au fost finalizate, dar aceste API-uri ar fi blocate de accesul aplicației la aceste permisiuni.
  • AD_ID: Posibilitatea de a solicita ID-ul de publicitate. Acest lucru ar fi, de asemenea, blocat de accesul aplicației la această permisiune.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Capacitatea de a utiliza API-ul de referință de instalare Google Play pentru a atribui sursa instalării unei aplicații.

Compania dorește, de asemenea, să limiteze accesul pe care îl au SDK-urile la memoria unei aplicații care rulează, dar și să împiedice o aplicație să acceseze și datele proprii ale unui SDK. O aplicație nu ar putea accesa direct stocarea SDK-urilor și invers, stocarea externă nu ar putea fi deschis pentru SDK-uri și ar exista atât spațiu de stocare accesibil tuturor SDK-urilor, cât și spațiu de stocare care este privat pentru un anumit SDK.

În ceea ce privește modul în care vor rula SDK-urile, acestea vor rula cu o prioritate puțin mai mică decât aplicația în sine. Adică, este foarte probabil ca o aplicație să fie terminată la scurt timp după ce un SDK Runtime a fost terminat dacă a apărut situația că trebuie să fie închisă de către sistem. În cazul în care nu se reziliază în același timp, sau în cazul în care există un alt motiv, propunerea oferă dezvoltatorilor de aplicații metode de apel invers legate de ciclul de viață pentru ca aceștia să gestioneze această excepție și să reinițializeze SDK-ul Timp de rulare. SDK-urile de rulare nu vor putea folosi API-urile de notificări pentru a trimite notificări utilizatorilor în orice moment.

În cele din urmă, Google observă că aceasta este o propunere generală care nu este unică pentru un anumit magazin de aplicații. Deși se presupune că va fi încorporat în Magazinul Google Play, nu există niciun motiv pentru care alte magazine de aplicații nu ar putea încorpora o structură similară. Google spune că următoarele beneficii sunt clare:

  • Asigurați calitatea și consistența SDK-urilor.
  • Raționalizați publicarea pentru dezvoltatorii SDK.
  • Accelerați lansarea actualizărilor versiunilor minore SDK pentru aplicațiile instalate.

Android Privacy Sandbox pare promițător

Calendarul Google pentru lansare este că T1 din 2022 implică propunerile inițiale de proiectare și feedback și iterații de proiectare. Previzualizările dezvoltatorilor vor veni mai târziu în cursul anului, cu o versiune beta la sfârșitul anului. În cele din urmă, în 2023 vor începe testele la scară. Aceste previzualizări și beta-uri vor fi independente de cadența lansării Android 13. De asemenea, vor exista comenzi orientate către utilizator în aplicația de setări, odată lansată.

În opinia mea, Android Privacy Sandbox arata promițător, dar va trebui să așteptăm și să vedem cum îl implementează compania. Este cu totul posibil ca dezvoltatorilor să nu le placă sau că de fapt va cauza mai multe probleme decât rezolvă. Dezvoltatorii sunt încurajați să citească documentația pe care Google a postat-o ​​pentru a avea o idee mai bună asupra a ceea ce va urma în viitorul confidențialității Android.

În prezent, aceasta este o propunere și nu o perspectivă definitivă asupra a ceea ce exact se va întâmpla într-o versiune viitoare de Android, dar este probabil să ajungă destul de aproape. Vom fi cu ochii pe orice evoluție ulterioară!


Sursă: Documentația pentru dezvoltatori Android