Porque é que a STAYAWAY COVID é uma aplicação (relativamente) segura

Recentemente, com o lançamento da aplicação de rastreio de contactos (contact tracing) STAYAWAY COVID, desenvolvida pelo INESC TEC para o Governo Português, envolvi-me numa série de discussões online sobre a «segurança» da mesma. De nada me serviu argumentar que a mesma foi auditada por várias organizações como a Comissão Nacional para a Protecção dos Dados ou o próprio Centro Nacional de Cibersegurança (CNCS), cujos pareceres estão disponíveis publicamente (ver FAQ do site oficial da app). De nada serviu apontar que o código-fonte da app (ambas as versões Android e iOS) é livre e aberto e pode ser consultado por qualquer pessoa. Apesar da tecnologia propriamente dita — o framework Google-Apple Exposure Notification (GAEN) que está incorporado nas versões recentes de Android e iOS — ser realmente «fechada», existe código-fonte parcialmente disponibilizado pela Google, assim como o código-fonte para um servidor de referência como base para um sistema completo — isto interessa essencialmente para as administrações públicas terem uma base de trabalho, mas pode-se assim validar o funcionamento do sistema de acordo com as especificações publicadas. E apesar de não haver acesso directo ao código-fonte da Google e da Apple, este pode ser auditado de fora, coisa que foi feita exaustivamente pelo equivalente suíço do centro nacional de cibersegurança e publicado online.

Mas mesmo assim há quem esteja desconfiado. Essencialmente há aqui dois problemas (interligados) que causam preocupação:

  1. Como impedir que o Governo, a Apple, a Google, etc. fiquem a saber por onde andámos e com quem estivémos.
  2. Como impedir que um utilizador malicioso consiga «interceptar» as nossas comunicações, obtendo acesso ilegítimo aos nossos dados.

Como tentarei explicar de seguida, e tendo sempre em consideração que não existe software 100% seguro, tanto esta aplicação como a tecnologia usada para a implementar foram criadas para que estas duas questões não possam ocorrer.

A implementação ingénua…

Como funciona o rastreamento manual feito pelo Serviço Nacional de Saúde (SNS)? Seja nesta pandemia, seja noutra qualquer, o protocolo é o mesmo: os profissionais de saúde que confirmam o diagnóstico da pessoa infectada vão lhe pedir que lhe digam os nomes das pessoas que contactou nos últimos X dias (no caso da COVID-19, 15 dias) e respectivos números de telefone, a fim de lhes telefonar a pedirem que façam um teste. Se algumas destas pessoas realmente testar positivo, pede-se então à mesma para fazer o mesmo, indicar o nome e telefone desses contactos, e assim por diante. É assim que o SNS consegue ter uma noção dos potenciais infectados e colocá-los em quarentena (isolamento domiciliário, se não apresentarem sintomas; ida imediata ao hospital mais próximo se de facto já tiverem alguns sintomas…).

Regra geral, as pessoas não se «preocupam» muito com o rastreio manual. Afinal de contas, quem o faz são profissionais de saúde (devidamente credenciados como tal, caso «suspeitemos» de que não o sejam), que estão obrigados pelo seu código deontológico a nunca revelar os dados dos pacientes, mesmo que, sei lá, alguém do Governo fosse lá bater à porta a pedir os números de telemóvel de todas as pessoas que se pensem estar infectadas. Os profissionais de saúde até se podem muitas vezes escusar a revelar esses dados mesmo com ordem do tribunal; penso que existem formas de, em caso de extrema necessidade, as respectivas ordens destes profissionais possam ser contactadas, através dos seus Comités de Ética, e, eventualmente, desta forma, «revelar» alguns dados a um tribunal que assim o «exija». Mas do que sei isto acontece mesmo muito raramente, e as pessoas têm consciência disso.

Da mesma forma, os dados que são recolhidos pelos profissionais de saúde até podem ser arquivados em sistemas informáticos, mas os pacientes também sabem que a Comissão Nacional para a Protecção dos Dados fez uma auditoria prévia a qualquer base de dados com os nomes de pacientes (e respectivos diagnósticos), e, segundo suponho, as ordens profissionais também devem ter feito o mesmo. Os profissionais de saúde sem extremamente paranóicos em relação aos dados dos seus pacientes, e protegem a sua identidade de todas as formas previstas na lei, ou seja, até às últimas consequências.

Sabendo isto, os potenciais infectados com COVID-19 têm menor relutância em falar com um médico, enfermeiro, ou outro profissional de saúde devidamente certificado como tal, para lhes confiarem os seus dados pessoais e até mesmo os dos seus colegas de trabalho, amigos, familiares, conhecidos, etc. — pois sabem que cada pessoa acrescentada à lista de pessoas sob suspeita pode vir a literalmente salvar vidas, e que os contactos só serão feitos por um profissional da área de saúde com o único propósito de garantir a saúde médica; sabem igualmente que os profissionais de saúde não podem pegar nestes dados recolhidos e entregá-los a empresas privadas como as farmacêuticas ou as seguradoras…

Como este método é na realidade bastante simples de entender (e até de implementar: tudo o que é preciso é um telefone e um bloco-notas), as pessoas, em geral, pensam que a substituição de profissionais de saúde por uma app no telemóvel seja, no fundo, a mesma coisa, devidamente adaptada para o mundo digital, e acrescentando mais uns «pozinhos» que não são possíveis com o contacto telefónico dos profissionais de saúde.

Por outras palavras, grande parte das pessoas acredita que a app funcione mais ou menos da seguinte forma:

  • App vai constantemente trocar informações de que telemóveis «viu»
  • Depois, via GPS, faz as contas de quanto tempo ficaram perto uns dos outros (abaixo dos 2 metros, sem ou com equipamento de protecção, por mais do que 15 minutos), e guarda o resultado dentro do telemóvel.
  • Entretanto, a intervalos regulares, imagina-se que cada telemóvel vai comunicar a sua posição GPS (e nº de telemóvel) para um servidor «central», nas mãos da Google, Apple, Governo/SNS/DGS (ou possivelmente todos estes em simultâneo)
  • Quando o teste de alguém dá positivo, alguém coloca essa informação no sistema, e a pessoa em questão recebe um SMS a dizer que está infectado
  • Simultaneamente, o sistema vai procurar na base de dados quem é que esteve a menos de 2 metros de distância dessa pessoa, durante 15 minutos, e efectua uma lista de números a contactar, mandando um SMS a cada uma delas, informando-as de que podem estar infectadas e que por isso devem contactar a Linha SNS 24 para marcarem um teste de despiste ao SARS-CoV-2

Infelizmente, houve realmente alguns países que implementaram o sistema desta forma (como a Índia, por exemplo); e ainda mais trágico foi que alguns estados americanos, desesperados por terem um sistema a funcionar depressa, acabaram por contratar uma ou outra empresa de reputação duvidosa, que implementaram um sistema nos moldes acima, com o objectivo explícito de obter de forma ilegítima todos os dados das pessoas que instalavam alegremente a aplicação… quando o «escândalo» se tornou público, como é evidente, os cidadãos passaram a desconfiar de todas estas apps de origem mais ou menos suspeita, e, por mais que as convençam do contrário, gato escaldado tem medo de água fria — será praticamente impossível fornecer-lhes uma alternativa, porque assumirão sempre que o Governo, ou a empresa que desenvolve o software (mesmo sendo a Google e/ou a Apple), não são de fiar.

Infelizmente também a coisa que se propaga mais depressa na Internet são as notícias falsas — em particular, aquelas que têm a intenção de assustar as pessoas. Rapidamente a notícia de que «algumas» apps tinham sido mal programadas e/ou maliciosamente implementadas para obter os dados privados dos cidadãos, com o «pretexto» de combater a COVID-19, se espalhou nas redes sociais — mas agora substituindo a expressão «algumas apps» por «todas as apps».

Do ponto de vista da esmagadora maioria dos cidadãos, com ou sem conhecimentos técnicos, é difícil de «olhar» para uma app e saber se é legítima ou não; o facto do Governo, da Google e/ou da Apple dizerem que é legítima deixou de ser suficiente para as pessoas acreditarem neles.

Apesar de haver imensos esclarecimentos e declarações do tipo «a nossa app é segura», ou «fizémos imensas auditorias, nacionais e internacionais, para garantir a privacidade dos dados», ou até diagramas engraçados que explicam muito basicamente como é que a app funciona, a verdade é que não é, de todo, fácil explicar como é que uma app como a STAYAWAY COVID funciona — e porque é que este funcionamento é seguro e não viola a privacidade de ninguém, mesmo que a app fosse «maliciosa», ou interceptada por piratas informáticos sem escrupulosos (ou mesmo agentes de cibercrime/ciberterrorismo, nacionais ou estrangeiros…).

Declaração de isenção de responsabilidade

Não trabalho para nenhuma das entidades ou organizações que elaboraram a aplicação STAYAWAY COVID, nem para a Apple, nem para a Google; também não colaborei nem participei em nenhuma auditoria ou elaboração de parecer. Não contactei com nenhum dos membros que participaram nos projectos, ou com os seus consultores, analistas, ou programadores. Não tenho pessoalmente nenhum interesse ou participação em alguma dessas entidades.

Logo, não só não sei nada de concreto sobre a aplicação em si, como nem sequer estive a analisar profundamente o código-fonte disponibilizado pelo Estado Português e pela Google. Também tenho poucos (ou nenhuns) conhecimentos em certas áreas muito específicas (como a comunicação de dados via Bluetooth Low Energy ou sistemas de encriptação de dados muito complexos).

Ao longo deste texto, vou fazer várias analogias para ilustrar alguns pormenores; como todas as analogias, não quer dizer que as coisas sejam mesmo assim. Em muitos dos casos, estarei deliberadamente a simplificar o modelo para que seja mais fácil concentrarmo-nos no essencial e não nos «detalhes» esotéricos. Mas muitas vezes são justamente esses «detalhes» que garantem a nossa privacidade, mesmo que não seja óbvio porquê. Noutros casos, simplesmente não sei como é que certas partes do sistema funcionam, e por isso a minha descrição ou analogia poderá estar completamente errada.

No entanto, não sou suficientemente humilde para dizer que não percebo nada do assunto. Digamos que se me tivessem dado as especificações completas do sistema (seja do lado da app, seja do lado do servidor) estaria apto para desenvolver alguma coisa de semelhante, baseada nos mesmos pressupostos; ou seja, o conceito geral do funcionamento do sistema não é uma «caixa negra» absoluta para mim (até porque imensas das opções adoptadas são perfeitamente lógicas, racionais, e apelam ao bom-senso e às boas práticas de programação) — tenho alguma ideia de como é que as coisas funcionam, lá bem no «fundo» da aplicação, naquilo a chamarei o core (= o centro, o núcleo, o cerne) do sistema, mas há obviamente muita coisa que desconheço e ainda mais outras em que posso ter uma ideia de como é que as coisas funcionam baseado na forma como eu as implementaria se tivesse os mesmos pressupostos em mente. Isso não quer dizer que tenha sido mesmo assim que as coisas foram desenvolvidas.

Logo, afirmo a total ausência de responsabilidade relativamente às diversas afirmações que aqui faço. Algumas poderão até estar correctas. Outras serão descrições muito incompletas ou totalmente erradas. O meu objectivo aqui é só um: apontar um foco de luz (fraquinho…) para o interior da tal «caixa negra», explicando um pouquinho mais de como funciona a app, de forma a que, quando lerem frases como «a app é extremamente segura e garante a privacidade das pessoas» possam saber porquê. A ideia, no fundo, é não aceitar sem hesitações o que o Governo, a Google ou a Apple nos dizem — eles estão a assumir a falácia da autoridade, ou seja, que pelo simples facto de dizerem que a aplicação é segura e garante privacidade, como eles são uma «autoridade» na área, toda a gente tem de acreditar neles — mas sim olhar para a solução implementada pela equipa do INESC TEC com um olhar crítico e saber porque é que essas entidades todas, públicas e privadas, podem, de livre consciência, afirmar que a aplicação é, de facto, segura e garante a privacidade.

É verdade que isto implica «descer» bastante aos níveis mais técnicos. Peço desculpa por isso. Gostaria que fosse mais fácil explicar tudo com analogias mais simples de perceber, sem precisar de recorrer a questões técnicas que são complexas. Infelizmente não o sei fazer. Mas como vi muitas notícias na comunicação social que tentaram explicar mais ou menos como é que as coisas funcionavam, reparei que muitas vezes se concentravam nalguns pormenores pouco essenciais — embora tecnicamente muito interessantes, têm pouco «impacto» para a percepção de que esta app é segura e que garante a privacidade — o que me faz suspeitar que isto ou é mesmo difícil de explicar, ou que muita gente não percebeu o essencial do funcionamento da app, que é fundamental se quisermos dar resposta ao porquê da sua segurança e garantia de privacidade.

Obviamente que aceitarei de bom grado qualquer correcção a este artigo, que tentarei actualizar à medida que fico mais esclarecido sobre certas partes mais «obscuras» do sistema.

Pressupostos

Vamos assumir que existem várias pessoas a circular com a app ligada, no bolso. Algumas dessas pessoas cruzam-se umas com as outras e distribuem códigos entre si à medida que vão passando uns pelos outros. Por uma questão de simplificação, vamos assumir que cada código recebido só é guardado se corresponder a um «contacto potencial», ou seja, alguém que esteve a menos de 2 metros de outra pessoa durante um período de 15 minutos (nota: é repetido diversas vezes nas especificações que estes parâmetros podem ser alterados de acordo com indicações da OMS).


De X em X tempo, esses códigos são enviados para o tal servidor central. Vamos assumir, por questões de simplificação, de que os códigos são apenas de 4 bits (de 0000 a 1111), gerados aleatoriamente, e sem correlação seja com a pessoa que envia o código, seja com o telemóvel, o local, a hora ou data, seja com qualquer outro código previamente gerado (ou que venha a ser gerado no futuro). E finalmente vamos assumir que a população só tem 6 pessoas a usar o sistema. Isto tudo obviamente que é uma enorme simplificação, mas é para ajudar a ilustrar como é que isto funciona.

Ok, o meu primeiro passo foi ir ao random.org gerar alguns códigos aleatórios (podia ter usado um dado ou mesmo uma moeda para fazer o mesmo, mas sou preguiçoso), e deu-me isto:

0010 0101 1110 1010 1000 0100

Depois atribui estes códigos aleatoriamente às pessoas, mas não digo quem é quem.

Ao longo desse dia, pois, os elementos da nossa população de 6 pessoas vão passeando pela rua, fazendo a sua vida regular, e ficam por vezes «demasiado perto» de outras pessoas por mais de 15 minutos (por exemplo, numa fila de supermercado), pelo que isso é registado na app.

Como?

Funciona assim. Vamos imaginar que temos duas pessoas, X e Y, que acabaram de fazer reset à app, e que X gerou o código 1010 (sem o saber — a app não diz) e Y o código 1000 (também sem saber). Ambos aproximam-se um do outro a menos de 2 metros e ficam 15 minutos à conversa. Ao fim desses 15 minutos, graças à comunicação Bluetooth entre ambos os telemóveis, X tem na sua app os códigos 1010 1000, e Y tem também na app os mesmos códigos: 1010 1000.

Nota que já nesta situação, apesar de estarmos a olhar para um universo de apenas duas pessoas, já temos uma primeira dificuldade: Se X ou Y olharem para os registos das respectivas apps, tentando identificar quem é quem, só vêem lá 1010 1000. Quem é quem? Tanto X como Y podem ser 1010, tal como podem ser 1000. Tudo o que X e Y sabem é que os seus códigos serão ou 1010 ou 1000, tendo 50% de hipótese de os adivinhar.

Para que isto seja seguro e que não haja perda de privacidade, temos de garantir que estes dois códigos, «atribuídos» às duas pessoas (e respectivos telemóveis), não têm nada a ver seja com as pessoas, seja com o telemóvel, seja com o local onde estão. Não são trocados os números de telemóvel, os IMEIs, o nome da operadora, a posição GPS, ou qualquer outro identificador da origem dos códigos. O nosso conhecimento sobre o sistema, neste ponto, é apenas este: quando X e Y se juntaram por mais de 15 minutos (não sabemos onde ou quando isso ocorreu), cada qual ficou com dois códigos no sistema, 1010 e 1000.

Donde vieram estes códigos? Quem é que os criou e atribuiu? Bem, eu fiz «batota» há bocadinho, fui a um site que sei que gera números verdadeiramente aleatórios, e, mentalmente, atribui-os a cada um dos dois utilizadores, X e Y.

Mas não é assim que as coisas funcionam. Na realidade, cada telemóvel gera aleatoriamente os seus próprios códigos. Não há mais nenhuma parte envolvida. O telemóvel de X gerou o seu código; o de Y o seu; nenhum dos telemóveis disse aos seus proprietários (aliás, a ninguém) qual foi o código que lhes foi atribuído pelos respectivos telemóveis; mas após o contacto durante 15 minutos, tanto X e Y «sabem» que têm os códigos 1010 e 1000. Não sabem é quem é quem…

Bom, então se cada telemóvel gera os seus próprios números, como é que sabem se não estão, por acaso, a usar o número doutra pessoa? Esta resposta está na matemática complexa da área da criptografia. Em termos muito simples: são conhecidas fórmulas matemáticas complexas que permitem garantir que num universo de biliões de telemóveis, nenhum gere um código igual a outro. Isto parece ser «impossível» sem haver uma base de dados central para verificar quem é que já tem códigos atribuídos e quem não tem, mas é verdade que é uma propriedade matemática de certos algoritmos complexos. Vai aqui um exemplo de como isto é feito, para quem goste de matemática: https://towardsdatascience.com/are-uuids-really-unique-57eb80fc2a87 (de notar que não é este o sistema que a app STAYAWAY COVID usa, mas algo ainda mais complexo e que consegue gerar ainda mais códigos aleatórios únicos — no entanto, o princípio é semelhante). Citando (e traduzindo) o ponto essencial deste método:

Uma amostra de 3.26*1016 UUIDs [universally unique identifiers] tem uma hipótese de 99.99% de não ter nenhum número duplicado. Para gerar esses UUIDs todos, um por segundo, levaria mil milhões de anos.

Ludi Rehak

