Veja como as novas regras de verificação de aplicativos do Android funcionarão realmente

Em agosto, o Google fez um anúncio que chocou os entusiastas do Android e os defensores da privacidade: a partir do próximo ano, o Android bloqueará a instalação de aplicativos a partir de desenvolvedores não verificados. Isso se aplica não apenas a aplicativos na Play Store, mas também a aplicativos distribuídos fora dela, provocando uma preocupação de que o Google deseja matar a carga lateral. Após algumas semanas de silêncio, o Google finalmente abordou essas preocupações, insistindo que a carga lateral chegou para ficar. A empresa também compartilhou novos detalhes sobre como seus requisitos de verificação de desenvolvedores serão aplicados, incluindo que, em alguns casos, o Android exigirá uma conexão de rede ativa para os aplicativos de margem.

No mês passado, vimos evidências no Android SDK sugerindo que a verificação do desenvolvedor poderia falhar quando uma conexão de rede não estiver disponível. Não foi possível confirmar esse comportamento na época, já que os requisitos de verificação do desenvolvedor do Android ainda não haviam entrado em vigor. Nesta semana, no entanto, o Google confirmou que esse será o caso. Juntamente com o post de seu blog, declarando que “o mar é fundamental para o Android”, o Google também publicou um vídeo explicando o raciocínio por trás dos requisitos de verificação e como será implementado no próximo ano. Antesei o vídeo para aprender o máximo que pude sobre essas próximas mudanças, para que você não precise.

Como o Android verificará os aplicativos

Quando você tenta instalar um aplicativo Android, o sistema operacional já executa várias verificações antes de permitir que a instalação seja realizada. Essas verificações garantem que um aplicativo com o mesmo ID do aplicativo (ou seja, nome do pacote) já não esteja instalado, que ele não foi criado para uma versão extremamente antiga do sistema operacional e, o mais importante, que não tenha sido sinalizado como malware pelo Google Play Protect.

O Google agora está abordando uma etapa adicional para esse processo. A empresa criou um gancho no fluxo de instalação, exigindo que qualquer aplicativo seja instalado pela primeira vez para fazer a verificação. No momento da instalação, o Android se comunicará com uma “entidade confiável” no dispositivo chamado Android Developer Verifier. Este novo serviço de sistema pré -carregado determina se o desenvolvedor do aplicativo foi verificado, se algum problema foi encontrado durante a verificação e, finalmente, qual política de instalação para fazer cumprir.

Para determinar se o desenvolvedor de um aplicativo foi verificado, o Serviço de Verificador de Desenvolvedores Android precisa verificar se o pacote e a chave usada para assiná -la foram enviados ao Google. É impossível manter um banco de dados abrangente no dispositivo desse pacote e combinações de chaves, especialmente porque muitos novos aplicativos Android aparecem a cada semana. É por isso que o Google diz que seu telefone precisará de uma conexão de rede para verificar os aplicativos, embora apenas no “pior cenário”. A empresa planeja que o Serviço de Verificador do Desenvolvedor mantenha um cache dos aplicativos mais populares que já verificou para que eles possam ser instalados sem uma conexão de rede.

Além disso, o Google diz que está trabalhando em uma solução para as lojas de aplicativos ignorarem chamadas adicionais de rede. As lojas de aplicativos podem passar o que é chamado de “token pré-autor”-uma “bolha criptograficamente verificável” associada ao pacote que eles desejam instalar. Isso permite que o desenvolvedor de um aplicativo seja verificado sem chamadas de rede adicionais para o back -end do Google.

O segundo lançamento trimestral do Android 16, ou seja. O Android 16 QPR2, será a primeira versão do Android a apoiar nativamente essas alterações. No entanto, as políticas de verificação não serão aplicadas quando a atualização for lançada em dezembro, pois o Google ainda está trabalhando em sua implementação e coleta de métricas. As alterações serão revoltadas para versões mais antigas do Android através do Google Play Protect, embora o Google diga que pode haver algumas pequenas diferenças, porque esse método aproveita um aplicativo existente em vez do novo serviço de verificador nativo embutido no sistema operacional.

Como os requisitos de verificação do Android afetarão os alunos e entusiastas

Quando o Google anunciou pela primeira vez seus novos requisitos de verificação do desenvolvedor, ele mencionou que criaria um “tipo separado de conta do console do desenvolvedor Android” para os desenvolvedores de hobby e estudantes, que teria “menos requisitos de verificação” e uma renúncia para a taxa de registro de US $ 25. À primeira vista, isso parece resolver as necessidades dos desenvolvedores independentes que distribuem seus aplicativos gratuitamente em lugares como Github ou F-Droid, mas há uma grande captura.

Os desenvolvedores que se registram no Google como estudante ou amador enfrentarão severas restrições de distribuição de aplicativos, a saber, um limite para o número de dispositivos que podem instalar seus aplicativos. Para aplicar isso, qualquer usuário que desejar instalar o software desses desenvolvedores deve primeiro recuperar um identificador exclusivo do dispositivo. O desenvolvedor precisa entrar esse identificador no console do desenvolvedor do Android para autorizar esse dispositivo específico para instalação.

Esse aperto de mão bidirecional entre usuários e desenvolvedores foi intencionalmente projetado para limitar a distribuição. O Google diz que as contas estudantis/hobbyistas são apenas para desenvolvedores que desejam compartilhar um APK com um conjunto finito de pessoas conhecidas, não para aqueles que desejam distribuir amplamente seus aplicativos. Os desenvolvedores que se inscrevem como estudante ou amador, mas depois decidem que desejam um público mais amplo terão a opção de converter sua conta, para que não fiquem sempre presos a distribuição limitada.

