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…

Populismo, nacionalismo, ignorância e comunicação social

Está-me a irritar descomunalmente a forma como a comunicação social — e, por inerência, o resto da população que passa o tempo todo nas redes sociais — tem andado a tratar o aumento do populismo no mundo ocidental. E chega a altura de alguém começar a ralhar com os senhores jornalistas e apontar-lhes o caminho — e abrir-lhes também uns livros de História para lerem! Continuar a ler

A bola é redonda, ou: a vitória do(s) Patrício(s)

Felizmente não percebo absolutamente nada de futebol. Também, isso não quer dizer nada, pois a esmagadora maioria dos «especialistas» — ou treinadores de sofá — que escrevem por aí e que comentam na rádio e na televisão têm tanta formação em futebol ou ciências do desporto como eu; as únicas pessoas que conheço pessoalmente e das quais respeitaria eventualmente a opinião, são o meu irmão e a minha cunhada, ambos licenciados em ciências do desporto, embora a especialidade deles seja o andebol, não o futebol… De resto, trata-se tudo de amadores que percebem tanto do assunto como eu percebo de mecânica quântica ou biologia molecular: e desde já devo explicar que sou capaz de ficar várias horas a falar sobre estes dois assuntos e convencer uma audiência de que percebo catrefadas do assunto, quando na realidade pouco mais sei do que se lê por aí em Wikipedias e afins. Mas como domino, em certas áreas, a técnica do bullshitting along (vão ao dicionário ver o que significa), cá vai a minha contribuição para este momento de orgulho nacional!

Continuar a ler

A solução para a Volkswagen?

Por esta altura do campeonato, a senhora Merkel andará com mais uma dor de cabeça. Ainda com os problemas da Ucrânia, da Grécia, e dos migrantes por resolver; a adivinhar-se uma longa batalha com David Cameron para mudar as regras da União Europeia (impedindo assim que em 2017 os britânicos não votem em referendo pela saída do Reino Unido); cai-lhe mais uma bomba em cima: que fazer com um dos maiores grupos da indústria automóvel europeia, sediada na Alemanha, que anda a enganar os consumidores e as entidades reguladoras há anos?

Continuar a ler

Para os indecisos…

Mulher gira lendoAs eleições estão à porta. Ainda não se decidiu em quem vai votar. Vamos imaginar que está confortavelmente num consultório médico à espera, a ler as notícias, a procurar informar-se sobre o que dizem os candidatos, a procurar escolher o destino que quer dar a Portugal para os próximos quatro anos.

Mas a comunicação social é confusa. Não a satisfaz. Continua com dúvidas. Qual é, de facto, a melhor escolha — para si, para os portugueses, para Portugal?

É difícil de tomar uma decisão? Este artigo é para si! Continuar a ler

Ortografia por computador

Na passada semana, uma série de meios da comunicação social andaram a divulgar que o (Des)Acordo Ortográfico de 1990 tinha entrado em vigor dia 13 de Maio de 2015, e que, por causa disso, agora passava a ser «proibido» escrever com o acordo «antigo».

Apesar dessa interpretação da data de entrada em vigor do acordo ser incorrecta, a questão principal que coloco não é essa. Nem sequer vou debater, como já fiz, os problemas deste alegado «acordo» de 1990.

A minha questão é mais pragmática: qual acordo é que foi, afinal de contas, aprovado?

Continuar a ler

Em defesa de Passos Coelho

À mulher de César não basta ser pura e virtuosa; também tem de estar acima de qualquer suspeita.

Está na moda «bater» em Pedro Passos Coelho porque este aparentemente não tem noção da legislação que regula as contribuições da Segurança Social, e, alegadamente, também não percebe da legislação fiscal. Ora num Estado de Direito, a ignorância da lei não é factor mitigante; e, para além disso, exige-se que um Primeiro Ministro seja, acima de tudo, exemplar na forma como cumpre a lei. Não basta parecer que é honesto e cumpridor. Tem de o ser mesmo. Esta é a essência sumária da opinião pública em relação ao actual Primeiro Ministro de Portugal: afinal de contas, é tão malandro como os outros, porque também não pagou as suas contribuições e dívidas fiscais — e ainda por cima teve pelo menos cinco processos de contra-ordenação e de execução fiscal!