(Nota: para quem não se lembra da notação científica, 1016 corresponde a um 1 seguido de 16 zeros, ou cerca de dez quadrilhões na notação da escala curta do Sistema Internacional de Unidades)

Se não há transmissão das posições respectivas, nem nenhum marcador de tempo, como é que o sistema então «sabe» quem é que esteve em contacto (a menos de 2 metros, durante pelo menos 15 minutos) com uma pessoa infectada? A resposta é simples: o cálculo é feito independentemente por cada telemóvel, estimando a distância entre as pessoas apenas pela força do sinal Bluetooth presente na intercomunicação. Ou seja, enquanto X e Y trocam os códigos entre si, o sistema «mede» a força do sinal Bluetooth, e se equivaler a menos de 2 metros de distância, coloca um cronómetro em funcionamento. Se se passaram quinze minutos sem que a força do sinal diminua (significando que as duas pessoas ficaram esse tempo todo em proximidade física), então os códigos de ambos são registados. Caso contrário, são descartados, o que significa que não andamos por aí a «carregar às costas» com códigos de pessoas das quais não estivémos «em contacto».

De notar que, como iremos ver mais adiante, é usado um método específico para impedir que o identificador do dispositivo Bluetooth seja registado em conjunto com a mensagem, o que permitiria a um utilizador malicioso fazer a correspondência entre um código e o telemóvel que gerou (e transmitiu) esse código.

Analisaremos mais tarde como é que depois as pessoas são notificadas de que estiveram realmente na presença de alguém infectado — tendo em conta que não guardam os números de telemóvel de ninguém e que os códigos são «apenas» números aleatórios, sem relação com nada nem niguém.

Tentativas de «quebrar o código»

Voltando ao exemplo original: X e Y, no exemplo acima, ficaram durante 15 minutos a menos de 2 m um do outro, e, ao final desse tempo, podem verificar os registos das suas respectivas apps (qualquer pessoa pode fazê-lo), mas só lá encontram justamente os códigos 1000 e 1010. Não têm nenhuma indicação de «quem é quem», embora ambos saibam que esses códigos lhes «pertencem»; há 50% de hipóteses do código 1000 pertencer a X e 50% de pertencer a Y, e o mesmo se passa com o código 1010.

Sem informação adicional, é impossível descobrir, com 100% de certeza, quem é quem.

Vamos ver se isto fica mais fácil se adicionarmos mais pessoas ao grupo. Ambos aproximam-se do amigo comum Z, pedem-lhe que faça reset à app, e ficam os três à conversa durante 15 minutos. Ora X e Y sabem que os seus códigos são 1010 ou 1000; qualquer terceiro código — pensam eles — será, pois, forçosamente de Z; Z não sabe nada (a app dele ainda tem zero registos), mas X e Y podem-lhe dizer qual é o seu código, e fica assim um código identificado! Depois fazem novo reset à app, X emparelha com Z, e descobrem o código de Y; etc. Certo?

X, Y e Z olham então para os registos das respectivas apps, e, para sua surpresa, todos eles têm a seguinte sequência de códigos:

1010 1000 0111 0100 1001

O que se passa? X e Y sabem evidentemente que os seus códigos são 1010 ou 1000, mas o que é que são os outros três códigos? A quem pertencem? Porventura Z não fez bem o reset da app? Vamos assumir que sim, o reset foi bem feito.

O que aconteceu foi o seguinte. 1010 e 1000 são duas interacções válidas, independentemente de pertencerem ou a X ou a Y, pelo que todos os três vão receber estes dois números. Até aqui tudo bem e tudo óbvio. Mas entretanto passaram-se 15 minutos (o tempo em que os amigos estavam à conversa), e o sistema gerou novos códigos aleatórios para X e Y, assim como o código de Z. Por isso agora todos andam com cinco códigos nas suas apps. Identificaram dois (embora não saibam precisamente se pertencem a X ou a Y), mas dos três «novos» códigos só podem afirmar que pertençam a X, Y ou Z, mas agora com uma probabilidade mais baixa, ou seja, de apenas 33%.

Se todos se afastarem e voltarem a juntar-se, bom, vão surgir mais e mais números (três novos por cada interacção); se fizerem o reset para «recomeçar» com uma sequência nova, vai sempre acontecer o mesmo que anteriormente.

Se fizerem com 4 pessoas… ainda pior. E o mesmo acontece à medida que vão fazendo com mais e mais pessoas — a probabilidade de conseguirem identificar correctamente os códigos de cada um diminui com o número de contactos que fizerem.

Mas vamos agora assumir que X e Y estão mesmo interessados em identificar o maior número de pessoas que conseguirem, e inventam o seguinte esquema:

X e Y juntam-se a menos de 2 metros um do outro e trocam os códigos entre si, e pedem a Z, mais afastado, que faça o reset da aplicação exactamente ao mesmo tempo. Depois juntam-se os três. Têm de esperar 15 minutos até as respectivas apps conseguirem detectar que Z também está a menos de 2 metros de X e Y, e, com sorte (ou engenho… hackando a app…), pode ser que consigam detectar o código de Z até que a app mude os códigos dos 3 (o que acontece justamente ao fim de 15 minutos, se todos fizeram reset ao mesmo tempo). Há, pois, uma possibilidade de «apanhar» o terceiro código, mesmo que por um fugaz momento, e sabe-se que este corresponde a Z, com 100% de probabilidade!

Por um fugaz momento. Depois as apps mudam os códigos todos. De qualquer das formas, ficou associado um código a uma pessoa. Como X, Y e Z conhecem-se pessoalmente, tomam nota do código, da data em que se juntaram, e verificam a localização onde estão. Se X ou Y receberem uma notificação de que estiveram na presença de alguém infectado, e nunca tiverem acrescentado mais nenhuns códigos, em teoria, se receberam a notificação, foi porque Z foi infectado — só pode ter sido ele. Isto será verdade nos próximos 15 dias. Podemos, pois, admitir a possibilidade de meter numa sala um enorme número de pessoas e coordená-las perfeitamente de forma a conseguir obter os códigos de quase todos. Se, no limite, conseguíssemos colocar todas as pessoas do país na mesma sala ao mesmo tempo, poderíamos ter os códigos de todos; na impossibilidade de o fazer, podemos imaginar um cenário em que vários grupos de pessoas espalhadas pelo país se juntam, obtêm os seus códigos, e enviam-nos para um site criado por X e Y, em que colocam os códigos que interceptaram (assim como os respectivos nomes das pessoas a que correspondem esses códigos), permitindo assim criar uma base de dados geral de residentes em Portugal que identificará pelo nome todos os que forem infectados num período de 14 dias; depois tem de se fazer tudo desde o início…

A ideia neste cenário é que podemos não saber qual é o código no momento presente de todas as pessoas, mas pelo menos, se alguma delas for infectada, saberemos quem foi.

As «falhas» neste método para enganar o sistema, claro está, são:

  1. Presume-se que as pessoas que participem nisto consigam fazer o reset no timing preciso para obter os códigos a um determinado instante no tempo (não será trivial; talvez se possa assumir que seja desenvolvida uma app «pirata» que faça essa sincronização automaticamente, e que seria instalada por todos os participantes…)
  2. Está-se a assumir que as pessoas, já naturalmente desconfiadas que o Governo, as operadoras, a Google, a Apple, etc. consigam «roubar» todos os dados, sejam «persuadidas» a entregarem os seus dados pessoais a X e a Y, perfeitos estranhos (e que ainda por cima poderão sugerir a instalação de uma app pirata para ajudar na sincronização…), apenas em troca de saberem o nome das pessoas infectadas…

Daí justamente os auditores suíços terem achado que este tipo de captura de informação usando timings precisos seja provável, mas de muito baixo risco.

E de notar também que o sistema acima pode até atribuir nomes das pessoas aos códigos (deixando estes de serem anónimos), mas, apesar de ser possível saber o dia, a hora e o local em que enviaram os seus dados para o site pirata, não é possível de saber quando é que as pessoas estiveram em contacto com a pessoa infectada, nem onde, muito menos, claro, ter uma ideia onde é que cada pessoa esteve (nos últimos 14 dias), com quem se encontrou, etc. Essa informação pura e simplesmente não existe!

Procurando a relação entre pessoas

Quando se faz rastreamento manual, não se obtém apenas uma lista de pessoas que podem estar ou não infectadas, mas também se obtém a relação entre estas — a cadeia de transmissão, ou, como se diz em matemática, um grafo. Evidentemente que esta informação é importante para os especialistas da área da saúde, mas o acesso à mesma por parte dos utilizadores é um sério problema de violação de privacidade.

Como é que esta app evita que isso aconteça?

Vejamos o seguinte caso: embora, no início do exemplo, conhecemos «alguma» relação — X e Y encontraram-se num certo local a dada hora e obtiveram o código de Z, que estava nesse sítio à mesma hora — a partir do momento em que X, Y e Z se separam, já não é «trivial» fazer um grafo de relações entre as pessoas, pois estas relações tornam-se demasiado complexas, embora não necessariamente a um ritmo exponencial — afinal de contas, se estivermos na proximidade de um grupo grande de pessoas, tipo num autocarro, todos vão trocar os mesmos códigos entre si, mais outros tantos das interacções que cada uma dessas pessoas teve (o sistema descarta duplicados). Numa situação em que, por exemplo, algumas pessoas, antes de irem para o autocarro, passaram no café da D. Jacinta para comer um bolo, «levam consigo» também o código da D. Jacinta; quando chegam ao autocarro, o código da D. Jacinta é distribuído por todos; quando saiem do autocarro, têm o código da D. Jacinta quer tenham estado em contacto com ela ou não. Quando chegarem a casa, «passam» o código da D. Jacinta para todos os seus familiares — mesmo que nenhum deles tenha estado em contacto com a D. Jacinta!

Vamos assumir um cenário em que as crianças de um casal cujo pai esteve no referido autocarro, A e B, vão no dia seguinte para a escola. Ora se alguém entretanto tivesse descoberto o código da D. Jacinta, vamos imaginar que chegam junto de A, olham para os códigos, e dizem: «olha, estiveste com a D. Jacinta!» A vai dizer que não, não esteve. «Então foi o teu pai, a tua mãe, ou a tua irmã». E, de facto, olhando para os telemóveis de todos eles, todos têm o código da D. Jacinta. Mas na realidade nenhum deles esteve no café dela! Foi «alguém» que esteve no autocarro com o pai — mas quem? A maioria serão perfeitos desconhecidos; mesmo que o pai identifique um ou outro vizinho… de que é que isso serve? Os vizinhos até poderiam ser contactados, um a um, para ver se alguém se lembra de ter estado com a D. Jacinta, e, eventualmente, obter-se assim um grafo parcial: D. Jacinta → vizinho → pai → crianças A e B. Mas a trabalheira que dá reconstruir só um pedacinho desse grafo!…

Ou seja: podemos assumir cenários em que alguns códigos até sejam «desanonimizados», mas não é possível, mesmo estando na posse de um grande número de códigos, de perceber quais as relações entre eles. Como os códigos não têm nem data, nem posição, nem nada que os associe a nada, sem «informação adicional», é impossível reconstruir um grafo de contactos apenas pelos códigos…

Isto é fundamental de perceber, pois é o mecanismo que permite, por um lado, garantir que as pessoas não só não podem ser «seguidas», como é extremamente difícil saber quem esteve em contacto com quem, em que altura, em que local — pelo menos sem dados adicionais (no exemplo acima, para o pequeno grafo que temos, podemos saber que a D. Jacinta tem um café e onde é que este fica; e sabemos a hora aproximada em que o que vizinho comeu um bolo, pois temos o horário dos autocarros, e o pai saberá mais ou menos a que hora é que o apanhou).

E o Governo, consegue obter essas relações?

Uma coisa é mostrar que mesmo um indivíduo malicioso com uma app «modificada» não consegue obter informação da relação entre as pessoas, nem as consegue «seguir» de forma alguma. Poderá, ocasionalmente, obter alguma informação, mas será sempre escassa, limitada no tempo e no espaço, e nas pessoas que foram identificadas, e, de qualquer das formas, mais cedo ou mais tarde toda a informação será apagada (quando os códigos mudam todos) e será difícil (mas não 100% impossível) «recuperar» a continuidade das relações entre pessoas. Por outras palavras: sim, é possível, do ponto de vista puramente teórico, conceber que se consiga hackar a app de forma a obter alguns destes dados, de forma muito esporádica, mas não é possível obter todos os dados, mesmo que sejam todos os dados apenas de uma pessoa.

Seguimos então para a questão seguinte: a comunicação com o servidor! Será que conseguimos obter alguns dados adicionais? Por outras palavras: será que o Governo, na posse de todos os dados, consegue não só reconstruir os grafos de interligação entre as pessoas, e, melhor do que isso, consegue descobrir onde é que cada pessoa esteve?

Vamos assumir que temos 6 pessoas com a app instalada (o nosso universo), nomeadas de A a B. Vamos assumir que os códigos são como no exemplo do início: 4 dígitos binários, o que dá para 16 códigos diferentes. Como cada app gera o seu próprio código aleatoriamente de 15 em 15 minutos, qualquer um dos 16 códigos pode ter sido atribuído, ao longo do dia, a qualquer pessoa.

Pelo menos uma vez por dia, as 6 apps comunicam com o servidor. Não o farão ao mesmo tempo, pelo contrário, será também aleatório (e no dia seguinte, será a uma hora completamente diferente). Mas suponhamos que, ao final do dia, os utilizadores A a F tenham nos seus telemóveis as seguintes sequências:

A0000001000110101100111001111
B00110100011001111100


C00000001010001011001101011011111
D001001001010101111001101

E010001100111




F00100011010001010111100111001101

O Governo, na posse destes dados, será que consegue…

  1. Saber que códigos pertencem a cada utilizador?
  2. Perceber quem é que esteve em contacto com quem?
  3. Ter uma noção de onde é que as pessoas estiveram, e quando?

Olhando para o exemplo acima, podemos imediatamente responder à pergunta 3: não. O melhor que o Governo pode saber, pelo exemplo acima, é que determinados códigos foram «vistos» por determinado utilizador, até ao momento em que os telemóveis contactaram com o servidor, no espaço dos últimos quinze dias.

Isto é muito pouca informação! Nomeadamente, o Governo não sabe quem esteve em contacto com quem (pelo menos não de toda a gente).

Olhe de novo para a tabela acima.

Pode reparar que, por exemplo, tanto A como C têm os códigos 0000 e 1001. Se nos lembrarmos dos exemplos anteriores, podemos imaginar que estes códigos pertencem a A e C — podemos é não saber qual é que pertence a A, ou qual pertence a C, mas podemos pressupor, com 50% de probabilidade, qual o código que pertence a A e qual a C.

B e E também partilham três códigos, 0100, 0110 e 0111. Podemos, pois, pensar que pelo menos dois destes três códigos pertencem a B e E (agora com menor probabilidade, pois pode ser uma de três combinações possíveis, 0100/0110, 0100/0111 ou 0110/0111; e para cada um destes pares, não sabemos quem é B, nem quem é E).

Como sabemos que A e C têm 0000 e 1001, e que nem B nem E têm esses códigos, poderíamos dizer: «bom, B e E nunca estiveram nem em contacto com A, nem com C». Por um processo de eliminação, pois, poderíamos chegar a alguma informação sobre as relações entre as várias pessoas!

Mas às vezes isto não bate certo: por exemplo, A e B partilham dois códigos, 0011 e 1100. Isto significa que estiveram em contacto um com o outro! Ora no raciocínio anterior, tínhamos chegado à conclusão que nem A, nem C tinham estado em contacto com B/E, apenas por eliminação dos códigos comuns de A/C (que são diferentes). No entanto, claramente A esteve a menos de dois metros de B, durante um período de quinze minutos, pois trocaram entre si dois códigos 0011 e 1100! Como explicar esta inconsistência?

Uma possibilidade é existirem pessoas fora desta tabela, digamos, um utilizador G, que tivesse o código 0011, e que tivesse estado tanto com A como com C, mas não ao mesmo tempo com ambos. Isto já ajudaria a estabelecer mais relações causais (e eliminar outras). Mas viola o nosso pressuposto inicial: de que o universo de pessoas é finito (tal como a população portuguesa — ou europeia, ou do mundo), e, no nosso caso, tínhamos apenas 6 indivíduos.

A outra possibilidade é que este código 0011 seja «antigo». Vamos supor que D é amigo de A e de B e que esteve em contacto com eles (separadamente). Na altura, transmitiu a cada um deles o código 0011 que era o seu código, mas, entretanto, passou-se mais de um dia, e agora o seu novo código é o 1010. D ainda tem o código 1010, mas já «perdeu» o 0011 — embora este último continue a ser válido no sistema, como iremos ver mais à frente.

Há, portanto, neste processo de «desanonimização», vários passos «para a frente e para trás», pura e simplesmente porque não podemos associar temporalidade aos contactos. Isto torna o problema bicudo, como podemos ver neste caso em particular:

  • A e B partilham 0011 e 1100
  • A e C partilham 0000 e 1001

Ora isso significa que A, durante o período considerado, também mudou de código (o que é normal: acontece pelo menos uma vez por dia!). Por exemplo, quando contactou B, o seu código era o 0011; mas quando contactou C, já era 0000 (de notar que isto é uma possibilidade entre 4, ou 25% de hipóteses de termos acertado no processo de mudança de código).

Qual dos dois contactos foi feito em primeiro lugar?

É evidente que com os dados de apenas um dia não conseguimos chegar a grandes conclusões; no entanto, é plausível acreditar que, tendo em conta que o Governo tem os contactos de todos os dias (num intervalo de 14 dias), podemos ver os dados do dia anterior, e, se A e C já partilhavam nesse dia os códigos 0000 e 1001, então é possível que o contacto de A com C tenha acontecido antes do contacto de A com B, com pelo menos 24 horas de diferença.

