Analisamos as permissões solicitadas pelos apps do governo, para verificar quais são solicitadas e se elas possuem relação com as funcionalidades dos apps. Não viu? Leia aqui o post de apresentação dessa série!

Já parou para pensar no que os apps que você instala no seu celular estão acessando? Uma estratégia de aplicativos para evitar que tenhamos que fornecer muitas informações é o uso de sensores e dados já cadastrados, armazenados e gerados em nossos dispositivos (celulares, tablets, computadores). Para acessá-los, o sistema operacional precisa dar certas permissões ao aplicativo.

Algumas dessas permissões frequentemente requeridas são de acesso a:

► lista de contatos (e todas as informações lá armazenadas);
► registros de ligações efetuadas e recebidas;
► dados de uso da internet;
► informações contidas em calendários;
► fotos (e acesso à própria câmera em si);
► dados sobre a localização do dispositivo;
► identificadores únicos de dispositivos;
► informação sobre como a usuária ou o usuário usa o app;
► hardware de identificação de impressão digital;

Quem define se o sistema operacional vai dar essa autorização é você, que tem a expectativa natural de que aquilo vá servir para o bom e conveniente funcionamento do app. A partir daí, a permissão é válida tanto durante execução da aplicação em primeiro plano (ou seja, enquanto estamos utilizando ativamente esse aplicativo), quanto em segundo plano (quando o aplicativo está fechado, mas ainda assim executando rotinas internas, sobre as quais nem tomamos conhecimento).[1]

Nesse contexto, um dos princípios básicos da segurança da informação – o princípio do menor privilégio – preceitua que todo programa deve operar utilizando o mínimo de privilégios necessários para realizar seu trabalho. [2] No caso de aplicativos, isso significa que eles devem usar o mínimo de permissões possíveis para que possam operar. Isso garante que eles tenham maior estabilidade e sejam menos vulneráveis. Quando esse princípio não é observado, os aplicativos expõem os usuários e as usuárias a mais riscos do que necessário.

Outro princípio importante é o da transparência: saber o que os apps estão fazendo com as permissões. Isso porque, depois de ganhar permissão, na teoria e do ponto de vista técnico, o app pode fazer com ela o que bem entender. Isso é especialmente sensível para algumas permissões de tipo abrangente, que são concedidas para uma ou outra funcionalidade específica do aplicativo (como enviar SMS com denúncias), mas são potencialmente capazes de ser usadas para muito mais (como visualizar o seu histórico de chamadas, por exemplo).

Aí aparece o elemento de confiança fundamental entre usuários e o provedor da aplicação, que pode ser mais um fator de risco: a permissão pode ser geral do ponto de vista técnico, mas esperamos que seja utilizada apenas dentro das nossas expectativas legítimas. [3] Se a confiança for quebrada, o usuária ou a usuária são expostos a riscos e abusos. Vamos voltar a esse ponto nos próximos posts desse ESPECIAL ao falar das políticas de privacidade e de consentimento. Agora, vamos entender melhor com o que estamos lidando.

Analisamos as permissões solicitadas pelos apps do governo que fazem parte deste estudo, para verificar quais são solicitadas e se elas possuem relação com as funcionalidades dos apps.

Para isso, utilizamos o aplicativo Lumen Privacy Monitor, desenvolvido pelo projeto Haystack da Universidade de Berkeley, que, entre outras finalidades, levanta as permissões envolvidas nos aplicativos instalados e as classifica em relação ao risco: “baixo, médio e perigosa”. As permissões consideradas de alto risco são aquelas que envolvem dados e recursos que podem comprometer a privacidade do usuário (como acesso a câmera, localização ou contas utilizadas no aparelho) ou até mesmo afetar a operação do aparelho (possível com uso indevido da memória externa, por exemplo).

Nossos achados

