10 requisitos para a avaliação de aplicações de “rastreamento de contactos”

Todos falam das “aplicações corona” como forma de conter a epidemia de SARS-CoV-2. O Computer Chaos Club (CCC) publica neste texto 10 requisitos para a sua avaliação de uma perspectiva técnica e social.

Actualmente, o “rastreamento de contactos” (“contact tracing”) tecnicamente suportado está a ser considerado como um meio de neutralizar a propagação do SARS-CoV-2 de maneira mais focada. A motivação geral é permitir uma maior liberdade de movimentos para um amplo espectro da sociedade, permitindo o rápido rastreamento e a interrupção das cadeias de infecção. Os contactos das pessoas infectadas devem ser alertados mais rapidamente e, assim, poderem-se colocar em quarentena mais rapidamente. Isso, por sua vez, deve evitar novas infecções. Uma “aplicação corona” não poderia, portanto, proteger-nos nem aos nossos contactos: ela seria concebida para parar as cadeias de infecção protegendo os contactos dos nossos contactos.

Rastreamento de contactos como tecnologia de risco
Há várias sugestões para a implementação técnica deste conceito. Essas propostas variam de sistemas distópicos de completa vigilância a métodos completamente anónimos e direccionados para alertar as pessoas potencialmente infectadas sem conhecimento dessa pessoa específica.

Em princípio, o conceito de uma “corona app” envolve um enorme risco devido aos dados de contacto e de saúde que podem ser recolhidos. Em simultâneo, há uma hipótese para conceitos e tecnologias de “privacidade por design” que foram desenvolvidos pela comunidade de criptografia e privacidade nas últimas décadas. Com a ajuda dessas tecnologias, é possível desenvolver o potencial epidemiológico do rastreamento de contactos sem criar um desastre para a privacidade. Por esse motivo, todos os conceitos que violam ou até ameaçam a privacidade devem ser rigorosamente rejeitados.

A seguir, descrevemos os requisitos mínimos sociais e técnicos para essas tecnologias. O CCC vê-se num papel consultivo e de observação neste debate. Não recomendamos aplicações, conceitos ou procedimentos específicos. No entanto, desaconselhamos o uso de aplicações que não atendam a esses requisitos.

I. Requisitos societais
1. Sentido epidemiológico e objectivo
O pré-requisito básico é que o “rastreamento de contactos” possa realisticamente ajudar a reduzir significativa e comprovadamente o número das infecções. A validação desta avaliação é responsabilidade da epidemiologia. Se o “rastreamento de contactos” através de aplicações não for útil ou não cumprir o objectivo, a experiência deve ser encerrada.

A aplicação e quaisquer dados recolhidos devem ser usados ​​exclusivamente para combater as cadeias de infecção pelo SARS-CoV-2. Qualquer outro uso deve ser tecnicamente evitado na medida do possível e legalmente proibido.

2. Voluntariedade e liberdade de discriminação
Para uma eficácia epidemiologicamente significativa, uma aplicação de “rastreamento de contactoss” requer um alto grau de disseminação na sociedade. Essa ampla distribuição não deve ser obtida à força mas apenas implementando um sistema fiável que respeite a privacidade. Nesse contexto, não deve haver cobrança de taxas pelo seu uso nem incentivos financeiros para esse uso.

As pessoas que se recusam a usá-la não devem ter consequências negativas. Garantir isso é uma questão para a política e legislação.

A aplicação deve informar regularmente as pessoas sobre a sua operação. Deve permitir a desactivação temporária simples e a remoção permanente. Medidas restritivas, como a função de “algemas electrónicas” para controlar as restrições de contacto, não devem ser implementadas.

3. Privacidade fundamental
Apenas com um conceito convincente baseado no princípio da privacidade é que a aceitação social pode ser alcançada por todos.

Ao mesmo tempo, medidas técnicas verificáveis, como as tecnologias de criptografia e de anonimização, devem garantir a privacidade do utilizador. Não é suficiente fiar-nos em medidas organizacionais, “confiança” e promessas. Os obstáculos jurídicos ou organizacionais contra o acesso aos dados não podem ser considerados suficientes no clima social actual de pensamento de estado de emergência e possíveis excepções de longo alcance aos direitos constitucionais através das leis de protecção contra infecções.

Rejeitamos o envolvimento de empresas que desenvolvem tecnologias de vigilância como “lavagem oculta”. Como princípio básico, os utilizadores não devem ter de “confiar” os seus dados a nenhuma pessoa ou instituição, mas devem usufruir de segurança técnica documentada e testada.

4. Transparência e verificabilidade
O código-fonte completo da aplicação e da infra-estrutura deve estar disponível gratuitamente, sem restrições de acesso, para permitir auditorias de todas as partes interessadas. Técnicas de criação reproduzíveis devem ser usadas para garantir que os utilizadores podem verificar se a aplicação transferida foi criado a partir do código-fonte auditado.