Isto significa que não apenas temos de ter em conta a dificuldade de estabelecer um grafo entre as relações, como é também importante estabelecer um grafo da mudança de códigos (por utilizador) ao longo do tempo. Mas, como podemos ver no exemplo anterior, mesmo com a totalidade dos dados presente no servidor, o Governo terá muita dificuldade em conseguir completar estes dados, e, mesmo que o consiga fazer com algoritmos sofisticados, a informação será muito vaga. A encontrou-se com C, sim… mas aonde? E a que horas? Sabemos que foi, pelo menos, um dia antes de A se ter encontrado com B… mas onde é que estavam nessa altura? E que «altura» é essa? Poderíamos eventualmente inferir que A, B e C se conhecem? Ou A e B estavam num supermercado e eram completos estranhos; enquanto que A e C são amigos inseparáveis (ou mesmo um casal), pelo que vamos encontrar todos os dias códigos comuns entre A e C, mas não necessariamente entre A e B?

Por outras palavras: sim, é evidente que conseguimos obter mais alguma informação sobre as relações entre pessoas se tivermos a totalidade destes dados.

O «problema» (da perspectiva de um Governo totalitário, bem entendido!) é que nem sequer temos estes dados no servidor central!

É que na realidade os utilizadores da app só transferem os códigos que possuem para o servidor caso tenham sido infectados. Ou seja, se no dia em que fizémos aquela tabela dos códigos nenhuma pessoa tenha sido infectada nesse dia, então o servidor central não recebe nenhuns dados — nem estes, nem quaisquer outros. Nos registos do servidor ficará um «buraco» na base de dados: «no dia D, nada a assinalar». Como a esmagadora maioria das pessoas não estará infectada (ou assim o esperamos!), ou, mais precisamente, não terá sido infectada todos os dias, a informação enviada para o servidor é muito parcial. De notar que, quando uma pessoa recebe o aviso de que está infectada, as instruções são para ligar para a Linha SNS 24, isolar-se enquanto aguarda o teste de SARS-CoV-2, e desinstalar a aplicação. Poderão haver pessoas que não respeitem nenhuma dessas regras, mas vamos assumir que a maioria as cumpra: o objectivo, afinal de contas, é fazer uma pré-triagem de toda a população, tentando descobrir quais são os potenciais infectados, e retirá-los temporariamente de circulação para não infectarem mais pessoas! A app, uma vez tendo colocado uma pessoa potencialmente fora de circulação, não serve para mais nada (depois da pessoa ter sido testada, se o teste for negativo, pode voltar a instalar a app de novo e a fazer a sua vida normal; se for positivo, então fica de quarentena em casa, ou, se tiver já com sintomas suficientemente graves, fica no hospital; uma vez tendo recuperado, pode voltar a instalar a app).

Faço notar que este exemplo é extremamente simplista. Não só o número de utilizadores é muito maior — serão de momento à volta de um milhão — como os códigos são muito mais compridos, e, pelo que li algures no código-fonte da app e num artigo que explicava o seu funcionamento, aparentemente os códigos não mudam todos os dias: é «pior» do que isso, ou seja, uma vez por dia é gerada uma chave encriptada, com a qual são depois assinados digitalmente 144 novos códigos diários — estes são depois «distribuídos» aleatoriamente sempre que houver um contacto.

A assinatura digital é um dos vários mecanismos para evitar que alguém se faça passar por nós e «espalhe» códigos falsos como se fôssemos nós a fazê-lo: como a assinatura usa encriptação com chaves públicas e privadas, a chave privada fica no nosso telemóvel — à qual nenhum pirata informático consegue aceder — enquanto que os códigos são assinados com a chave pública. Isto faz com que qualquer telemóvel possa verificar se recebeu um código «nosso» que seja válido ou não, mas é impossível de «forjar» assinaturas válidas sem saber a nossa chave privada. De notar que não sei exactamente como é que este mecanismo funciona ao pormenor — as informações de como exactamente estas mensagens são validadas quanto à sua autenticidade são um pouco vagas, e suponho que grande parte deste processo esteja lá no tal código-fonte da Google e da Apple que eles não divulgam (numa tentativa de obrigar os piratas informáticos a perderem mais tempo a tentar «adivinhar» como é que o mecanismo funciona — há muitas maneiras de fazer isto, e o pirata terá de testar todas, uma por uma, até saber como atacar o mecanismo).

Resumindo esta secção:

  • Mesmo na posse de um grande número de códigos numa base de dados, e mesmo assumindo que se possa correr um software muito sofisticado para tentar encontrar padrões e relações entre as pessoas, nem sequer o Governo consegue obter uma «visão geral» de onde é que as pessoas estiveram, com quem estiveram, e quando é que contactaram umas com as outras. Consegue-se eventualmente de forma pontual estabelecer algumas relações entre algumas pessoas (não podemos excluir essa hipótese!), mas sem os dados nem do nº de telemóvel, nem da localização das pessoas no momento em que trocaram códigos, será extremamente difícil a um Governo obter muito mais do que a informação de que «a pessoa A falou com a pessoa B nas últimas 24 horas» — sem sequer ter uma ideia quem é A e quem é B.
  • De forma similar, mesmo «atacando» um telemóvel específico, não se consegue obter esta informação da app propriamente dita — mesmo em relação a uma pessoa apenas — sendo necessário ao pirata informático «descer» a um nível mais profundo, onde tem acesso directo à informação de GPS, por exemplo. Mas se já tem um método para aceder a esse nível, de pouco lhe serve atacar a app propriamente dita. Isto quer dizer que mesmo que a app tenha eventuais vulnerabilidades que de momento desconhecemos, não é através da app que um potencial pirata informático vai obter a informação que precisa para seguir pessoas, saber com quem a pessoa contactou, etc.
  • Finalmente, para evitar que o sistema seja subvertido, enviando mensagens falsas para outros utilizadores (mesmo que seja só como «brincadeira de mau gosto»), ou, inversamente, para ler as mensagens que as pessoas estão a enviar umas às outras, existe um mecanismo de assinatura digital das mensagens, que, embora eu não perceba como é que funciona na totalidade, permite pelo menos que a app «saiba» se as mensagens que recebeu vieram de uma fonte credível; por sua vez, se as suas mensagens forem captadas, é difícil a um potencial pirata informático conseguir obter muita informação a partir destas (pois é possível que estas mensagens venham encriptadas e que o pirata não tenha a chave que lhe permita desencriptá-las).

Faço ainda notar o seguinte:

  • Há mais mecanismos para «baralhar» ou «confundir» os piratas informáticos; um deles descobri por acaso, quando estava a ler o código-fonte, e depois fui confirmar nas especificações do protocolo de comunicações. Já explico melhor.
  • Os exemplos que mostram que o sistema pode ser hackado, como um famoso vídeo que surgiu no início de Setembro a demonstrar uma vulnerabilidade do sistema conhecida pelo menos desde Junho, não obtiveram «os dados todos», mas apenas conseguiram seguir uma pessoa à distância durante algum tempo, baseando-se apenas nas mensagens enviadas por Bluetooth. De notar que neste caso não foram desencriptadas quaisquer mensagens; tudo o que se fez foi aproveitar um período microscópico de tempo em que um telemóvel mais antigo pode eventualmente dar a conhecer o momento em que os códigos mudam, conseguindo-se assim, nessa fracção de tempo, saber qual é o código «antigo» e qual o «novo», e a que identificador Bluetooth está associado. Esta é uma vulnerabilidade de risco muito baixo, já que, para efectivamente «seguir» uma pessoa desta forma (assumindo que tem um telemóvel mais antigo) seria preciso ter uma rede de antenas Bluetooth com cobertura global… mas o ponto importante é perceber que apesar de eventualmente ser possível de seguir uma pessoa desta forma, ainda não foi demonstrada nenhuma forma de desencriptar as mensagens que contém os códigos, e por sua vez, associar os códigos a pessoas concretas. Não quer dizer que isso não seja possível (lá está, não existem sistemas 100% seguros); para já, não só o risco disso acontecer é extremamente baixo, como requer meios altamente sofisticados, que não estão ao alcance do comum mortal.

Como é que o sistema sabe que as pessoas estão infectadas?

Vamos agora analisar melhor qual o papel do servidor central neste processo, para depois também perceber porque é que não é assim tão fácil nem trivial «subverter» o sistema todo.

Para que as apps saibam quem foi infectado ou não, precisam de ter uma lista de códigos de todas as pessoas que o sistema saiba que testaram positivo ao SARS-CoV-2 (vamos depois ver como é que o sistema sabe isso).

Todos os dias (se bem que a uma hora diferente, escolhida aleatoriamente) a app faz um contacto com o servidor (na realidade, actualmente, trata-se não de um único servidor, mas sim de um cluster de servidores correndo código livre e aberto e instalado na Imprensa Nacional Casa da Moeda, de acordo com as especificações oficiais; para simplificar vou-lhe chamar «o servidor» apesar de poder ser mais do que um) e descarrega uma lista de todos os códigos novos que foram recebidos pelo sistema desde o dia anterior. Isto é uma base de dados incremental (que faz reset de 14 em 14 dias), ou seja, a app só vai buscar aquilo que precisa (os códigos que lhe faltam), não descarrega a base de dados toda. Escusado será dizer que este descarregamento é feito através de um canal seguro, com informação encriptada, com uma chave privada do lado do servidor, e uma chave pública que (provavelmente) muda todos os dias.

Os detalhes exactos da implementação são da responsabilidade de cada país, ou seja, a partir deste ponto, a Google e a Apple deixam de estar associados ao processo. Se, até agora, havia uma vaga hipótese (muito vaga mesmo!) do fabricante do sistema operativo do nosso telemóvel, de alguma forma maliciosa, fazer uma cópia dos códigos para usos indevidos — algo que foi testado exaustivamente pelos diversos auditores, que concluíram que isso não acontecia, mas nunca se sabe… — a partir deste momento a Google e a Apple não sabem o que se passa com o servidor. É certo que teoricamente poderiam obter estes dados após uma desencriptação com sucesso; mas não é possível à Google e à Apple «atacarem» maliciosamente o servidor por esta via.

No entanto, este passo obviamente que inclui algumas vulnerabilidades. Nada é perfeito, e o certo é que, ao contactar o servidor da INCM, a comunicação faz-se via Internet (seja na rede móvel de dados, seja por Wi-Fi). Logo, no mínimo dos mínimos, o servidor vai saber qual o endereço IP usado pelo nosso telemóvel no momento da comunicação (momento esse que também fica registado). Na realidade, pelo que pude observar, há mais um dado que é enviado: o sistema operativo que usamos no nosso telemóvel (Android ou iOS), e, provavelmente, mais alguma coisinha que até nos permite identificar o modelo do telemóvel. Não sei para que isto serve, excepto para uma questão de estatísticas (por exemplo, saber se as pessoas estão todas a usar a versão mais recente dos respectivos sistemas operativos — pois as versões antigas podem ter a tal vulnerabilidade do timing das mensagens Bluetooth que permite, por uma fracção infinitesimal de tempo, saber qual era o código associado ao identificador Bluetooth antigo e qual que está associado ao novo).

Ora «saber o endereço IP» é relativamente inócuo, excepto em circunstâncias muito específicas. Regra geral, os endereços IP podem dar uma localização aproximada do local onde a pessoa se encontra — normalmente é difícil «descer» abaixo do nível da cidade, por exemplo. A informação também nem sempre é rigorosamente correcta: apesar de morar em Odivelas, o meu endereço IP de casa é frequentemente reportado (consoante a base de dados usada) como «Santo António dos Cavaleiros», «Loures», ou simplesmente «Lisboa». Digamos que temos uma margem de erro de ±20 quilómetros usando este sistema de georeferenciação, que é bastante primitivo — baseia-se num registo voluntário por parte dos fornecedor do serviço de Internet que indicam, para cada endereço IP que detêm, a sua localização aproximada.

Embora a informação do país em que a pessoa está a fazer a comunicação seja bastante correcta, já a informação da cidade pode ser mesmo muito vaga.

No entanto, se determinado utilizador da app estiver dentro da rede Wi-Fi de uma entidade — como uma empresa, uma escola/universidade, um hospital, um centro comercial ou supermercado, etc. — já será mais fácil determinar onde se encontra, pois, regra geral, é possível determinar que endereços IP pertencem a certas entidades, desde que estas tenham as suas redes Wi-Fi «abertas» ao público e com um endereço IP fixo.

Uma particularidade deste segundo caso é que todas as pessoas dentro da mesma entidade vão apresentar o mesmo endereço IP. Isto não é verdade para 100% dos casos, mas é o habitual em quase todos os casos (nalguns casos as entidades podem ter mais de uma rede Wi-Fi ou mais de um endereço IP; mesmo assim, saber-se-á a que entidade pertence, mas não mais do que isto). Uma dezena de alunos espalhados num campus universitário aparecerão no sistema como todos estando «na universidade», mas não se saberá quem é quem, ou exactamente em que edifício ou sala de aula estão.

Resumindo: se estamos na rede Wi-Fi de casa, partilhada por um número reduzido de pessoas (geralmente só a nossa família), é mais fácil saber quem fez a comunicação (ou melhor, qual telemóvel), mas a localização é bastante imprecisa; já se estivermos numa rede Wi-Fi pública, será possível identificar com precisão a entidade a que pertence esse endereço IP, mas todas as pessoas na mesma entidade à mesma altura terão exactamente o mesmo endereço IP. Do ponto de vista do Governo, pois, uma vez que nos desloquemos de casa (que saberão muito vagamente onde é) para o Centro Comercial Colombo (que saberão exactamente onde é, basta ver a morada…), para todos os efeitos «desaparecemos» no meio da infinitude de outras pessoas também no Centro Comercial Colombo, todas elas partilhando (temporariamente) o mesmo endereço IP. Ou seja, apesar do local ser, nesse caso, conhecido, há um certo anonimato, fruto do facto de tantas pessoas terem o mesmo endereço…

Voltemos a nossa tabela das pessoas A a F, e vamos imaginar que o servidor, em dado momento, «sabe» que as sequências 0011 e 1101 correspondem a pessoas com diagnóstico positivo (já vamos ver como é que isto funciona) ou que estiveram na proximidade de pessoas com diagnóstico positivo. Cada uma das 6 pessoas descarrega, pois, a sequência 0011 e 1101.

Agora o que app faz é comparar cada um destes códigos com aqueles que já tem no telemóvel. Se houver algum que coincida, a app avisa o utilizador para contactar a Linha SNS 24. Vejamos a tabela seguinte:

A0000001000110101100111001111
B00110100011001111100


C00000001010001011001101011011111
D001001001010101111001101

E010001100111




F00100011010001010111100111001101
As células coloridas representam pessoas infectadas com as quais houve contacto

Ups! Neste dia, todas as pessoas excepto E vão ser notificadas pela app para contactarem a Linha SNS 24!

De notar o caso interessante de F: tem duas coincidências. Mas não sabemos absolutamente mais nada sobre estas. Podem ter sido duas pessoas diferentes. Podem ser dois códigos correspondentes à mesma pessoa, mas em períodos de tempo diferentes; por exemplo, alguém com quem estivémos de manhã e à tarde em proximidade — imaginemos, no cenário da pastelaria da D. Jacinta, que alguém lá comeu um bolo de manhã, depois de sair do autocarro e antes de ir para o emprego; e que essa pessoa, à tarde, no regresso do emprego, antes de se meter no autocarro, lá foi comer outro bolo. A D. Jacinta é a «mesma» pessoa; no entanto, à tarde o código dela era diferente do da manhã. Mas pode ter sido um caso mais complicado: se nos relembrarmos da pequena história com a D. Jacinta, podemos imaginar que o pai da história só esteve uma vez com a D. Jacinta. No entanto, ia no autocarro com o vizinho, que também esteve uma vez com a D. Jacinta. Quando o pai se encontra com o vizinho, para além do código da D. Jacinta que já tem, recebe igualmente o código da D. Jacinta que foi recebido pelo vizinho (que não é o mesmo).

Com uma população tão pequena, podemos já imaginar inúmeros cenários plausíveis sobre a forma de como ocorreram as sequências de contágio e a propagação dessa indicação pelas apps. Não sou matemático, mas aposto como o número de combinações pode ser perto de infinitas, pois pouco nos limita a «imaginação» sobre o que pode ter acontecido, e por qual sequência; sem ter acesso a mais informação sobre o sistema, é-me impossível reconstruir seja o percurso das 6 pessoas, seja a forma como ocorreu o contágio. Mais ainda: apesar das 6 pessoas receberem, no mesmo dia (embora não à mesma hora), a mesma sequência de pessoas infectadas, a verdade é que nenhum deles consegue — mesmo comparando os dados! — identificar quem é que infectou quem.

Um pirata informático que obtenha acesso ilegítimo aos 6 telemóveis e que também saiba a sequência de códigos de pessoas infectadas nesse dia estará na mesma situação: pura e simplesmente não consegue estabelecer nenhuma relação. Pode, no entanto, saber que pessoas é que o Governo pensa estarem infectadas. Ou seja, se tiver acesso ilegítimo ao telemóvel de A, e conseguir ler os códigos tanto detidos pelo mesmo, como a sequência recebida do servidor na INCM, então sabe que A está potencialmente infectado. Não sabe mais nada.

Mas o Governo ainda sabe menos. É que o Governo não tem acesso aos códigos na app de cada cidadão. Sim, é verdade que «sabe» que os identificadores 0011 e 1101 correspondem a pessoas infectadas. Sim, até pode, a dada altura, ter uma noção dos endereços IP de quem descarregou a lista de códigos de suspeitos (e, através desse endereço IP, ter uma ideia aproximada de onde se encontrava o utilizador quando descarregou os códigos — em determinado dia, durante um mero instante). Mas além disto não sabe mais nada.

Até aqui tudo bem. Mas como é que o servidor «sabe» quem é que está infectado?

A lista de códigos de quem está infectado

É importante explicar que desta parte em diante, a responsabilidade de todos os procedimentos informáticos já não é da Apple ou da Google — mas sim do Governo e das entidades que foram contratadas para desenvolverem a app. Aliás, na realidade, até este ponto, não precisamos verdadeiramente da app em si: é que o processo todo de troca de códigos entre utilizadores, os cálculos dos timings todos, a gestão das chaves de encriptação, etc. é tudo feito a nível do sistema operativo do smartphone. Há obviamente alguma articulação com a entidade responsável pelo rastreamento da COVID-19 em Portugal (por exemplo, é preciso saber qual o servidor onde se vão buscar os códigos das pessoas infectadas), mas, grosso modo, esta funcionalidade de base é já fornecida pelo protocolo Google Apple Exposure Notifications.