O Lumen classifica como perigosas as permissões de acesso à geolocalização do aparelho, à câmera e às contas cadastradas no dispositivo, e também as permissões de leitura e registro da memória externa e de realização de chamadas. Quando olhamos o que os apps do governo estão pedindo, são poucos os que não fazem as solicitações mais arriscadas.

A maior parte dos aplicativos analisados utilizam permissões relacionadas à geolocalização [4] do usuário ou usuária. No entanto, não fica claro para todos, pelo menos da perspectiva do usuário, para quê isso seria necessário. Os aplicativos do Metrô de São Paulo e SP Serviços, que possuem essa permissão, não utilizam ela em nenhuma das funcionalidades acessíveis pelo usuário do aplicativo [5], por exemplo. Já outros aplicativos como, por exemplo, FGTS, Bolsa Família, EMTU utilizam essa permissão para fornecer informações como agências ou linhas mais próximas do usuário, mas todas as outras funcionalidades continuam operando mesmo sem que essa permissão seja concedida [6]. Apenas quatro dos aplicativos analisados não solicitam essas permissões: Nota Fiscal Paulista, CNH Digital, CPTM Oficial e Meu Imposto de Renda.

Outra permissão ‘perigosa’, a de acesso à câmera do dispositivo, é solicitada por apenas dois apps analisados: o da Caixa e o da Nota Fiscal Paulista. O pedido parece fazer sentido para esses apps, pelo menos em princípio, porque ambos aplicativos possuem funcionalidades relacionadas com a leitura de documentos físicos (sejam boletos ou notas fiscais). Outra permissão solicitada por estes dois aplicativos é o sensor de impressão digital, considerada de médio risco pelo Lumen, por permitirem substituir a senha pela impressão digital do usuário.

Diversos aplicativos[7] analisados possuem a permissão GET_ACCOUNTS que permite que os aplicativos tenham acesso a todas as contas cadastradas no dispositivo: sejam de redes sociais ou de outros serviços. O Lumen registrou que o aplicativo da ANATEL, explorando essa permissão, enviou para os seus servidores as informações de duas contas registradas no celular que utilizamos para o estudo, a do Twitter e a de acesso à nuvem da Microsoft, por exemplo, algo que pode ser inesperado a usuários – e será discutido no próximo post dessa série.

Um outro conjunto de permissões “perigosas” (segundo o Lumen) bastante utilizado pelos aplicativos do governo analisados são as referentes ao acesso à memória externa, como cartões de memória [8]. Isso permite que os aplicativos leiam qualquer arquivo que esteja ali armazenado. Isso em geral é feito por aplicativos que precisam salvar e ler diferentes arquivos. No caso do app do Meu Imposto de Renda, por exemplo, isso é feito para permitir que o usuário reaproveite informações já inseridas na sua antiga declaração na elaboração da atual. Outra vez, entretanto, não fica claro porque essa funcionalidade é necessária para utilização de todos os aplicativos analisados. O aplicativo do EMTU possui essa permissão, mas mesmo com ela desativada, ele é capaz de executar suas funcionalidades sem qualquer alteração. O mesmo acontece com o aplicativo SP Serviços e o ANATEL Consumidor.

O aplicativo SP Serviços, por exemplo, realiza todas as funções a que ele se propõe mesmo após desativarmos todas as permissões que o Android permite gerenciar. Isso mostra que o aplicativo opera por padrão com um nível de privilégio maior que o necessário para realizar suas tarefas, incluindo permissões que podem comprometer a privacidade do usuário. Como falamos na introdução desse post, isso é problemático, pois está em desacordo com o princípio do menor privilégio.

Sem assumir má-fé do desenvolvedor do app, é possível elencar as seguintes hipóteses para essas solicitações de permissões sem motivo evidente:

