We analyzed the permissions requested by Brazilian government apps in order to verify which ones are requested and if they indeed related to the apps’ functionalities

Did you not read the other posts? See our presentation post here!

Have you ever stopped to think about what the apps you install on your cell phone are accessing? One strategy used by the apps to avoid our manual supply of information is the use of sensors and data that is already registered, stores and generated by our devices (smartphones, tablets, computers). To access this, the OS needs to give certain permissions to the app.

Some of the most common permissions request access to:

• ► contacts (and all information stored with them);
• ► call logs;
• ► Internet data;
• ► calendar information;
• ► photos (and access to the camera);
• ► device location data;
• ► device unique identifier;
• ► information on how the user uses the app;
• ► fingerprint hardware;

You are the one who decides if the OS will give these permissions, with the natural expectation that it will serve the good and convenient functioning of the app. From there, the permission is valid both during the execution of the app on the foreground (that is, when we are actively using this app), as well as when it is in the background (when the app is closed but is still running internal activities we do not even know).[1]

In this context, one of the most basic principles of information security — the principle of least privilege — establishes that all programs should operate using the least privileges necessary to do its job. [2] In the case of applications, this means that they should use the least possible permissions in order to operate. This guarantees that they have a better stability and are less vulnerable. When this principle is not observed, the apps are exposing users to more risks than necessary.

Another important principle is the one of transparency: knowing what the apps are doing with their permissions. That is why, in theory, after receiving the permission from a technical point of view the app can do what it sees fit with it. This is especially sensitive when we are dealing with some broad permissions, which are given to a specific functionality within the app (like sending SMS) but are potentially capable of being used for much more (like seeing your call log, for instance).

That is where the fundamental element of trust between users and application providers comes in, which can be another risk factor: the permission can be broad from a technical point of view but we expect for it to be used only within our legitimate expectations.[3] If this trust is broken, the user is exposed to risks and abuses. We will talk about this on the other posts of this SPECIAL about privacy policies and consent. Now, we will better understand what we are dealing with.

We analyzed the permissions requested by government apps that are part of this research in order to verify which ones are requested and if they are indeed related to the apps’ functionalities.

For this, we used the Lumen Privacy Monitor app, developed by the Haystack project of Berkeley University, that, among other functionalities, sees the permissions involved with the apps installed in a device and classifies their risk: “low, medium, and dangerous”. The permissions which are considered of high-risk are the ones that involve data and resources that can compromise the user’s privacy (like access to the camera, location, or accounts used on the device) or even affect the device’s operation (what is possible with the undue use of the external memory, for instance).

Our findings

Lumen classifies as dangerous the permissions to access the device’s geolocation, camera, and accounts, as well as permissions to read and register the external memory and call logs. When we look at what the government apps are requesting, there are few which do not make these high-risk permissions.

The majority of the apps we analyzed use permissions related to the geolocation [4] of the user. However, it is not clear for everyone, at least from the user perspective, why this is necessary. The apps Metrô de São Paulo (Subway) and SP Serviços, which have this permission, do not use it in any of the functionalities accessible to the user [5], for example. Other apps like FGTS, Bolsa Família, EMTU use this permission to give information on closest agencies or lines, but all other functionalities continue to operate even if this permission is not granted [6]. Only four of the analyzed apps do not request this permission: Nota Fiscal Paulista, CNH Digital, CPTM Oficial and Meu Imposto de Renda.

Another ‘dangerous’ permission is the one of access to the device’s camera which is requested by two of these apps: Caixa and Nota Fiscal Paulista. The request seems to make sense for these apps, at least in principle, as both apps have functionalities related to the scanning of documents (like billets or receipts). Another permission requested by these two apps is to access the fingerprint sensor, considered as a medium risk by Lumen as it allows the substitution of the user’s fingerprint password.

Several apps [7] have the permission GET_ACCOUNTS, which allows the apps to access all accounts registered on the device: from social networks to other services. Lumen registered that the ANATEL app, using this permission, sent information from two accounts from the device to its servers, our Twitter account and the one used to access Microsoft’s cloud service, for instance, something that can be unexpected to users — and will be discussed on this series’ next post.

On the left: accounts registered on one of our devices used for this test. On the right: accounts sent by the ANATEL app and the electronic address to where this data was sent.