Mas que malandro!

Continuar a ler

O que os analistas da indústria exigem da Apple…

Nota: Este texto apareceu na sua versão original no Facebook. Mas como o Facebook é impossível de pesquisar por conteúdo, e daqui por uns anos será divertido rir-me do que escrevi, resolvi copiar isto para o meu blog.

Li hoje de manhã um artigo escrito por analistas do mercado, antes dos anúncios da Apple, de que a Apple «tinha» que lançar outro produto que fosse revolucionário e que abrisse um novo mercado, pois «há nove meses que não o fazia» e como tal o seu futuro estaria sob compromisso…

Aparentemente, os especialistas da indústria estão à espera que a Apple faça o trabalho de todo o mundo — que diga ao mundo para onde é que a tecnologia deve apontar! Se não for a Apple a fazê-lo, mais ninguém o saberá fazer?

Pior que isso, acusam a Apple de «só» ganhar 10 mil milhões por ano a vender iPhones e outro tanto a vender música e apps. Dizem esses analistas que a Apple «está acabada» se não vender mais coisas diferentes. Mas babaram-se quando o Facebook anunciou, todo contente, que já ganhava mil milhões de dólares em publicidade…

Ou seja, o argumento destes analistas é que se a Apple só vender iPhones, apps, música, filmes, Macs, portáteis, iPods, iPads, Apple TVs, e sei lá que mais coisas existem hoje em dia na linha de produtos deles, ganhando umas dezenas de milhares de milhões de dólares por ano, com margens que fazem a concorrência chorar de raiva, então a Apple está «arrumada». Tem que fazer muito mais. Tem, por alguma imposição talvez divina, de inventar novos mercados, porque os que tem, «já não chegam para nada», como se fossem apenas uns «trocos»…

Bem. Olhemos para os últimos 15 anos apenas. Nesse período de tempo, é certo que a Apple lançou meia dúzia de produtos que de facto revolucionaram mercados, criando-os onde não existiam. Os meus amigos anti-Apple adoram dizer como a Apple nunca inventou nada (apenas copia as ideias que a Xerox já tinha no final dos anos 1970) e que os seus produtos são uma porcaria e estão ultrapassados (claro que esses meus amigos anti-Apple nunca experimentaram a sério os produtos da Apple por uma questão de fundamentalismo ideológico e apenas fazem comentários a partir de revistas que lêem e experiências que fazem em 5 minutos na FNAC; mas isso é outra conversa ). Na maior parte dos casos, até pode ser verdade. Os engenheiros da Apple são bons, mas os da Samsung, só para darem um exemplo, são melhores.

A questão nem é essa. Quando a Apple lançou no mercado um computador com interface gráfico de utilizador e um rato, tudo isso já tinha sido desenvolvido pela Xerox uma década antes. E pouco tempo depois os PCs passaram também a ter Windows e rato, e pode-se argumentar que eram melhores que os produtos da Apple. Mas essa não é a questão. A questão é que a Apple inventou a «necessidade» dos computadores pessoais terem interfaces gráficos de utilizador e que usassem janelas e ratos. Não interessa se já existiam e se o que veio depois era melhor. A necessidade — o mercado — não existia. A Xerox não acreditava nele. A Microsoft e a IBM riam-se da ideia. Mas a Apple mostrou que havia gente que preferia essa forma de utilizar os seus computadores pessoais, de uma forma simples, sem memorizar comandos complicados. Depois fez-se melhor, claro.

Já haviam trackpads antes da Apple achar uma boa ideia colocá-los em computadores portáteis. Mais uma vez a Apple não foi «a primeira». E se calhar hoje em dia nem é a melhor. A ideia de colocá-los num produto de massa é que foi inovadora (alguém se lembra dos micro-ratos de borracha dos IBM Thinkpads, encaixados entre teclas no teclado? Uma ideia giríssima, mas que não «pegou»).

A Sony, quando lançou o Walkman, também não estava a inventar algo de radicalmente novo. Já haviam leitores de cassetes portáteis, a pilhas, que se levavam a tiracolo, e nos quais se podiam ligar auscultadores. A inovação foi de conceito, de produto — não se pode correr com um leitor a tiracolo, enrola-se, é desconfortável… E de certeza que depois surgiram empresas a fazer melhores walkmen que a Sony. E de certeza muito mais baratos. Também não interessa. A Sony, apenas com boa concepção de produto, criou um mercado novo que não existia antes.

