Wersja deweloperska Androida 11: wszystkie nowe funkcje prywatności i bezpieczeństwa

click fraud protection

Google udostępniło pierwszą wersję deweloperską Androida 11 dla Pixel 2, 3, 3a i 4. Oto wszystkie ogłoszone przez nich nowe funkcje prywatności i bezpieczeństwa.

Przed terminem, Google dzisiaj ukazała się pierwsza wersja deweloperska kolejnej wersji systemu operacyjnego Android: Android 11. Obrazy systemu są dostępne dla Pixela 2, Pixela 3, Pixela 3a i Pixela 4, ale jeśli nie posiadasz żadnego z nich urządzeń, możesz także wypróbować wersję Developer Preview za pośrednictwem emulatora Android Studio lub systemu ogólnego Obraz. Chociaż Google zapisuje większość ekscytujących nowych funkcji dla użytkowników i programistów na wielkie ogłoszenie na Google I/O 2020firma udostępniła mnóstwo zmian, które są dostępne w pierwszym podglądzie programisty. Oto podsumowanie wszystkich nowych funkcji związanych z prywatnością i bezpieczeństwem, które Google ogłosiło w wersji Android 11 Developer Preview 1.

Wersja deweloperska Androida 11 w wersji zapoznawczej 1 — nowe funkcje prywatności

Dostęp z jednorazowym zezwoleniem

Android kontroluje, do jakiego rodzaju danych aplikacje mogą uzyskać dostęp za pośrednictwem swojego systemu uprawnień. Przed Androidem 6.0 Marshmallow aplikacje prosiły o przyznanie uprawnień podczas instalacji, więc użytkownicy musieli przed zainstalowaniem zdecydować, czy nie przeszkadza im to, że aplikacja ma określone uprawnienia. W systemie Android 6.0 Marshmallow wprowadzono uprawnienia wykonawcze dla wybranego zestawu poufnych uprawnień, w tym dostępu do lokalizacji, dostępu do mikrofonu i dostępu do kamery. Uprawnienia wykonawcze można przyznać dopiero po instalacji, a aplikacja żądająca ich musi poprosić użytkownika o zezwolenie na dostęp w wyświetlonym przez system oknie dialogowym. Wreszcie w Androidzie 10 Google wprowadziło specjalną wersję uprawnień wykonawczych, która pozwala użytkownikowi na udzielenie dostępu tylko wtedy, gdy aplikacja jest aktywnie używana; jednak firma Google wprowadziła jedynie opcję „podczas używania aplikacji” w celu uzyskania pozwolenia na lokalizację.

W Androidzie 11 Google zapewnia użytkownikom bardziej szczegółową kontrolę nad innymi wrażliwymi uprawnieniami, w tym dostępem do kamery i mikrofonu. Firma wprowadziła nową funkcję „jednorazowego pozwolenia” w wersji Android 11 Developer Preview pozwala użytkownikowi tymczasowo udzielić aplikacji dostępu do uprawnienia, o ile aplikacja znajduje się w pierwszoplanowy. Gdy użytkownik opuści aplikację, aplikacja traci dostęp do tego uprawnienia i musi o nie poprosić ponownie.

Zmiany w zakresie magazynu

W Android 10 beta 2Google zaproponował radykalną zmianę sposobu, w jaki aplikacje uzyskują dostęp do pamięci zewnętrznej w systemie Android. (Pamięć zewnętrzna jest tutaj zdefiniowana jako dane widoczne dla użytkownika i innych aplikacji znajdujących się w /data/media.) zmiana, nazwana „Scoped Storage”, miała na celu wyeliminowanie zbyt szerokiego wykorzystania READ_EXTERNAL_STORAGE pozwolenie. Zbyt wiele aplikacji w Sklepie Google Play żądało dostępu do całej pamięci zewnętrznej, w której użytkownicy zapisywali swoje prywatne dokumenty, zdjęcia, filmy i inne pliki, i otrzymywało do nich dostęp. W przypadku usługi Scoped Storage aplikacje domyślnie będą miały możliwość przeglądania tylko swoich prywatnych katalogów danych. Jeśli aplikacja posiada uprawnienie READ_EXTERNAL_STORAGE w ramach wymuszania przechowywania o określonym zakresie, może przeglądać określone pliki multimedialne dostępne za pośrednictwem interfejsu API MediaStore. Alternatywnie aplikacja może korzystać ze struktury dostępu do pamięci masowej, aby użytkownik mógł ręcznie wybierać pliki za pomocą systemowego selektora plików. Wreszcie aplikacje wymagające szerokiego dostępu do pamięci zewnętrznej, takie jak menedżery plików, mogą korzystać z platformy dostępu do pamięci masowej, aby wysyłać żądania umożliwienie użytkownikowi przyznania aplikacji dostępu do katalogu głównego pamięci zewnętrznej, zapewniając w ten sposób dostęp do wszystkich jej podkatalogów, zbyt.

