It’s completely normal for a regular smartphone user to have more than 50 apps installed at once. Some apps are used on a regular basis and other ones might sit closed for several weeks or longer, but almost all of them require some kind of information about either the device they’re installed on or something about you – the user. This information might be your email address, your actual physical address, or your real name.
At the same time, the very nature of such a complicated device as a smartphone allows apps to gather much more information than you might think, even including something unexpected, such as your exact geolocation, access to your iPhone’s microphone or its’ camera.
While all of the above might be done with the user’s consent, it’s surprising how much some of your regular apps can gather when it comes to information or permissions. For example, an extremely large amount of applications both on iOS and Android requires access to your exact geolocation to work properly, and even more apps are requesting access to your camera on a regular basis. In some cases, it’s possible for Android apps to also request permissions to access your SMS messages and/or your phone call history.
A number of researches have been conducted on the topic, comparing the amount of permissions that the user agrees to with the amount that was actually used and needed by the app in question. Most of the use cases were indeed needed and used, with something like a taxi app requesting the user’s location so that the driver knows where the client is that he needs to get to. The interesting part here is if apps were requesting an excessive amount of permissions and if the requested data was protected within the app in question.
Personally Identifiable Information
One of the most important topics for this kind of research is everything that surrounds PII (Personally Identifiable Information) and how apps are handling their interactions with PII. With a relatively small difference in numbers between the two, both iOS and Android apps were using the same types of PII the most.
PII – Personal Identifiable Information – is a specific piece of information that can be used to identify a specific person among many others. Some examples of such information are medical history, birthdates and many other credentials. This article about personal identifiable information would help you learn many different nuances and aspects of the topic, as well as some of the terminology.
As it stands, the most commonly shared piece of PII within smartphone applications is email address, followed closely by the username (which is often the user’s actual real name). Another two examples of a popular PII type that is often collected by such applications are phone numbers and user locations (even though both of those are not as frequently used as the email or the username).
Different types of PII do not hold the same amount of importance, and companies have to implement various processes called “data classification” to make sure that all of the important data is properly secured and protected. The following article about the topic of data classification would help you with understanding the specifics of the process, as well as some additional information.
That’s not to say that these are the only examples of PII being shared with the smartphone app. There’s a lot of examples when apps can integrate with social media accounts, allowing the application to create a post directly from under the user’s account on the social media website, among other advantages. This allows users to remove the need to input their password each time, friends from a social media website can be invited to play mobile games with the account holder, etc.
Of course, a different side of this symbiotic relationship also exists, since the social media service can collect data from the application, and the app in question can collect data from the user’s account within that social media website. And this is where everything gets complicated, with some Android applications preventing the user from knowing what PII were shared, while most of the iOS apps in similar cases were allowing such information. This divide is created by the use of Facebook’s Graph API, and the Android version of Graph API uses a specific method called “certificate pinning” that prevents the list of shared PIIs from being seen by the user.
While Facebook’s Graph is not the most popular integration service, with Google integration service claiming that spot, Graph is definitely the most infamously-known one. The popularity of Graph is directly tied to the fact that it was used by Cambridge Analytica to compile PII of 80+ million Facebook users back in 2016. It is worth mentioning that after the incident Facebook significantly reduced the amount of personal data that could be shared through Graph, and tightened up the entirety of the API in general.
Risky permissions
Another important part of any application that lets it work properly is about permission requests. Each and every application requires a specific list of permissions to be able to operate properly. As with the PII sharing, applications do not always need all of the permissions that they’re requesting.
This is where the term of “risky permissions” comes in, signifying specific permissions that could lead to an application gaining access to specific resources or information about the user, which might be PII in the first place, or something that can affect other applications within the device. Some of the popular examples of such permissions are user location, phone call history, calendar, camera, SMS messages and contacts, among others.
When it comes to popularity, access to your smartphone’s camera is definitely the most popular one in the list, followed closely by the GPS tracking. Audio recording is another popular example of such a feature, as well as the Android-exclusive ones that are about accessing your SMS messages and phone call history. Unlike with the direct PII sharing, the number of Android applications requesting each of these permissions is almost twice as high as the number of iOS ones, and this applies to almost all of the examples above, as well. At the same time, there are some cases when the identical application for iOS does not request a permission to read your phone call logs or your SMS history, and its Android counterpart does request at least one of those permissions.
The topic of risky permissions should also be approached from a more cautious standpoint. While the definition itself does appear to be somewhat malicious, you don’t have to reject the permission request just because an app requested it. In a lot of cases such a permission is needed for the app in question to operate properly, such as the delivery app or the taxi app requesting your geographical location, among many other examples. The best approach to the topic of risky permissions is by thinking through if there’s a reason for this specific request to be granted, and if you really want to provide, for example, phone call logs to your alarm clock application?
Security
While this is not as widespread of a topic as the problem of excessive permissions or PII sharing, some applications simply do not have any sort of proper security measures to protect the data you’re sharing with them. For example, there’s a relatively high amount of applications that request risky permissions and do not have any privacy policy at the same time. A privacy policy is necessary in these cases so that you can learn what data types are collected, how they are processed, who they are shared with and what are the security measures of the app in general.
A privacy policy is also important for companies to be able to become compliant with many different government regulations. One of the most popular and well-known regulations like these is GDPR, strictly regulating the processing of personal data of EU citizens all over the world. The following article describes the topic of GDPR compliance and the many different nuances and regulations involved in the process.
Another arguable topic of interest is certificate pinning, which is also barely ever used by apps in the first place. Certificate pinning is a security precaution that was created to prevent attacks against secure communications. Certificate pinning ensures that the app can only communicate with a server with the same security certificate.
At the same time, there’s no definitive opinion about certificate pinning in the industry. Apple, for example, does not recommend app developers to do their own certificate pinning since such an approach might lead to various problems in the enterprise environment, as well as the overall fragility of the system in general.
Conclusion
The subject of mobile privacy is vast and extensive, covering multiple different approaches and nuances. At the same time, it brings a lot of important topics to light, too, such as the problem of PII sharing, risky permissions, and so on.
The importance of PII is unmatched, as well as the need for its protection. Knowing about different ways of sharing PII, either through direct requests from apps or via risky permissions, is the first step towards securing your PII from falling into the wrong hands.