Tanto é assim que a Google e a Apple, conscientes de que alguns países (ou regiões autónomas) podem ter dificuldades em desenvolver (e manter) as suas próprias apps, oferecem a essas entidades um serviço que não precisa de app nenhuma para funcionar.

Além disso, uma vantagem de ter vários países/regiões a usarem o mesmo protocolo de base significa que, em princípio, o sistema de rastreamento funcionará entre países. Por exemplo, tanto Portugal como Espanha têm a sua própria app, mas ambas comunicam com os respectivos sistemas nacionais de saúde através da tecnologia da Google e Apple. Isto significa que um português e um espanhol, estejam onde estiverem, podem trocar códigos entre si; se forem infectados, os códigos de ambos são enviados para a autoridade respectiva (o formato dos códigos é o mesmo, seja em que país se estiver) e podem ser usados — em teoria pelo menos — para alertar pessoas em ambos os países. Para isso bastaria Portugal e Espanha entrarem em acordo para a troca desses dados. É mais uma questão política do que propriamente uma questão tecnológica. Se ambos os Governos compreenderem que ter a lista de códigos de pessoas infectadas não tem qualquer problema real de segurança, então não haverá razão para impedir que estes dados sejam transferidos entre os diversos países. Aliás, tanto a Google como a Apple esperam que isso aconteça. O facto de, por exemplo, a nível europeu, se esteja a tentar uma harmonização entre um protocolo europeu (dp3t, uma iniciativa à qual Portugal também está associado) e o próprio sistema da Google/Apple (a STAYAWAY COVID, por exemplo, alegadamente usa os dois sistemas — não verifiquei isto no código), dá um sinal positivo à possível integração de, pelo menos, os códigos de pessoas infectadas de países europeus e alguns dos seus aliados mais próximos que usam a mesma tecnologia (como, por exemplo, o Canadá). Embora tenha lido comentários de várias partes a indicar o desejo dessa harmonização, com o apoio da Google/Apple, não vi ainda nenhuma notícia de alguma data concreta a partir da qual isto se torne uma realidade. De notar que os dois protocolos são mesmo muito parecidos, sendo que a diferença principal está nos detalhes e pormenores da implementação (por exemplo, o dp3t usa chaves bem menores), não no conceito em si.

Seja qual for o resultado destas conversações entre países e fornecedores de tecnologia, o que parece mais certo é que o modelo de funcionamento será essencialmente o seguinte: diariamente, o telemóvel contacta com o servidor da autoridade de saúde do seu país respectivo. Quando o faz, não envia nenhuns dados; apenas vai buscar uma lista de códigos de pessoas infectadas, e verifica se algum desses códigos condiz com os que já tem armazenados; se sim, avisa o utilizador para contactar a respectiva linha de saúde (em Portugal será sempre a Linha SNS 24, 808 24 24 24) para seguir os procedimentos recomendados para o país em questão.

Falta, pois, saber como é que estes códigos de pessoas infectadas «aparecem» nos servidores dos diversos países!

Ora aqui cada país pode ter uma abordagem radicalmente diferente. Em países com elevada consciência cívica (nota: não é o nosso caso!) pode-se pedir que sejam os próprios utilizadores a reportarem se estão doentes com COVID-19 ou não, a título estritamente voluntário. Quando o fazem, o seu telemóvel envia uma lista de todos os códigos que tem guardado, correspondendo a pessoas que estiveram em contacto com essa pessoa a menos de 2 metros e por mais de 15 minutos, assim como todos os seus próprios códigos (nunca esquecer que podem ser muitos, que tenham mudado ao longo dos últimos 15 dias… é necessário enviar todos).

É importante que não enviem rigorosamente mais nada. Nem a data, nem o local, nem o nome, nem sequer o nº do telemóvel, ou o seu IMEI, ou qualquer elemento que possa identificar o utilizador. Nem há diferença entre os códigos próprios e os códigos das outras pessoas. São todos transferidos de forma aleatória, e não há forma de distinguir uns dos outros. É isto que permite garantir que o Governo não só não saiba quem somos, mas também não sabe com quem estivémos em contacto.

Por exemplo, no «nosso» exemplo, imaginemos que E, que até agora escapou ileso da COVID-19, tem finalmente o azar de se encontrar com outra pessoa (que não usa a app e, logo, não está a ser considerado no nosso exemplo) infectada, e tem um teste positivo de COVID-19. Os códigos que envia então para o servidor na INCM são os seguintes:

0100 0110 0111

Com estes dados não se sabe qual dos códigos pertence a E. Sabemos que pelo menos um deles lhe pertence, e que muito provavelmente será o código «do dia». Os restantes códigos podem ser todos de E (justamente explicando porque é que, até agora, foi a única pessoa que não tinha sido infectada — não esteve em contacto com nenhuma das 5 restantes!). Ou podem ser outros códigos de outras pessoas, cuja relação não conhecemos (ou seja, essas pessoas entretanto já mudaram de código várias vezes, pelo que não temos a menor ideia de qual código têm agora, mas a app também mantém uma lista desses códigos antigos).

É certo que há mais um elemento que não podemos ocultar: o endereço IP do telemóvel, no momento em que comunicamos que estamos infectados. Em teoria, se todas as nossas transmissões para o servidor na INCM forem sempre feitas a partir do mesmo endereço IP (por exemplo, se estivermos sempre em casa quando isso acontece), há uma possibilidade remota do Governo ter pelo menos uma ideia vaga da origem das pessoas infectadas; é suficiente para obter algumas estatísticas relativamente ao número de pessoas (que usam a app) infectadas e a localização geográfica aproximada — mas será pouco mais do que isso que se consegue «descobrir». Nem sequer sabemos, no nosso exemplo, quantas pessoas foram infectadas por E o facto de enviarmos três códigos (ou trezentos, ou três mil) não quer dizer que estivémos em contacto com três pessoas infectadas. Como vimos, podemos nem sequer ter estado em contacto com ninguém nas últimas 34 horas e mesmo assim termos códigos de pessoas potencialmente infectadas (logo, nós também podemos estar potencialmente infectados!).

Fiz um teste ao SARS-CoV-2 e deu positivo. E agora?

Na secção anterior só falámos dos códigos que estão arquivados no servidor central, e a forma como estes são obtidos para comparação por parte das apps. Mas não respondemos à pergunta de como é que os códigos são introduzidos no sistema!

A Google e a Apple não também não fazem nenhuma «sugestão» de como implementar isto — basicamente porque cada país tem a sua própria legislação relativamente à protecção de dados dos seus cidadãos, nomeadamente dados médicos.

O sistema mais simples, pois, assenta no civismo e voluntariado. Alguém que use uma app num país em que há relativamente pouca preocupação deontológica com a forma como estes dados são guardados (considerando que o risco de ter acesso a algum elemento «importante» é baixo) podem simplesmente sugerir aos seus cidadãos, quando receberem os resultados do teste ao SARS-CoV-2 que fizerem e se este for positivo, que carreguem num botão qualquer da app a confirmar que estão infectados. O que acontece de seguida é que a app vai enviar todos os códigos que tem guardados em memória — representando o histórico das pessoas com as quais houve uma «cadeia de transmissão» nos últimos 14 dias, mesmo que não façamos a menor ideia de quem é que contagiou quem, ou se temos diversos códigos diferentes para a mesma pessoa, etc… — para o servidor central.

Poder-se-ia pensar, de uma forma simplista, que, de alguma forma mágica, o servidor central iria agora «avisar» as pessoas todas desta lista que estiveram em contacto com alguém infectado. Mas isso implicaria que o servidor soubesse, pelo menos, o endereço IP (idealmente o telemóvel!) correspondente a cada um dos códigos. Como essa informação não está disponível, o servidor apenas os arquiva… e fica à espera, pacientemente, de que todos os utilizadores, ao longo de 24 horas, mais cedo ou mais tarde contactem o servidor para descarregar a lista actualizada.

O problema com este sistema é essencialmente evitar que existam «engraçadinhos» que enviem uma indicação falsa de que estão infectados, para assustar amigos e familiares (e mais umas não sei quantas pessoas desconhecidas…). Em países com elevado nível de civismo, os Governos confiam que os seus cidadãos jamais abusariam do sistema desta forma, pelo que podem ter este tipo de sistema, confiantes que as pessoas se comportem com dignidade e civismo (e que os casos excepcionais sejam poucos e relativamente fáceis de «apagar» do sistema); mas obviamente que esse não é o caso de Portugal, pelo que é preciso criar um novo sistema.

Uma das recomendações do tal consórcio dp3t vai no sentido de garantir a veracidade do diagnóstico antes da pessoa poder carregar no tal botão que indica ao sistema de que está infectado. Por exemplo, nalguns países, o que se pode fazer é pedir ao utilizador que coloque um identificador qualquer relativamente a um teste que deu positivo — o nº do teste, o nº da factura-recibo, uma indicação qualquer que esteja no seu teste e que possa eventualmente ser confirmado a posteriori; caso persistam dúvidas se a pessoa em questão fez mesmo um teste e que este é positivo, poder-se-á verificar essa informação independentemente, pedindo à pessoa que apresente então o documento em questão. Outra alternativa seria pedir à pessoa que digitalizasse o documento que serve de «prova» e o anexasse à comunicação feita pela app.

Mas em Portugal as coisas são um pouco mais complicadas do que isso. Não por causa dalgum desejo perverso de usar a tecnologia mais complicada possível — mas sim por causa da legislação extremamente rigorosa relativamente aos dados dos cidadãos, em especial os dados médicos. Para ser ainda mais preciso teria de ir consultar a legislação em vigor, mas posso usar uma simplificação fácil de entender: em Portugal, as únicas entidades que podem ter acesso aos dados clínicos de um doente são os profissionais de saúde. Esta lei aplica-se em termos praticamente absolutos — os dados clínicos, independentemente da forma como são guardados (sob formato digital ou outro qualquer) são considerados como parte integrante da relação de confidencialidade entre paciente e médico e não podem ser violados.

Se já usaram a Área do Cidadão do Portal da Saúde, sabem do que estou a falar. Podemos usar esta área para (voluntariamente) acrescentar indicações sobre as nossas doenças ou medicamentos que estamos a tomar. Mas algumas áreas do nosso perfil só podem ser actualizadas por profissionais de saúde. Ou seja, dada a legislação restritiva que temos, podemos ter a certeza absoluta que foram tomados todas as precauções na elaboração do Portal da Saúde para que os nossos dados clínicos nunca possam ser vistos por quem não seja um profissional credenciado da saúde (que esteja inscrito numas das Ordens profissionais respectivas). Ou seja, até é possível, por exemplo, que uma simpática funcionária da recepção esteja disponível para actualizar a morada, nº de telefone ou endereço de email da nossa ficha de paciente — afinal de contas, essa base de dados também está sob a alçada da legislação de protecção de dados, significando que podemos ter confiança que a funcionária em questão não faça uma cópia de toda a base de dados para uma pen drive para depois a levar às farmacêuticas…

Até pode ser possível que possam fazer marcações de consultas — que é visto como um procedimento administrativo — mesmo que isso implique que a funcionária fique pelo menos a saber que tipo de doença pensamos ter, dependendo da consulta médica que temos marcada. Já fui fazer consultas ao Hospital Júlio de Matos (Centro Hospitalar Psiquiátrico de Lisboa) em que a marcação da consulta era de sexologia clínica — digamos que não era propriamente algo que eu estava interessado em divulgar ao público em geral! Mas esses dados também são confidenciais — acessíveis aos serviços administrativos, sim, mas eles estão habituados aos casos mais estranhos. Por exemplo, nesse hospital, a segurança era fornecida por um agente da PSP. Apesar de ser uma autoridade, nem sequer o(s) polícia(s) tinham autorização para espreitar por cima do ombro dos funcionários da recepção para ver que tipo de consulta estavam a marcar!

Se já para estas coisas mais simples e essencialmente burocráticas existe uma enorme quantidade de protecções relativamente aos dados, imagine-se então o que é preciso fazer para salvaguardar os dados clínicos. Coisas como receitas, diagnósticos, análises ao sangue, resultados de testes, etc. são absolutamente confidenciais. Não podem ser acedidas por ninguém, excepto, em teoria, o médico que criou esses documentos no sistema. Na prática, numa emergência clínica, é possível aceder a alguns desses dados, se estiverem disponíveis, desde que seja um profissional de saúde a fazê-lo — embora na realidade o protocolo implique que tal cedência de dados, mesmo entre colegas, seja apenas feito com o consentimento do doente e do paciente.

Um exemplo típico: numa clínica de fisioterapia, é o médico fisiatra que receita o tratamento, que depois é aplicado pelo fisioterapeuta. Ambos são profissionais de saúde. É habitual, nos casos em que tanto as consultas de fisiatria e os tratamentos de fisioterapia sejam feitos no mesmo espaço físico, que os médicos recebam uma confirmação implícita do paciente para poderem mostrar ao fisioterapeuta o que devem fazer. Já quando se trata de fazer uma consulta de fisiatria num sítio e depois fazer as sessões de fisioterapia noutro, as coisas podem ser mais complicadas (por diversas razões, há clínicas que não aceitam fazer fisioterapia sem que se consulte o seu médico fisiatra primeiro). Teoricamente, o médico nem precisa de dizer qual é o diagnóstico feito ao paciente; apenas precisa de indicar, com detalhe e precisão, qual o tratamento a aplicar. Na prática, claro, os fisioterapeutas, baseado no tratamento receitado, podem inferir qual o diagnóstico que foi feito (pois lidam com estes casos todos os dias…), mas, como também são profissionais de saúde credenciados, a informação sobre o diagnóstico (directa ou indirecta) só circula entre profissionais de saúde credenciados. Da mesma forma, numa enfermaria de um grande hospital, se alguém estiver numa ala de doenças cardíacas e receber medicação para hipertensão, não é muito difícil aos enfermeiros saberem de que é que o paciente sofre… mas podem não saber todos os detalhes. Saberão, sim, apenas o mínimo que for necessário para poderem tratar devidamente todos os pacientes.

Bom. Tendo isto em mente, podemos ver que há aqui um problema complexo com a questão do diagnóstico de alguém que testou positivo ao SARS-CoV-2. O médico responsável, obviamente, saberá quem é o seu doente que testou positivo. Mas não pode divulgar essa informação, excepto ao seu paciente. Este, por sua vez, até pode dizer aos amigos que está doente (somos livres de fazermos o que quisermos com os nossos dados…), mas na app estão — potencialmente — dados de potenciais estranhos (pessoas com as quais andámos de autocarro ou com as quais partilhámos uma casa de banho pública, por exemplo). Como vimos, não é possível saber quem é quem.

Ora a app «sabe» quem é que são as pessoas com quem estivémos em contacto. Nós podemos teoricamente informar a app de que fizémos um teste que deu positivo — é o que acontece nas apps de países em que a comunicação é feita em regime de voluntariado — mas, no nosso caso, como vimos, o Governo não confia que o sistema não seja abusado.

Por outro lado, como nem sequer o Governo sabe a quem corresponde cada código, mesmo que um médico até saiba o telemóvel do paciente infectado, não pode comunicá-lo (seja de que forma for), mesmo ao Governo. As leis de protecção de dados não servem apenas para a comunicação entre particulares, mas aplicam-se com ainda mais rigor aos organismos governamentais.

Mas também não é menos verdade que os médicos não têm nada que saber de forma automática quem foram os potenciais infectados por determinado doente. Tem de ser o doente a explicitamente lhes dar permissão para divulgarem os seus dados clínicos (nomeadamente, que deram positivo num teste de SARS-CoV-2) a terceiros (neste caso, todas as pessoas que potencialmente estiveram em contacto connosco nos últimos 14 dias)

Temos, pois, por um lado, garantir que as pessoas só possam comunicar ao sistema que estão infectados se e só se tiverem em sua posse, efectivamente, um resultado oficial de um teste de SARS-CoV-2 que tenha dado positivo; e, pelo outro, que a disseminação desse resultado a outros utilizadores da app seja feita apenas com o consentimento explícito da pessoa alegadamente infectada; e que, neste processo todo, não haja mais nenhuma entidade que armazene, mesmo que temporariamente e meramente para um propósito muito específico, qualquer dado que seja considerado «clínico» (ao abrigo do princípio de confidencialidade entre médico e paciente) e que possa potencialmente ser visto por uma pessoa que não seja um profissional da área da saúde.

O esquema que foi desenhado pelo INESC TEC (e demais entidades que participaram neste projecto) tinha que dar resposta a estes problemas todos, e a solução encontrada foi engenhosa. Não quer dizer que seja única (acredito que o sistema seja semelhante em todos os países que sejam paranóicos com o acesso a dados clínicos — surpreendentemente, são bem menos do que eu pensava! — mas não estive a ver as soluções encontradas pelos outros países), nem quer dizer que seja perfeita (já vou depois explicar, a meu ver, algumas «fraquezas» do sistema), mas pelo menos podemos dizer que, na sua essência, os programadores da app e dos restantes sistemas deram uma resposta satisfatória a todas as complexas especificações (o que foi atestado depois por entidades como a Comissão Nacional de Protecção dos Dados, as várias Ordens profissionais no sector da saúde, etc.).

Na verdade, até agora tenho estado a falar de um servidor, na Imprensa Nacional Casa da Moeda (explicando que não se trata apenas de um, mas sim de um cluster de servidores). A verdade é que todo o sistema tem, na verdade, dois (o segundo também é um cluster, mas, por analogia, vou assumir que é apenas «mais um»). Este segundo sistema está algures no Ministério da Saúde, e só pode ser acedido por um profissional de saúde. Ou seja, mesmo a equipa que faz a gestão e manutenção da app, dos servidores associados, da rede de telecomunicações que suporta a infraestrutura toda, etc. não têm acesso a este servidor do Ministério da Saúde. De forma deliberada, este servidor está completamente isolado do outro.

É, no entanto, neste servidor que os médicos podem aceder livremente onde são guardados os testes de SARS-CoV-2 — ou, mais precisamente, não é preciso propriamente guardá-los (não confirmei os detalhes exactos). O papel essencial deste servidor é o seguinte:

  • Gerar uma chave aleatória para cada teste (que depois é impresso no mesmo) e guardá-la em arquivo;
  • Confirmar, quando lhe é apresentada uma chave, que esta de facto existe e que corresponde a um teste válido.