Egzekwowanie ograniczonej pamięci masowej miało obowiązywać w przypadku wszystkich aplikacji w systemie Android 10, ale po opiniach i krytyce ze strony programistów, Google złagodził zmiany, wymagając ich tylko w przypadku aplikacji przeznaczonych dla poziomu interfejsu API 29 (Android 10). Po 1 sierpnia 2020 r. wszystkie nowe aplikacje przesłane do Sklepu Google Play muszą być przeznaczone dla systemu Android 10 i to samo dotyczy wszystkich aktualizacji istniejących aplikacji po 1 listopada 2020 r. Ponadto w systemie Android 11 twórcy aplikacji do zarządzania plikami należy złożyć formularz oświadczenia do Google o umożliwienie szerokiego dostępu do pamięci zewnętrznej; po zaakceptowaniu aplikacje do zarządzania plikami będą miały niefiltrowany widok MediaStore, ale nie będą miały dostępu do zewnętrznych katalogów aplikacji.

Ponadto Google wprowadził inne zmiany w Scoped Storage w Androidzie 11 Developer Preview. Aplikacje mogą wyrazić zgodę na pobieranie nieprzetworzonej ścieżki pliku i wykonywanie operacji edycji zbiorczej plików multimedialnych w sklepie MediaStore. Interfejs DocumentsUI został zaktualizowany, aby był prostszy dla użytkowników. Zmiany te zostały ogłoszone podczas konferencji prasowej Szczyt deweloperów Androida w zeszłym roku i obiecano nam dodatkowe ulepszenia pamięci masowej w przyszłych wersjach Androida 11.

Wersja deweloperska Androida 11 w wersji zapoznawczej 1 — nowe funkcje zabezpieczeń

Wsparcie w zakresie mobilnego prawa jazdy

Od początku ubiegłego roku Google pracuje nad rozwiązaniem IdentityCredential API i HAL w AOSP. Ta funkcja stanowi podstawę do bezpiecznego przechowywania dokumentów identyfikacyjnych na Twoim urządzeniu mobilnym, a w szczególności mobilnych praw jazdy zgodnych z normą ISO 18013-5. Oficjalnie Google’a ogłosił tę funkcję na konferencji Google I/O 2019, a teraz jest wreszcie obsługiwana w wersji Android 11 Developer Preview 1.

Google nie miał zbyt wiele do powiedzenia na temat tej funkcji w komunikacie prasowym, ale ponieważ funkcja ta jest rozwijana od zewnątrz, wiemy już wiele z planów. Na konferencji I/O 2019 firma Google oświadczyła, że ​​współpracuje z ISO w celu ujednolicenia wdrażania paszportów elektronicznych; nadal nie mamy pojęcia, kiedy e-paszporty będą dostępne, ale w kilku stanach USA wprowadzono już eDL lub znajdują się one w fazie próbnej. Google poinformowało również, że pracuje nad udostępnieniem biblioteki Jetpack, aby programiści mogli tworzyć aplikacje tożsamościowe. Nie wiemy jednak, jak szybko programiści będą mogli przetestować tę funkcję, ponieważ prawidłowe wsparcie wymaga bezpiecznego sprzętu na urządzeniu. The Bezpieczna jednostka przetwarzająca w Qualcomm Snapdragon 865 obsługuje interfejs API IdentityCredential, chociaż może nie obsługiwać trybu bezpośredniego dostępu interfejsu API, ponieważ SPU jest zintegrowane z SoC; Tryb bezpośredniego dostępu umożliwi użytkownikowi wyciągnięcie zapisanego elektronicznego identyfikatora, nawet jeśli nie ma wystarczającej mocy, aby uruchomić system Android. Aby uzyskać więcej informacji na temat tego API, polecam czytając naszą pierwszą relację gdzie Shawn Willden, kierownik zespołu ds. bezpieczeństwa sprzętu Android, podzielił się swoimi uwagami.

