~marado's tildelog

a tildelog on tildeverse

Contact Tracing

09 de maio de 2020 — ~marado

Pensei fazer um tweet, e quando dei conta tinha monologado uma thread bem grande. Para facilitar a sua leitura, decidi publicar essa thread aqui.

O Ricardo Lafuente escreve mais um interessantíssimo artigo no seu blog, desta vez sobre Contact Tracing.

Todo o artigo é bom (e leitura recomendada), mas gosto principalmente por estas duas frases que, em meu entender, são as que metem o dedo bem mesmo na ferida:

Seria ótimo termos em mãos a informação sobre o que se pretende implementar em Portugal, mas não existe ainda qualquer documento formal a descrever o que se está a preparar, apenas comentário de imprensa. Não pode ser assim, se estamos a falar de uma decisão sócio-política com implicações que ainda não conseguimos quantificar enquanto sociedade, mas cujo desfecho definirá as nossas existências nos tempos que aí vêm.

A meu ver, não podemos continuar a estar nesta situação em que aparentam estarem a testarem-se águas sobre várias soluções e a tentar formar opinião pública, sem que todas as cartas sejam postas em cima da mesa. É assim que temos coisas como este artigo da DECO, ao mesmo tempo que temos a admissão, mesmo dos proponentes deste tipo de apps, que, na realidade, a privacidade não está garantida, apesar dos riscos estarem minimizados (supostamente: nos promenores, encontram-se diversos compromissos a serem tomados mas várias soluções).

O artigo da DECO tb é apresentado como "país quer ARCs", quando na realidade os números que lá se vêm falam do inverso: afinal, "a maioria" pouco importa neste discurso, menos de 60% da população se voluntaria para o uso, e sem 60% estas apps são inúteis, dizem os estudos.

De notar que, pelo que se vai sabendo pela imprensa, a "app oficial", apoiada pelo Governo, será a StayAway, do INESC TEC. Mais uma vez, só se sabe dessa app o que vai aparecendo na imprensa, mas já com detalhes que levantam muitas questões.

Mas será mesmo assim? Urge que o Governo seja claro e transparente. Vai mesmo adoptar uma ferramenta? Haverá ainda espaço para o debate público sobre esta matéria? A adoptar, será mesmo a StayAway? Se sim, há ainda espaço para debate sobre as decisões de arquitectura da solução?

Urge termos respostas para estas perguntas. Até lá, será útil ler o artigo de ontem da ACM sobre o tema. Destaco três frases:

No known tracing applications can fully preserve individual privacy and anonymity, while multiple technical issues hinder the ability to prove or assume the apps' accuracy.

Moreover, high technical quality and functionality are insufficient for ensuring their efficacy.

Mechanisms should be employed for seeking the public’s and civil society representatives’ comment on proposed contact tracing technology and all aspects of its intended deployment.

tags: pt, tracing, COVID-19, privacy

comentários? tweetar  

Decentralized Privacy-Preserving Proximity Tracing -- is it really?

29 de abril de 2020 — ~marado

DP-3T, as it is known, stands for Decentralized Privacy-Preserving Proximity Tracing. It tries to be a decentralized, privacy-preserving solution to a problem: to make phone applications help mitigate the current COVID-19 pandemic.

OK, let me take a step back. There have been talks (and in some contries already actions) about having an app to use phones in order to help track down the spread of COVID-19. I am not focused, in this article, to argue that the idea, in general is bad (tip: I think it is, due to privacy concerns), or to point out that relying on big companies like Google or Apple to "take care of it" using closed and opaque methods is a really bad idea (tip: it should be obvious: it is). I also don't plan to discuss what is each country proposing, adopting, or doing: not even the Portuguese case, where the Prime Minister and President announce they are against geolocalization, one week later the same Prime Minister consider it a possible solution, and one other week later the adoption of a platform for that is announced. I am not even focused on the discussion between the adoption of DP-3T or one of the proposals of PEPP-PT: much was already written about it, and if you still don't know that DP-3T is a better design than any of the PEPP-PT endorsed solutions.

Instead, this article is about something I didn't see yet anything making the case for: DP-3T, the best protocol/architecture for a solution out there, claims to be Privacy-Preserving. But is it?

Not yet