Ou seja: sempre que, algures no país, há um laboratório que faz um teste de SARS-CoV-2, este servidor associa este teste a uma chave aleatória, única no sistema, e que constará do suporte físico (ou digital) que é enviado ao paciente. A chave não tem qualquer relação seja com o paciente, a data/hora a que fez o teste (ou que recebeu os resultados), o laboratório que fez a análise, os elementos das equipas desse laboratório, ou sequer o médico que pediu o teste, ou os seus colegas, ou o local onde trabalha. É apenas uma sequência de letras e números sem qualquer nexo; não é possível, a partir dessa sequência, «adivinhar» qualquer dado. Não tendo feito nenhum teste de SARS-CoV-2, não posso sequer garantir que só os testes positivos é que têm essa chave; se tivesse sido eu a fazer o software, teria gerado chaves para todos os testes, independentemente do seu resultado (isto para tornar a tarefa de potenciais piratas informáticos muito mais complicada — pois assim, dada uma chave, nem sequer se pode saber se corresponde a um teste positivo ou negativo, quanto mais tentar adivinhar quem é que o fez; sabendo também que há muito mais testes negativos do que positivos — felizmente! — estamos a criar uma carga de trabalhos aos piratas informáticos…). Mas isso são detalhes. O que interessa é que a chave associada a um teste — emitido por um laboratório, validado por um médico — é única e permite identificar o mesmo, sem, no entanto, revelar quaisquer dados clínicos. Esta chave está apenas no servidor do Min. Saúde, assim como no resultado do teste que é enviado para o paciente; mais ninguém tem acesso à mesma, nem sequer as equipas técnicas que mantêm o sistema a funcionar.

Quando uma pessoa com a app recebe o teste, também tem então acesso à «sua» chave, ou, mais precisamente, à chave que identifica aquele teste em particular. Vai então à app e voluntariamente introduz a chave numa área especialmente reservada para o efeito. O facto disto ser feito «voluntariamente» é crítico e essencial: significa que o cidadão está a dar um consentimento formal e explícito que os seus dados clínicos podem ser vistos por terceiros. Sim, é verdade que todo este processo, como temos vindo a ver, é todo anonimizado e encriptado em várias fases. Mas isso é irrelevante, do ponto de vista legal. O que é importante, isso sim, é que seja a pessoa a dar conscientemente esta autorização. Não há surpresas: o médico não pode, do ponto de vista legal e deontológico, indicar a terceiros que o seu paciente está doente (mesmo que estes terceiros sejam «desconhecidos», perfeitos estranhos, e não haja qualquer forma desses terceiros poderem alguma vez relacionarem o código que têm com o paciente), sem uma autorização explícita do paciente. Bem podemos argumentar que estamos a falar num caso de saúde pública, que cada informação sobre potenciais infectados é preciosa para fazer um rastreamento mais eficaz, e, logo, a necessidade pública poder-se-ia sobrepôr à «vontade» do paciente.

Mas em Portugal isso não é possível. Por mais grave que seja a pandemia, especialmente fora do estado de emergência (e mesmo com o estado de emergência declarado não se podem revogar todos os direitos dos cidadãos), este direito que as pessoas têm de que os seus dados clínicos não podem ser divulgados sem a sua autorização é absoluto e inalienável. Tal como ninguém pode ser «obrigado» a usar a app, também ninguém é obrigado, caso esteja infectado, a dar autorização para que se informem os restantes cidadãos da sua condição clínica (por mais «anónima» que esta seja, do ponto de vista digital).

Imaginemos então que, no nosso exemplo, a pessoa em questão quer informar o sistema de que está infectado com SARS-CoV-2. Vai buscar a chave aos resultados do teste e introduz a mesma na app.

Por sua vez, a app comunica com o servidor na INCM, e, para além de enviar os códigos de todas as pessoas com as quais se esteve em contacto, também envia a chave do teste. Evidentemente, não envia a chave assim sem mais nem menos; esta é devidamente encriptada com uma chave pública (a privada está do lado dos servidor), que presumo ser alterada pelo menos uma vez por dia (as especificações disponibilizadas publicamente nem sempre são 100% claras a esse respeito).

Do ponto de vista da pessoa infectada, a sua participação terminou. Depois de ter feito esta comunicação, pode desinstalar a app do telemóvel — já não será necessária. Do ponto de vista legal, desde que recebeu o teste positivo, passou a ser seguido(a) pelo SNS em regime de isolamento domiciliário. Não é suposto ir «andar na rua» assim sem mais nem menos (e se for preciso deslocar-se para ir a um hospital, fica depois ao critério do SNS como fazer o transporte), logo, a ideia é deixar de continuar a contagiar outras pessoas…

Do ponto de vista do servidor do INCM, ainda faltam uns passos. Como referi múltiplas vezes, este servidor não sabe se esta chave recebida é válida ou não, e muito menos a que tipo de teste corresponde. Não cabe sequer a este servidor «especular» se realmente receberam uma chave verdadeira, se houve um «engraçadinho» que gerou automaticamente uma chave «falsa», ou se na realidade a pessoa que enviou a comunicação da sua app leu bem os números, ou se enganou a fazê-lo, ou se tinha um teste negativo mas mandou a chave à mesma, etc. etc. etc. O servidor do INCM não sabe nada disto.

Em vez disso, comunica com o servidor do Min. Saúde através de um canal seguro (usando mais chaves de encriptação trocadas regularmente…), e pergunta ao sistema: «olha lá, recebi esta chave. É válida ou não?» ao que o servidor do Min. Saúde responde, laconicamente, «sim» ou «não».

Internamente, o servidor do Min. Saúde vai pegar na chave e confirmar que faz parte da lista de chaves emitidas para testes que deram positivo. Nada neste processo é «visível», nem sequer ao servidor do INCM. Por exemplo, até se pode dar o caso de que realmente um médico tinha classificado o teste como positivo, mas depois foi feito um contra-teste, que acabou por dar negativo, e agora resta a dúvida se a pessoa está infectada ou não. Um segundo médico poderia, por exemplo, aceder aos dados do sistema e invalidar a chave. O servidor do INCM não tem hipótese de saber se a chave foi mudada, invalidada («revogada», em termos técnicos), ou como é que foi gerada, quando, onde, etc… tudo o que sabe do Min. Saúde é se essa chave é válida ou não.