A dada altura a Apple achou que andar só com uma cassete ou um CD não chegava, e meteu milhares de músicas num aparelho pequenino que cabia em qualquer bolso. Mais uma vez não eram originais. Já haviam produtos assim no mercado. Nenhum foi massificado — porque, em simultâneo, a Apple lançou a idiea que a melhor forma de carregar músicas nesses aparelhos seria convencer a indústria musical a vender a sua música num formato novo: em vez de ser em CD, seria em descarregamento directo via Internet. Nada disso é novo. Já havia pirataria maciça quando o iPod foi lançado. Toda a gente sabia descarregar música via Internet e o que não faltavam eram sites. E haviam também sites que vendiam músicas. Mas, mais uma vez, o que não havia era alguém que dissesse à indústria de música que passara a haver um método novo de vender música — e a convencesse a aderir. Hoje em dia, podem-me dizer que todos os outros sites de venda de música são melhores que os da Apple, e que as próprias editoras e os artistas preferem a concorrência da Apple. Não questiono isso. O que importa é que o conceito não existia: distribuir música pela Internet era sinónimo de pirataria, mas a Apple mostrou que se podia também ganhar dinheiro. E de facto assim foi. Depois outros pegaram na ideia e melhoraram-na.

Quando o iPhone foi lançado, haviam decerto excelentes telemóveis no mercado. Os melhores já corriam aplicações em Java e noutras plataformas. A ideia de que o telemóvel pode ser um computador que sincroniza contactos e calendário com o nosso computador pessoal não era nova de todo. Mas a Apple foi muito mais longe, especialmente ao irritar os gigantes de telecomunicações, que, até à data, eram eles que impunham as regras aos fabricantes de telemóveis e ficavam com as margens todas. A Apple acabou com essa tirania criando um produto que os consumidores queriam, contra a vontade dos operadores. E o produto não tinha nada a ver com o que existia no mercado. É certo que fazia também chamadas, mas era um conceito completamente novo, com um interface absolutamente diferente de tudo o que existia na altura. Hoje em dia, chamamos-lhes «smartphones», e, como os meus amigos anti-Apple gostam tanto de dizer, publicando todo o tipo de estatísticas, a Apple não fabrica os melhores e mais sofisticados smartphones. São os engenheiros da Samsung, que forneceram quase todas as peças para os primeiros iPhone, que hoje em dia fabricam produtos muito superiores. Não nego isso, de todo. Mas é preciso lembrar que a Samsung estava incrivelmente céptica com as ideias da Apple quando esta lançou o iPhone. Só os fabricavam porque a Apple lhes pagava, e bem, por componentes caríssimos que na altura ninguém pensava usar (porque não havia margem para isso!), e, tal como todo o mundo, não acreditavam na capacidade da Apple de vencer um combate contra os gigantes das telecomunicações.

Uma vez que estes foram «vencidos» — e com bons argumentos: apesar de tudo, fizeram balúrdios com o negócio! — tal como os gigantes da indústria da música uns anos antes, então, sim, toda a gente passou a acreditar em smartphones. A Google comprou o Android e ofereceu-o. Gasta milhares de milhões por ano para manter um produto do qual não obtém retorno financeiro, mas apenas brand awareness. Em compensação a Apple ganha… dez mil milhões por ano a vender os seus smartphones quiçá obsoletos, ultrapassados, e demasiado caros para o que fazem. Não interessa. O facto é que o smartphone não é «apenas» um telefone móvel mais sofisticado. É todo um ecosistema que envolve a indústia de telecomunicações, de desenvolvimento de software, de distribuição de músicas, filmes, e livros. Nada disso existia antes da Apple «inventar» o iPhone — não o aparelho, que pode não ser inovador, mas o conceito. Hoje em dia, falamos do mercado da «economia móvel» como se fosse algo estabelecido há décadas por decreto governamental. Mas não existia antes da Apple o inventar!