Nowe moduły głównego projektu

Jedną z największych zmian w Androidzie 10 dla nowo wprowadzonych urządzeń było wprowadzenie Główna linia projektu, który pomimo swojej nazwy nie ma nic wspólnego ze wsparciem głównego jądra Linuksa na Androidzie. (Nawiasem mówiąc, projekt ten nazywa się Generic Kernel Image i wciąż jest w toku.) Zamiast tego celem Project Mainline jest Google przejmie kontrolę nad kluczowymi komponentami frameworku i aplikacjami systemowymi od producentów OEM. Każdy moduł Mainline jest hermetyzowany jako plik APK lub plik APEX i jest aktualizowany przez Google za pośrednictwem Sklepu Play. Użytkownik widzi aktualizacje na swoim urządzeniu jako „aktualizację systemu Google Play” (GPSU), a aktualizacje są publikowane regularnie, podobnie jak pociąg (tj. są pobierane i instalowane w tym samym czasie).

Korzyści z Project Mainline. Źródło: Google.

Google wymaga włączenia określonych modułów Mainline, które w czasie Google I/O 2019 obejmowały 13. Teraz Google wymaga łącznie 20 modułów Mainline w wersji Android 11 Developer Preview 1.

Początkowe moduły główne (@ Google I/O 2019)

Aktualne moduły główne (dla Androida 11 Developer Preview 1)*

KĄT

Logowanie do portalu Captive

Logowanie do portalu Captive

Skrypt

Skrypt

Narzędzie do rozpoznawania DNS

Narzędzie do rozpoznawania DNS

Interfejs Dokumentów

Interfejs Dokumentów

Usługi zewnętrzne

Usługi zewnętrzne

Kodeki multimedialne

Kodeki multimedialne

Komponenty platformy multimedialnej

Komponenty platformy multimedialnej

Metadane modułu

Metadane modułu

Stos sieciowy

Stos sieciowy

Konfiguracja uprawnień stosu sieciowego

Konfiguracja uprawnień stosu sieciowego

Kontroler uprawnień

Kontroler uprawnień

Dane strefy czasowej

Dane strefy czasowej

Nowy moduł uprawnień

Nowy moduł dostawcy mediów

Nowy moduł API sieci neuronowych (NNAPI).

*Uwaga: w momencie publikacji Google nie udostępniło nam pełnej listy modułów Mainline, które są obecnie wymagane. Zaktualizujemy tę tabelę, gdy będziemy mieli pełną listę.

Zmiany biometryczne

Wprowadzono Androida 9 Pie API BiometricPrompt, ujednolicony interfejs API dla sprzętu do uwierzytelniania biometrycznego. Interfejs API zapewnia programistom możliwość kwestionowania użytkownika za pomocą zapisanych danych biometrycznych, niezależnie od tego, czy są to odciski palców, twarz czy tęczówka. Przed BiometricPrompt programiści musieli stworzyć własne okno dialogowe uwierzytelniania i używać interfejsu API FingerprintManager, który obsługiwał tylko uwierzytelnianie odcisków palców, aby rzucić wyzwanie użytkownikowi. W przypadku smartfonów Galaxy ze skanerami tęczówki programiści musieli użyć pakietu SDK firmy Samsung, aby rzucić wyzwanie użytkownikowi. Dzięki BiometricPrompt programiści mogą rzucać użytkownikowi wyzwanie dowolną obsługiwaną metodą biometryczną, a system udostępnia użytkownikowi okno dialogowe. W ten sposób programiści nie muszą się już martwić o zapewnienie obsługi konkretnego rodzaju sprzętu biometrycznego, a także nie muszą już kodować interfejsu użytkownika na potrzeby okna dialogowego uwierzytelniania. The Bezpieczny sprzęt do rozpoznawania twarzy w Pixelu 4można na przykład używać do uwierzytelniania w aplikacjach korzystających z funkcji BiometricPrompt.

