Casual talk: Some thoughts on Android system permissions

The permission management of the Android system has always been a very confusing thing. This is not only clearly seen by a large number of relevant researchers, but many users of the system have also actually felt some of the shortcomings of Android phones.

Recently, I happened to read and organize some articles related to Android system permission management. Here I will sort them out and summarize them, and talk about my personal understanding.

Whenever I get an Android phone and complete the initialization operation, the first thing I do is to uninstall most of the pre-installed applications if the system allows. These are considered low-quality applications to me, and my relationship with them can be said to be basically orthogonal.

[[416046]]

APP pre-installation should be regarded as an important way for application software developers to promote their products. It is a common practice for APP manufacturers to pay a large sum of money to let mobile phone manufacturers write their own APP into the hardware or implant their own APP into the system, thereby obtaining a large number of new registered users. However, the process of packaging so many pre-installed applications into the firmware is basically a black box for users, that is, there is zero transparency.

The strong openness of the Android system has led to a variety of different stakeholders and a complex supply chain ecosystem formed by the system. Among them, whether it is the manufacturer, or the developers and dealers affiliated with the mobile phone manufacturers, they can add proprietary applications and higher-level functions to the system at will, and even complete the design and commercialization of a customized system.

So, is the vast amount of pre-installed software under the control of many manufacturers, each of which has its own owner, safe and harmless? The answer is: No

An article published in Oakland S&P last year[1] conducted a related survey on this issue, and the popular domestic mobile phone manufacturers such as Xiaomi, Huawei, vivo, OPPO and Meizu were all within the scope of its research.

According to the statistics in the article (this analysis took place on November 19, 2018), only 9% of pre-installed apps can be retrieved in the Play Store, while 74% of non-public apps have basically not been updated, and 41% of apps have not had any patch updates for 5 years or even longer, which means that many outdated vulnerabilities can easily invade these pre-installed software.

In addition to being hacked, these software may themselves be malicious software that actively invades user systems for profit.

For example, many custom permissions declared by mobile phone vendors, analytics services, and online services present certain security risks and vulnerable modules.

In addition, the number of permissions requested by different Android manufacturers' phones varies greatly, ranging from 9 core module permissions in Google to more than 100 permissions in Samsung devices. In addition, the author also gave an example that the average number of permissions for com.android.contacts is 35, while the number of permissions requested in Samsung, Huawei, Advan and LG devices exceeds 100.

In addition, many Android pre-installed applications have TPLs that request access signatures or certain dangerous permissions, which makes it easier for important sensitive resources of the system to be exposed.

Finally, the author also analyzed 158 apps through manual reverse analysis, and the results are as follows

First, suspicious software including Triada, Rootnik, SnowFox, Xinyin, Ztorg, Iop and developed by GMobi were found in a large number of low-end Android devices and some high-end devices on the market. Their malicious behaviors include bank fraud, sending SMS or subscription services to premium numbers, silently installing other applications, accessing links and displaying advertisements.

Secondly, almost all applications that allow access to PII have the ability to collect and upload potential personal software and hardware user information on mobile phones.

Finally, among the 612 pre-installed apps, the authors found many potentially dangerous apps that, based on their package and app names, could implement engineering mode or factory mode functionality. Such functionality includes relatively harmless tasks, such as hardware testing, but also potentially dangerous functionality, such as the ability to root Android devices.

At the end, the author also gave his proposed solutions, such as introducing and using certificates signed by globally trusted certificate authorities, establishing a certificate transparency library, and including corresponding instruction documents in pre-installed applications to facilitate user information.

In my opinion, there are two main problems with the author's suggestion.

First, there is currently no mandatory third-party organization or government agency to force mobile phone manufacturers to make their permissions public and transparent. If the manufacturers rely on their own initiative, it will inevitably conflict with the interests of certain companies in the entire mobile phone supply chain. Will they make concessions without being forced? I don’t think it is realistic, unless consumers use some means to harm their vital interests.

Second, even if mobile phone manufacturers can openly and transparently show users the permissions used by each app, can users judge the extent of the harm?

Let’s first look at the first question. A 2020 IJCNN[2] article investigated whether Android apps comply with the privacy policy of the Google Play Privacy Guide and whether they access privacy-sensitive information only when users accept the policy.

The overall method design of the article is as follows:

The main experimental results are as follows:

The results show that among 5,057 apps, only 5.5% (4.6% + 0.9%) of them follow the Google Play privacy guidelines, and 4.6% of them do not access any PSI and therefore do not need a privacy policy. It can be seen that moral appeals and condemnations are basically ineffective.

How do these apps steal user data? They mainly use ad libraries and analytics libraries.

First, ad libraries are almost universal in all smartphone apps and have begun to collect and accumulate sensitive personal data. Research shows that they mainly involve location information, app usage, device information, communication data such as logs, storage access permissions (and microphone control permissions, etc.)

Secondly, the analytics library mainly collects users’ in-app operations, which is more likely to leak users’ private information than the advertising library. A 2020 MobileCom[3] study and analyzed this type of privacy leakage.

The overall analysis framework is as follows:

Next, let’s look at the experimental results of the article.

First, will the analytics library leak users’ personal information to app developers? The answer is: yes

Since developers cannot obtain the raw data of the collected information, it is difficult for them to analyze individual users. However, developers can use these analysis libraries to directly collect users' private data. For example, Wo Mailbox Version 6.3.0 is a mailbox application that helps users manage emails. It was developed by China Unicom and had more than 2.6 million active users in February 2016. Through the analysis library, this application automatically records the user's email address, the recipient's email address, the email address of the user who was copied on the message, etc.

Secondly, will the analytics library leak users’ personal information to analytics companies? The answer is: yes

Since the analysis company has the raw data of the collected information, the information leaked to the analysis company is much more serious than the information leaked to the developer, which leads to the following security issues:

Next, if analytics companies link together information collected from different apps, how much will they learn about users?

The privacy risks caused by analytics pools are exacerbated if analytics companies link together data collected from different apps to profile users. Analytics companies can do this easily because they collect device identifiers along with users’ in-app actions. They know which apps are installed on the same device and used by the same user. The more popular the analytics pool, the more information it can obtain, and the more comprehensive its knowledge of users will be.

Finally, are users aware that third-party analytics companies collect their in-app activity? The answer is: Most don’t.

After studying the privacy policies of analytics libraries, the article found that some analytics companies list the information they will collect and require developers to display the usage of analytics libraries and the information collected by analytics libraries in their app privacy policies. However, after reading the privacy policies of these apps, it was found that only a few apps follow this rule. Therefore, most users are unaware that their in-app operations will be collected and analyzed by third-party analytics libraries.

Next, let's look at the second question we talked about before. Even if mobile phone manufacturers can openly and transparently show users the permission usage of each APP, can users judge the degree of harm?

The answer is: It is difficult, and many users will find it difficult to distinguish

A USENIX article in 2021 [4] conducted a detailed analysis of this. Currently, the system provides very limited information when requesting permissions, which makes it difficult for users to understand the function of the permissions and may cause corresponding risks.

The article shows that only a very small number of users (6.1%) can accurately infer the scope of the permission group from the information provided by the system. This means that the permission information provided by the current system is far from enough.

For example, in the permission request dialogs on Android and iOS shown above, in Figure 1(a), the dialog box only shows Snapchat requesting permission to make and manage calls; however, it does not inform the user that it will also allow the app to access the phone status and ID (i.e., IMEI). In Figure 1(b), the usage description provided by the Twitter application only gives a vague description of how location data is used, rather than a more detailed and complete description, which seems to be confusing users.

App developers may be motivated to dishonestly and fully disclose their full access to and use of user data, and the victims are users, because, from these brief descriptions, it is difficult for users to fully understand the risks of granting these permissions, and they may then take extremely dangerous actions.

Current mobile systems play a neutral role in protecting users' private information - they just provide simple descriptions and allow applications to explain their permission request intentions. This can easily lead to accidental privacy leaks due to users' inadequate understanding of permissions. Many users have many common misunderstandings, or "confusion", about certain permission groups. Secondly, many Android users are unaware of the changes in the permission model, which exacerbates the dangers of user-related decisions.

refer to

• ^An Analysis of Pre-installed Android Software https://ieeexplore.ieee.org/abstract/document/9152633
• ^Proc.of the IEEE International Joint Conference on Neural Networks (IJCNN 2020) https://arxiv.org/pdf/2004.08559.pdf
• ^Privacy Risk Analysis and Mitigation of Analytics Libraries in the Android Ecosystem https://ieeexplore.ieee.org/document/8660581
• ^Can Systems Explain Permissions Better? Understanding Users' Misperceptions under Smartphone Runtime Permission Model https://www.usenix.org/conference/usenixsecurity21/presentation/shen-bingyu