Google detalha proposta de design do SDK Runtime para o Android Privacy Sandbox

Recentemente, vimos a Apple e o Google se esforçarem para criar um ecossistema mais consciente da privacidade quando se trata de anúncios. Com a Apple, foi com a introdução de um botão para evitar que os aplicativos rastreassem você, e com o Google, foi o Iniciativa Android Privacy Sandbox. Embora as informações fossem escassas durante o seu anúncio, surgiram mais detalhes em torno do “SDK Runtime”, que abrange parte da solução do Google para publicidade e privacidade.

O Android Privacy Sandbox é composto por dois componentes principais: o SDK Runtime e as APIs de preservação de privacidade, que serão distribuídos como componentes modulares do sistema, dos quais você deve se lembrar como Linha principal do projeto. Desde então, o Google publicou documentação para desenvolvedores sobre o SDK Runtime e como ele aumentará ainda mais a privacidade do usuário. A empresa afirma que o SDK Runtime permitirá que SDKs de terceiros sejam executados em um ambiente de execução dedicado em

Andróide 13, longe do código de um aplicativo.

No Android, cada aplicativo é executado em uma sandbox com permissões próprias e acesso variável ao sistema dependendo do acesso concedido. Como o Google diz, "se o aplicativo A tentar fazer algo malicioso, como ler os dados do aplicativo B ou discar o telefone sem permissão, ele será impedido de fazer isso porque não tem o privilégios de usuário padrão apropriados." O SDK Runtime expande ainda mais essa sandbox para executar SDKs de terceiros em um ambiente de tempo de execução dedicado, longe de qualquer ambiente específico. aplicativo.

Por que existe o SDK Runtime

O Google deseja evitar que SDKs de anunciantes coletem dados aos quais não deveriam ter acesso de forma maliciosa (ou mesmo inadvertidamente) como resultado do compartilhamento da sandbox do aplicativo host. Quando um SDK de anúncio é executado dentro de um aplicativo, ele também tem acesso a tudo o que o aplicativo faz, e um desenvolvedor de aplicativo pode não estar completamente ciente de quanto acesso isso realmente significa. Ao remover o código do anunciante e executá-lo em seu próprio tempo de execução, ele só poderá acessar os dados que o desenvolvedor compartilha explicitamente com ele.

Como resultado, o Google afirma que o SDK Runtime fornece as seguintes proteções e garantias mais fortes em relação à coleta e compartilhamento de dados do usuário:

• Um ambiente de execução modificado
• Permissões e direitos de acesso a dados bem definidos para SDKs

A primeira versão do SDK Runtime concentra-se exclusivamente em SDKs relacionados a publicidade, incluindo SDKs que permitem veiculação de anúncios, medição de anúncios, fraude publicitária e detecção de abuso.

Como funciona o tempo de execução do SDK

Atualmente, sem o tempo de execução do SDK, um processo de aplicativo chamará um SDK e esse SDK será executado dentro da mesma sandbox que o restante do código do aplicativo. O Google deseja que os desenvolvedores tenham uma interface para um SDK que funcione no processo de primeiro plano de um aplicativo, e essa interface pode se conectar e compartilhar dados específicos com o SDK que está sendo utilizado.

Antes

Depois

O diagrama "antes" (primeiro) mostra que o código de chamada do SDK, juntamente com os SDKs que recebem as chamadas desse código, residem no processo do aplicativo. Isso significa que o SDK pode acessar todos os dados que o aplicativo pode. O diagrama "depois" (segundo) mostra que, no processo de primeiro plano do aplicativo, o código de chamada do SDK se comunica com as interfaces do SDK. Essas interfaces cruzam um limite de processo para o processo SDK Runtime para chamar os próprios SDKs. Isso significa que o SDK usado não pode simplesmente acessar o que quiser, ele só pode receber informações do aplicativo com o qual é executado.

Novo modelo de distribuição confiável para SDKs

Atualmente, quando você baixa um aplicativo com SDKs de terceiros, eles são incluídos pelo desenvolvedor no aplicativo carregado e distribuído na Google Play Store. Em vez disso, o Google deseja que, quando você instala um aplicativo em seu telefone que usa esses SDKs, eles sejam baixados separadamente do próprio aplicativo. Isso significa que os desenvolvedores do SDK podem fazer alterações ininterruptas (ou seja, nenhuma alteração nas APIs ou sua semântica) para seus SDKs e distribuí-los para dispositivos sem qualquer envolvimento do aplicativo desenvolvedores.

Por sua vez, alterações ininterruptas do SDK podem ser implantadas ou revertidas, sem necessariamente precisar esperar para que os desenvolvedores de aplicativos reconstruam seus aplicativos com os novos SDKs ou esperem que os usuários finais atualizem seus aplicativos. Mudanças significativas que alteram as APIs e sua semântica ainda precisariam ser atualizadas pelos desenvolvedores de aplicativos, mas os desenvolvedores de SDK poderiam obter suas versões mais recentes e ininterruptas. muda e corrige de forma mais rápida e uniforme para mais pessoas ao mesmo tempo, sem depender de um desenvolvedor de aplicativo para atualizar seu aplicativo e pacote no novo SDK.