Quando a Apple lançou o iPad, os tablets não eram de todo uma novidade. Numa «Scientific American» de 1993, salvo erro, havia um artigo sobre a Xerox. Viam-se claramente tablets, de vários formatos, sobre uma mesa à entrada das instalações; o tablet moderno tinha sido inventado em 1972 por Alan Kay, um cientista na altura na Xerox, que lhe deu o nome Dynabook (mas só foi construído um protótipo nos anos 1990), e que andava a pensar nestes conceitos já desde 1968. Funcionavam precisamente como hoje: sincronizavam via wireless a um sistema central. Os funcionários da Xerox quando chegavam ao escritório pegavam num tablet do tamanho que preferiam, faziam login, e ficavam com acesso aos servidores do escritório, e podiam tomar notas e comunicar em qualquer lado. No artigo referia-se que, embora a Xerox tivesse muito boas ideias, esta provavelmente não iria vingar fora do espaço de um escritório altamente especializado.

Imagem de um tablet a fazer uma chamada vídeo no filme «2001: Odisseia no Espaço», em 1968. O tablet parece ter o logotipo da IBM.

Imagem de um tablet a fazer uma chamada vídeo no filme «2001: Odisseia no Espaço», em 1968. O tablet parece ter o logotipo da IBM.

E como a Samsung demonstrou em tribunal num processo em que a Apple os colocou, o filme «2001 — Odisseia no Espaço», realizado em 1968, tem tablets iguazinhos aos iPads, até mesmo no pormenor de serem usados para ver vídeos e consultar notícias e mandar mensagens (talvez Kubrick tivesse lido os primeiros artigos de Alan Kay…)… Portanto, a ideia, o conceito, não tinha nada de revolucionário. A própria Apple já tinha experimentado uma coisa parecida com o Apple Newton, um PDA demasiado grande para caber num bolso que foi um «flop» comercial tremendo, ao ponto de já ninguém se lembrar disso (eu cheguei a ter um mas vendi-o ).

O facto é que há anos que se viam produtos semelhantes no mercado. Mas não «pegavam». A Apple lança a sua visão do que deve ser um tablet, e é um sucesso imediato. Depois é copiada por quem faz melhor e, principalmente, muito mais baratos — estive a ver tablets a correr Android por €40, que podem ser adquiridos directamente da China (portes incluídos!), e que têm as mesmas características e capacidades das «marcas brancas» que se vêem na FNAC pelo triplo do preço. Se se derem ao trabalho de pesquisar pelos fabricantes chineses de tablets, até ficam vesgos das opções que existem — centenas de marcas com dezenas de milhares de produtos, com todo o tipo de especificações que quiserem, a custar desde os tais €40 aos mais de €1000. Há para todos os gostos e todas as bolsas. É um mercado maduro, um produto de consumo completamente banalizado, e altamente apetecível. Mas não existia. Em 1993, ninguém acreditava nele. Antes de 2010, muita gente experimentava com a ideia, mas ninguém conseguia ter sucesso. Depois disso, abriu-se um mercado vasto que pura e simplesmente não existia — e do qual a Apple já provavelmente nem sequer é líder de mercado.

Não quer dizer que toda a inovação tecnológica que tenha radicalmente mudado o mercado e a forma como encaramos o papel da tecnologia no mercado tenham vindo da Apple. A Apple não inventou a World-Wide Web. Também não inventou o comércio electrónico, embora tenha contribuído bastante na questão da venda de música online. E, mais importante que isso, não inventou os serviços baseados em cloud —o mérito vem principalmente da Amazon, que os colocou de forma maciça e acessível a todos, e da Dropbox, que demonstrou o que se pode fazer com isso. O produto da Apple, agora iCloud (dantes era MobileMe), é, francamente, uma porcaria. Funciona, mas não se percebe bem como. A Apple chegou tarde a perceber as vantagens do conceito, e adaptou-o muito mal à sua própria filosofia (as novas versões do Mac OS X e do iOS que se aguardam a qualquer momento devem corrigir os problemas principais, mas, mais uma vez, repito, a Apple aqui nem inovou, nem sequer implementou bem, anda apenas a «reboque» e a cometer erros).

