- A Google começou recentemente a aplicar uma política de restrição ao sideloading de apps no Android, ampliando o debate sobre a autonomia digital dos usuários e a abertura do ecossistema móvel
- Em um projeto-piloto em Singapura, houve endurecimento das regras ao bloquear a instalação de apps recebidos via web, mensageiros e gerenciadores de arquivos que solicitem permissões sensíveis (como SMS e acessibilidade)
- Com a adoção da Play Integrity API, desenvolvedores podem restringir funções de apps instalados por sideloading, reforçando uma estrutura de distribuição fechada e centrada na Google Play Store
- Embora essas medidas possam contribuir para o reforço da segurança, surgem críticas de que elas enfraquecem a inovação e a concorrência, além de reduzir a abertura do Android
- A Purism apresenta PureOS e Librem 5 como alternativas de mobilidade com foco em código aberto e privacidade, garantindo a soberania dos dados do usuário e um ambiente livre para instalação de apps
Google implementa restrições ao sideloading no Android
- A Google começou recentemente a aplicar novas restrições a apps instalados por sideloading no Android, alegando questões de segurança
- A política piloto em Singapura foi introduzida em cooperação com uma agência de cibersegurança e funciona limitando, em especial, a instalação de apps que solicitam permissões sensíveis, como acesso a SMS ou serviços de acessibilidade, quando recebidos por navegadores, apps de mensagens ou gerenciadores de arquivos
- A medida tem como objetivo evitar crimes ligados a golpes e malware
Play Integrity API e dependência de loja de apps
- Ao introduzir a Play Integrity API, a Google permite que desenvolvedores de apps restrinjam algumas funcionalidades quando o app tiver sido instalado por sideloading
- Essas políticas pressionam os usuários a instalar apps apenas pelo caminho oficial da Google Play Store
- Embora, na superfície, a justificativa seja o reforço da segurança, na prática isso leva a um maior controle da Google sobre o ecossistema Android
- Com isso, voltam a surgir preocupações sobre autonomia digital, inovação e direitos dos usuários
Críticas e impacto
- Críticos apontam que, embora a política possa ajudar a bloquear apps maliciosos, ela também levanta questões sobre restrição à concorrência e redução da liberdade de escolha do usuário
- A abertura da plataforma e a liberdade de sideloading características do Android ficam enfraquecidas, levando o sistema a uma direção mais parecida com o ecossistema fechado do Apple iOS
- Há a possibilidade de que essa tendência resulte em prejuízo à inovação e monopólio na distribuição de apps
A alternativa da Purism: PureOS e Librem Phone
- A Purism apresenta uma solução focada em privacidade como resposta ao avanço da vigilância e do controle corporativo
- O PureOS é um sistema operacional Linux baseado em Debian, embarcado no Librem 5 e nos Liberty Phones, garantindo autonomia total ao usuário e soberania sobre seus dados
- Nesse ambiente, só há suporte para apps de segurança open source que não usam publicidade direcionada, mineração de dados, algoritmos viciantes nem manipulação comportamental
- Os usuários não dependem de lojas de apps corporativas nem de APIs invasivas, o que proporciona uma experiência de computação mais transparente e segura
Conclusão: a importância de alternativas abertas
- Enquanto a Google torna o ecossistema Android cada vez mais fechado, a Purism defende um ambiente de computação móvel ético, seguro e aberto
- Alternativas com foco em soberania do usuário e privacidade emergem como opções importantes para a indústria de tecnologia e os desenvolvedores
3 comentários
Na verdade, no caso do sideloading, bastaria adotar um "sistema de signatários confiáveis" e abri-lo para certificadoras terceiras como a DigiCert para que, no mínimo, fosse possível verificar se é um APK confiável. O problema é que o Google estruturou isso de um jeito que delega tudo à Play Store. Mas, se a pergunta é se a Google Play Store realmente bloqueia bem apps maliciosos, aí já não sei, e quanto aos apps que vão contra as políticas do Google Play...
O próprio texto parece ter uma intenção meio suspeita, mas é verdade que, no uso real, isso está ficando cada vez mais incômodo.
Pelo visto, nos aparelhos Galaxy já deixaram até impossível desativar funções como o bloqueio de apps suspeitos de serem maliciosos. Existem formas de contornar, mas estão adicionando cada vez mais esse tipo de restrição.
Para usuários mais casuais, pode até ser um recurso bom, já que quase não usam sideloading e isso pode impedir a execução de malware, mas não deveriam pelo menos permitir desligar isso?
Eu estava querendo que o Pixel fosse lançado oficialmente por aqui, mas se o Google também fizer algo parecido...
Comentários no Hacker News
Foi expressado que é um timing bem estranho para publicar um post de blog agora, levantando a dúvida se não seria um texto preparado há meses e só divulgado agora; foi compartilhado que esse programa piloto foi anunciado em Singapura há 1 ano e 4 meses, que vale apenas para Singapura e para apps que exigem permissões específicas (por exemplo,
RECEIVE_SMS,READ_SMS,BIND_NOTIFICATIONS, permissões de acessibilidade), e somente para apps baixados diretamente fora de lojas de aplicativos; também foi informado que instalar via F-Droid ouadbparece estar liberado, que é possível tentar contornar desativando o Play Protect, embora nem o próprio autor saiba se isso de fato funciona em Singapura, e que, de forma interessante, o Google impediu que o Play Protect fosse desligado durante uma chamada, o que foi elogiado como uma decisão sensata; foi citado ainda que, segundo a polícia de Singapura, essa abordagem não tem gerado efeitos práticos muito bons, com exemplos de vítimas sendo instruídas a desativar o Google Play Protect antes de instalar arquivos APK e até a instalar apps de VPN, permitindo que golpistas contornem as tecnologias de proteção dos bancos (https://police.gov.sg/media-room/news/…)Foi mencionada a existência de dados indicando que os singapurianos são especialmente vulneráveis a golpes; no ano passado, dezenas de milhares de pessoas foram prejudicadas e perderam, ao todo, 1,1 bilhão de dólares de Singapura, um aumento de 70% em relação ao ano anterior; também foi compartilhada a experiência de que, segundo estatísticas da Global Anti-Scam Alliance, o volume real provavelmente é maior do que o oficialmente reportado; como explicação para Singapura virar alvo, foram citados riqueza, digitalização e uma cultura de conformidade regulatória (https://archive.is/fCmW1)
Foi opinado que não está claro por que o post do blog da Purism saiu agora, e que isso parece ser apenas FUD de marketing; foram mencionados diretamente o Librem 5 e os Liberty Phones baseados em PureOS, questionando-se inclusive se eles conseguem rodar APKs; acrescentou-se que só o Sailfish oferece esse tipo de funcionalidade, de forma excepcional por causa de questões de licenciamento; reconhece-se que a Purism investe bastante no desenvolvimento de Linux touch, como o Phosh, mas enfatiza-se que o ambiente Linux para toque ainda é muito precário; a leitura geral é que, mesmo sem ser um caso que os afete diretamente, eles tentam retratar alternativas mainstream de forma negativa para usar isso no marketing dos próprios produtos
Foi levantado que importa distinguir o momento antes e depois de o Google receber uma decisão desfavorável no processo relacionado à App Store; também se enfatizou como é difícil encontrar um equilíbrio entre permitir liberdade ao usuário e ainda protegê-lo; mencionou-se o fenômeno de que, quando usuários se acostumam com alertas de segurança, acabam ignorando-os; argumentou-se ainda que nem a Play Store pode ser considerada totalmente segura e que até dados públicos de GPS de usuários Android mostrariam comportamento malicioso em apps oficiais; no fim, considerou-se que uma alternativa seria um terceiro inteligente e confiável ter privilégios de administrador do dispositivo para proteger usuários mais vulneráveis
Houve a opinião de que o texto parece mais uma propaganda da Purism do que algo com conteúdo substancial
Assim que se percebeu que era publicidade, julgou-se que todo o conteúdo perdia o valor, e foi pedido um link melhor
Pelo número de upvotes, foi sugerido que muita gente está preocupada com a direção do Android e interessada em alternativas
Foi levantada a dúvida se esse assunto não era, na verdade, de 2024 (https://techcrunch.com/2024/02/…)
Sobre o programa piloto introduzido primeiro em Singapura, foi explicado que o bloqueio só se aplica a apps que pedem certas permissões específicas (SMS, acessibilidade) quando instalados por navegador, mensageiro ou gerenciador de arquivos; como há várias condições, foi defendido que usuários avançados ainda conseguiriam instalar os apps que quiserem; a análise é que a medida busca dificultar para o usuário médio o sideload de apps perigosos com permissões de SMS/acessibilidade, e foi destacado que isso está sendo feito em cooperação com a Cyber Security Agency de Singapura para prevenir golpes e malware, o que explicaria a limitação ao país
Foi apontado que, na prática, esse tipo de restrição pode funcionar de forma anticompetitiva no mercado de massa: uma minoria tecnicamente preparada ainda instala o que quiser, mas a maioria fica confinada ao “jardim murado” controlado pelo Google; também foi destacado que Google e Apple usam até linguagem alarmista sobre apps de terceiros para criar barreiras psicológicas, e que esse tipo de “controle mental” deveria ser eliminado por regulação
Enfatizou-se que “limitado a Singapura” não é um motivo tão tranquilizador assim, e que navegador/gerenciador de arquivos são meios comuns de movimentar arquivos, então essas condições não inspiram muita confiança
Foi argumentado que, enquanto não houver bloqueio até de ADB, a expressão “bloqueio de sideloading” não é totalmente precisa; no fim, manter o equilíbrio entre proteger usuários contra malware e garantir a liberdade de instalar os apps desejados continua sendo essencial
Foi compartilhada a lembrança de já ter sido exigida integração com o SingPass (o sistema nacional de identidade digital de Singapura) ao trabalhar com clientes de lá; hoje o autor já não atende mais esses clientes, mas a integração ainda deve estar em algum lugar no codebase
Defendeu-se que novas regiões podem ser adicionadas a qualquer momento, então não faz sentido relaxar por enquanto ser só Singapura; em vez disso, sugeriu-se que seria melhor o Google avançar em técnicas de conceder “permissões falsas” aos apps, caso contrário criminosos sempre vão encontrar outros caminhos para contornar o sistema
Mencionando a ideia que apareceu nos comentários de que “o problema de sideloading se resolve instalando GrapheneOS”, foi apontado que essa resposta é muito distante da realidade da maioria dos usuários comuns; lembrou-se que usuários do HN conseguem até lidar com depuração de hardware, mas pessoas normais não sabem mexer nesse tipo de configuração em nível de sistema
Foi compartilhada a experiência de estranhamento em fóruns Linux, onde respostas presumiam conforto com CLI complexa; observou-se que, para iniciantes que querem soluções simples e diretas, o viés de especialistas pode acabar atrapalhando a adoção e a disseminação
Diagnosticou-se que a maioria das pessoas não tem boa noção do que é uma experiência “média”, e que em comunidades de especialistas essa distorção é ainda maior, gerando opiniões bem distantes da realidade da maioria dos usuários
Foi analisado que pessoas comuns, em geral, não fazem sideload; tendem a instalar um app necessário uma vez e depois continuar usando repetidamente os mesmos apps
Foi apontado que usuários comuns não conseguem distinguir a legitimidade de apps sideloaded que pedem permissões de SMS ou acessibilidade; por isso, enfatizou-se que o objetivo central do bloqueio é evitar o uso indevido dessas funções por pessoas comuns
Manifestou-se preocupação de que, com o Google adicionando tecnologias de DRM e APIs, até instalar GrapheneOS deixará de ser uma alternativa viável, e que isso levaria a um cenário em que só sair completamente do ecossistema Android permitiria usar um sistema operacional alternativo
O autor disse que costumava ter a postura de “o telefone é meu, então quero poder fazer o que eu quiser”, mas ficou chocado ao perceber que, no caso de drones DJI e Air Units, o usuário é empurrado à força para instalar apps por sideload; explicou-se que o motivo de a DJI não conseguir colocar o app na Play Store seria o fato de o app poder modificar o próprio código; alertou-se que, em um contexto de conflito político, isso abriria o risco de malware patrocinado por Estado assumir o controle do drone; também foi enfatizado que milhões de pessoas instalaram esses apps sem entender direito o problema
Defendeu-se que a solução para esse problema não é o Google fingir que faz varredura de malware, mas sim introduzir controles mais fortes sobre as permissões e capacidades reais do app da DJI; a visão apresentada é que a motivação principal do Google não seria segurança, e sim ampliar seu poder de controle
Nesse contexto, afirmou-se acreditar que a liberdade de “fazer o que eu quiser” deve se aplicar também ao software; a ideia de Richard Stallman, apresentada em 1988, da “liberdade de receber o código-fonte e modificá-lo”, foi considerada ainda atual; lamentou-se que a realidade esteja caminhando no sentido oposto, com o software controlando o usuário; e argumentou-se que, quando governos nacionais passam a dominar o código dos softwares, o risco vai além da violação dos direitos do consumidor
Foi analisado que governos de vários países já inserem esse tipo de função por meio dos OEMs, e que bloquear sideloading só impede que hackers consigam desativar esse malware embutido
Argumentou-se que o fato de um app modificar a si mesmo não significa tanto assim, já que seria possível embutir um motor V8 no app e alterar código à vontade; ainda assim, apontou-se a ironia de o Google não tratar essa abordagem como problema
Também se questionou por que o comentário original, que demonstrava cautela em relação aos apps de drones da DJI, recebeu downvotes; como exemplo, foram citados casos recentes de supostos kill switches encontrados em painéis solares chineses, sustentando a tese de que empresas chinesas próximas ao governo poderiam embutir funções suspeitas em hardware e software (https://reuters.com/sustainability/climate-energy/…, https://rickscott.senate.gov/2025/6/…)
Foi apontado que instalar GrapheneOS pode até resolver a limitação ao sideloading, mas que hoje o Google vem intensificando o uso da Play Integrity API para restringir funções dos apps apenas a instalações via Play Store; destacou-se que, mesmo usando a Play Store em GrapheneOS com bootloader travado, o Google bloqueia o uso de APIs de atestação de hardware, fazendo com que apps bancários, Google Wallet e outros recursos deixem de funcionar; criticou-se o fato de o Google tolerar vendors ruins que atrasam atualizações de segurança, mas excluir um sistema aberto com excelente segurança; também se argumentou que a parceria com a Cyber Security Agency de Singapura serve mais como justificativa política do que outra coisa; por fim, perguntou-se por que apps como Facebook e Instagram não entram no mesmo tipo de bloqueio (https://localmess.github.io, https://grapheneos.social/@GrapheneOS/112878070618462132)
Foi opinado que o Google tolera práticas de segurança frouxas de terceiros, então seu objetivo real não seria segurança, mas controle em si
Apontou-se que o maior problema do GrapheneOS é o suporte a pouquíssimos dispositivos, e que seria necessária uma alternativa que não dependesse de hardware específico e ainda mantivesse algum nível de segurança
Foi observado que a Android Key Attestation API é suportada também no GrapheneOS e pode ser integrada por desenvolvedores (https://grapheneos.org/articles/attestation-compatibility-guide)
Como resposta à tese de que instalar GrapheneOS resolve o problema, foi dito que uma resposta direta a isso já havia sido apresentada, deixando um link de referência (https://news.ycombinator.com/item?id=32496220)
Foi levantada a preocupação de que essa medida causaria um impacto grave na comunidade de pessoas com deficiência visual; em países onde Android é popular e iPhone é caro, o leitor de tela Commentary (Jieshuo) seria uma alternativa melhor que o TalkBack, mas não está na Play Store por ser um app chinês de desenvolvedor independente; destacou-se que apps desse tipo exigem permissões muito amplas para ler a tela inteira e controlar a interface do sistema, e que, se o acesso a apps sensíveis for bloqueado, a própria finalidade do leitor de tela perde o sentido; criticou-se ainda a possível postura de funcionários do Google de tratar isso como irrelevante com base em estatísticas do WebAIM, já que essa amostra é majoritariamente de usuários anglófonos de alta renda e não representa o uso global real (https://webaim.org/projects/screenreadersurvey10/)
Houve quem considerasse essa intenção de design razoável e de bom senso; embora ainda seja possível instalar malware por ADB, a barreira de entrada sobe e isso funciona como um redutor de velocidade para o usuário comum; também se afirmou não conhecer nenhum app típico de sideloading que esteja sendo injustamente discriminado
Por fim, explicou-se por que é essencial bloquear pedidos de permissões de dados pessoais como SMS e acessibilidade: só com permissão de SMS já dá para roubar OTPs e informações de login de praticamente qualquer serviço, e com acessibilidade é possível manipular funções críticas de apps bancários e outros; acrescentou-se que, em Singapura, o comércio de dados de identidade é tão grave que há avisos do tipo “se um desconhecido quiser comprar seu número de telefone ou outros dados de identidade, isso pode dar 5 anos de prisão”; o mesmo valeria para contas bancárias e cartões de crédito; concluiu-se que, como dados de identidade usados em crimes ficam vinculados à pessoa, cooperar com isso gera punições mais severas