Antes

Depois

O diagrama “antes” mostra exatamente como os aplicativos são distribuídos com SDKs agora. Eles são empacotados em um aplicativo e o aplicativo é enviado à Google Play Store. No diagrama “depois”, os desenvolvedores de SDK não colocariam mais seus SDKs diretamente nos aplicativos; em vez disso, os desenvolvedores do SDK carregariam um SDK e o publicariam na Google Play Store. A Google Play Store cuidaria então da distribuição de aplicativos, juntamente com quaisquer dependências do SDK, para dispositivos do usuário final. O Google também está usando intencionalmente a frase “loja de aplicativos” em seus diagramas, pois é uma solução aberta e geral que pode funcionar em outras lojas.

Mudanças na forma como SDKs e aplicativos são criados, executados e distribuídos

A proposta inicial para o SDK Runtime propõe uma série de mudanças em cinco áreas principais:

• Acesso
• Execução
• Comunicações
• Desenvolvimento
• Distribuição

O Google deseja definir o seguinte conjunto de permissões para o SDK Runtime:

• INTERNET: Acesso à internet para poder se comunicar com um serviço web.
• ACCESS_NETWORK_STATE: acessa informações sobre redes.
• Permissões para acessar o APIs que preservam a privacidade, que fornecem recursos básicos de publicidade sem a necessidade de acesso a identificadores entre aplicativos. Os nomes das permissões não foram finalizados, mas essas APIs seriam controladas pelo acesso do aplicativo a essas permissões.
• AD_ID: Capacidade de solicitar o ID de publicidade. Isso também seria limitado pelo acesso do aplicativo a essa permissão.
• BIND_GET_INSTALL_REFERRER_SERVICE: Capacidade de usar o API de referência de instalação do Google Play para atribuir a origem da instalação de um aplicativo.

A empresa também deseja limitar o acesso que os SDKs têm à memória de um aplicativo em execução, mas também evitar que um aplicativo acesse os próprios dados de um SDK. Um aplicativo não seria capaz de acessar diretamente o armazenamento de seus SDKs e vice-versa, o armazenamento externo não seria aberto para SDKs, e haveria armazenamento acessível a todos os SDKs e armazenamento privado para um determinado SDK.

Quanto à forma como os SDKs serão executados, eles serão executados com uma prioridade um pouco menor do que o próprio aplicativo. Isso quer dizer que é muito provável que um aplicativo seja encerrado logo após o encerramento de um SDK Runtime se surgir uma situação em que ele precise ser fechado pelo sistema. Caso não seja encerrado ao mesmo tempo, ou caso haja motivo diverso, a proposta oferece métodos de retorno de chamada de ciclo de vida relacionados aos desenvolvedores de aplicativos para que eles lidem com essa exceção e reinicializem o SDK Tempo de execução. Os SDKs de tempo de execução não poderão usar as APIs de notificações para enviar notificações ao usuário a qualquer momento.

Por fim, o Google observa que esta é uma proposta geral que não é exclusiva de nenhuma loja de aplicativos específica. Embora presumivelmente seja integrado à Google Play Store, não há razão para que outras lojas de aplicativos não possam incorporar uma estrutura semelhante. O Google afirma que os seguintes benefícios são claros:

• Garanta a qualidade e consistência dos SDKs.
• Simplifique a publicação para desenvolvedores de SDK.
• Acelere a implementação de atualizações de versões secundárias do SDK para aplicativos instalados.

O Android Privacy Sandbox parece promissor

O cronograma de lançamento do Google é que o primeiro trimestre de 2022 envolva as propostas iniciais de design e feedback e iterações de design. As prévias para desenvolvedores chegarão no final do ano, com uma versão beta no final do ano. Finalmente, 2023 verá o início dos testes em escala. Essas prévias e betas serão independentes da cadência de lançamento do Android 13. Também haverá controles voltados para o usuário no aplicativo de configurações, uma vez implementado.

Na minha opinião, o Android Privacy Sandbox visual promissor, mas teremos que esperar e ver como a empresa o implementará. É perfeitamente possível que os desenvolvedores não gostem ou que cause mais problemas do que resolva. Os desenvolvedores são incentivados a ler a documentação publicada pelo Google para ter uma ideia melhor do que está por vir no futuro da privacidade do Android.

Esta é actualmente uma proposta e não uma perspectiva definitiva sobre o que exatamente acontecerá em uma versão futura do Android, mas é provável que acabe bem perto. Estaremos atentos a quaisquer desenvolvimentos futuros!

---

Fonte: Documentação do desenvolvedor Android