Um aprofundamento técnico no aplicativo de rastreamento de contatos NHS COVID-19
O rastreamento de contato do NHS COVID-19 beta agora é de código aberto para iOS e Android , junto com alguma documentação . Como acompanhamento da publicação " Permanecer vivo ", aprofundamos o código-fonte. É agradavelmente surpreendente encontrá-lo licenciado pelo MIT, indicando um compromisso do NHSX com a transparência e a qualidade.
Nos últimos dois dias, vários engenheiros revisaram o aplicativo para descobrir se - e como! - é capaz de permanecer vivo. Entender isso exigiu uma compreensão mais profunda da estrutura CoreBluetooth
relevante do que a maioria dos desenvolvedores possui. Não é uma estrutura que os engenheiros geralmente precisam investigar.
Bem cedo, vimos e relatamos como o truque funcionava para dispositivos Android. Hoje à noite, estamos compartilhando o que está acontecendo no iOS. Vamos passar por isso.
Lançamento inicial
No primeiro lançamento, o aplicativo faz uma solicitação PUT
para https://api.svc-covid19.nhs.uk/api/devices/registrations
com um código de ativação, um token de notificação por push e a primeira metade da entrada do usuário código postal. Em resposta, o servidor responde com um linkingId
armazenado nas configurações do aplicativo. O aplicativo também solicita notificações por push e permissões de Bluetooth, como seria de esperar. Ele não solicita permissões de localização e, como tal, não valida o código postal do usuário. Apenas os primeiros dígitos de um código postal são necessários.
Houve alegações de que o aplicativo Android acessa dados de localização, pois a solicitação de acesso à API Bluetooth em dispositivos Android parece solicitar permissões de localização. No entanto, desmistificamos isso ontem: isso é uma consequência de como o Android gerencia solicitações de permissões de Bluetooth .
Mantendo-se vivo no Android
Impedir que um aplicativo durma em segundo plano é trivial no Android, pois as APIs padrão suportam essa funcionalidade, oferecendo aos engenheiros acesso de baixo nível ao hardware Bluetooth.
No entanto, no iOS, a história não é tão simples. Quando os aplicativos têm um background em iOS, sua funcionalidade é reduzida significativamente. Esse também é o caso do CoreBluetooth
, a estrutura da Apple que fornece aos desenvolvedores acesso ao Bluetooth. Com exceção de uma solução inteligente, isso torna substancialmente mais difícil para o aplicativo detectar iPhones que podem estar sendo executados no modo de segundo plano. Testamos com vários dispositivos iOS deixados sozinhos ao longo de várias horas e observamos que as pesquisas aconteciam com menos frequência, mas que os dispositivos ainda se comunicavam da noite para o dia.
Usando o Android para ativar os iPhones
Yesterday we also reported that when backgrounded, iOS apps continue to broadcast Bluetooth advertisements, but in a different way that’s specific to Apple. We believed the NHSX / Pivotal engineers had reverse-engineered this, and added support for it to the Android app. We can confirm that this is the case, and their technical details about it can be found here. What this means is that in addition to iOS devices being able to keep the app backgrounded, Android devices can wake a “sleeping” iOS device up regardless of how long it has been backgrounded for.
Então, quais são as implicações disso? Bem, isso significa que, para que o aplicativo funcione, um iPhone deve estar dentro do alcance de um dispositivo Android com bastante frequência, para que ele possa enviar keepalives para se manter em segundo plano. Isso, por si só, pode não ser uma solução viável, mas ...
Usando dispositivos iOS para ativar ... outros dispositivos iOS
Na postagem de ontem " Staying alive ", informamos que acreditávamos que o aplicativo iOS estava usando "keepalives" para contornar as restrições de segundo plano. Após examinar o código-fonte do aplicativo iOS, concluímos que esse é realmente o caso. Mas como exatamente eles funcionam?
Simplificando, um keepalive - nesse contexto - é uma ideia que os desenvolvedores do aplicativo tiveram: é uma notificação enviada entre dois dispositivos iOS executando o aplicativo para manter viva a conexão entre os dispositivos. O interessante sobre isso é que ele também tem o efeito de permitir que o aplicativo permaneça acordado por um período significativamente maior, pois quando um dispositivo recebe uma atividade ativa, o iOS permite que o aplicativo permaneça acordado para fazer algum processamento adicional.
Do ponto de vista prático, isso significa que o aplicativo será capaz de manter seu estado vivo, pois está próximo a outros dispositivos. De certa forma, essa é a lógica do projeto de rastreamento COVID-19: mesmo sem esse truque técnico, uma massa crítica de usuários precisará executar o aplicativo de rastreamento para obter um bom resultado de segurança pública.
Independentemente disso, o aplicativo não adormece imediatamente e entra em um estado suspenso quando em segundo plano. Assim, a questão se torna se a maioria dos usuários estará em torno de dispositivos iOS ou Android suficientes para viabilizar as soluções alternativas. Nossa opinião é que isso parece provável, e ainda mais para usuários que estão mais regularmente em áreas povoadas. O Bluetooth tem um alcance efetivo decente.
Alguns observadores sugeriram que a capacidade do aplicativo de receber notificações silenciosas significava que estava usando esses recursos para acordar remotamente. No entanto, esses recursos são simplesmente usados para informar ao usuário se eles estiveram perto de alguém que contratou o COVID-19. O aplicativo também faz uso de notificações locais que detectam quando o aplicativo é morto pelo sistema, instruindo os usuários a reabrir o aplicativo. Uma notificação semelhante é usada quando o usuário desabilita o Bluetooth.
O CEO da Reincubate, Aidan Fitzpatrick, diz:
Sim, é o caso da próxima estrutura Apple
ExposureNotification
no iOS 13.5, que evita a necessidade desses itens de manutenção. No entanto, vale a pena notar que:
- O iOS 13.5 não foi lançado e pode não durar algumas semanas
- Antes de ontem, o último iOS 13.5 beta apresentava uma falha de segurança importante , sugerindo o trabalho pesado nas equipes de engenharia da Apple
- Depois de lançado, provavelmente levará meses para a maioria dos usuários do iOS instalá-lo (de maneira incomum, a adoção equivalente do Android pode ser mais rápida )
- Os dispositivos iOS mais antigos - como o iPhone 6 - não podem executar o iOS 13 e não poderão usar a técnica da Apple
- Não há razão para que o aplicativo NHS COVID-19 não seja capaz de fazer a transição automática no futuro para o uso da estrutura da Apple - ou mesmo de execução dupla dos dois mecanismos
O aplicativo se tornará cada vez mais eficaz à medida que mais pessoas o usarem, e os benefícios da adoção em massa criarão um efeito de volante nesse sentido. O aplicativo COVIDSafe australiano teve problemas, pois não suportava detectar dispositivos iOS em segundo plano de um dispositivo Android e não possuía esse mecanismo inteligente de manutenção de vida útil do iOS para o iOS.
É importante refletir sobre quais circunstâncias fazem uso de tecnologia como essa apropriada. Se o rastreamento de contatos for bem-sucedido em salvar vidas, quais critérios devem ser avaliados para determinar se ele é aplicado a doenças futuras? Uma vez estabelecido o precedente, existe um argumento de que essa tecnologia pode ser usada para combater doenças infecciosas pré-existentes ? É previsível que diferentes sociedades avaliem as compensações de maneira diferente.
Salvaguardas de privacidade
Embora a redação de uma análise detalhada da matemática por trás do protocolo esteja um pouco fora do escopo deste post, analisamos as salvaguardas de privacidade. O aplicativo parece respeitar rigorosamente o artigo divulgado pelo NCSC . Podemos confirmar que nenhum dado-chave sai do dispositivo do usuário até que eles relatem sintomas e só então as chaves anonimizadas dos dispositivos que estiveram muito próximas para deixar o dispositivo. A primeira metade do código postal inserido pelo usuário é enviada à API como parte do serviço de registro.
Por fim, o código sugere que há pouco risco técnico à privacidade do uso do aplicativo até que um usuário relate sintomas e entre em contato com o NHS para agendar um teste. Nesse ponto, o resultado do teste seria gerenciado pelo NHS, embora isso não seja diferente com ou sem o aplicativo . No entanto, quando vários usuários entram em contato, relatam sintomas e organizam testes usando o identificador fornecido pelo aplicativo , pode ou não ser possível uni-los centralmente. Essa é uma pergunta de back-end e, como o NHSX declara em seu relatório de privacidade de aplicativos, o código é verdadeiro nesse sentido.
Proteção contra relatórios falsos
Como o back-end do sistema não tem código aberto, não é possível confirmar isso, mas parece que nenhuma notificação por push é enviada para outros dispositivos até que os cidadãos tenham um teste positivo para o COVID-19. Depois que um usuário relata sintomas, ele recebe um código de referência que pode ser usado para reservar um teste. (Este código passa a ser o mesmo que o linkingId
que descrevemos na seção de registro.)
de Joseph
The termination notification seems unreliable in my testing of the production app. Might be that the app sometimes terminates before the notification has been scheduled.
They probably need to always have one scheduled a few minutes ahead and keep updating it further into the future on a timer while the app is running. That way when the app dies or is killed the notification is already scheduled.