• i) indisposição: pedir várias permissões permite ao desenvolvedor trabalhar com mais liberdade, sem muitas restrições atrapalhando testes e validações;
• ii) objetivos futuros do aplicativo: existem objetivos de adicionar funcionalidades com geolocalização, e a arquitetura de permissões já está preparada para esse futuro;
• iii) informações de uso: conhecer quem são usuários e usuárias para entender quem são e elaborar estratégias em cima disso.

No entanto, essas hipóteses não mitigam a aparente falta de cuidado do poder público, que deve atuar sempre na persecução do interesse público, estritamente vinculado ao princípio da legalidade, e minimizando riscos a cidadãos e cidadãs.

Outra permissão perigosa (segundo o Lumen) presente nos  apps analisados é a “READ_PHONE_STATE” que permite, como o nome diz, acesso ao ‘estado do celular’, incluindo número de telefone do dispositivo, informações de rede atuais, status de chamadas, e lista de contatos registrados no aparelho. Tal permissão é solicitada pelos apps FGTS, Caixa, Bolsa Família, ANATEL Consumidor, SP Serviços e Meu Imposto de Renda.

Essa permissão está entre aquelas de tipo bastante abrangente, que, como apontamos na introdução desse post, podem ser usadas para fins específicos, mas podem potencialmente ser utilizadas para muito mais. Especialistas em segurança da informação recomendam que desenvolvedores prefiram permissões específicas e não de tipo abrangente como essa, justamente para diminuir os riscos a usuários e usuárias. Aliás, a própria Google, em sua página de boas práticas para desenvolvimento de aplicativos para Android, recomenda que desenvolvedores utilizem somente permissões essenciais para o funcionamento do seu aplicativo, evitando utilizar informações sensíveis de usuários e usuárias.[9]

Para verificarmos, na prática, o que esses aplicativos do governo fazem com essa permissão seria necessário analisar o código-fonte do aplicativo. O problema, todavia, neste ponto, é que nenhum dos aplicativos analisados possuem seu código disponível no portal https://softwarepublico.gov.br/, que foi criado para dar publicidade a programas desenvolvidos com código-aberto pelo governo brasileiro. Por estarem fechados, não permitem uma análise do que é coletado e utilizado pelo aplicativo.

Nesse cenário de obscuridade do código, ficam ainda mais importantes as análises das políticas de privacidade dos apps, que constituem o compromisso público escrito do provedor com usuários e usuárias e que são tema do próximo post.

______

[1] Esse comportamento pode ser encontrado em aplicativos que utilizam essa execução em segundo plano para indicar lugares de interesse a partir da localização do usuário ou para enviar “alertas” e “notificações”, por exemplo.

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

[3] Sobre o tema, ver RICHARDS, Neil; HARTZOG, Woodrow. Taking Trust Seriously in Privacy Law. Stanford Technology Law Review, vol. 19, p. 431-472, 2016.

[4] Existem duas permissões desse tipo: para acessar localização precisa e aproximada.

[5] Podem existir funcionalidades que funcionam de forma independente do usuário ou da usuária e não foram avaliadas nesse momento nesse estudo. Essas funcionalidades não são visíveis a usuários e usuárias e normalmente são utilizadas para transmissão de dados de uso e atualizações de informações do próprio aplicativo. Isso acontece para a verificação de novas mensagens em aplicativos de chat e email, por exemplo.

[6] O aplicativo do EMTU funciona, avisa que o app não consegue encontrar a geolocalização, mas não dá erro. O aplicativo do FGTS funciona normalmente. O aplicativo do Bolsa Família também funciona no geral, mas não foram testadas as funcionalidades pós-login.

[7] Os aplicativos que pedem essa permissão: FGTS, Bolsa Família, ANATEL Consumidor, SP Serviços, EMTU SP e Meu Imposto de Renda.

[8] Os aplicativos que pedem essa permissão são: 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. As exceções são CNH Digital e Metrô SP.

[9] A documentação sobre boas práticas do Android está disponível em: https://developer.android.com/training/permissions/usage-notes. Acesso em 17 de maio de 2018.

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