Quero apenas dizer que muitas das inovações tecnológicas que tiveram um impacto drástico no mercado partiram efectivamente da Apple, mesmo que actualmente não seja ela a principal beneficiada disso (ou sequer uma das principais). Claro que houve muitas mais coisas revolucionárias nestes últimos 15 anos. Estou a pensar em coisas como o Kinect da Microsoft (que vai muito mais além do interface do Wii), que podem revolucionar completamente como interagimos com os jogos — e, quiçá, com computadores — no futuro. Mesmo os conceitos de motores de pesquisa, o YouTube, e os sites sociais em geral são revoluções em termos de mentalidade, e a Apple não teve um papel activo em nada disso (nem sequer passivo — os forums da Apple são horríveis!). Podia listar muito mais coisas que tiveram um impacto na economia em torno da tecnologia em que a Apple não esteve presente. Mas isso não quer dizer que uma quota de mercado considerável dessas inovações radicais pertence, realmente, à Apple, mesmo que depois tenha sido ultrapassada pela concorrência, que faz mais, melhor, e por vezes mais barato.

Tira de «Basic instructions» por Scott Meyer

Tira de «Basic instructions» por Scott Meyer

Sem as inovações da Apple, hoje em dia continuaríamos a ter telemóveis minúsculos com teclas, cujas ligações à Internet se limitariam a consultar uns mails (como nos tempos áureos da Blueberry) de forma proprietária. Teriam muito melhor voz, uma autonomia extraordinária, e muito maior capacidade de armazenar contactos. Mas não tirariam fotografias, não dariam para jogar clones de Starcraft, ou para mandar mensagens no Facebook. Continuaríamos a ter gravadores de CDs nos portáteis porque seria a única forma de ouvirmos música — com os nossos Sony CD Walkman. E obviamente que continuaríamos a ir à FNAC para comprar música, ou pirateá-la na net como sempre. Os televisores em casa não estariam ligados à rede. Os fabricantes de portáteis continuariam a investir nas linhas dos subnotebooks e desesperadamente a tentar aumentar a performance dos mesmos — e as horas de bateria — para que conseguissem correr as últimas versões do MS-DOS… porque nenhum fabricante acreditaria que fosse útil usar um interface gráfico de utilizador! Provavelmente a Amazon continuaria a não vender eBooks… não vou dizer que tenha sido a Apple a «inventar» os leitores electrónicos portáteis (porque não foi!), mas se não tivessem sido os iPhones a serem usados como uma forma simples de ler livros, talvez nem sequer a Amazon se arriscasse a lançar o Kindle…

Seria um mundo muito diferente, o que se pode dizer praticamente de toda a tecnologia que force uma mudança de paradigma. No caso da Apple, fizeram-no muitas vezes.

Hoje a Apple anunciou o lançamento de… um relógio. Também não é nada de novo: há mais de um ano que existem «pesos-pesados» na indústria que têm os seus relógios a correr Android. Mais baratos e provavelmente melhores que o Apple Watch. Mas a diferença, mais uma vez, está nos pormenores. Quando Steve Jobs, ainda vivo, explicou que as pessoas iriam usar telemóveis para jogar jogos (em vez de comprarem consolas portáteis), estava a explicar que pensava no iPhone como muito mais do que meramente um dispositivo de comunicações, mas como uma forma de vida. O Apple Watch terá como característica notável a capacidade de substituir os dispositivos usados pelos maluquinhos do exercício — colocando sensores para o batimento cardíaco, pressão arterial, GPS, e tudo o que é preciso para o jogger profissional (incluindo música!) no relógio. Mas o mesmo relógio também vai servir para fazer pagamentos em 220.000 lojas nos Estados Unidos, no dia em que for lançado. Mais uma vez: nada disto é original. Antes do Natal de certeza que os fabricantes chineses vão todos lançar coisas idênticas. Daqui por cinco anos, é possível que a Visa e a MasterCard, em vez de emitirem cartões de plástico para os seus cartões, passam a oferecer relógios (têm a vantagem de poderem ser imediatamente desactivados se forem roubados), fabricados na China por uns tostões. Se calhar as companhias de aviação farão o mesmo — porque os cartões de embarque também já são arquivados no Apple Watch — e, pelo menos nos Estados Unidos, poder-se-á andar nalguns transportes públicos apenas envergando o relógio.

