At first glance, the relationship between privacy on Android phones may seem complicated.

Given Google’s prominent role in the advertising business, where the bulk of its revenue is generated, it can be challenging to reconcile the idea of data collection with the desire for carefully controlled information. In this article, I’d like to delve into some reflections on privacy concerning Android phones and share some suggestions on how to fortify it.

Avoid Rooting

Rooting Android phones can significantly compromise security, as it undermines the entire Android security model. This poses a threat to privacy, especially in the event of an exploit taking advantage of weakened security. Common rooting methods involve tampering with the boot partition, making successful Verified Boot impossible. Apps that demand root access also modify the system partition, keeping Verified Boot disabled. Having root exposed in the user interface expands the attack surface, potentially aiding in privilege escalation vulnerabilities and SELinux policy bypasses.

For instance, Adblockers such as AdAway, which modifies the hosts file, and firewalls like AFWall+, requiring root access persistently, are deemed unsafe and should be avoided. Instead, I recommend steering clear of these methods and opting for encrypted DNS blocking solutions like NextDNS or a custom solution using Cloudflare to enhance security without compromising the integrity of the Android system.

System and Firmware Updates

Using an end-of-life version of Android poses a significant security risk, as it not only denies you crucial operating system security updates but also misses out on vital privacy enhancements. The importance of upgrading to newer Android versions is underscored by the example of changes made prior to Android 10. Previously, apps with the READ_PHONE_STATE permission could access sensitive phone information like IMEI, MEID, or IMSI. With newer Android versions, such access is restricted to system apps provided by the OEM or Android distribution.

image

Firmware updates are critical for maintaining device security, but OEMs have support agreements to provide closed-source components for a limited period. For components relying on closed-source technologies, updates must come from manufacturers like Qualcomm and Samsung, who support their devices for 4 years and, in the case of Google’s Pixel, provide a minimum of 5 years of support (beginning with the Pixel 8 and 8 Pro, Pixel devices receive a minimum of 7 years of guaranteed security updates).

It’s crucial to purchase devices within an active support cycle, as cheaper products often have shorter support periods. Devices that reach end-of-life and are no longer supported by the System on Chip (SoC) manufacturer miss out on firmware updates, leaving security vulnerabilities unaddressed. Therefore, ensuring your device receives regular updates is essential for safeguarding against potential security issues.

Data encryption and verified boot

Verified Boot plays a crucial role in fortifying the Android security model, acting as a bulwark against various threats like evil maid attacks, persistent malware, and preventing the downgrade of security updates through rollback protection.

With Android 10 and later versions, there’s a shift from full-disk encryption to more adaptable file-based encryption. This involves encrypting data with unique keys while leaving the operating system files unencrypted. Verified Boot becomes pivotal in this context by ensuring the integrity of these OS files, thwarting any attempts at tampering or malware installation by an adversary with physical access. Even if malware manages to exploit other system parts and gain elevated access, Verified Boot steps in to prevent and reverse changes to the system partition upon device reboot.

However, it’s worth noting that OEMs are only obligated to support Verified Boot on their stock Android distribution. Limited OEMs, such as Google, allow custom AVB key enrollment on their devices. On the flip side, some AOSP derivatives like LineageOS or /e/ OS may lack Verified Boot support, even on hardware designed for third-party operating systems. To safeguard against this, it’s advisable to check for Verified Boot support before purchasing a new device. AOSP derivatives without Verified Boot support are not recommended. Additionally, some OEMs may have flawed implementations of Verified Boot, emphasizing the importance of scrutiny beyond marketing claims.

App Permissions Awareness

image Source: NordVPN

Permissions on Android empower users with control over app access, and Google consistently enhances this system in each new version. Following, some examples of the new permissions introduced between Android 10 and Android 14.

Android 10:

  • Reinforced location privacy by implementing the ACCESS_BACKGROUND_LOCATION permission. This new permission is a significant step towards tighter control over app access to device location, specifically when running in the background. Its introduction ensures that apps cannot access location data in the background without explicit permission from the user.
  • Scoped Storage represents a significant evolution in Android’s file management system, providing users with enhanced control over their files while restricting access to external storage. With Scoped Storage, apps gain the capability to have designated directories in external storage, offering a more organized and structured approach to file storage. This feature not only streamlines file management for apps but also contributes to improved security by limiting access to external storage. Apps can now store specific types of media in designated directories, contributing to a more organized and efficient file ecosystem. Scoped Storage aligns with the broader trend in mobile operating systems towards offering users more granular control over app access to sensitive areas, promoting a secure and user-centric experience on the Android platform.

Android 11:

  • Granular permissions for accessing phone number-related features, enhancing user control and privacy. This means that apps now require explicit permission from users to access specific phone number-related functionalities. This includes features like accessing the phone number itself, making calls, or sending messages. This granular approach empowers users to have more control over how and when apps interact with their phone number. It aligns with the broader trend in mobile operating systems towards giving users increased transparency and control over app permissions, contributing to a more secure and privacy-focused mobile experience on the Android platform.
  • One-time permission: this feature offers a temporary control over app permissions. When a user selects one-time permission, the app can access the specified permission (such as location or camera) for that particular session but will need to request permission again for subsequent uses.
  • Auto-reset permissions: this feature automatically resets runtime permissions that were granted to an app when it was initially opened. In other words, after the app is closed, any permissions it acquired during runtime are revoked.

Android 12:

  • Approximate location allows to grant only the approximate location. This means that users now have the option to provide apps with a general idea of their location, rather than granting precise, pinpoint access.
  • Auto-reset of hibernated apps: this functionality is designed to automatically reset apps that have been hibernated, offering users a convenient way to manage their device’s performance, resource usage and security.
  • Data access auditing: provides a detailed insight into how and when an app interacts with user data. This level of granularity is crucial for both users and developers, enabling a better understanding of data usage patterns within an application.

Android 13:

  • Permission for nearby wifi access: the introduction of a specific permission for nearby WiFi access represents a crucial step in bolstering user privacy on Android. Previously, apps could exploit the addresses of nearby WiFi access points as a method to track a user’s location. Now, with this dedicated permission, users have more control over which apps can access information about nearby WiFi networks.
  • More granular media permissions: this feature allows users to finely control which types of media files (images, videos, or audio files) an app can access. Instead of granting broad access to all media files, users can now specify the types of media that an app is allowed to interact with.
  • Starting from Android 13, background use of sensors requires the BODY_SENSORS permission: this change ensures that apps utilizing sensors in the background, such as those for fitness tracking or health monitoring, must explicitly request permission from the user.

Android 14:

  • Privacy-preserving Screenshot Detection API that allows apps to detect when a user takes a screenshot. The API lets the app register a callback at an activity level. When a screenshot is taken, a visual notification is shown and the callback is invoked.
  • Selected Photo Access: allows a user to grant access to specific media files when an app requests visual media permissions READ_MEDIA_IMAGES or READ_MEDIA_VIDEO, first introduced in Android 13.

Some apps can request more permissions than they need, so whenever you’re installing a new app on your Android device, it’s crucial to check its permissions. Take a moment to see exactly what kind of access the app is requesting. If, for example, a seemingly innocent app like a wallpaper or game is asking for extensive permissions—like access to your accounts, SMS, microphone, location, or unlimited internet—that’s a red flag.

During installation, make sure to review the list of permissions displayed on the screen. Click on the ‘See Permissions’ link at the bottom of the app page for a more detailed view.