Google podał kilka szczegółów na temat propozycji projektu SDK Runtime. SDK Runtime stanowi część piaskownicy prywatności systemu Android.
Ostatnio zaobserwowaliśmy, że zarówno Apple, jak i Google starają się stworzyć ekosystem bardziej dbający o prywatność, jeśli chodzi o reklamy. W przypadku Apple było to wprowadzenie przycisku uniemożliwiającego aplikacjom śledzenie Ciebie, a w przypadku Google było to możliwe Inicjatywa Android Privacy Sandbox. Chociaż w momencie ogłoszenia nie było zbyt wielu informacji, pojawiło się więcej szczegółów na temat „SDK Runtime”, który obejmuje część rozwiązania Google dotyczącego reklamy i prywatności.
Android Privacy Sandbox składa się z dwóch głównych komponentów — środowiska wykonawczego SDK i interfejsów API chroniących prywatność — które będą dystrybuowane jako modułowe komponenty systemu, które możesz zapamiętać jako Główna linia projektu. Od tego czasu firma Google opublikowała dokumentację dla programistów dotyczącą środowiska wykonawczego SDK i sposobu, w jaki jeszcze bardziej zwiększy to prywatność użytkowników. Firma twierdzi, że SDK Runtime umożliwi uruchamianie zestawów SDK innych firm w dedykowanym środowisku wykonawczym
Androida 13, z dala od kodu aplikacji.W systemie Android każda aplikacja działa w piaskownicy z własnymi uprawnieniami i różnym dostępem do systemu w zależności od przyznanego dostępu. Jak to określa Google, „jeśli aplikacja A spróbuje zrobić coś złośliwego, na przykład odczytać dane aplikacji B lub wybrać numer telefonu bez pozwolenia, nie będzie mogła tego zrobić, ponieważ nie ma odpowiednich uprawnień odpowiednie domyślne uprawnienia użytkownika.” SDK Runtime dodatkowo rozszerza tę piaskownicę, aby uruchamiać zestawy SDK innych firm w dedykowanym środowisku wykonawczym, z dala od jednego konkretnego aplikacja.
Dlaczego istnieje środowisko wykonawcze SDK
Google chce uniemożliwić pakietom SDK reklamodawców gromadzenie danych, do których nie powinien mieć dostępu w sposób złośliwy (lub nawet niezamierzony) w wyniku udostępnienia piaskownicy aplikacji hosta. Gdy pakiet SDK reklam jest wykonywany wewnątrz aplikacji, ma on również dostęp do wszystkiego, co robi aplikacja, a twórca aplikacji może nie być do końca świadomy tego, jak duży jest to dostęp. Usuwając kod reklamodawcy i wykonując go we własnym środowisku wykonawczym, będzie on miał dostęp tylko do danych, które programista mu wyraźnie udostępni.
W rezultacie Google twierdzi, że środowisko wykonawcze SDK zapewnia następujące silniejsze zabezpieczenia i gwarancje dotyczące gromadzenia i udostępniania danych użytkowników:
- Zmodyfikowane środowisko wykonawcze
- Dobrze zdefiniowane uprawnienia i prawa dostępu do danych dla zestawów SDK
Pierwsza wersja SDK Runtime skupia się wyłącznie na pakietach SDK związanych z reklamami, w tym SDK umożliwiających wyświetlanie reklam, pomiar reklam, oszustwa reklamowe i wykrywanie nadużyć.
Jak działa środowisko wykonawcze SDK
Obecnie bez środowiska wykonawczego zestawu SDK proces aplikacji wywoła zestaw SDK, który zostanie wykonany w tej samej piaskownicy, co reszta kodu aplikacji. Google chce, aby programiści zamiast tego mieli interfejs dla pakietu SDK, który działa na pierwszym planie aplikacji, i ten interfejs może następnie łączyć się i udostępniać określone dane tam i z powrotem za pomocą aktualnie tworzonego zestawu SDK wykorzystany.
Zanim
Po
Diagram „przed” (pierwszy) pokazuje, że kod wywołujący zestaw SDK wraz z zestawami SDK odbierającymi wywołania z tego kodu znajdują się w procesie aplikacji. Oznacza to, że zestaw SDK może uzyskać dostęp do wszystkich danych dostępnych w aplikacji. Diagram „po” (drugi) pokazuje, że w procesie pierwszoplanowym aplikacji kod wywołujący SDK komunikuje się z interfejsami SDK. Interfejsy te następnie przekraczają granicę procesu do procesu SDK Runtime, aby wywołać same zestawy SDK. Oznacza to, że używany pakiet SDK nie może po prostu uzyskać dostępu do wszystkiego, czego chce, może uzyskać jedynie informacje z aplikacji, z którą współpracuje.
Nowy zaufany model dystrybucji pakietów SDK
Obecnie, gdy pobierasz aplikację z pakietami SDK innych firm, programista dołącza je do aplikacji przesyłanej i rozpowszechnianej w sklepie Google Play. Zamiast tego Google chce, aby po zainstalowaniu na telefonie aplikacji korzystającej z tych pakietów SDK były one pobierane osobno z samej aplikacji. Oznacza to, że programiści SDK mogą wprowadzać nieistotne zmiany (to znaczy żadnych zmian w interfejsach API lub ich semantykę) do zestawów SDK i rozpowszechniania ich na urządzeniach bez udziału aplikacji deweloperzy.
Z kolei nieprzerwane zmiany pakietu SDK można wdrożyć lub wycofać, bez konieczności czekania dla twórców aplikacji, aby mogli odbudować swoje aplikacje przy użyciu nowych zestawów SDK lub poczekać, aż użytkownicy końcowi zaktualizują swoje aplikacje aplikacje. Decydujące zmiany zmieniające interfejsy API i ich semantykę nadal będą musiały zostać zaktualizowane przez twórców aplikacji, ale programiści SDK będą mogli uzyskać najnowsze, nieniszczące zmiany i poprawki są szybsze i bardziej jednolite dla większej liczby osób jednocześnie, bez konieczności polegania na twórcy aplikacji w kwestii aktualizacji aplikacji i pakietu w nowej wersji SDK.
Zanim
Po
Diagram „przed” pokazuje dokładnie, jak obecnie aplikacje są dystrybuowane za pomocą zestawów SDK. Są one spakowane w aplikację i to ona jest przesyłana do Sklepu Google Play. Na diagramie „po” programiści SDK nie będą już umieszczać swoich zestawów SDK bezpośrednio w aplikacjach; zamiast tego programiści SDK przesyłaliby pakiet SDK i publikowali go w sklepie Google Play. Sklep Google Play zajmowałby się wówczas dystrybucją aplikacji wraz z wszelkimi zależnościami SDK na urządzenia użytkowników końcowych. Google celowo używa również na swoich diagramach wyrażenia „sklep z aplikacjami”, ponieważ jest to otwarte i ogólne rozwiązanie, które może działać w innych sklepach.
Zmiany w sposobie tworzenia, uruchamiania i dystrybucji zestawów SDK i aplikacji
Początkowa propozycja środowiska wykonawczego SDK proponuje szereg zmian w pięciu kluczowych obszarach:
- Dostęp
- Wykonanie
- Komunikacja
- Rozwój
- Dystrybucja
Google chce zdefiniować następujący zestaw uprawnień dla środowiska wykonawczego SDK:
-
INTERNET: Dostęp do Internetu umożliwiający komunikację z usługą sieciową. -
ACCESS_NETWORK_STATE: dostęp do informacji o sieciach. - Uprawnienia dostępu do API chroniące prywatność, które zapewniają podstawowe możliwości reklamowe bez konieczności dostępu do identyfikatorów między aplikacjami. Nazwy uprawnień nie zostały jeszcze sfinalizowane, ale te interfejsy API będą blokowane przez dostęp aplikacji do tych uprawnień.
-
AD_ID: Możliwość żądania identyfikatora wyświetlania reklam. Byłoby to również ograniczone dostępem aplikacji do tego uprawnienia. -
BIND_GET_INSTALL_REFERRER_SERVICE: Możliwość korzystania z Interfejs API strony odsyłającej do instalacji Google Play aby przypisać źródło instalacji aplikacji.
Firma chce także ograniczyć dostęp SDK do pamięci działającej aplikacji, ale także uniemożliwić aplikacji dostęp do własnych danych SDK. Aplikacja nie będzie miała bezpośredniego dostępu do pamięci SDK i odwrotnie, pamięć zewnętrzna nie będzie miała takiego dostępu otwarte dla zestawów SDK, przy czym istniałaby zarówno pamięć dostępna dla wszystkich zestawów SDK, jak i pamięć prywatna dla danego zestawu SDK SDK.
Jeśli chodzi o sposób działania zestawów SDK, będą one działać z nieco niższym priorytetem niż sama aplikacja. Oznacza to, że jest bardzo prawdopodobne, że aplikacja zostanie zakończona wkrótce po zakończeniu środowiska wykonawczego SDK, jeśli pojawi się sytuacja wymagająca zamknięcia jej przez system. W przypadku, gdy nie zostanie ona wypowiedziana w tym samym terminie lub jeżeli istnieje inna przyczyna, propozycja oferuje twórcom aplikacji powiązane metody wywołania zwrotnego cyklu życia, aby mogli obsłużyć ten wyjątek i ponownie zainicjować zestaw SDK Czas wykonania. Zestawy SDK środowiska wykonawczego nie będą mogły w żadnym momencie używać interfejsów API powiadomień do wysyłania powiadomień do użytkowników.
Na koniec Google zauważa, że jest to ogólna propozycja, która nie jest charakterystyczna dla żadnego konkretnego sklepu z aplikacjami. Chociaż prawdopodobnie zostanie ona wbudowana w sklep Google Play, nie ma powodu, dla którego inne sklepy z aplikacjami nie mogłyby mieć podobnej struktury. Google twierdzi, że następujące korzyści są oczywiste:
- Zapewnij jakość i spójność zestawów SDK.
- Usprawnij publikację dla programistów SDK.
- Przyspiesz wdrażanie mniejszych aktualizacji wersji pakietu SDK do zainstalowanych aplikacji.
Piaskownica prywatności w systemie Android wygląda obiecująco
Harmonogram udostępnienia przez Google pierwszego kwartału 2022 r. obejmuje wstępne propozycje projektów oraz opinie i iteracje dotyczące projektu. Wersja zapoznawcza deweloperów pojawi się w dalszej części roku, a wersja beta pod koniec roku. Wreszcie w 2023 r. rozpoczną się skalowane testy. Te podglądy i wersje beta będą niezależne od częstotliwości wydawania Androida 13. Po wdrożeniu w aplikacji ustawień pojawią się również elementy sterujące dostępne dla użytkownika.
Moim zdaniem Piaskownica prywatności w systemie Android wygląda obiecujące, ale będziemy musieli poczekać i zobaczyć, jak firma to wdroży. Jest całkiem możliwe, że programistom się to nie spodoba lub że faktycznie spowoduje więcej problemów niż rozwiąże. Zachęcamy programistów do zapoznania się z dokumentacją opublikowaną przez Google, aby lepiej poznać przyszłość prywatności Androida.
Jest to obecnie propozycja, a nie ostateczne spojrzenie na temat czego Dokładnie stanie się to w przyszłej wersji Androida, ale jest prawdopodobne, że zakończy się to dość blisko. Będziemy śledzić dalszy rozwój wydarzeń!
Źródło: Dokumentacja programisty Androida