O sistema de permissões não é uma lista de caixas para assinalar: é uma arquitetura de isolamento. Perceber como funcionam as permissões das aplicações explica ao mesmo tempo porque é que os telemóveis são, neste ponto, mais protegidos do que os computadores tradicionais, e onde ficam os pontos fracos.
Este artigo desce ao mecanismo por trás da recomendação verificar as permissões das aplicações: o que o sistema controla, o que deixa de controlar depois de dizeres que sim, e porque é que as opções intermédias existem.
Não é preciso ser técnico para o seguir. Basta a imagem de uma casa com muitas divisões fechadas, e de um porteiro que decide quem passa de uma para a outra.
Nota de variante: este texto está em português europeu. Onde se lê aplicação, no Brasil diz-se aplicativo; telemóvel é celular, ecrã é tela e definições são configurações.
O princípio: cada aplicação num quarto fechado
Nos sistemas móveis, cada aplicação funciona num espaço isolado das outras. Tem a sua própria área de armazenamento, e não consegue ler os dados das outras aplicações.
É uma diferença de fundo em relação aos computadores tradicionais, onde um programa pode, em regra, aceder a todos os ficheiros de quem o usa.
Deste isolamento resultam duas consequências:
Tudo o que está fora do quarto exige uma permissão. Câmara, microfone, contactos, localização, ficheiros partilhados: são recursos do sistema, não da aplicação.
O sistema é o único intermediário. A aplicação não acede diretamente ao hardware: pede ao sistema operativo, que verifica a permissão e responde. É nesse ponto que as tuas definições produzem efeito.
Os níveis de permissão
Não funcionam todas da mesma maneira.
| Nível | Como é concedida | Exemplos |
|---|---|---|
| Automática | Declarada pela aplicação, concedida sem perguntar | Acesso à internet, vibração |
| A pedido | Janela de diálogo no momento da utilização | Câmara, microfone, contactos, localização |
| Especial | Obriga a ir às definições, com avisos explícitos | Acessibilidade, sobreposição, administração |
| De sistema | Reservada ao fabricante | Funções internas |
A terceira linha foi pensada de propósito para ser incómoda: o sistema não mostra uma janela com «Permitir», manda a pessoa para um ecrã das definições, com um aviso que explica o que está em causa.
Esse incómodo é uma medida de segurança, e é a razão por que as técnicas que procuram obter a acessibilidade têm de convencer a pessoa a dar vários passos seguidos.
A evolução: de «tudo no início» a «só quando faz falta»
Conta-se depressa, e explica porque é que os dispositivos antigos estão numa situação pior.
Antes: as permissões eram concedidas todas de uma vez, no momento da instalação. Ou aceitavas a lista completa, ou não instalavas. Nenhuma escolha parcial, nenhuma revogação.
Depois: o pedido passou a ser contextual — no momento em que a aplicação usa a função — e revogável a qualquer altura.
Hoje: juntaram-se os meios-termos.
| Novidade | O que permite |
|---|---|
| Só durante a utilização | Acesso limitado à aplicação que está aberta |
| Só desta vez | Acesso válido para uma sessão |
| Elementos selecionados | Só as fotografias ou os contactos que escolhes |
| Precisão reduzida | Uma zona em vez de um ponto |
| Remoção automática | As permissões caducam se a aplicação não for usada |
| Indicador de utilização | Um sinal visível quando o recurso está a ser usado |
As duas últimas são as mais interessantes porque não exigem nenhuma decisão de quem usa o telemóvel: fazem manutenção e informam sozinhas.
O que acontece quando revogas uma permissão
Uma pergunta prática, com uma resposta tranquilizadora.
A aplicação não é avisada de antemão. Descobre a revogação quando tenta usar o recurso e recebe uma recusa.
A aplicação não se estraga. Foi feita para lidar com a recusa: mostra uma mensagem ou desativa uma função. As lojas exigem expressamente que uma aplicação continue utilizável quando é negada uma permissão não essencial.
O efeito é imediato. Não é preciso reiniciar nem desinstalar.
É reversível. Voltar a conceder leva dois toques.
Os dados já obtidos ficam onde estavam. A revogação fecha o acesso futuro, não recupera o passado: é por isso que a decisão inicial conta mais do que a correção.
É também por isso que a revisão das permissões tem um risco mínimo: na pior das hipóteses, uma função deixa de funcionar, dás por isso logo e voltas a conceder. O procedimento completo, ecrã a ecrã, está em rever as permissões concedidas.
Os controlos antes da publicação
Uma peça do quadro que explica porque é que instalar a partir da loja oficial faz diferença.
Antes de ser publicada, uma aplicação passa por várias verificações:
Controlos automáticos. Análise do código à procura de comportamentos conhecidos como nocivos, verificação das bibliotecas incluídas, comparação com registos de software problemático.
Controlos de coerência das permissões. Algumas permissões exigem uma justificação explícita do programador, e podem ser recusadas se a função declarada não as justificar.
Verificações manuais por amostragem, mais frequentes para as aplicações que pedem permissões sensíveis.
Identificação do programador, que responde com uma identidade verificada.
Vigilância depois da publicação, com a possibilidade de retirar uma aplicação e, nalguns casos, de a desinstalar dos dispositivos.
O que estes controlos conseguem fazer: apanhar software abertamente nocivo, antes e depois da publicação. É a principal razão por que instalar a partir da loja oficial reduz muito o risco.
O que não conseguem fazer: julgar se uma recolha declarada e permitida é proporcionada. Essa avaliação não se delega, porque depende daquilo que cada pessoa está disposta a trocar — e é exatamente o espaço que esta recomendação ocupa.
O que o sistema não consegue controlar
É a parte mais importante deste artigo, porque delimita aquilo que a arquitetura protege.
O que a aplicação faz com os dados que obteve legitimamente. Se concedes o acesso aos contactos, o sistema não sabe nem controla se esses contactos são enviados para um servidor. A permissão governa o acesso, não o uso posterior. É por isso que o remédio está a montante: decidir se concedes, porque depois o sistema já não intervém.
O que a aplicação transmite. A permissão de rede é automática e universal. Nenhuma aplicação tem de pedir autorização para comunicar.
O conteúdo das declarações de privacidade. As lojas exigem declarações sobre os dados recolhidos, e há controlos, mas são autodeclarações: o sistema não as verifica uma a uma.
A mudança de dono. Uma aplicação pode ser vendida, e quem a compra herda as permissões já concedidas por milhões de pessoas. É um caso documentado, e diz respeito sobretudo às extensões do browser.
Porque é que as extensões do browser são diferentes
Merecem um parágrafo próprio, porque escapam a esta arquitetura.
Uma extensão do browser não funciona num quarto isolado: funciona dentro do browser, e o browser é a aplicação que vê tudo o que fazes online.
A permissão típica de uma extensão — «ler e alterar os dados nos sites que visitas» — é muito mais ampla do que qualquer permissão de uma aplicação móvel. Abrange os sites onde escreves as tuas credenciais.
Os browsers introduziram limites — permissões concedidas a cada site em separado, ativação só a pedido —, mas continuam a ser o sítio onde se concede mais com menos consciência.
O caso dos perfis separados
Uma função útil e pouco usada: muitos sistemas permitem ter um perfil de trabalho separado do pessoal no mesmo dispositivo.
As duas áreas estão isoladas: as aplicações de uma não veem os dados da outra, as permissões são independentes e os contactos ficam distintos. O João, que usa o mesmo telemóvel para a vida pessoal e para o escritório em Lisboa, tem no perfil de trabalho apenas o correio, o calendário e a aplicação de reuniões da empresa — e os jogos dos filhos nunca chegam aos contactos dos clientes.
É a solução estrutural para o problema do telemóvel pessoal usado para trabalhar, melhor do que qualquer cuidado com permissões isoladas, porque não depende de te lembrares.
As bibliotecas de terceiros: a peça invisível
Um aspeto técnico pouco conhecido que explica porque é que até as aplicações honestas recolhem mais do que parece.
Nenhuma aplicação é escrita inteiramente de raiz. Cada programador inclui bibliotecas de terceiros para funções comuns: publicidade, estatísticas de utilização, relatórios de erros, mapas, pagamentos, início de sessão com contas já existentes.
Cada biblioteca incluída funciona dentro da aplicação e com as permissões dela.
| Tipo de biblioteca | O que pode ver |
|---|---|
| Publicidade | Identificadores, localização se concedida, interesses |
| Estatísticas de utilização | Como usas a aplicação, quando, durante quanto tempo |
| Relatórios de erros | Informação sobre o dispositivo e o seu estado |
| Mapas | A localização, se concedida |
| Início de sessão com outra conta | A identidade com que entras |
O ponto relevante: uma só aplicação pode incluir uma dezena delas, e cada uma transmite a uma entidade diferente. Muitas vezes nem o próprio programador tem uma visão completa do que cada uma faz.
Isto explica duas coisas. Porque é que a declaração sobre os dados é muitas vezes ampla: não é necessariamente má-fé, é a soma do que as componentes incluídas recolhem. Porque é que uma aplicação gratuita recolhe mais do que uma paga: a primeira inclui bibliotecas publicitárias, a segunda muitas vezes não.
E sugere uma escolha prática: quando existe uma versão paga de uma aplicação que usas muito, muitas vezes não estás a comprar funções — estás a comprar a ausência dessas bibliotecas.
Como funcionam as permissões das aplicações à vista de todos
Uma evolução recente e pouco conhecida, que mudou aquilo que se pode verificar.
O indicador em tempo real. Um ponto ou um ícone aparece quando o microfone ou a câmara estão em uso. Fica visível por cima de qualquer aplicação e é desenhado pelo próprio sistema, pelo que uma aplicação comum não tem forma de o esconder.
O relatório histórico. Um ecrã que enumera que aplicações usaram que permissões, quando e quantas vezes, nas últimas horas ou dias.
As notificações de resumo. Um aviso periódico que assinala o uso de permissões sensíveis por aplicações em segundo plano.
As etiquetas na loja. A declaração obrigatória sobre os dados que uma aplicação recolhe e com quem os partilha, visível antes da instalação.
A indicação da origem. Alguns sistemas assinalam quando um conteúdo ou uma aplicação vem de uma fonte diferente da loja oficial.
Juntas, estas funções deslocaram o problema: até há poucos anos não havia maneira de saber o que uma aplicação fazia; hoje há, e está a dois toques. O que falta já não é a informação. É o momento em que alguém olha para ela — e esse nenhum sistema operativo consegue criar no lugar de quem usa o telemóvel.
Ligação ao Framework Cyber Welfare
Este conteúdo trabalha sobretudo a compreensão do mecanismo: quem percebe onde o sistema protege e onde deixa de proteger sabe em que momento a decisão tem de ser sua.
| Pilar | Contributo deste conteúdo |
|---|---|
| Competências | Perceber os níveis de permissão e o que muda entre eles |
| Consciência | Saber que o sistema governa o acesso, e não o uso posterior |
| Comportamento Seguro | Decidir a montante, porque depois o sistema já não intervém |
Níveis de maturidade digital.
- FL1 – Básico. Para ti, as permissões são janelas que aparecem e se fecham com «Permitir».
- FL2 – Inicial. Sabes que as permissões se revogam nas definições e que a revogação não estraga nada.
- FL3 – Autónomo. Percebes a diferença entre permissões a pedido e especiais, e que o sistema não controla o uso dos dados já obtidos.
- FL4 – Hábil. Usas perfis separados, opções intermédias e o relatório de privacidade como ferramentas de rotina.
- FL5 – Especialista-Guia. Explicas a outras pessoas porque é que a decisão a montante conta mais do que qualquer correção.
Nível de referência: FL3 – Autónomo.
O que podes verificar hoje
Lista breve
- ☐ Sei em que parte das definições estão as permissões especiais
- ☐ A remoção automática das permissões está ativa
- ☐ Já vi o indicador de microfone e câmara, e sei o que significa
- ☐ Os dados de trabalho estão num perfil separado, se o sistema o permite
- ☐ Revoguei pelo menos uma permissão e confirmei que a aplicação continua a funcionar
Para situar o teu ponto de partida com mais rigor, podes fazer a Autoavaliação de Resiliência Digital.
Resumo
- Cada aplicação está isolada: tudo o que está fora exige uma permissão.
- As permissões especiais são deliberadamente incómodas: é uma medida de segurança.
- O sistema controla o acesso, não o uso dos dados já obtidos.
- As extensões do browser têm permissões muito mais amplas do que as aplicações móveis.
Perceber como funcionam as permissões das aplicações é, no fundo, perceber porque é que o momento do pedido pesa tanto.
Ação concreta para hoje. Revoga uma permissão a uma aplicação que achas que não precisa dela, e abre a aplicação. Na quase totalidade dos casos não acontece nada — e é a melhor maneira de te convenceres de que a revisão não custa.
Conteúdos relacionados
- verificar as permissões das aplicações — a recomendação de onde nasce este aprofundamento, e a referência geral sobre as permissões das aplicações
- rever as permissões concedidas — onde intervir, na prática
- impacto de permissões excessivas — o que cada nível permite
- abuso das permissões das aplicações — o que explora os limites desta arquitetura
- indicadores de compromissão — a entrada de glossário sobre os sinais de um dispositivo afetado
- instalar aplicações apenas das lojas oficiais — a recomendação sobre a origem das aplicações, o primeiro filtro antes de qualquer pedido de permissão
Dá o primeiro passo: o Programa «Protege a Tua Privacidade Digital» acompanha-te gratuitamente, uma recomendação de cada vez.
