O beta do app de rastreamento de contatos NHS COVID-19 agora tem código aberto para iOS e Android, junto com alguma documentação. Como continuação da nossa publicação “Staying alive”, fizemos uma análise aprofundada do código-fonte. É uma surpresa agradável encontrá-lo licenciado sob MIT, o que indica um compromisso do NHSX com a transparência e a qualidade.
Nos últimos dois dias, vários engenheiros analisaram o app para descobrir se — e como! — ele consegue se manter ativo. Entender isso exigiu um conhecimento mais profundo do framework CoreBluetooth em questão do que a maioria dos desenvolvedores tem. Não é um framework em que os engenheiros costumam precisar se aprofundar.
Logo no início, identificamos e relatamos como o truque funcionava nos dispositivos Android. Hoje à noite, vamos compartilhar o que está acontecendo no iOS. Vamos por partes.
Primeira abertura
Na primeira abertura, o app faz uma requisição PUT para https://api.svc-covid19.nhs.uk/api/devices/registrations com um código de ativação, um token de notificação push e a primeira metade do código postal informado pelo usuário. Em resposta, o servidor devolve um linkingId, que é armazenado nos ajustes do app.
O app também solicita permissão para notificações push e para Bluetooth, como seria de esperar. Ele não solicita permissão de localização e, por isso, não valida o código postal do usuário. Apenas os primeiros dígitos do código postal são necessários.
Houve alegações de que o app para Android acessa dados de localização, pois o pedido de acesso à API de Bluetooth nos dispositivos Android parece solicitar permissões de localização. No entanto, desmentimos isso ontem: é uma consequência da forma como o Android gerencia as solicitações de permissão de Bluetooth.
Como manter o app ativo no Android
Impedir que um app entre em repouso em segundo plano é trivial no Android, pois as APIs padrão oferecem suporte a essa funcionalidade e dão aos engenheiros acesso de baixo nível ao hardware de Bluetooth.
No entanto, no iOS a história não é tão simples. Quando os apps vão para segundo plano no iOS, a sua funcionalidade fica bastante reduzida. Isso também vale para o CoreBluetooth, o framework da Apple que dá aos desenvolvedores acesso ao Bluetooth. Sem uma solução alternativa engenhosa, isso torna substancialmente mais difícil para o app detectar iPhones que possam estar em execução em segundo plano. Testamos com vários dispositivos iOS deixados em repouso por várias horas e notamos que a verificação ocorria com menos frequência, mas que os dispositivos ainda se comunicavam durante a noite.
Usar o Android para despertar iPhones
Ontem também relatamos que, quando estão em segundo plano, os apps de iOS continuam a transmitir anúncios de Bluetooth, mas de um modo diferente, específico da Apple. Acreditávamos que os engenheiros do NHSX / Pivotal haviam feito engenharia reversa disso e adicionado suporte a ele no app para Android. Podemos confirmar que é o caso, e os detalhes técnicos deles sobre isso podem ser encontrados aqui. Isso significa que, além de os dispositivos iOS conseguirem manter o app em segundo plano, os dispositivos Android podem despertar um dispositivo iOS “adormecido”, não importa por quanto tempo ele esteja em segundo plano.
Então, quais são as implicações disso? Bem, significa que, para o app funcionar, um iPhone precisa estar ao alcance de um dispositivo Android com bastante frequência, para poder enviar keepalives que o mantenham em segundo plano. Isso, por si só, pode não ser uma solução viável, mas...
Usar dispositivos iOS para despertar... outros dispositivos iOS
Na publicação de ontem, “Staying alive”, relatamos que acreditávamos que o app de iOS estava usando “keepalives” para contornar as restrições de segundo plano. Depois de examinar o código-fonte do app de iOS, concluímos que é exatamente isso que acontece. Mas como eles funcionam, exatamente?
Em poucas palavras, um keepalive, neste contexto, é uma ideia que os desenvolvedores do app tiveram: é uma notificação enviada entre dois dispositivos iOS que executam o app para manter viva a conexão entre eles. O interessante é que isso também tem o efeito de permitir que o app permaneça ativo por muito mais tempo, pois, quando um dispositivo recebe um keepalive, o iOS permite que o app continue ativo para fazer algum processamento adicional.
Do ponto de vista prático, isso significa que o app conseguirá manter o seu estado ativo desde que esteja próximo de outros dispositivos. Em certo sentido, essa é a lógica do projeto de rastreamento da COVID-19: mesmo sem esse truque técnico, será preciso que uma massa crítica de usuários execute o app de rastreamento para que se alcance um bom resultado de segurança pública.
Apesar disso, o app não adormece imediatamente nem entra em estado suspenso quando vai para segundo plano. A questão passa a ser, então, se a maioria dos usuários estará perto de dispositivos iOS ou Android suficientes para que as soluções alternativas sejam viáveis. Na nossa opinião, isso parece provável, ainda mais para usuários que estão com mais frequência em áreas populosas. O Bluetooth tem um alcance efetivo razoável.
Alguns observadores sugeriram que a capacidade do app de receber notificações silenciosas significava que ele usava esses recursos para se despertar remotamente. No entanto, esses recursos são usados simplesmente para informar o usuário se ele esteve perto de alguém que contraiu a COVID-19. O app também usa notificações locais que detectam quando o app é encerrado pelo sistema e instruem os usuários a reabri-lo. Uma notificação semelhante é usada quando o usuário desativa o Bluetooth.
O CEO da Reincubate, Aidan Fitzpatrick, diz:
Sim, é verdade que o futuro framework
ExposureNotificationda Apple no iOS 13.5 elimina a necessidade desses keepalives. No entanto, vale observar que:
- O iOS 13.5 não foi lançado e pode demorar algumas semanas para ser
- Antes de ontem, a última versão beta do iOS 13.5 tinha uma falha de segurança grave, o que sugere que há muito trabalho pesado acontecendo nas equipes de engenharia da Apple
- Depois de lançado, provavelmente levará meses para que a maioria dos usuários de iOS o instale (incomumente, a adoção equivalente no Android pode ser mais rápida)
- Dispositivos iOS mais antigos, como o iPhone 6, não conseguem executar o iOS 13 e não poderão usar a técnica da Apple
- Não há motivo para o app NHS COVID-19 não conseguir passar automaticamente, no futuro, a usar o framework da Apple, ou até mesmo executar os dois mecanismos em paralelo
O app ficará cada vez mais eficaz à medida que mais pessoas o usarem, e o benefício da adoção em massa criará, nesse sentido, um efeito de volante de inércia. O app australiano COVIDSafe teve dificuldades porque não conseguia detectar dispositivos iOS em segundo plano a partir de um dispositivo Android e não tinha esse engenhoso mecanismo de keepalive entre iOS e iOS.
É importante refletir sobre em que circunstâncias o uso de uma tecnologia como essa é apropriado. Se o rastreamento de contatos for bem-sucedido em salvar vidas, que critérios devem ser avaliados para decidir se ele será aplicado em doenças futuras? Uma vez aberto o precedente, há um argumento de que essa tecnologia poderia ser usada para combater doenças infecciosas preexistentes? É previsível que sociedades diferentes avaliem de maneira diferente os prós e os contras.
Salvaguardas de privacidade
Embora redigir uma análise detalhada da matemática por trás do protocolo esteja um pouco fora do escopo desta publicação, demos uma olhada nas salvaguardas de privacidade. O app parece seguir rigorosamente o documento que o NCSC divulgou. Podemos confirmar que nenhum dado de chave sai do dispositivo do usuário até que ele relate sintomas e, só então, as chaves anonimizadas dos dispositivos com os quais ele esteve em contato próximo saem do dispositivo. A primeira metade do código postal informado pelo usuário é enviada à API como parte do serviço de registro.
Em última análise, o código sugere que há pouco risco técnico de privacidade em usar o app até o momento em que o usuário relata sintomas e entra em contato com o NHS para agendar um teste. Nesse momento, o resultado do teste seria gerenciado pelo NHS, embora isso não seja diferente com ou sem o app. No entanto, quando vários usuários entrarem em contato, relatarem sintomas e agendarem testes usando o identificador que o app forneceu a eles, pode ou não ser possível associá-los de forma centralizada. Essa é uma questão do back-end e, como o NHSX afirma no seu relatório de privacidade do app, nesse aspecto o código é a verdade.
Proteção contra relatos falsos
Como o back-end do sistema não teve o código aberto, não é possível confirmar isso, mas parece que nenhuma notificação push é enviada a outros dispositivos até que os cidadãos tenham resultado positivo para a COVID-19. Quando um usuário relata sintomas, ele recebe um código de referência que pode ser usado para agendar um teste. (Esse código por acaso é o mesmo linkingId que descrevemos na seção de registro.)