My first take on this issue is to consider DP-3T as it is right now. It is, we understand, an ever-evolving specification, that, due to the time constraints inherent to the demand for applications of this sort, need to adopt a 'release early, release often' approach. Still, in the moment I am writting this, there are 14 open issues to the spec tagged as 'privacy risks'. Privacy, like security, or life, in certain cases is quite binary: there only needs to be one privacy issue with a certain protocol, format or tool, to make it not be privacy-preserving, so the answer to the question of DP-3T is privacy perserving is... "not yet."

Not really

But is that it? If you take a closer look, things get even grimmer. From the "privacy risk" issues previously opened and now closed on the project, we can see that several of them (nine, at this moment) were closed because they stopped having input. While a manual reading of each of them will show a status of them, and most of them were dealt (partially or entirely) one way or another, the struggle of the maintainers of the project to keep the number of issues low is clear, the reference to future versions of the documents leave things unclear of wether the issues have been addressed or not, and the way some things are not solved, but only mitigated shows that there is a "best effort" sort of approach to privacy, the idea that "let's see how privacy-preserving can we be in a rushing development cycle", instead of what it should be: a firm stance that no privacy-risk can exist in a privacy-preserving solution.

I do understand that the critic here so far is vague enough that one could argue that we're still on the 'not yet' field: after all, after all the privacy-related issues are closed, after all the documents still being prepared are published, one can go through all of those issues, check the latest version of the document, and verify if all of the privacy issues were indeed solved. Arguably, they could. But we do not need to stay on the theoretical field here, not when the "best effort" approach, even in partial sacrifice of privacy, is actually documented. My favorite example of this, is the FAQ's 5th point, about the use of anonymous communication systems.

Why not use mixnets or other anonymous communication systems to query the server?

In the answer to this question, DP-3T stipulates, first, that this is a valid question and concern. Then, they explain that they decided not to for three reasons: a solution would increase complexity, anonymity would cost latency and bandwidth, and it would widen the field of research necessary to take protocol decisions.

In the end, the answer is a claim that there currently is no system ready to use DP-3T could piggy back on and simply use to this purpose, mature enough to the scale DP-3T aims to be deployed -- if there was, they'd use it.

While I do not disagree - such anonymous communication system is a need we, as a society, have for a long time, but an itch we did never focus on scratching, and the solutions so far are far from a stable and consolidated state - I also believe that this is clear proof that DP-3T is, by design, not 'Privacy-Preserving', but only 'as Privacy-Preserving as we can be, with these time constraints'.

Why does it matter?

The difference between "private" and "as private as possible" is not small, no matter how tiny it is: it is the difference between a solution that respects your privacy, and a solution that doesn't. While I can understand DP-3T and its interesting properties as an academic project, it is, IMO, a dangerous assumption to think that, because this is the best someone has came up to, that it is good enough for us, and that we should adopt it. In fact, my belief is that, since DP-3T is the best we aim to be able to achieve during this outbreak, it should not be used. On the other hand, this can and should be used as a learning experience, proof that there is a need to serious public investment on the development of real Privacy-Preserving technologies, of which anonymous communication systems are just an example.

What could have been

This article is long enough already, and I could go on and on about what can be done, if the serious effort is made to make it happen. The first paper I wrote about GNUnet was more than 15 years ago: since then many things have happened, extraordinary developments in many technological fields, a decade and half has passed... but GNUnet seems to me as being still the most promising privacy-centric project out there, and, quite unfortunately, it is still in an early alpha stage. The latest incarnation of its website has a tagline that is quite fitting for this article: "The Internet of tomorrow needs GNUnet today". In 2020, technology failed us in many ways: when a worldwide event like COVID-19 hit, we searched for technological solutions that still did not exist. 2020 was tomorrow, and we did not have GNUnet (or any other solution of choice -- take your pick, there is plenty around to do). My biggest fear on this subject is not to see solutions like DP-3T (or worse) being adopted, affecting the privacy of real lives, real people. My biggest fear that we will step out of the current sittuation, and decide not to learn from the evidences of past mistakes. Let's build the Internet of tomorrow, now.

tags: en, DP-3T, COVID-19, privacy, tracking, tracing, localization, PEPP-PT, gnunet

comentários? tweetar