Another set of ‘dangerous’ (according to Lumen) permissions that is used very often by government apps are the ones related to the access to the external memory, like memory cards[8]. This allows the apps to read any file stored there. In general, this is made by apps that need to save and read different files. In case of the app Meu Imposto de Renda, for example, this is used to allow the user to reuse information from their previous Income Tax Return in their current one. However, it is not clear why this functionality is necessary for all apps we analyzed. The EMTU app has this permission and even when it is turned off, it is capable of exercising its functionalities without prejudice. The same happens with the apps SP Serviços and ANATEL Consumidor.

SP Serviços, for instance, fulfills all its functions even after all permissions that we were able to manage through Android were disabled. This shows that the app operates through a pattern with a higher level of privilege than necessary to fulfill its tasks, including permissions that can compromise the user’s privacy. As we said in the introduction of this post, this is a problem since it is not in accordance with the principle of least privilege.

Without assuming the developer’s bad-faith, it is possible to list some hypotheses as to why this requests happened for no apparent reason:

• i) indisposition: the request for several permissions allows the developed to work more freely, without restrictions getting in the way of tests and validations;
• ii) future purposes of the app: there are plans to add functionalities involving geolocation on the app and so the architecture of permissions is already in place for this future;
• iii) usage information: knowing who are the users in order to understand who they are and elaborate strategies from this.

However, these hypotheses do not mitigate the apparent lack of care from the public administration, which should always act in the pursuit of the public interest, strictly connected to the principle of legality, and minimizing the risks to citizens.

Another harmful request (according to Lumen) is called “READ_PHONE_STATE” which allows, as the name says, to access the ‘smartphone’s state’, including its telephone numbers, current network information, call status, and list of contacts. This permission is requested by the apps FGTS, Caixa, Bolsa Família, ANATEL Consumidor, SP Serviços and Meu Imposto de Renda.

This permission is among the broad kind ones that, as we have pointed out at the beginning of this post, can be used for specific purposes but can also potentially be used for much more. Information security specialists recommend for developers to favor specific permissions and not broad ones like this, precisely to reduce the risks to users. Google itself, on its good practices for Android app development page, recommends that developers only use essential permissions for the functioning of their apps, avoiding to use sensitive user information.[9]

In order to verify, in practice, what these government apps do with this permission, it would be necessary to analyze the apps source-code. However, the problem at this point is that none of the analyzed apps have their code available at https://softwarepublico.gov.br/, which was created to publicize programs developed with open-sources by the Brazilian government. As they are closed-source, they do not allow for an analysis of what is collected and used by the app.

In this scenario of codes being obscured, the analysis of these apps’ privacy policies are even more important, as they constitute the written public commitment of the provider with users — and are the topic of our next post.

______

[1] This behavior can be found on apps that use this execution on the background to indicate places of interest from the user’s location or to send ‘alerts’ and ‘notifications’, for instance.

[2] SALTZER, Jerome H. Protection and the Control of Information Sharing in Multics. Commun. ACM, 17(7), 388–402, 1974. Available at: https://doi.org/10.1145/361011.361067.

[3] On the topic, see RICHARDS, Neil; HARTZOG, Woodrow. Taking Trust Seriously in Privacy Law. Stanford Technology Law Review, vol. 19, p. 431-472, 2016.

[4] There are two permissions of this kind: to access approximate and precise locaitions.

[5] There can be functionalities that work independently from the user and were not assessed at this moment on the study. These functionalities are not visible to users and are usually not used for data transmissions and updates by the app. This happens for the verification of new messages in chat apps and email, for instance.

[6] The EMTU app works, notifies that it cannot find the geolocation but does not crash. The FGTS app works normally. The Bolsa Família app works in general but the functionalities after the login were not tested.

[7] Apps that request this permission: FGTS, Bolsa Família, ANATEL Consumidor, SP Serviços, EMTU SP and Meu Imposto de Renda.

[8] Apps that request this permission: FGTS, Caixa, Bolsa Família, Nota Fiscal Paulista, Meu INSS, ANATEL Consumidor, SP Serviços, EMTU SP, CPTM Oficial, SNE DENATRAN, Meu Imposto de Renda. The exceptions are CNH Digital and Metrô SP.

[9] Android good practices are available at https://developer.android.com/training/permissions/usage-notes. Accessed on May 17th 2018.

By Jacqueline de Souza Abreu (jacqueline@internetlab.org.br), Lucas Lago (lucas.lago@internetlab.org.br) and Heloisa Massaro (heloisa.massaro@internetlab.org.br).

Translation: Ana Luiza Araujo