Se for válida, então arquiva os códigos que recebeu da app da pessoa infectada. Caso contrário, estes são descartados (e presumivelmente o utilizador da app poderá receber a indicação que introduziu uma chave errada, inválida, ou revogada; dependendo da forma como isto está programado — podia ter olhado para o código, mas sou preguiçoso e não o fiz — a app poderá sugerir à pessoa que contacte com o seu médico para esclarecer com este o que é que se passou). Finalmente, a chave então é também descartada pelo servidor do INCM (a teoria é que de nada serve «atacar» o servidor do INCM, pois este não guarda as chaves que indicam que «alguém» deu positivo no teste para o vírus; a comunicação entre app ↔︎ INCM ↔︎ Min. Saúde processa-se num tempo consideravelmente curto, pelo que, se alguém tentar registar no sistema a mesma chave por uma segunda vez, o servidor do INCM provavelmente não guardou uma cópia do resultado, e trata todas as chaves recebidas como se fossem novas, ou seja, vai sempre perguntar ao servidor do Min. Saúde se a chave é válida ou não.

Com este sistema, é verdade que há aqui um custo operacional superior, que foi o da aquisição do cluster de servidores do Min. Saúde e respectivo software. Mas garante-se assim que os dados clínicos nunca saiam do Ministério da Saúde.

Há países que «poupam» a duplicação de esforços, e os médicos acedem logo directamente ao servidor «central», onde depositam as chaves geadas. No caso português, isso significaria que os médicos e os técnicos «partilhariam» o mesmo servidor, o que implicava que pelo menos um dado — um paciente infectado — seria potencialmente acessível a pessoas que não fossem profissionais de saúde. Este processo pelo menos impede que isso aconteça (pelo menos em teoria).

Limitações do sistema

Embora os detalhes deste sistema de duplo servidor, pelo menos no papel, pareçam indicar que não só funciona bem para todas as partes envolvidas, como obedece a todas as regras estritas impostas pela legislação portuguesa sobre protecção de dados, não existem «sistemas perfeitos» — muito menos quando se está a desenvolver uma coisa completamente nova, no meio de uma situação tão anómala em que vivemos.

Relembro de que, embora o sistema de base — fornecido essencialmente pela Google e pela Apple — tenha sido exaustivamente testado por vários auditores de segurança um pouco por todo o mundo (incluindo por cá), o sistema português, ou seja, a parte da operação do sistema que está para além do protocolo de base da Google/Apple, foi auditado apenas pelas várias entidades portuguesas. Não quero com isto dizer que não confie nessas entidades, antes bem pelo contrário; até conheço alguns dos profissionais que trabalham para elas (ou pelo menos reconheço os seus nomes…) e sei que são pessoas de competência extraordinária, para além de qualquer dúvida. Mas não posso cair no erro da falácia da autoridade: lá porque eu (ou qualquer outra pessoa!) diga que confie nas instituições portuguesas a fazer este tipo de auditorias (que, para além da segurança informática, também precisam de adequar a infraestrutura tecnológica à legislação em vigor), isso não quer dizer que toda a gente possa (ou deva!) confiar nessas mesmas instituições, independentemente de não se tratarem de entidades «anónimas» a trabalhar «no segredo dos deuses» (os relatórios já tornados públicos são assinados por uma equipa técnica de dimensão considerável, e é perfeitamente possível, com algum trabalho de «jornalismo de investigação», obter os curriculum vitae dessas pessoas na Internet).

Em vez disso, as provas devem falar por si próprias.

Ora para além do que foi publicado, acredito que existam alguns relatórios internos, cuja relevância eventualmente não tenha sido considerada suficiente para merecer o acesso do público; poderão ser questões técnicas muito específicas que pouco ou nada digam a quem esteja «de fora».

Embora em relação à tecnologia Google/Apple haja um limite até qual a podemos testar — pois parte do código é um segredo industrial, protegido como tal, e não é possível saber exactamente o que está a acontecer esse nível — como disse, podemos sempre testar de fora a ver se o comportamento da solução Google/Apple faz aquilo que dizem fazer. É um pouco como os testes de emissões dos automóveis: não precisamos desmontar um automóvel (protegido por patentes e segredos industriais!) para saber se cumprem ou não com a regulamentação das emissões, basta testarmos. O que podemos questionar, isso sim, é o que está a ser medido; como os acontecimentos recentes mostraram, os fabricantes de automóveis durante anos «permitiram» que se medisse apenas aquilo que eles deixavam ser medido — graças a software especializado (secreto… e ilegal), os fabricantes de automóveis, sem conseguirem realmente efectuar a redução de emissões poluentes de acordo com a legislação em vigor (sem sacrificar a potência dos motores), optaram por dispositivos engenhosos de software que «detectam» quando o automóvel está a ser testado, e, nesse caso, «activam» um modo de «baixas emissões» para passarem nos testes; mas depois, nas auto-estradas, com motores a debitarem a potência para atingir os 200 km/h, a conversa já é outra…

Não podemos, pois, excluir que a Google/Apple tenham «escondido muito bem escondido» uma série de mecanismos que lhes permitam copiar todos os dados recolhidos pelos telemóveis. Por exemplo, podem ter activo um «modo de diagnóstico» — informando até os seus parceiros (como o Governo português…) da existência do mesmo, que, nesta fase, para efectuar testes que sirvam para corrigir eventuais falhas, permitam aos técnicos da Google e da Apple ter acesso aos dados. Temporariamente. Depois, na fase de produção, o modo de diagnóstico é desligado… mas, na realidade, isso nunca acontece, e a Google e a Apple continuariam a receber os dados todos, sem dizer nada a ninguém…

Isto é possível e até seria plausível, mas, obviamente, também seria razoavelmente fácil de detectar (haveriam comunicações «extra» que não estavam documentadas em lado nenhum) — se houvesse uma denúncia ou uma suspeita de que era o que estava a acontecer. Um hacker ético poderia simplesmente desbloquear o acesso de administração dum telemóvel low-cost que corresse Android e ver o que são essas tais «comunicações extras» (também podia fazer o mesmo num iPhone… se não estivesse minimamente interessado em perder a garantia, claro). Ou poderia colocar o telemóvel dentro de uma gaiola de Faraday, isolando-o do mundo exterior, e ter vários receptores (Wi-Fi, Bluetooth, NFC…) junto ao telemóvel ao longo de vários dias para tentar perceber que acessos estavam a ser feitos que não constam das especificações. Tentativas de contactar servidores da Google ou da Apple seriam consideradas altamente suspeitas.

Este tipo de teste está perfeitamente ao alcance de qualquer laboratório de investigação forense, por exemplo, e acredito que possa ser relativamente fácil de demonstrar se houver uma «violação» das especificações produzidas pela Google e pela Apple (já o contrário é mais difícil; ou seja, se não se tiver detectado «nada», não se pode argumentar que a violação das especificações não exista — apenas que os testes feitos não detectaram nada de anormal). Tanto é assim que ambas as empresas estão cientes disso e não vão querer colocar a sua reputação em risco. Qualquer potencial violação que façam será sempre a um nível tecnológico infinitamente complexo cuja detecção seja extraordinariamente difícil mesmo para alguém que saiba exactamente do que está à procura — e que seja, ao mesmo tempo, fácil de «explicar» numa conferência de imprensa, descartando a «descoberta» e atribuindo-a a outras causas.

Por exemplo, imagine-se que de X em X minutos, um iPhone comunica, de forma «suspeita», para um servidor da Apple. Esta comunicação está fortemente encriptada e a sua desencriptação é impossível em tempo útil com a tecnologia disponível. Poderemos suspeitar de que a Apple está a fazer batota, mas será que podemos acusá-los disso? Mesmo que tal «descoberta» seja trazida a público, a resposta da Apple (independentemente da verdade) poderia ser simplesmente que essas comunicações são para o servidor que indica quando é que está disponível uma versão nova do iOS ou das apps instaladas, por isso, tais comunicações são «perfeitamente inócuas» e «nada têm a ver com o rastreamento digital». Sim, mas… embora essa explicação seja muito plausível, o certo é que, sem termos acesso aos dados, nada podemos concluir. Ficaremos eternamente na dúvida!

Nota: na realidade, duvido seriamente que o mecanismo acima descrito fosse utilizado — seria demasiado óbvio! Afinal de contas, já existe um mecanismo para os iPhones descobrirem se têm versões novas do software. Apesar de eu não saber como funciona, tenho a certeza que isso é do conhecimento público. Obviamente que envolve comunicações encriptadas. Logo, a Apple só precisaria de acrescentar às comunicações encriptadas legítimas e conhecidas um conjunto de mensagens adicionais, também encriptadas, também com destino ao mesmo servidor que lida com os upgrades e updates, mas cujo conteúdo incluiria a informação «preciosa» sobre quem tinha sido infectado e com quem tinha estado em contacto…

Há obviamente milhares de formas de «esconder» este tipo de comunicação para que não seja facilmente «detectado», ou, mesmo que o seja, que não tenha qualquer significado para quem está em posse dos dados (querendo isso dizer que não consegue tirar nenhuma conclusão).

Vou dar um exemplo, que descobri por mero acaso. Como a app desenvolvida pelo INESC TEC é livre e de código-fonte aberto, isto permite a sua auditoria por qualquer parte interessada — mas também permite a pessoas maliciosas perceberem como é que funciona. Existem imensos métodos de conseguir a segurança das comunicações mesmo que o código-fonte que faça essas comunicações seja totalmente aberto. A abordagem que conheço melhor é o recurso à aleatoriedade — está na base de muita encriptação, por exemplo. Lá porque o código-fonte da STAYAWAY COVID seja público, não quer dizer que consiga desencriptar mensagens enviadas pela app — as chaves são geradas usando uma certa dose de aleatoriedade que, como o nome indica, não é previsível. Sim, podemos saber que, de X em X tempo, as chaves de encriptação mudam. Mas mudam para quê? Como o processo de geração das mesmas assenta, em parte pelo menos, em processos aleatórios, dado um determinado telemóvel na nossa mão e o código-fonte ao lado, é impossível de determinar a priori qual é a chave que vai ser gerada. Portanto, não há problema algum que esse código-fonte esteja à vista de todos — de nada serve, pois não permite prever comportamento futuro. Podemos, isso sim, ter uma noção do tipo de encriptação que é usado (há muitos). Mas isso provavelmente até afasta muitos piratas informáticos: certos tipos de encriptação são, para todos os efeitos, com a tecnologia de 2020, impossíveis de desencriptar — e basta dar uma olhadela ao código para ver isso.

Ora a verdade é que nem todas as operações ditas aleatórias são mesmo aleatórias. Nos sistemas informáticos usa-se muito mais aquilo que é conhecido por pseudo-aleatoriedade. Trata-se de um conjunto de funções matemáticas complexas que, dado um ponto inicial, geram uma sequência potencialmente infinita de números, cuja relação não é possível de determinar de forma trivial. Ou seja, mesmo que olhemos para milhares ou milhões de números dessa sequência, é pouco provável que consigamos identificar qual foi a função usada para prever qual será o próximo número a ser gerado. Mesmo que façamos a experiência com diversas funções (não há assim tantas como isso, ou seja, o número é finito), como não sabemos em que ponto da sequência estamos, não podemos «olhar para trás» para tentar determinar esse ponto, e depois usar a mesma função para continuar a gerar novos números. É certo que, no passado, as primeiras funções pseudo-aleatórias tinham um período relativamente curto — por exemplo, ao fim de uns milhões de números, voltavam ao início e geravam todos os números de novo na mesma sequência. Há muitos métodos para determinar o período desse tipo de funções, ou seja, por quantos números temos de esperar até que nos saia de novo o primeiro da série. Processar milhões de números é algo que está ao alcance dos modernos computadores — daí essas funções serem muito pouco seguras.

Há outras, no entanto, que podem ter períodos vastamente superiores, o que torna o trabalho dos piratas informáticos bastante mais complicado — e, potencialmente, podem levar anos até encontrarem o ponto inicial. Isto é um pouco mais seguro, mas continua a ser verdade que basta sabermos o ponto inicial que podemos (conhecendo a função) determinar exactamente quais números é que vão sair «a seguir» na sequência.

Muitos sistemas de geração de números pseudo-aleatórios usam «pontos iniciais» que são relativamente fáceis de adivinhar. O pirata informático, em vez de analisar triliões ou quadriliões de sequências, investirá o seu tempo de forma bem mais produtiva a tentar identificar o ponto inicial. É por isso que os sistemas contemporâneos de geração de números pseudo-aleatórios usam verdadeira aleatoriedade para o ponto inicial. Por exemplo, num telemóvel, pode ser o produto da medição da temperatura interna do CPU pela localização GPS e o número de microsegundos que passaram desde que o telemóvel fez o seu último reboot. Como nenhum destes dados se consegue reproduzir exactamente (a temperatura do CPU varia consoante as apps que estão activas, as chamadas que estamos a receber, etc…), também é difícil a um pirata informático — ordens de vezes mais difícil — encontrar alguma base que lhe permita identificar esse tal ponto inicial.

Isto obviamente que é uma descrição ultra-simplificada de como as coisas funcionam, e que estou a citar, mais ou menos de memória, daquilo que aprendi algures há uns 30 anos atrás. Hoje em dia, não só há métodos muito mais sofisticados para gerar números aleatórios, como há igualmente métodos muito sofisticados para «quebrar» chaves de encriptação — aquilo que era considerado «seguro» há dez anos atrás é hoje trivialmente «quebrado» por qualquer pirata informático amador.

No caso da aplicação STAYAWAY COVID, há dois principais vectores de ataque. O primeiro é o Bluetooth — um dispositivo com Bluetooth sempre ligado tem mais uma «porta de entrada» disponível para um pirata informático poder «atacar». Como já vimos, isto não é assim tão trivial como se possa pensar, pois a tecnologia Bluetooth também evoluiu, em especial as funções de segurança colocadas no protocolo de comunicações. Este vector de ataque é também aquele que (provavelmente) foi mais testado — é o mais óbvio, já que está «sempre disponível», há muitas vulnerabilidades conhecidas que podem ser exploradas, etc.

O outro vector potencial de ataque são as comunicações que a app faz para o servidor central (seja para descarregar novas listas de códigos de pessoas infectadas — seja para o caso potencialmente ainda mais interessante do envio de códigos de pessoas em contacto, após o utilizador da app ter introduzido a chave que consta do teste positivo ao SARS-CoV-2). Ora estas são feitas por Wi-Fi (fáceis de interceptar) ou rede de dados móvel (um bocadinho mais difíceis de interceptar). No entanto, têm a particularidade de usarem um canal de comunicação encriptado de forma segura (leia-se: segundo o conhecimento que temos, estas formas de encriptação são consideradas seguras, porque se estima que os meios para as atacar «à força» requeira tecnologia que não esteja disponível, e, mesmo que estivesse, levaria anos ou séculos; no entanto, ressalve-se que os «ataques à força» são apenas uma das armas no arsenal dum pirata informático) — conhece-se muito bem como é que a segurança deste tipo de comunicações é feita e os «ataques» conhecidos exploram determinadas falhas na implementação que foram já corrigidas há anos.

Mas é um facto que alguém que esteja a «escutar» constantemente as comunicações para o servidor central pode potencialmente encontrar padrões nas comunicações, e, com tempo e paciência, tentar «adivinhar» a forma que estas comunicações tomam, para tentar interceptá-las, descobrir eventuais falhas na sua implementação, ou tentar qualquer outra forma de «ataque» que possa ter sucesso.

Olhando para o código-fonte, e fi-lo só de forma muito superficial, com muitas limitações quanto ao meu conhecimento sobre o desenvolvimento de apps em telemóvel, deu para identificar que existem mais mecanismos de «defesa» das comunicações (para além do óbvio, que é a encriptação de todas as mensagens, com chaves criptográficas trocadas muito frequentemente — se o pirata informático por acaso conseguisse ter acesso a uma, só conseguiria desencriptar as comunicações durante um período de tempo consideravelmente curto… pois de nada lhe serviria essa chave quando o sistema as mudasse).

Aquele que me chamou mais a atenção foi uma ideia muito simples. Parte-se do princípio que alguém que queira interceptar as mensagens entre o telemóvel e o servidor na INCM que esteja a monitorizar as mesmas, 24 horas por dia, pois não se sabe exactamente quando é que essa comunicação vai ser feita. Por isso, para «baralhar» o pirata informático, são despoletadas, ao longo do dia, várias comunicações «falsas».

As comunicações falsas são iguaizinhas às verdadeiras: também vão encriptadas da mesma forma, etc. Também enviam «códigos», mas estes não correspondem rigorosamente a nada (nem ninguém). O formato da mensagem, do ponto de vista exterior, é exactamente o mesmo. No interior, claro está, existe uma indicação se a mensagem é verdadeira ou falsa.

Ora o pirata informático tem de desencriptar as mensagens, uma a uma, operação essa que não é «instantânea» mas pode levar muito tempo. Sem as desencriptar — e como tenho repetido vezes sem conta, isto é muito mais difícil do que se possa pensar (já que originalmente os algoritmos de encriptação foram desenhados para não ser possível desencriptá-los — com um nível admissível para comunicações militares, pelo que não estamos a falar de uma coisa como a simples e trivial Cifra de César!) — não é possível, só de olhar para as sequências de bytes, quais delas são verdadeiras e quais são falsas. Portanto, o pirata informático tem primeiro de desencriptar todas as mensagens, e só depois é que poderá perceber quais são as falsas… e no meio destas todas, qual é a (única) que é verdadeira!

Em segurança informática, o objectivo principal de quem programa um sistema o mais seguro possível é fazer com que o processo de ataque leve o maior intervalo de tempo possível. A ideia é que quanto mais tempo for necessário para ter sucesso em atacar um determinado sistema, maior a probabilidade do pirata informático desistir e, em vez disso, atacar um sistema menos seguro. Isto é verdade na esmagadora maioria das situações, embora por vezes não seja óbvio quais são os sistemas que são mais seguros que outros.

Os piratas informáticos vão também privilegiar, sempre que possível, a engenharia social, ou seja, entrar em contacto com uma pessoa humana (e, logo, falível… e susceptível de ser «persuadida» a revelar mais dados do que devia). Neste caso da app STAYAWAY COVID, não há propriamente um intermediário humano que possa ser usado num esquema de phishing ou semelhante. Mesmo os (poucos) técnicos que possam estar afectos ao sistema não são susceptíveis de «ataques sociais» por parte de um potencial pirata informático: imaginemos um cenário onde um pirata informático consiga, de alguma forma, acesso físico ao parque de servidores da INCM, fazendo-se passar por «consultor» ou «auditor». Até talvez consiga que alguém lhe diga qual é a password de acesso aos mesmos, e, sem ninguém suspeitar, fazer uma cópia da base de dados, assim como de eventuais chaves de encriptação guardadas no sistema.

Chegando a casa — ou à sua base de operações secreta — o pirata automático passa então a base de dados «a pente fino». Consegue, evidentemente, saber os códigos de quem está infectado — mas de nada lhe serve esse conhecimento, pois não consegue ligar os códigos a pessoas concretas. Com um pouco de sorte, terá uma indicação do endereço IP (que, como já vimos anteriormente, não é a melhor forma de localizar uma pessoa…) que foi usado para carregar cada um dos códigos. Poderá, eventualmente, ter uma noção muito vaga do «ritmo» de infecções, ou do número de contactos médios por pessoa… mas essa informação não é «valiosa» no sentido em que já é tornada pública pela DGS (eventualmente, se houvesse uma enorme discrepância, ainda teria interesse para divulgar o «escândalo»…). O melhor que consegue é obter algumas chaves de encriptação que lhe permita descodificar para aquele dia as mensagens entre os telemóveis e o servidor — mas se já tem uma cópia da base de dados, de nada lhe serve!… e, no dia seguinte, todas as chaves serão mudadas automaticamente pelo sistema.

Porventura o maior «estrago» que um pirata informático poderia fazer acedendo fisicamente ao servidor seria «baralhar» a informação: por exemplo, apagando os códigos recebidos nos últimos 14 dias (fazendo assim com que as pessoas não fossem notificadas e não soubessem se tinham ou não estado em contacto com alguém infectado); ou, pior, inserindo códigos falsos, de pessoas que não estão infectadas, para criar o caos e a confusão — mas para isso, claro, teria também de ter uma forma de criar os códigos falsos. Ora isso é tudo menos trivial, visto que não é o servidor que os cria, mas sim as apps nos telemóveis; e estes códigos, ao serem enviados para o servidor, são assinados digitalmente (de forma a que o servidor saiba que vieram de uma fonte válida), com elementos como a data e hora precisas e o endereço IP do envio — que, contudo, não são «revelados» ao servidor. O servidor apenas consegue determinar, dada uma assinatura, se esta é válida ou não — não «sabe» como é que foi gerada.

Uma possibilidade seria pura e simplesmente o pirata instalar a app numa dúzia de telemóveis e deixar que estes gerem códigos aleatoriamente durante uns dias, tendo um conjunto de «amigos piratas» a passear pelos locais com maior densidade de pessoas (transportes públicos e escolas). Estes códigos podem ser facilmente exportados do sistema (já que são inócuos, por si só); agregados num vasto ficheiro; e, depois de «roubar» as chaves de encriptação usadas por cada telemóvel (outra tarefa não trivial), tornar os códigos assim agregados em códigos «válidos» (ou seja, marcá-los como «códigos de pessoas infectadas» usando todos os mecanismos necessários para a sua validação), e, então sim, inseri-los directamente na base de dados.

Isto pelo menos faria com que um número considerável de pessoas apanhasse um susto grande — mas não passaria disso. O SNS teria um pouco mais de trabalho nesse dia. Iriam ser feitos testes potencialmente «desnecessários». Mas seria o limite a que o pirata informático poderia usar para que as pessoas deixassem de acreditar no sistema, se este começasse subitamente a mandar avisos a torto e a direito a um número considerável de pessoas. Isto seria tanto mais eficaz se o pirata conseguisse ter acesso a muitos telemóveis com a app instalada, por exemplo, espalhando uma app falsa que também enviasse uma cópia dos códigos para o seu servidor…

Ora estamos a falar de situações hipotéticas, claro está, porque nada do que foi descrito anteriormente é «trivial». Teria de ser uma operação montada durante vários dias, por uma equipa de ciberterroristas, que tivessem como objectivo não a localização das pessoas (já vimos que isso é pouco provável de se conseguir), mas sim desacreditar o sistema. Podemos imaginar que uma organização de COVID deniers tenha contratado uma equipa de ciberterroristas com o objectivo de fazer com que os portugueses deixem de acreditar no SNS, na DGS, e na app propriamente dita.

É possível, claro está. Mas não é plausível.

Em conclusão…

Não existe software 100% seguro.

No entanto, há uma regra simples que permite aferir a probabilidade duma determinada aplicação ser ou não alvo de um ataque informático por parte de hackers maléficos, piratas, cibercriminosos/ciberterroristas, ou mesmo elementos das forças armadas de um país hostil empenhado em ciberguerra.

O «esforço» para «furar» a segurança de determinada aplicação ou sistema deve ser proporcional ao benefício obtido.

Por exemplo, vale a pena tentar «furar» a segurança de uma aplicação de homebanking, por mais difícil que essa tarefa seja, pois o benefício — transferir dinheiro para contas próprias, por exemplo — é imenso. O nível de segurança de tais aplicações é, pois, de tal forma, que descobrir um método de o «contornar» requeira um esforço de tal forma monumental que nem mesmo que se roubem milhões ou biliões, o esforço não compensa. Podemos imaginar o nível de complexidade que isto exige.

Por outro lado, numa aplicação de homebanking, existem duas partes envolvidas, sendo que uma «sabe tudo» (o banco) e outra «sabe tudo aquilo a que lhe diz respeito» (o cliente, usando a aplicação de homebanking). Qualquer banco tem vários níveis de segurança para guardar a totalidade dos dados dos seus clientes.

No caso da aplicação STAYAWAY COVID, há algumas questões problemáticas, pois a última coisa que nós queremos (os cidadãos que usam a app) é que o Governo (ou a Apple, a Google, os operadores das redes móveis, os fabricantes de telemóveis…) tenha acesso aos nossos dados sem autorização. Ou seja: estamos apenas dispostos a entregar ao Governo um número mínimo de dados que permita «avisar» concidadãos de que podem estar potencialmente infectados, mas isso não quer dizer que estejamos dispostos a enviar mais dados do que o estritamente necessário!

As especificações funcionais do sistema que implementam a app STAYAWAY COVID têm isto em consideração. Os dados que transitam entre os telemóveis das pessoas, e entre estes e o servidor central, são, na sua maioria, inócuos — no sentido em que ter acesso descontextualizado a estes dados de pouco ou nada serve para inferir o que quer que seja sobre as pessoas (e respectivas apps). Mesmo que as mensagens sejam desencriptadas, ou que existam agentes maléficos a interceptar comunicações Bluetooth, a informação que conseguem obter é muito limitada (tanto em número, como no tempo e no espaço) e de pouco ou nada serve. Sim, o «elo mais fraco», a meu ver, encontra-se nos servidores da INCM e do Min. Saúde, porque podem permitir — através de um processo complexo, não trivial, e quase de certeza com presença física do pirata informático na sala em que são guardados os respectivos computadores — a eliminação de dados (impedindo as pessoas de serem devidamente avisadas) e/ou a injecção de dados falsos (criando confusão e o descrédito no sistema). O que não é possível é obter dados que não circulam no sistema — nomeadamente, dados que identifiquem as pessoas, os seus telemóveis, a sua localização ou os seus movimentos e contactos ao longo do tempo. Não é possível «reconstruir» essa informação, mesmo tendo-se a totalidade dos dados.

Mas, como disse, não há sistemas impenetráveis. Podemos sempre admitir que um agente maléfico, seja com que intenções for (pode ser o próprio Governo a querer «espiar» os seus cidadãos), distribua uma app falsa, em tudo idêntica à STAYAWAY COVID (até mantendo a mesma funcionalidade básica!), mas que envie muitos mais dados para além dos códigos de que já falámos. Desenvolver uma aplicação assim e distribui-la pelos cidadãos nacionais não é propriamente fácil: para isso acontecer, nas lojas oficiais da Apple e da Google, é preciso passar por um processo de autorização complexo, que envolve a troca de informação (mais chaves digitais…) entre o Governo e estas duas empresas. Ou seja, uma nova versão da STAYAWAY COVID que tenha sido «adulterada» vai ter de passar pelo crivo dos peritos de segurança que a Apple a Google tem para fazer uma «inspecção» da app, antes que esta seja colocada nas suas respectivas lojas. Por outras palavras: se a app STAYAWAY COVID for descarregada ou da Apple, ou da loja online oficial da Google (atenção que há muitas que não são oficiais…), então há a garantia dessa aplicação ser genuína, ou seja, que não foi um pirata informático ou um ciberterrorista a desenvolver essa versão…

Tecnologia marada

Uma coisa que é fixe no «mundo» Apple — apenas fixe, não necessariamente «útil» — é uma tecnologia que a Apple chama «Handoff». Isto serve para se poder começar a fazer uma tarefa num dispositivo Apple e continuar noutro, precisamente no ponto em que se estava.

Continuar a ler

Não percebo muito de «net neutrality» mas…

Net Neutrality

O meu primo Ludwig Krippahl mandou há uns tempos para o Facebook um link de um artigo do Cory Doctorow para o Guardian sobre os perigos que se avizinham com o fim da net neutrality nos Estados Unidos. Queria meter um comentário no Facebook também, mas, por ironia do destino, o Facebook estava com problemas e «censurou-me» o comentário 🙂 Por isso vai aqui para o meu blog, como referência futura…

Continuar a ler

Phishing: burlas e como se proteger

Tendo em conta o recente ataque aos cartões de pontos Continente, uma notícia muito bem coberta pelo Lourenço Medeiros da SIC, talvez o grande público (e as grandes empresas!) comece a compreender que as coisas já não são como dantes: a Internet pode ser a plataforma mais segura do mundo, mas não podemos dar-nos ao luxo de sermos negligentes com a segurança informática. Neste mundo onde podemos pagar tudo (mesmo os impostos) via Internet, onde as facturas e os recibos podem ser enviados digitalmente, e onde praticamente todas as empresas que têm os nossos dados pessoais têm-nos de alguma forma acessíveis via um site qualquer, e em que recebemos toneladas de mails todos os dias — muitos parecendo vir de empresas das quais somos clientes ou fornecedores — há que tomar os mesmos cuidados que temos com as comunicações que são feitas em papel.

É por isso que o Paulo Laureano também está a fazer uma série de podcasts sobre informática chamado Os Zeros e os Uns — e sobre segurança informática, à parte do seu trabalho constante de informar o público em geral através do seu blog pessoal — e, neste episódio, em que ele convidou um caramelo gordo e feio para o programa, fala-se justamente de quão fácil é «enganar» as pessoas com aldrabices simples mas altamente eficazes; do cuidado mínimo que devemos ter todos os dias quando lemos comunicações aparentemente «sérias» no email ou nos sites que parecem ser legítimos mas são tudo menos isso; e das soluções que podemos adoptar para que seja muito, mas muito mais difícil, «apanharem-nos» as passwords.

Podcast disponível no iTunes: https://itunes.apple.com/us/podcast/os-zeros-e-os-uns/id595785752, via Feedburnerhttp://feeds.feedburner.com/OsZerosEOsUns, MEO Kanal 508991, e, claro, no YouTube.

Continuar a ler

Quem quer os dados de todos os clientes Continente?

Nota: esta notícia é do início de Fevereiro de 2013. Só a republico porque se calhar o assunto referido ainda não foi resolvido…

Sabia que os seus dados no cartão Continente podem ser facilmente acessíveis por quem os queira obter? E que o Continente, apesar de ter sido informado da falha de segurança, nada fez para resolver o problema? Pois.

Aos meus amigos jornalistas: isto são notícias que os «mass media» ainda não divulgaram. Apenas alguns sites de cromos informáticos é que parecem estar atentos à situação: http://www.tugaleaks.com/continente-vulneravel-ataque.html

Se até ao dia 26 de Fevereiro ninguém do lado do Continente agir, o código fonte para obter a lista completa de clientes vai estar disponível na Internet — nomes, moradas, telefone, BI, e saldo no cartão — para que qualquer pessoa possa ir buscar esses dados à vontade. Cortesia da Team n00bz.

Continuar a ler

MAPAlhaçada

Desde que a Apple lançou o iPhone 5 com o iOS 6 que tem sido a gargalhada geral em torno da sua nova aplicação, o Apple Maps, que vem substituir a aplicação nativa do Google Maps. O Apple Maps é provável que se torne no maior falhanço na história recente da Apple (e mesmo na antiga) e o maior motivo de chacota pública, tendo sido já criado um site no Tumblr só com imagens exemplificativas do mau funcionamento da aplicação. Talvez seja mesmo a pior coisinha alguma vez desenvolvida pela Apple, pior até do que o Apple Newton, que, apesar de tudo, funcionava, mas foi silenciosamente esquecido pela história.

Se o Apple Maps tivesse sido lançado em vida do Steve Jobs, tenho a certeza que não teria aparecido como uma aplicação 🙂 Jobs era um perfeccionista, e não deixaria que uma aplicação «feita às três pancadas» fosse assim lançada publicamente… assim, Jobs deve estar às voltas no túmulo.

Apesar dos erros hilariantes da aplicação de mapeamento da Apple, e de realmente não dever ter sido lançada numa fase ainda tão cheia de bugs, a verdade é que há uma certa «injustiça» para com a Apple. Em primeiro lugar, devido às questões complicadas de licenciamento, e à guerra entre a Apple e a Google pelo domínio do mundo móvel, era evidente que a Apple teria, mais cedo ou mais tarde, de largar o Google Maps e optar pela «sua» aplicação. Portanto, mesmo que prematura, esta aplicação tinha de ser lançada, e tinha de estar «pronta» com urgência. Não é por «malandrice» ou «pura incompetência» que a Apple foi forçada a fazê-lo: foi por pressão da concorrência.

Ora em segundo lugar, é evidente que as comparações estão a ser feitas com o gigante do mapeamento digital, que é o Google Maps. Claro que a comparação é legítima: afinal de contas, os iPhones e iPads usavam o Google Maps antes, e é lógico que os actuais utilizadores comparem o que têm agora — que funciona horrivelmente mal — com uma aplicação que funcionava perfeitamente. Mas a verdade é que é importante perceber porque é que a Google é um «gigante» do mapeamento digital, batendo toda a concorrência — nomeadamente, os fabricantes de sistemas de navegação por GPS. É que para além de aceder a bases de dados públicas e bases privadas, que estão constantemente a ser actualizadas — fontes às quais a Microsoft e o Yahoo também têm acesso, para as suas próprias aplicações de mapeamento — a Google faz mais. Faz muito mais: Alexis Madrigal, no The Atlantic, explica isso muito bem.

Para resumir a questão: a maior parte dos sistemas GIS que por aí andam, e cujos dados são públicos (ou que podem ser adquiridos, tal como os dados cartográficos do Instituto Geográfico do Exército), baseiam-se num misto de cartografia por satélite, por imagens aéreas, e caminhadas no terreno para localizar certos pontos. A Google acrescenta a isso as famosas Google Vans que andam pelas principais cidades do mundo todo a fotografar todas as ruas — as imagens tiradas a partir das carrinhas são depois processadas para extrair uma montanha de dados incríveis, desde localizações de lojas a sinais de trânsito. E, claro, o gigante da pesquisa também extrai informação da localização de sites Web, dos telemóveis com que as pessoas andam na rua, das fotografias que contenham informação de GPS e uma identificação (se alguém mandar para o Picasa uma fotografia da Torre Eiffel e disser, «estou na Torre Eiffel em Paris», a Google pode associar uma coisa à outra e aumentar assim a precisão do mapa…).

Ora tudo isto chega a uma equipa de umas centenas de pessoas que depois validam essa informação e a colocam no mapa final. São centenas! E, para mais, fazem-no há cinco anos, tendo aprendido com os erros do passado. O Google Maps, a início, não era assim tão impressionante como isso; lembro-me de ter usado mais vezes os Mapas do Sapo (com informação geográfica vinda da InfoPortugal) para encontrar algumas ruas nos sítios mais obscuros. Os mapas da Yahoo eram tão bons ou tão maus como os da Google. Foram apenas cinco longos e penosos anos para que a Google se tornasse também no gigante da informação cartográfica que é hoje — apostaram imenso na tecnologia e deixaram praticamente toda a gente para trás.

A Apple, essa, coitada, andou a «namorar» a Tom Tom, ainda não se sabe se a vão adquirir ou não, mas é certo que a informação principal da base de dados que serve para alimentar o Apple Maps vem da Tom Tom. E está visto que nem a Tom Tom, nem a concorrência (em termos de sistema de navegação GPS), têm a riqueza de informação que a Google tem, especialmente no que concerne a imagens em 3D (pois a Google tem a tecnologia StreetView que usa imagens tiradas pelas suas famosas carrinhas, coisa que a concorrência não tem…), mas não só: por muita informação que a Tom Tom tenha (e disponibilize à Apple), não têm um motor de busca gigantesco que indexa o mundo todo. E isso é o que faz a diferença.

A Microsoft podia concorrer com os mapas do Bing, mas não o faz. É pena (a concorrência é boa!), pois os mapas do Bing usam imageologia muito mais recente que a Google, pelo menos na maior parte dos locais de Portugal. Pessoalmente irrita-me que na minha zona a Google ainda esteja a usar imagens de satélite de há uns sete anos atrás: faltam ruas e edifícios monumentais como a Igreja da Boa Nova, entre outras coisas. O Bing há anos que as mostra. Mas se compararmos toda a riqueza de informação que, regra geral, a Google apresenta, está a anos-luz do que quer que a Microsoft possa apresentar.

Mas evidentemente que a Apple também não pode usar a informação da Microsoft — seria ainda mais irónico! Ao ler melhor nas entrelinhas, olhando para as fontes que a Apple usa para complementar a falta de informação da Tom Tom, reparei numa coisa curiosa: também vão buscar dados ao OpenStreetMap.

OpenStreetMap? Eh lá! Eis uma coisa que não ouvia falar desde há uns anos, em que me registei lá no site deles. O OpenStreetMap (OSM), para quem não saiba, é uma espécie de «wiki cartográfica» — por outras palavras mais simples, um mapa do mundo em que todos podem acrescentar informação georeferenciada, editando o que quiserem em colaboração com milhares de outras pessoas. Quinhentas mil pessoas, para ser mais preciso.

A informação submetida ao OpenStreetMap é, como de costume nestes projectos de crowdsourcing, completamente pública e licenciada em modelo open source. Qualquer pessoa — incluindo a Apple! — pode usar esta informação como muito bem lhe apetecer e distribuir sob forma de uma aplicação, mesmo que seja comercial.

Cabe aqui fazer uma pausa para reflectir nisto. Em primeiro lugar, será que vale sequer a pena olhar para este tipo de soluções? Para já, não é a única solução de cartografia crowdsourced; a Waze também permite que as pessoas editem e completem os seus mapas; a diferença é que, neste caso, os direitos ficam todos com a Waze, que explora os mapas comercialmente. Por outro lado, graças às API da Google, qualquer pessoa pode usar a vastíssima informação que a Google colocou no Google Maps, de borla. De borla? Bem… sim… desde que seja para uma aplicação, também ela, gratuita. Evidentemente que a Google não é parva. Não há problemas em colocar um mapazinho num site — isso só dá mais hits à Google, e mais informação para pesquisar — mas empacotar a informação toda numa aplicação comercial (ou numa aplicação que sirva para vender um produto — como, por exemplo, um telemóvel que corra um sistema operativo concorrente ao Android…), é evidente que a Google não vai na conversa e diz que não!

Ou seja: na realidade não há dados georeferenciados, à escala mundial, que sejam gratuitos e livres de qualquer licenciamento. Com uma excepção: OpenStreetMap. Só isto devia encorajar aqueles que desenvolvem aplicações que necessitam de georeferenciação e que usam informação do Google Maps, mas que têm dúvidas se podem depois vendê-las. Em princípio não podem. Na prática, é pouco provável que a Google «ande atrás» dos pequenos programadores que vendem meia dúzia de licenças por ano. É evidente que «andará atrás» de gigantes como a Apple!

Mas há mais uma pequena coisa que sempre me irritou em todas as aplicações que por aí existem que usem dados cartográficos, que é: como é que os corrijo quando estão mal?

É evidente que esse é o cerne da questão! Se a Tom Tom permitisse que, no mundo todo, as pessoas pudessem corrigir as informações erradas na sua base de dados, o Apple Maps não mostrava os disparates que mostra. Mas não o faz, por razões óbvias (comerciais!), e por isso, dada a quantidade gigantesca de «erros», vai levar anos para corrigir tudo. A Google tem, como disse, uma equipa com centenas de pessoas para corrigir os erros que lhes são submetidos. A Tom Tom se calhar nem sequer tem uma linha de suporte para a qual se possa fazer essa submissão — e se calhar a Apple também não (ainda não fui verificar).

Mas mesmo a Google não deixa acrescenta com facilidade nova informação georeferenciada. É claro que qualquer pessoa pode registar a sua empresa no Google Maps de borla. Para validar que os dados são verdadeiros, a Google manda uma carta com um código para a morada da empresa. Assim evitam-se os dois principais problemas dos sistemas baseados em crowdsourcing: o spam e o vandalismo. Tenho uma vaga memória que, muito a início, a Google deixava as pessoas acrescentarem pontos e localizações no mapa, que eram «votados» pela comunidade, e que se tivessem votos suficientes, passavam a fazer parte do mapa. Mas isso acabou; ou se não acabou, não descobri como é que se faz. Também é possível, com o SketchUp e uma ferramenta baseada em browser, acrescentar novos modelos 3D ao Google Earth. Mas lembro-me de ter contribuído com bastantes modelos, há uns dois anos atrás, que nunca foram aceites/aprovados pela Google (nessa altura já deviam estar com as carrinhas na rua e a desenvolver o StreetView…). E isso é sempre desencorajador para quem não se importe de contribuir gratuita e voluntariamente com informação, que depois é descartada e esquecida. Essa é a razão principal pela qual não contribuo com informação para a Wikipedia: na altura em que o fiz, há muitos anos atrás, perdi semanas a escrever artigos, que foram depois todos rejeitados pelos Wiktators que administram a Wikipedia. Foi demasiado frustrante. Nunca mais contribui com nada para a Wikipedia!

Em compensação, o OpenStreetMap é totalmente diferente. Tal como todos os outros sistemas de cartografia online, usa várias fontes — públicas — para a informação «inicial». Por exemplo, a maioria dos rios em Portugal vem da Yahoo. A maioria das estradas vem do Bing. Noutros países obteve-se informação de fontes públicas semelhantes. Ao fim de uns anos, o OpenStreetMap estava mais ou menos ao nível do Yahoo, do Bing, ou mesmo dos Mapas Sapo: tinha a informação essencial — linhas costeiras, rios, estradas, e nomes de localidades — para a maioria dos locais do Planeta Terra.

Depois chegou a vez dos voluntários. O OpenStreetMap não tem dezenas de carrinhas a fotografar as ruas. Mas tem quinhentos mil voluntários a passearem por aí com os seus telemóveis com GPS — mesmo nos confins de África! — a recolher dados: nomes de ruas, tipos de edifícios, lojas, etc. Depois chegam a casa e metem essa informação no OSM. Mais do que isso: na realidade, nem toda a gente anda pelas ruas. Muitos fazem apenas a mesma coisa que eu: conheço bem a minha redondeza, e que me custa acrescentar informação sobre tudo o que conheço à minha volta?

No site do OSM existem várias formas de acrescentar informação aos mapas. Pode ser com uma aplicação externa que depois exporte para a base de dados central do OSM. Ou então com uma aplicação em Flash chamada Potlatch que é muito fácil de usar. Sobrepoem-se as imagens de satélite (que vêm do Bing, mas podem-se usar outras…) e toda a cartografar! Ao fim de umas horas, a cache do OSM já contém os novos dados, que são visíveis por todo o mundo. E há mesmo muita informação que se pode colocar — muito mais do que aparece na maioria das aplicações de cartografia digital que são publicamente acessíveis.

O princípio funciona — porque as pessoas conhecem as suas redondezas, e muitas pessoas a colaborarem podem efectivamente «preencher» muitas redondezas! Ademais, quanto mais alguém estiver frustrado com a falta de informação da sua redondeza, mais se sente encorajado em preenchê-la com informação, que é o que me acontece a mim! É por isso que o OSM tem, por exemplo, o mapa mais completo de Bagdade — os iraquianos estavam fartos de serem ignorados pelas empresas de georeferenciação, e por isso mapearam a sua cidade ao pormenor e ao detalhe.

Vamos a alguns exemplos. Eis o que a Microsoft pensa da zona onde vivo:

Ok, tem as ruas e pouco mais. De notar que a Rua do Monte Leite, onde vivo, está interrompida logo a meio do mapa. Mas a imagem de satélite que o Bing tem mostra a rua completa! E há umas ruas no canto inferior, ao centro, que estão por ali sem se perceber o que são. Na realidade não são ruas públicas: fazem parte de um condomínio de luxo que há por aqui, e não são acessíveis ao público. A norte, também ao centro, estão as ruas (sem nome) de um bairro social que outrora foi a zona mais temível do concelho — o Bairro do Fim do Mundo. Fazendo o zoom out, a Microsoft coloca correctamente o nome do bairro, mas não acha que vale a pena cartografar com mais detalhe um bairro social…

A Microsoft não tem mais informação nenhuma para estas paragens. Mas também não estaríamos à espera de melhor de um produto Microsoft 🙂

A Google, no entanto, não é muito melhor:

A ironia é que as imagens de satélite do Google mostram a rua interrompida, mas o mapa está correcto! De notar como as ruas parecem diferentes e às vezes até com menos nomes — embora na realidade, ampliando-se o mapa, há mais ruas com os nomes correctamente identificados. E, claro, começa a aparecer informação de empresas e pontos de interesse no mapa. Uma coisa que há muitos anos que aparece no Google Maps é a «Dolce Vita Guesthouse», que nunca percebi onde ficava, pois nunca a vi na minha rua!! (Já vou esclarecer o mistério mais abaixo).

Infelizmente não tenho nenhum produto Apple que corra iOS 6, pelo que não faço a menor ideia de como isto aparece no Apple Maps. Mas deve ser hilariante!

Contrastem isto com a riqueza de informação produzida pelo OpenStreetMap:

À partida, parece que há menos nomes de ruas, mas isso é apenas uma questão de ampliação — na realidade estão lá todos os nomes. Mas está muito mais. Por exemplo, percebe-se que há ali vários condomínios privados (na minha rua são dois, e há mais um abaixo) — quem conheça a legenda dos sinais topográficos do OpenStreetMap saberá distinguir entre estradas públicas e caminhos de acesso privados. Estão marcados passadeiras de peões, as zonas verdes, e até os percursos pedonais nos jardins! E, tal como nos mapas da Google de «cidades importantes», também aparecem os edifícios todos. Mas está lá muito mais ainda, que não se vê no mapa: os edifícios são classificados conforme sejam residências familiares, blocos de apartamentos, etc. Não se vê neste nível de ampliação, mas os edifícios principais têm também os números das portas. Os ícones podem apenas dizer que são ATMs, mas dizem também que são do Multibanco. Um símbolo de um banco diz que banco é que é. Podem-se ver não apenas as escolas, mas também os edifícios que pertencem à escola, os parques de estacionamento, e até os campos de futebol!

E toda esta informação está disponível para todas as aplicações que usem o OSM.

E resolvi finalmente o mistério do «Dolce Vita Guesthouse»: nunca o tinha visto na minha rua porque está num edifício dentro de um condomínio fechado ao qual não tenho acesso! Obrigado, OpenStreetMap, pelo esclarecimento de algo que me andava a fazer confusão há anos! Imagino a centenas de turistas confusos que andaram às voltas à procura do tal guesthouse sem saber onde ficava… 🙂

Ora mas a esta altura do campeonato vão-me dizer que é batota, porque é óbvio que fui eu quem lá colocou essa informação toda. Claro 🙂 Mas esse é o objectivo deste artigo. Na realidade, esta zona é um pedacinho de um trabalho de cartografia digital feita essencialmente por duas pessoas ao longo de dois dias. Não faço a menor ideia de quem seja a outra pessoa. No início da semana passada, o mapa do OSM estava igual ao do da Google, excepto com mais uma ou outra correcção que tinha feito há uns anos atrás. Mas reparei que havia um voluntário que estava a «encher» o lado leste da freguesia com casinhas, assim como a zona das praias. Então eu comecei a fazer o mesmo do lado oeste e norte, e corrigi alguns pormenores na zona das praias (não se vê nesta imagem). Ao fim de dois dias, praticamente mapeámos toda esta parte da freguesia, onde vivem 18.000 pessoas: S. João do Estoril tem neste momento no OSM mais informação cartográfica do que qualquer outra aplicação do mundo. E isto graças apenas a dois voluntários com insónias em dois dias. Imaginem isto multiplicado por quinhentos mil voluntários.

Ora claro que é fácil de acrescentar informação quando se conhece muito bem o sítio onde se mora, ou onde se trabalha, etc. Eu não conheço muita coisa assim tão bem em Portugal, por isso fui dar um saltinho aos mapas do Funchal, onde vivi mais de meio ano, e sabia que podia contribuir com alguma informação. Para meu espanto, vi que a cidade do Funchal tem já tantos voluntários a mapear aquilo tudo, que até fiquei vesgo com tanta informação!! Na altura em que vivia no Funchal, o Google Maps tinha apenas uma superfície toda branca para a Ilha da Madeira, com uma bolinha a dizer «Funchal». Hoje em dia claro que não é assim, mas a Google tem talvez um centésimo da informação que o OSM tem. Porquê? Porque não há Google Vans no Funchal. Mas há provavelmente algumas centenas de voluntários a cartografar tudo.

Ao ver nos sites das piadas dos mapas do iOS 6 que tantas universidades tinham desaparecido, ou que pelo menos os seus edifícios já não estavam lá, fui ver se a UTAD já estava no OSM. Claro que está. E com o mesmo nível de detalhe que a Google coloca nos seus mapas. Devem haver também alguns voluntários em Vila Real que fizeram o mesmo que os funchalenses fizeram à sua cidade, pois o nível de informação sobre Vila Real em geral é igualmente impressionante.

É evidente que os mapas no OSM são muito assimétricos em termos de informação: só aparece informação detalhada quando há voluntários nessa zona para fazer a cartografia. No entanto, os mapas «comerciais» também não têm o mesmo nível de detalhe — concentram-se primeiro nas zonas mais densamente povoadas, e deixam os subúrbios e as cidades de menor interesse para o fim. A ideia é que serão zonas tão remotas e despovoadas que não passará por lá ninguém.

Claro que eu acho que é justamente nos sítios mais remotos e despovoados que a cartografia faz mais falta, porque é precisamente aí que não se encontra informação em lado nenhum! Então, num impulso, decidi cartografar a Vila de Fonte Arcada, Concelho de Sernancelhe, Distrito de Viseu — pop. 270 (terra onde nasceu o meu pai):

Ok, é pouco provável que os turistas estejam interessados em visitar uma aldeia histórica (mais de dois terços dos edifícios têm mais de um século; alguns tem um milénio!) perdida na Beira Alta, mas se o fizerem, e usarem alguma aplicação que use dados do OSM, vão encontrar a Aldeia Com Mais Informação Cartográfica de Portugal™. Embora a ampliação acima não dê para ver, estão indicados todos os monumentos (e não são poucos), todas as ruas com nomes (nem todas as têm), e todas as casinhas que existem num raio de 10km, com os principais percursos pedonais assinalados, assim como os miradouros — e os dois únicos cafés e as fontes públicas que existem na redondeza quando for preciso beber água.

No Google Maps pelo menos fica-se a saber o traçado das ruas e os nomes das mesmas; os Mapas do Sapo têm até alguma informação adicional (excelente trabalho!) que muito me surpreendeu. Já não é nada mau, mas não conseguem competir com O Poder do Crowdsourcing™ do OpenStreetMap. Heh!

Ora isto tudo para dizer o quê?

Se a Apple tivesse usado uma das várias aplicações para iOS que usam OpenStreetMap em vez do Tom Tom, não teria havido tanta gargalhada geral. O que teria acontecido era que as pessoas reparavam que as coisas estavam todas mal e iam ao site do OpenStreetMap corrigi-las. É certo que iriam colocar imagens dos disparates que por lá encontraram, mas quem visse essas imagens, após se rir um bocado, se as fosse consultar no seu iPhone ou iPad, veria que já estavam corrigidas. É que com milhões de pessoas a actualizar o que está mal, o Apple Maps, em pouco tempo, deixaria de ter os problemas que tem.

Ironicamente, porque a Apple também usa informação do OSM, embora só para as zonas não mapeadas pela Tom Tom, vão ser justamente nas zonas menos povoadas e mais remotas que a informação do Apple Maps vai estar mais correcta e mais completa do que o Google Maps! Isto vai ser divertido de ver. O OSM publica imensa informação estatística sobre a sua utilização, e é giro de reparar que, desde que o iOS 6 foi lançado, que a utilização do OSM disparou. É natural que assim seja. Eu já me tinha esquecido de que o OSM existia, apesar de ter lá um login há anos. Foram justamente as piadas todas em torno do Apple Maps que me motivaram a ir lá acrescentar informação, mesmo sabendo que a Apple usa pouca informação do OSM. Mas usa alguma, e, pelo menos, para as dezenas de aplicações que usam, de facto, informação do OSM, todas estas ficaram mais enriquecidas com mais e melhor cartografia.

Há quem discuta o interesse da existência do OSM. Eu quando era puto era fascinado por mapas. Dizem-me os meus pais que aprendi a ler sozinho olhando para plantas de cidades e mapas porque queria saber os nomes das terras por onde passávamos quando andávamos de carro (já não me lembro nada disso). Na minha adolescência, perdia horas a fazer mapas imaginários para os meus jogos de role-play (na altura em que isso significava papel, lápis, dados, e jogadores humanos à volta de uma mesa). Sempre adorei mapas e cartografia. Obviamente que uma forma de contribuir com informação cartográfica é algo que me estimula. Inclusive parte do meu trabalho académico tem a ver justamente em descobrir formas de automaticamente encontrar percursos, e tudo o que tenha a ver com percursos de alguma forma atrai-me a atenção. Sei que há meio milhão de pessoas como eu, que estão registadas no OSM.

O argumento contra o OSM é que «dilui esforços». É verdade: se esse meio milhão de pessoas estivesse a contribuir para o Google Maps, este seria infinitamente superior. Mas a Google não está interessada nessas contribuições, não quer saber delas para nada (e porque provavelmente receia o vandalismo e o spam). Tal como a Microsoft, o Yahoo, a Tom Tom, etc. Provavelmente nem sequer o pessoal formidável dos Mapas do Sapo quer saber disso. E de certeza que o Instituto Geográfico do Exército, fonte da melhor e mais exacta informação georeferenciada neste país, deve odiar sistemas de crowdsourcing cartográfico, porque a venda de informação georeferenciada é uma fonte de receitas para o Exército Português, que bem precisa delas. E, finalmente, as dezenas de empresas em Portugal que trabalham em GIS também detestam esta ideia de ter centenas de milhares de voluntários a cartografar o mundo todo de borla. Estragam-lhes o negócio. É que uma coisa é ter duas ou três pessoas a fazer isso — naturalmente, cometerão erros, e os profissionais da cartografia farão mais e melhor, de forma consistente. Mas outra coisa é ter milhares de pessoas, a actualizar e a corrigir-se mutuamente. Tal como aconteceu com a Wikipedia, em relativamente pouco tempo — alguns anos — superaram qualquer outra enciclopédia do planeta.

Imaginem agora o que seria ter um funcionário de cada câmara municipal deste país dedicar, por exemplo, duas horas por semana a cartografar partes do seu concelho e a meter no OSM. Nem seria preciso mais do que isso. Ao fim de um ano, a informação cartográfica que existe para o país todo seria incrível — batendo toda e qualquer empresa ou aplicação existente. Mesmo o Exército Português, que tem mapas topográficos com um detalhe assustador (identificam árvores individuais e pedras que rolaram para o meio de caminhos florestais!), poderia beneficiar desse trabalho colaborativo. E duas horas por semana não é nada: é talvez o tempo que um funcionário camarário, em média, perde a ir à casinha e a tomar café 🙂 Mas o benefício será incomensurável, e, mesmo que cometa erros, mais tarde haverá quem os corrija. A Google pode ter centenas de pessoas para cartografar todo o mundo, mas Portugal teria centenas só para cartografar este país — e são pessoas que vivem no sítio que estão a cartografar, e sabem muito bem o que é importante e o que não é. Isso traduz-se na vantagem que a aplicação da Apple, em contraste, não tem: apresentar uma visão do território de acordo com a importância que as pessoas lhe dão.

A Apple jamais irá «apanhar» a Google em termos de informação cartográfica. Os meninos da Google têm cinco anos de vantagem, têm Google Vans, têm o maior e melhor motor de pesquisa do mundo. Em termos de tecnologia e capacidade de recolha e processamento de informação à escala global, a Google é imparável e imbatível. Talvez a Microsoft conseguisse fazer o mesmo, se fosse uma prioridade para eles, mas parece não ser. A Apple não tem um motor de pesquisa (tem o Siri…), e mesmo que contratasse centenas de pessoas e alugasse carrinhas, precisaria dos mesmos cinco anos para chegar ao mesmo nível da Google.

No entanto, aquilo que a tecnologia super-sofisticada da Google faz automaticamente pode ser replicada rapidamente — e com mais precisão — com centenas de milhares de voluntários. Como a própria Google sabe, há certas tarefas que os humanos desempenham muito melhor do que sistemas informáticos. Durante anos que a Google usava voluntários para fazer a classificação de imagens; de forma inteligente, até criaram um jogo em torno disso, para motivar as pessoas a classificar imagens. Isso criou-lhes uma base poderosíssima para terem imagens pesquisáveis de forma útil para os humanos (por isso é que o motor de pesquisa deles é tão bom a classificar imagens! Foram humanos que as classificaram!). Se a Google não o faz, a Apple nunca apoiará um modelo baseado em crowdsourcing para melhorar a qualidade do Apple Maps: não faz parte da sua cultura empresarial. O que isto significa é que, durante pelo menos uns cinco anos, vão continuar a ser o alvo da chacota universal dos utilizadores dos seus caríssimos produtos tecnológicos, que podem ser muito bons em imensos aspectos, mas que têm agora uma aplicação de cartografia digital pouco útil — ou mesmo totalmente inútil em muitas áreas do mundo.

No entanto, se forem espertos (não costuma ser o caso, na Apple…), poderão usar mais e mais o OpenStreetMap, e menos e menos o Tom Tom, e, «como por magia», a aplicação deles parecer-se-á mais e mais com o Google Maps, até finalmente o ultrapassar. Isto, claro, é fazer batota, e da grande. Mas as empresas espertas usam o que for de borla da melhor forma possível, se o objectivo for bater a concorrência. A Apple não consegue bater a concorrência excepto se usar informação crowdsourced — pelo menos a curto prazo.

Nos tempos do Steve Jobs, a Apple fazia este tipo de coisas com mais frequência. Toda a gente sabe que a Apple não desenvolveu o Mac OS X de raíz: foi buscar uma versão do FreeBSD e adaptou-a. Toda a gente sabe que não fez um browser de raíz: absorveu o projecto WebKit (que ironicamente a Google também usa) e deu-lhe apenas um nome novo. Eles fazem isso constantemente: encontram um produto open source estável e desenvolvido, e re-utilizam-no sob um novo nome, «vendendo-o» como se tivessem sido eles a inventar (a comunidade nem se importa, porque depois a Apple também contribui com algum desenvolvimento que fica depois disponível para todos de forma gratuita. É verdade!).

Nesta altura do campeonato, se fosse eu, tomava uma atitude de humildade (coisa que a Apple nunca faz!) e pedia desculpa aos milhões de utilizadores de iOS 6 que têm mapas inúteis. Lançava um patch ao iOS 6 com a mesma aplicação, mas a «puxar» dados do OpenStreetMap. E anunciava aos fãs todos da Apple em todo o mundo que, se quisessem melhorar os resultados dos mapas, podiam fazê-lo imediatamente, sem esperar pela Apple: bastava irem ao site do OpenStreetMap e corrigir o que está errado. Mas a Apple não é humilde e nunca pede desculpa pelos erros que comete. Por isso vai sofrer a gargalhada geral da humanidade (principalmente do campo Android!) durante muitos e muitos anos!

Dirão os anti-Appleianos: é muito bem feito! Estão a ser castigados pelo pecado do orgulho! 🙂

Entretanto, a única coisa que posso dizer é: não gostam dos mapas da vossa aplicação de mapeamento favorita? Fixe. Deitem-na fora. Usem uma aplicação que use os dados do OpenStreetMap e corrijam o que não gostam.

Será que o pessoal do Sapo está a ouvir? 🙂

É triste gastar-se tanto dinheiro…

Diariamente os meus amigos computer geeks quarentões atiram-me com links para o Facebook de artigos sobre o dinheiro que se gasta na Administração Pública com software e serviços informáticos neste país que depois até nem funcionam. Geralmente fico sempre chocado, e depois um pouco triste, pois há tantas soluções dispendiosas que podiam ser evitadas com apenas um pouco de bom senso e de conhecimentos…

Não pretendo aqui estar a fazer um «ataque» ao software comercial, dizendo que não presta e que as empresas que o comercializam são umas exploradoras. O mercado é livre: só compra produtos de software comerciais quem quer, ou quem pode. A título particular, nas alturas em que tenho dinheiro, até adquiro bastante software comercial (mesmo que seja de baixo custo). Não é porque não hajam alternativas open source gratuitas — normalmente até há! — mas porque gosto mais da interface, ou porque são mais estáveis, ou porque têm mais opções, etc. Num meio onde as empresas que vendem software comercial têm de concorrer com produtos idênticos open source a custo zero, há pressão para justificar a diferença de preço, porque os clientes potenciais (quando são indivíduos) que não tenham pruridos (leia-se: lavagem cerebral de que só o que é comercial é bom, uma falácia muito bem disseminada) sabem pesquisar na ‘net as alternativas e optar pelo que lhes parece melhor. Chamo a isto tomar decisões em consciência.

Infelizmente, neste país, o mesmo não se aplica à Administração Pública. Aqui o caso é grave, porque a Administração Pública está a gastar dinheiro que é de todos nós. Não seria legítimo, enquanto contribuintes, que esperássemos que gastassem esse dinheiro da forma mais eficaz possível?

Continuar a ler

A Internet totalitária

Disclaimer: Não me filiei no Bloco de Esquerda e não defendo a sua ideologia (se é que eles têm alguma). Continuo a achar, mais do que nunca, de que neste momento a monarquia seria mais útil à sociedade portuguesa (mesmo que também possa não concordar com as opções ideológicas da maioria dos monárquicos). Continuo a defender o direito a todo e qualquer cidadão de ser remunerado pelo seu trabalho da forma como muito bem entender e de afixar os preços como achar que é melhor para si, sem intervenção do Estado (excepto em situações de monopólio/oligopólio/cartelização). Portanto ainda defendo ideiais de direita.

Continuo igualmente a apoiar a ideia do Estado Social, onde o único papel do Estado é o de distribuir riqueza para termos uma sociedade mais justa. Esse papel é o de Robin dos Bosques: tirar aos que têm demais para apoiar os que mais precisam (e que realmente merecem o apoio); não o papel «invertido» que temos hoje em dia (onde o Estado taxa os que não podem fugir aos impostos para enriquecer aqueles que têm os seus bens e capital fora do alcance da máquina fiscal). Continuo a defender que o papel do Estado deve ser limitado à fiscalização e regulação, nomeadamente o de evitar (mas também o de prevenir) os abusos a um mercado que se pretende livre (o combate à corrupção, à cartelização, aos monopólios, quasi-monopólios, e oligopólios). Nesse sentido, sou social-democrata, mas na utilização dada por essa designação fora do PSD.

Mas também apoio a mobilização da sociedade para apoiar os mais carenciados (e hoje em dia somos quase todos…) e do Estado para financiar aquilo que a sociedade civil não quer apoiar: a cultura, a arte, a ciência (e em certas situações, a educação e a saúde). Nesse sentido sou quase socialista 🙂 Entre o modelo europeu e o americano (onde o Estado não apoia directamente esses aspectos da sociedade), revejo-me mais no modelo europeu, porque as noções de «caridade» e investimento voluntário e altruista na arte e cultura são valores que não fazem parte da nossa sociedade — embora façam parte da sociedade americana, mais conservadora e religiosa que a europeia.

Apoio a livre circulação de pessoas, bens e serviços como pilar fundamental da União Europeia — deve ser o cidadão europeu que escolhe onde quer trabalhar, onde quer viver, e onde quer pagar impostos. Nesse sentido, sou liberal. Mas também defendo que o modelo de «União Europeia» não funciona: estamos a dar dinheiro (quase) de borla sem impôr regras estritas da sua aplicação. Nesse sentido, sou federalista: se os Estados-membros não conseguem ser rígidos na aplicação das regras, tem de haver alguém que lhes diga o que fazer, como fazer, e como é que não o podem fazer, e essa aplicação de regras não pode ser «voluntária».

E, finalmente, apoio a livre circulação de ideias, seja pela Internet, seja por qualquer outra forma. Acredito em modelos de sociedade onde as pessoas, nos seus tempos livres, e tendo garantido o direito ao seu trabalho (o que está na Declaração Universal dos Direitos do Homem e replicado em praticamente todas as constituições democráticas no mundo), possa colaborar livremente em projectos e ideias que beneficiem terceiros, sem se preocupar muito com a sua própria remuneração. Apoio o voluntarismo. Apoio a criação espontânea de grupos de trabalho para resolver problemas sem ser necessária uma «organização estatal» (ou corporativa) que diga as pessoas o que fazer; estas conseguem organizar-se perfeitamente sozinhas, desde que haja vontade e capacidade de trabalho. Mas também apoio o direito à privacidade (em todos os seus aspectos) e a liberdade de cada cidadão de apenas revelar ao Estado o que quer — e que, na privacidade das suas casas, toda a gente tem direito a fazer o que muito bem lhe apetecer (desde que não seja ilegal). Nesse sentido, sou quase libertário de esquerda 🙂

Neste último aspecto, é óbvio que apoio todas as iniciativas que procurem limitar a liberdade de acesso à Internet, à livre circulação de ideias, e à privacidade do que cada cidadão faz com a Internet no conforto e segurança das suas próprias casas. Não reconheço a ninguém, por mais bem intencionado que seja, o «direito» a interferir com essa liberdade. Não aceito «moralismos» de que fazer X ou Y é errado, porque «uma entidade superior» (mundana ou alegadamente supra-mundana) sussurrou a um político o que está «certo» ou «errado», e que, a partir disso, lhe concedeu o «direito» de dizer às pessoas como devem pensar, seja no espaço público, seja no privado. Obviamente que em público temos regras e normas de conduta a seguir, para benefício de todos. Mas o que fazemos em privado com a nossa família e/ou amigos é connosco (desde que não seja ilegal).

Continuar a ler

WordCamp Lisboa 2011 — Um resumo

Todos os resumos serão necessariamente incompletos, pessoais e muito parciais. Esta é apenas a minha percepção do evento!

Mas antes de mais, um resumo do evento em imagens 🙂

Em primeiro lugar devo referir a perfeição da organização. Graças à Ana Aires, que fez a coordenação geral, o evento começou a horas, as sessões tiveram a duração prevista, e a pontualidade foi levada ao extremo. Nada de atrasos e de «quinze minutos académicos» ou semelhantes desculpas para a falta de pontualidade: o evento decorreu com maior precisão cronográfica que o sincronismo por NTP 🙂 Continuar a ler