Essas restrições fazem sentido no contexto dos objetivos gerais do Google. Permitir que a distribuição ilimitada para contas estudantis/hobbyistas criaria uma brecha para os maus atores explorarem; portanto, ao limitar seu alcance, o Google impedir os desenvolvedores maliciosos de usar mal esse tipo de conta.

Como o Google impedirá os maus atores de evitar a verificação

Falando em maus atores, o Google diz que projetou seu sistema para capturar e impedir que eles aproveitem a verificação. Para iniciantes, os desenvolvedores não serão capazes de reivindicar a propriedade sobre qualquer pacote existente. Para provar a propriedade, eles devem mostrar que podem assinar aplicativos usando a mesma chave do aplicativo que estão reivindicando. Isso não requer compartilhar chaves privadas com o Google, para que a própria empresa não ganhe direitos de assinatura. O Google diz que seu único objetivo é impedir que os maus atores distribuam aplicativos nocivos, como malware. Portanto, não colocará outras restrições de políticas aos desenvolvedores, como limitar os nomes e ícones que eles podem usar para seus aplicativos.

Os desenvolvedores capturados distribuindo malware terão restrições colocadas em suas contas. Por um período não especificado, todos os aplicativos de propriedade desses desenvolvedores serão bloqueados da instalação em dispositivos de usuário. Isso se aplica a qualquer desenvolvedor cuja conta esteja associada à distribuição de malware, mesmo que esse desenvolvedor não seja o autor de malware. Os autores de malware geralmente tentam comprar contas de desenvolvedor existentes para alavancá -las para distribuição; O Google diz que, em última análise, os desenvolvedores são responsáveis ​​por qualquer coisa publicada em sua conta, justificando qualquer ação tomada contra eles.

Outra técnica que os autores de malware usam para contornar a verificação é a fraude de identidade. O Google diz que possui algum “molho secreto” – técnicas que permitem identificar quando os desenvolvedores estão mentindo sobre sua identidade. A empresa possui equipes que realizam verificação e são treinadas para identificar envios falsos, mesmo os gerados usando ferramentas de IA. Além disso, a necessidade de obter um número de duns impedirá muitos atores ruins de se candidatarem a uma conta organizacional.

E os casos de privacidade, D-droid e uso corporativo?

Em seu vídeo, o Google abordou várias preocupações que os usuários levantaram após o anúncio. Em relação à privacidade, o Google reconheceu que existem razões legítimas para o anonimato do desenvolvedor, como ao distribuir aplicativos para dissidentes. É por isso que a empresa declarou que não compartilhará informações publicamente do desenvolvedor (no entanto, principalmente, não se comprometia a reter essas informações dos governos). Independentemente disso, o Google insiste que o status quo deve mudar, argumentando que o anonimato do desenvolvedor representa riscos para os usuários que ele não pode mais ignorar.

Embora o Google não tenha abordado diretamente as preocupações de que suas políticas matarão lojas de aplicativos independentes como o F-DROID, ele mencionou um pequeno revestimento de prata. A empresa disse que em cenários raros permitirá a duplicação de nomes de pacotes. Por exemplo, se um aplicativo na Play Store compartilhar um nome de pacote com um aplicativo de outra fonte, mas tiver menos instalações, o Google funcionará com os desenvolvedores em uma solução, o que pode exigir que o desenvolvedor da Play Store altere o nome do pacote do aplicativo.

Infelizmente, é improvável que essa escultura ajude muitos desenvolvedores no F-Droid. O problema decorre de como o F-DROID distribui aplicativos: sua equipe compila o código-fonte fornecido pelos desenvolvedores e depois assina os próprios aplicativos. Essa prática geralmente cria duas versões conflitantes de um aplicativo-uma do F-Droid e uma do desenvolvedor original-que ambos usam o mesmo nome de pacote.

Para impedir que vários desenvolvedores reivindiquem a propriedade do mesmo pacote, o Google dará preferência ao desenvolvedor cuja versão tem a maioria das instalações conhecidas. Para muitos aplicativos no F-Droid, isso significa que sua equipe se tornaria efetivamente o proprietário, mesmo que não sejam os desenvolvedores originais. Os criadores originais seriam forçados a alterar o nome do pacote para distribuir seu aplicativo em outro lugar. Esse resultado é indesejável e viola a filosofia central do F-Droid, explicando sua forte oposição às novas políticas do Google.

Por fim, o Google fará algumas exceções para as empresas. Um aplicativo instalado via ferramentas de gerenciamento corporativo em um dispositivo gerenciado será instalável, mesmo que o desenvolvedor não esteja registrado. Essa escultura existe porque os dispositivos gerenciados têm um terceiro responsável-um administrador de TI-encarregado da segurança. Infelizmente, o Google diz que as entidades que distribuem aplicativos para dispositivos offline precisarão determinar por si mesmos como lidar com solicitações de verificação, como se conectando à Web periodicamente.

Muitas perguntas ainda permanecem sobre os novos requisitos de verificação do desenvolvedor da Android, incluindo quais métodos irão ignorá -lo. Já sabemos que a instalação do ADB funciona, mas não está claro se isso se estenderá a soluções como Shizuku, o que permite a execução de comandos do ADB usando privilégios de shell. Ainda há muito tempo até que o Google aplique suas novas políticas, para que os detalhes possam mudar e novas informações possam surgir. Se aprendermos algo novo, informaremos você – siga -nos para nos mantermos atualizados!