Ahead of schedule, Google today released the first Developer Preview of the next version of the Android OS: Android 11. System images are available for the Pixel 2, Pixel 3, Pixel 3a, Pixel 4, but if you don’t own one of these devices, you can also try out the Developer Preview via the Android Studio emulator or the Generic System Image. Although Google is saving most of the exciting new user and developer features for a grand announcement at Google I/O 2020, the company has shared a plethora of changes that are available in the first Developer Preview. Here’s a summary of all the new privacy and security-related features that Google has announced in Android 11 Developer Preview 1.
Android 11 Developer Preview 1 – New Privacy Features
One-time Permission Access
Android controls what kinds of data apps can access through its permission system. Before Android 6.0 Marshmallow, apps requested to be granted permissions at installation, so users had to decide whether they were okay with an app having certain permissions before installing it. Android 6.0 Marshmallow introduced runtime permissions for a select set of sensitive permissions, including location access, microphone access, and camera access. Runtime permissions can only be granted after installation, and the app requesting them must prompt the user through a system-provided dialog to allow access. Finally, in Android 10, Google introduced a special version of the runtime permission which allows the user to grant access only while the app is in active use; however, Google only introduced the “while app is in use” option for the location permission.
In Android 11, Google is giving users more fine-grained control over other sensitive permissions, including camera and microphone access. The company has introduced a new “one-time permission” feature in the Android 11 Developer Preview that allows the user to temporarily grant an app access to a permission so long as that app is in the foreground. Once the user navigates away from the app, the app loses access to that permission and must request it again.
Scoped Storage changes
In Android 10 beta 2, Google proposed a radical change to the way that apps access the external storage on Android. (External storage, here, is defined as the data visible to the user and other apps located in /data/media.) The change, dubbed “Scoped Storage,” was aimed at eliminating the overly broad use of the READ_EXTERNAL_STORAGE permission. Too many apps on the Google Play Store were requesting and being granted access to the entire external storage where users were saving their private documents, photos, videos, and other files. With Scoped Storage, apps would, by default, only be granted the ability to see their private data directories. If an app holds the READ_EXTERNAL_STORAGE permission under Scoped Storage enforcement, then it can view certain media files accessible through the MediaStore API. Alternatively, the app can use the Storage Access Framework to have the user manually select files through the system file picker. Finally, apps that need broad access to the external storage, such as file managers, can use the Storage Access Framework to request the user to grant the app access to the root directory of the external storage, thereby granting access to all its subdirectories, too.
Enforcement of Scoped Storage was set to take effect for all apps in Android 10, but after feedback and criticism from developers, Google relaxed the changes, only requiring them for apps targeting API level 29 (Android 10). After August 1st, 2020, all new apps submitted to the Google Play Store must target Android 10, and the same is true for all updates to existing apps after November 1st, 2020. Furthermore, in Android 11, developers of file manager apps must submit a declaration form to Google to be allowed broad access to the external storage; once accepted, file manager apps will have an unfiltered view of MediaStore but will not have access to external app directories.
In addition, Google has introduced other changes to Scoped Storage in the Android 11 Developer Preview. Apps can opt-in to get the raw file path and perform batch edit operations for media files in the MediaStore. The DocumentsUI has been updated to be simpler for users. These changes were announced at the Android Dev Summit last year, and we’re promised additional enhancements to Scoped Storage in future Android 11 releases.
Android 11 Developer Preview 1 – New Security Features
Mobile Driver License Support
Since early last year, Google has been working on the IdentityCredential API and HAL in AOSP. This feature lays the groundwork for securely storing identification documents on your mobile device, and in particular, ISO 18013-5 compliant mobile driving licenses. Google officially announced this feature at Google I/O 2019, and now it’s finally supported in Android 11 Developer Preview 1.
Google didn’t have a lot to say about this feature in the press release, but because the feature is being developed in the open, we already know a lot of what’s planned. At I/O 2019, Google stated that they were working with the ISO to standardize an implementation of electronic passports; we still don’t have an inkling of when ePassports will be available, but there are already several U.S. states where eDLs are implemented or are in the trial phase. Google also said they are working to provide a Jetpack library so developers can create identity apps. We don’t know how soon developers will be able to test this feature, though, since proper support requires secure hardware on the device. The Secure Processing Unit on the Qualcomm Snapdragon 865 supports the IdentityCredential API, though it may not support the API’s Direct Access mode since the SPU is integrated into the SoC; Direct Access mode would allow the user to pull up a stored electronic ID even when there isn’t enough power to boot Android. For more information on this API, I recommend reading our initial coverage where Shawn Willden, the Android hardware-backed security team lead, provided his input.
New Project Mainline Modules
One of the biggest changes in Android 10 for newly launched devices was the introduction of Project Mainline, which despite its name, has nothing to do with supporting the mainline Linux kernel on Android. (That project, by the way, is called Generic Kernel Image and is still a work-in-progress.) Instead, the purpose of Project Mainline is for Google to wrest control of key framework components and system applications away from OEMs. Each Mainline module is encapsulated as either an APK or an APEX file and is updateable by Google through the Play Store. The user sees updates as a “Google Play System Update” (GPSU) on their device, and updates are released on a regular cadence as a train (ie. they’re downloaded and installed at the same time).
The benefits of Project Mainline. Source: Google.
Google mandates the inclusion of specific Mainline modules, which at the time of Google I/O 2019, included 13. Now, Google is mandating a total of 20 Mainline modules in Android 11 Developer Preview 1.
| Initial Mainline Modules (@ Google I/O 2019) | Current Mainline Modules (for Android 11 Developer Preview 1)* |
|---|---|
| ANGLE | Captive Portal Login |
| Captive Portal Login | Conscrypt |
| Conscrypt | DNS Resolver |
| DNS Resolver | Documents UI |
| Documents UI | ExtServices |
| ExtServices | Media Codecs |
| Media Codecs | Media Framework Components |
| Media Framework Components | Module Metadata |
| Module Metadata | Network Stack |
| Network Stack | Network Stack Permission Configuration |
| Network Stack Permission Configuration | Permission Controller |
| Permission Controller | Time Zone data |
| Time Zone data | New permissions module |
| New media provider module | |
| New neural networks API (NNAPI) module | |
*Note: at the time of publication, Google has not provided us the full list of Mainline modules that are currently required. We will update this table once we have the full list.
BiometricPrompt Changes
Android 9 Pie introduced the BiometricPrompt API, a unified API for biometric authentication hardware. The API provides developers a way to challenge the user through their saved biometrics, whether that be fingerprint, face, or iris. Before BiometricPrompt, developers had to create their own authentication dialog and use the FingerprintManager API, which only supported fingerprint authentication, to challenge the user. On Galaxy smartphones with iris scanners, developers had to use Samsung’s SDK to challenge the user. With BiometricPrompt, developers can challenge the user with any supported biometric method, and the system provides the dialog to the user. Thus, developers no longer need to worry about specifically providing support for a particular kind of biometric hardware, and they also no longer had to code the UI for the authentication dialog. The Pixel 4’s secure facial recognition hardware, for example, can be used for authentication in apps that use BiometricPrompt.
Facial authentication using BiometricPrompt.
What’s new for BiometricPrompt in Android 11 Developer Preview 1? Google has added 3 new authenticator types: strong, weak, and device credential. Before Android 11, developers could only query the device’s secure biometric hardware—fingerprint scanner, 3D facial recognition scanner, or iris scanner—when using BiometricPrompt. Starting in Android 11 Developer Preview 1, developers can also query biometric methods deemed “weak” such as the software-based facial recognition solutions found on many phones. For example, Google previously blacklisted multiple Samsung Galaxy phones for returning a weak facial recognition authenticator when attempting crypto-based authentication. It’s now up to the developer to decide what level of biometric authentication granularity their app needs.
Secure Storage and Sharing of BLOBs
A new API called the BlobstoreManager will make it easier and more secure for apps to share data blobs with one another. Google cites apps sharing machine learning models as an ideal use case of the new BlobstoreManager API.
Platform Hardening
In an effort to reduce the attack surface of Android, Google uses LLVM sanitizers to identify “memory misuse bugs and potentially dangerous undefined behavior.” Google is now expanding the use of these compiler-based sanitizers to several security-critical components including BoundSan, IntSan, CFI, and Shadow-Call Stack. To catch memory issues in production, Google is enabling “heap pointer tagging” for all apps targeting Android 11 or higher. Heap pointer tagging is supported on ARMv8 64-bit devices with kernel support for ARM Top-byte Ignore (TBI), a feature in which “the hardware ignores the top byte of a pointer when accessing memory.” Google warns developers that these hardening improvements may “surface more repeatable/reproducible app crashes,” so developers should thoroughly test their apps on the new Android 11 Developer Preview. In order to find and fix many memory errors in the system, Google used a memory error detection tool called hardware-assisted AddressSanitizer (HWASan). Google is offering HWASan-enabled prebuilt system images on the AOSP build server in case you’re interested in finding and fixing memory errors in your own apps.
Google is sure to announce additional features to protect user privacy and improve security, so be sure to keep an eye out on our Android 11 coverage to stay up-to-date.
The post Android 11 Developer Preview: All the new Privacy and Security features appeared first on xda-developers.
from xda-developers https://ift.tt/2HFF2CV
via IFTTT
Aucun commentaire:
Enregistrer un commentaire