Vão-me dizer que nada disto é novo. Pois não é. Tenho amigos meus que usam os seus telemóveis para andar nos transportes públicos e que não precisam de relógios para nada. É verdade. Mas a questão nem é se o Apple Watch vai ser um sucesso ou não: é a mudança de paradigma que vai ocorrer quando passarmos a olhar para o relógio de uma forma completamente diferente de antigamente. Tal como um smartphone deixou de ser uma ferramenta de comunicação para ser muito mais, um relógio vai passar a ser muito mais do que uma coisa que diz as horas e que tem uns alarmes e uns cronómetros. Vai ser um equipamento prático que podemos usar a qualquer momento sem ter que o tirar do bolso e andar a teclar umas coisas fazendo figuras tristes. É isso que o Apple Watch implica. Primeiro, claro está, vai apelar aos fãs da Apple que não se importam de gastar balúrdios por um relógio que eu pessoalmente acho bonito, mas que muita gente não acha. Mas daqui por 5 anos os «smartwatches» vão custar €30 e correr Android e fazer praticamente o mesmo que os relógios da Apple. Toda a gente vai ter um — mesmo em África ou no Haiti. Para as pessoas que querem lá saber das trinta mil funções de um smartphone e que não se entendem com ele, e tudo o que querem é fazer chamadas telefónicas simples — e, já agora, ver as horas — se calhar só precisam é de um «smartwatch». A ideia da Apple de aumentar o tamanho dos iPhones se calhar não é tão burra como parece: um dia, muito próximo, se calhar deixamos de usar o smartphone para telefonar. Têmo-lo no bolso ou na mala, e usamos apenas o relógio para comunicar, que é mais prático para isso. É esta a questão. Não é se o relógio da Apple presta ou não. É no que vai transformar a nossa vida.

Curiosamente, de entre as coisas que a Apple apresentou, uma delas ainda me chamou mais a atenção, e que se calhar ainda representa uma mudança de paradigma mais profunda, mas passou despercebida à maioria das pessoas. Os U2 lançaram um álbum novo — exclusivamente via iTunes. Isto pode não parecer ser nada de especial. Mas uma particularidade é que o álbum é oferecido pela Apple, de borla, a toda a gente que esteja registada no iTunes. Dirão que é uma tentativa desesperada da Apple para que as pessoas voltem a ligar-se ao iTunes, que não tem feito tanto dinheiro como dantes. Talvez seja. Mas tem consequências curiosas. O álbum «Sounds of Innocence» dos U2, em poucos dias, vai ter 500 milhões de pessoas a descarregá-lo. Será provavelmente o álbum mais ouvido desde sempre no espaço mais curto de tempo. Eu nem gosto muito de U2 (mas a minha mulher adora), mas descarreguei o álbum e ouvi-o, porque é de borla. Poderão dizer-me que música de borla, na ‘net, é o que há mais. Sem dúvidas, mas não temos métricas sobre a pirataria. Do ponto de vista das editoras e da indústria de música, isto é uma anomalia. Será que o Bono levará um disco de platina um dia depois do álbum ter sido lançado? Aliás, na realidade, deve receber um disco de platina de praticamente todos os 119 países do mundo onde o álbum foi lançado. Que quer isto dizer para a indústria da música? Como serão feitas as métricas a partir de agora? E que dizer do modelo de negócios novo, em que uma empresa — a Apple — por uma questão de publicidade, contrata uma banda para depois oferecer a sua música a centenas de milhões de fãs? Será isto a indústria da música de futuro? Será que amanhã teremos a Google a contratar a Rihanna para fazer o mesmo? O que será o futuro da indústria quando as bandas, em vez de ganharem dinheiro a fazer concertos e a vender os poucos CDs que ainda conseguem, em vez disso passam a ser patrocinados pelas empresas, que subsidiam os seus álbuns — pagando-lhes milhões, claro, porque os artistas mais que merecem ser bem pagos! — para depois serem distribuídos gratuitamente, de forma legal, pelos vários sites de música?

Terá sido isto meramente um golpe de publicidade por parte da Apple, ou meramente um sinal de mais uma revolução silenciosa, que mal deu nas vistas — excepto para quem hoje abriu o iTunes, seja no computador, seja no telemóvel ou no tablet, e que reparou que tinha lá um álbum novo?…

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