II Requerimentos técnicos
5. Nenhuma entidade central em quem confiar
Um rastreamento de contactos completamente anónimo sem servidores centrais omniscientes é tecnicamente possível.

Tecnicamente, não é necessária uma dependência da privacidade dos utilizadores quanto à fiabilidade e competência do operador da infra-estrutura central. Conceitos baseados nessa “confiança” devem, portanto, ser rejeitados.

Além disso, a segurança prometida e a fiabilidade dos sistemas centralizados – por exemplo, contra a ligação de endereços IP com IDs de utilizador anónimo – não podem ser efectivamente verificadas pelos utilizadores. Os sistemas devem, portanto, ser concebidos para garantir a segurança e a confidencialidade dos dados do utilizador exclusivamente pelo conceito da criptografia e da anonimização e da verificabilidade do código-fonte.

6. Economia de dados
Apenas dados e metadados minimamente necessários para a finalidade da aplicação podem ser armazenados. Esse requisito proíbe a recolha central de dados não específicos de um contacto entre pessoas e a sua duração.

Se dados adicionais, como as informações de localização, são gravados localmente nos telefones, os utilizadores não devem ser forçados ou tentados a transmitir esses dados a terceiros ou a publicá-los. Quando os dados deixam de ser necessários, devem ser apagados. Os dados sensíveis também devem ser cifrados localmente com segurança no telefone.

Para a recolha voluntária de dados com fins de investigação epidemiológica que vai além do objectivo real do rastreamento de contactos, um consentimento claro e em separado deve ser explicitamente obtido na interface da aplicação e deve ser possível revogá-lo a qualquer momento. Este consentimento não deve ser um pré-requisito para utilização.

7. Anonimato
Os dados que cada dispositivo recolhe sobre outros dispositivos não devem ser adequados para desanonimizar os seus utilizadores, assim como os dados que cada pessoa pode transmitir sobre si mesmo. Portanto, deve ser possível usar o sistema sem recolher ou ser capaz de derivar dados pessoais de qualquer tipo. Este requisito proíbe identificações exclusivas de utilizadores.

Os IDs para “rastreamento de contacto” por meio da tecnologia sem fios (por exemplo, Bluetooth ou ultra-sons) não devem ser rastreados para pessoas e devem ser alterados com frequência. Por este motivo, também é proibido ligar ou fazer derivar IDs que acompanham os dados de comunicação, como “push tokens“, números de telefone, endereços IP usados, IDs de dispositivos, etc.

8. Nenhuma criação central de movimentos ou de perfis de contacto
O sistema deve ser concebido por forma a que os perfis de movimento (rastreamento da localização) ou os perfis de contacto (padrões de contactos frequentes rastreáveis par​​a pessoas específicas) não possam ser estabelecidos intencionalmente ou não. Métodos como o registo central de ligação GPS/localização ou ligar os dados a números de telefone, contas de media social e similares devem, portanto, ser rejeitados por uma questão de princípio.

9. Desconectabilidade
O design do ID de geração temporária deve ser tal que os IDs não possam ser interpretados e vinculados sem a posse de uma chave privada controlada pelo utilizador. Assim, eles não devem ser derivados de outras informações da identificação do utilizador, directa ou indirectamente. Independentemente da maneira como os IDs são comunicados em caso de infecção, deve-se garantir que os dados recolhidos de “rastreamento de contactos” possam ser encadeados por períodos mais longos.

10. Inobservabilidade da comunicação
Mesmo que a transmissão de uma mensagem seja observada no sistema (por exemplo, através dos metadados da comunicação), não deve ser possível concluir que uma pessoa esteja infectada ou teve contacto com pessoas infectadas. Isso deve ser garantido em relação a outros utilizadores e a operadores de infra-estrutura e rede ou a atacantes que obtiverem conhecimentos sobre estes sistemas.

O papel do CCC
Há mais de 30 anos, o CCC envolve-se em trabalho voluntário na intersecção entre tecnologia e sociedade. Os nossos princípios éticos defendem a privacidade, descentralização e economia de dados – e contra qualquer forma de vigilância e coerção.

Sem pretender ser exaustivo, neste artigo, citamos os requisitos mínimos de privacidade que uma “corona app” deve ter para ser social e tecnologicamente tolerável. O CCC nunca fornecerá uma implementação concreta com aprovação, recomendação, certificação ou selo de teste.

É da responsabilidade dos programadores de sistemas de rastreamento de contactos comprovar o cumprimento destes requisitos ou tê-los comprovados por outras entidades independentes.

* Texto original do Computer Chaos Club (CCC), traduzido e reproduzido com autorização.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.