Re: [ANSOL-geral] ANSOL: Disponibilização do código da STAYAWAY COVID não é suficiente

[Marcos Marado]

Olá Bruno,

Este tema é abrangente e complexo: peço desde já desculpas por uma resposta que
por um lado é longa e por outro lado menos profunda do que, se calhar,
gostarias. Aqui vai ela.

On Thu, Jul 23, 2020 at 11:07 AM Bruno D. Rodrigues <bruno.rodrigues  litux.org>
wrote:

[...]
> É fundamental não abrir mão da pressão para que o INESC liberte o código de
> toda a plataforma, desde as aplicações móveis aos código do servidor, tal
> como a SAP fez na Alemanha.

Concordo, mas também não tenho dúvidas que isso venha a acontecer. A promessa
está feita no site oficial da aplicação[1], e tem sido reiterada[2], ainda que
eles saibam que a promessa que fazem náo é suficiente para nos deixar
descansados[3].

> No entanto tenho de discordar com parte desta mensagem, pois a funcionalidade
> da Exposure Notification está bem documentada e é claro para qualquer
> developer que não há informação pessoal envolvida de todo nesse componente -
> bem pelo contrário, até o ID do bluetooth deixa de ser visível.

Teremos de discordar. É verdade que a GAEN tem uma especificação pública, mas
não consigo concordar que esteja "bem documentada". Para te dar um exemplo bem
concreto, a Google decidiu finalmente lançar "algum" deste código (o que eles
chamam de 'snippets', mas mesmo com esse código (que vais bem além da
especificação), estão a haver dúvidas sobre o que é efectivamente feito na
"parte escondida" - tens aqui um exemplo[4].
Também dá parte da questão de não haver informação pessoal envolvida é algo que
tenho de discordar, não por achar que há, mas por achar que não tens informação
suficiente para chegar a essa conclusão - afinal, a implementação é secreta...

> Criticar o projecto porque usa essa API é o equivalente a criticar porque
> corre em cima dos sistemas operativos fechados da Google e da Apple. É como
> criticar que não se pode usar a app a menos que todo o sistema operativo seja
> aberto por todas as marcas de telemóveis. Isto não faz sentido.

Também não posso concordar. Uma aplicação que use APIs do sistema Android
(repara, do Android, não do GMS, onde se encontra a GAEN) pode ser estudada,
escritinada a 100%, validada, reproduzida, e até mesmo portada. A parte
aplicacional está aberta, mas a parte do Sistema Operativo também, e essa
aplicação já não teria, os problemas de, por exemplo, não funcionarem nalguns
dispositivos da Huawei[5], ou em dispositivos com Lineage OS[6], ou de outra
forma sem GMS[7].

A GAEN não é só uma implementação do protocolo BLE - se assim fosse, estaríamos
provavelmente conversados. Mas a GAEN faz mais do que isso, e o que faz, e como
faz são duas perguntas para os quais não temos resposta absoluta, o que já
demonstrou ser um problema por exemplo para a comunidade científica[8]. A falta
de controlo dos detalhes de implementação também tem sido vista como
entrave[9].

> A interface de EN foi criada propositadamente para garantir que não haja
> abusos de privacidade (por razões altruístas, sim) e para que seja eficiente
> energicamente (por razões económicas).

Parece-me que a razão dos "abusos de privacidade" (na realidade, a opção para
uma solução descentralizada em vez de uma centralizada, além do não uso de GPS)
foi usada muito eficazmente pela Google e Apple, mas, na realidade, julgo mais
justa a afirmação "o DP^3T (no qual a GAEN se inspirou) apareceu com motivos
altruístas, para garantir que não hajam problemas de privacidade". Ainda assim,
nem sequer concordo que se possa afirmar (ainda que isto comece a ficar já um
bocadinho off-topic) que o DP^3T garante a privacidade aos utilizadores do
protocolo. Mas, acima de tudo, julgo que há pouco interesse nesta afirmação,
porque, em termos pragmáticos, menos do que interessar porque é que determinada
coisa apareceu, interessa é o que é que ela faz. E, lamento, mas como já disse
acima, não acredito que possamos ter a certeza de que o GAEN não permite abusos
de privacidade, quando não podemos escrutinar o que é ali feito, ao certo.

Chamo a atenção, aliás, a um exemplo que a própria ANSOL apontou na sua nota à
imprensa:

> > No dia 23/07/2020, às 09:42, Tiago Carrondo <tiago.carrondo  ansol.org>
> > escreveu:
[...]
> > Esta não é a primeira vez que nos deparamos com os problemas que advêm
> > do uso desta componente de software proprietário. Em [resposta à
> > comunidade
> > científica](https://github.com/corona-warn-app/cwa-documentation/issues/228)
> > quando esta encontrou um problema de segurança na ARC alemã, também
> > assente na interface GAEN, a equipa que a desenvolve
> > desresponsabilizou-se do problema, nem sequer alertando os seus
> > utilizadores, com o argumento de que o problema está na GAEN, e que "não
> > gerem essa componente", indicando que estas preocupações deviam ser
> > "enviadas directamente à Apple e à Google".

Já foi o problema de segurança encontrado e apontado nesse issue resolvido no
GAEN? Sim? Não? Não sabes? Se sim, em que versão? Com updates automáticos e
transparentes ao GAEN, como sabes o que mudou, o que foi resolvido e quando, a
cada momento? Será que a própria equipa da aplicação sabe alguma destas
respostas?

> Se só houvesse Android e as ARC usassem bluetooth normal, haveria facilmente
> a hipótese de abusos de privacidade, pois usando os IDs únicos do Bluetooth
> seria possível reconhecer outra pessoa em diversos dias, ou até ir à procura
> dela após a notificação de infeção.

Repara que não só o DP^3T foi desenhado antes (e depois em paralelo) com a
GAEN, como a GAEN se baseia nele. Ambos usam BLE, e há não só uma implementação
e uma especificação abertas destas ARCs, recorrendo às APIs de sistema para o
uso de BLE, sem recorrer ao GAEN[10]. Não há absolutamente alguma (que eu tenha
conhecimento, mas aceito correcções!) indicação ou motivação no que diz
respeito a segurança ou privacidade para que se use a "versão GAEN" do
protocolo. Na realidade, as sugestões de implementação para melhorias em termos
de privacidade até foram no sentido contrário (do DP^3T para a GAEN)[11].

> A API de EN tem zero de informação pessoal.

A API não tem, é verdade. Mas ao contrário do sistema de permissões de uma
aplicação, a GAEN é executada pelo GMS, que tem muitos outros componentes, faz
muitas outras coisas, e /pode/ estar a fazer integração de dados. Não é que eu
acredito esteja, pelo menos propositadamente, mas essa possibilidade existe, e
a única forma que tens de garantir que isso não acontece, é com transparência,
que até há data não existe.

> No entanto a app que corre terá acesso a tudo o que quiser (ao que pedir
> autorização), desde dados pessoais a localização. A Apple e Google
> comprometeram-se a analisar as apps e tentar que sejam compliant com
> privacidade, mas isso não chega, e está nas nossas mãos exigir o código fonte
> de toda a plataforma para que vários olhos possam verificar que faz o que diz
> que fará, e temos todo o direito de o pedir pois é uma plataforma paga com o
> nosso dinheiro.

É verdade que há uma "desresponsabilização confortável" na opção do uso da
GAEN. Uma aplicação que implemente as coisas ela, tem de estar bem
implementada, vai ser escrutinada, e quando forem encontrados erros, ou más
opções de arquitectura, é a equipa que desenvolve a aplicação a ser
responsabilizada. Já se usar a GAEN, as responsáveis pela API (Google e Apple)
responsabilizam-se por esse controlo: elas garantem que a aplicação não está a
tentar cruzar estes dados com dados de localização, por exemplo. Por outras
palavras: com o GAEN, estamos a fazer outsourcing da responsabilização a duas
empresas nas quais há bastante fé de que eles sabem o que estão a fazer; na
opção "implementação própria" estamos a conviar numa centena de programadores
dos mais variados institutos, tipicamente relacionados com a academia, e de
quem quase de certeza ninguém ouviu falar.
Mas - e é aqui que entra a minha opinião de que o Software Livre é, por
desenho, vantajoso - eu acredito que vale mais a segunda opção (software aberto
e escrutinável por todos), do que a primeira (software feito por gigantes
tecnológicas que podem até ter conflitos legais com as suas promessas que não
podem ser provadas do cumprimento da privacidade).

> A SAP lançou o código fonte duas semanas antes de lançar a app. Onde está o
> nosso código? Teremos disponível o código todo, incluindo servidor?

O que já há está no github[12], e as promessas vagas que há sobre a matéria
levam-me a acreditar que eles querem disponibilizar tudo, mais moldado do
modelo suíço que no alemão. Infelizmente, principalmente devido há já falta de
transparência até ao momento, além de atitudes como fazer trials antes de ter o
código publicado, não acredito que a documentação, principalmente em termos de
arquitectura, vá ser tão completa como o caso Suíço[13].

> O que é que a ANSOL recomenda que cada um de nós possa fazer pressão no INESC
> e no governo para que isto aconteça?

Mediatizar o assunto parece-me ser a coisa mais eficaz neste momento. Repare-se
que estamos num cenário em que provavelmente a força que podemos fazer em
termos oficiais não é muita: o Governo parece estar convencido que isto é uma
ideia boa e popular, e se até está a fazer coisas como aprovar Decretos-Lei
antes de pedir o parecer da CNPD ao mesmo, não os estou a ver a estar
preocupados com a questão "então e o código". Mas a pressão mediática já fez,
sem dúvida, o seu impacto, e algumas das afirmações e medidas tomadas pela
equipa do Stayaway parecem ter sido já em relação a elas (por exemplo, ao
excelente trabalho que a D3 tem desenvolvido sobre esta matéria).

[1] https://stayaway.inesctec.pt/
[2] https://eco.sapo.pt/2020/06/29/app-de-contact-tracing-portuguesa-tera-codigo-aberto/
[3] https://twitter.com/mind_booster/status/1284217210769215488
[4] https://github.com/google/exposure-notifications-internals/issues/2
[5] https://visao.sapo.pt/exameinformatica/noticias-ei/software/2020-07-14-aplicacao-stayaway-covid-nao-vai-funcionar-em-smartphones-huawei-sem-servicos-google/
[6] https://gitlab.com/LineageOS/issues/android/-/issues/1949
[7] https://github.com/DP-3T/dp3t-sdk-android/issues/10
[8] https://www.scss.tcd.ie/Doug.Leith/pubs/luas.pdf
[9] https://down.dsg.cs.tcd.ie/tact/posorient.pdf
[10] https://github.com/DP-3T/dp3t-sdk-android/issues/143
[11] https://github.com/DP-3T/documents#apple--google-exposure-notification
[12] https://github.com/stayawayinesctec
[13] https://github.com/admin-ch/PT-System-Documents

Cumprimentos,
-- 
Marcos Marado