Uwierzytelnianie twarzy za pomocą BiometricPrompt.

Co nowego w BiometricPrompt w Androidzie 11 Developer Preview 1? Google dodało 3 nowe typy uwierzytelnień: silny, słaby i dane uwierzytelniające urządzenia. Przed Androidem 11 programiści mogli wysyłać zapytania do bezpiecznego sprzętu biometrycznego urządzenia – skanera linii papilarnych, skanera rozpoznawania twarzy 3D lub skanera tęczówki – podczas korzystania z BiometricPrompt. Począwszy od Androida 11 Developer Preview 1, programiści mogą także sprawdzać metody biometryczne uważane za „słabe”, takie jak oparte na oprogramowaniu rozwiązania do rozpoznawania twarzy, które można znaleźć w wielu telefonach. Na przykład Google’a wcześniej umieściło na czarnej liście wiele telefonów Samsung Galaxy za zwrócenie słabego modułu uwierzytelniającego rozpoznawanie twarzy podczas próby uwierzytelnienia opartego na kryptografii. Teraz do programisty należy decyzja, jakiego poziomu szczegółowości uwierzytelniania biometrycznego potrzebuje jego aplikacja.

Bezpieczne przechowywanie i udostępnianie obiektów BLOB

Nowy interfejs API o nazwie BlobstoreManager ułatwi aplikacjom wzajemne udostępnianie obiektów blob danych. Google podaje aplikacje udostępniające modele uczenia maszynowego jako idealny przypadek użycia nowego interfejsu API BlobstoreManager.

Hartowanie platformy

Aby zmniejszyć powierzchnię ataku na Androida, Google wykorzystuje środki dezynfekujące LLVM w celu zidentyfikowania „błędów niewłaściwego użycia pamięci i potencjalnie niebezpiecznego, niezdefiniowanego zachowania”. Obecnie Google rozszerza ich zastosowanie oparte na kompilatorze narzędzia dezynfekujące kilka komponentów o znaczeniu krytycznym dla bezpieczeństwa, w tym BoundSan, IntSan, CFI i Shadow-Call Stack. Aby wykryć problemy z pamięcią w środowisku produkcyjnym, Google włącza opcję „tagowanie wskaźnika sterty” dla wszystkich aplikacji przeznaczonych dla systemu Android 11 lub nowszego. Znakowanie wskaźników sterty jest obsługiwane na 64-bitowych urządzeniach ARMv8 z obsługą jądra dla ARM Top-byte Ignore (TBI), funkcji, w której „ sprzęt ignoruje górny bajt wskaźnika podczas uzyskiwania dostępu do pamięci.” Google ostrzega programistów, że te ulepszenia mogą powodować zwiększenie bezpieczeństwa „powierzchni bardziej powtarzalne/odtwarzalne awarie aplikacji”, dlatego programiści powinni dokładnie przetestować swoje aplikacje na nowym Androidzie 11 Developer Zapowiedź. Aby znaleźć i naprawić wiele błędów pamięci w systemie, Google użył narzędzia do wykrywania błędów pamięci o nazwie wspomagany sprzętowo AddressSanitizer (HWASan). Google oferuje gotowe obrazy systemu obsługujące HWASan na serwerze kompilacji AOSP na wypadek, gdybyś chciał znaleźć i naprawić błędy pamięci we własnych aplikacjach.


Google z pewnością ogłosi dodatkowe funkcje chroniące prywatność użytkowników i poprawiające bezpieczeństwo, więc miej oko na naszą ofertę Androida 11, aby być na bieżąco.

Wiadomości o Androidzie 11 na XDA