Misleading comparative legal analysis of the NTK system

[pdehaye]

The new security analysis of the NTK system published by DP-3T states:

the backend also learns encounters among non-infected users, in contravention of the need-to-know and data minimization principles expressed in the GDPR, as alternatives where this does not occur, such as DP-3T, are also available

This seems to me to be misleading, since both DP-3T and NTK seem to make assumptions that are different, with neither of the two documenting them fully.

For instance, DP-3T states in their own White Paper:

Note: we are actively discussing with epidemiologists if the data provided by this design is sufficient to achieve their objectives.

While on the other side:

• PEPP-PT in their press presentation, Prof. Fraser stating - paraphrase - earnestly "why wouldn't I want all the data?"
• ROBERT: Prof. Sportisse couching in sovereignty terms within a dynamic context the issue of massive data collection

In short, NTK assumes they need more data than DP-3T (i.e. some edges in the social graph). Part of the reason is speculatively to conduct research to calibrate their Bluetooth proximity to actual infection risk (i.e. research around digital contact tracing). Part of this calibration will presumably require knowing about contacts that don't lead to infections, especially if tests remain scarce, nations don't share them, etc.

It is clear that NTK will require justifying later on why they need to collect parts of the social graph (in a DPIA, for instance). But DP-3T has not provided conclusive evidence either that this data is not needed. I am aware of the paper meant to touch on this topic included in the repo, but it doesn't actually answer the calibration issue (and is not peer-reviewed), and doesn't really seek the right engagement with the rest of the digital epidemiology community.

So in short: please remove any legal analysis from your criticism of NTK, or qualify it heavily.

[ralfr]

The good news is: PEPP-PT's implementation cannot be implemented on iOS –– for obvious and very good reasons. Apple made a clear design decision in favor of a decentralized solution. So NTK in its current form is not going to happen at least on iPhones.

If Google follows Apple's lead, it won't happen on Android either, however, Google will have more difficulties enforcing it, while on iOS, it's very straight forward.

[pdehaye]

How would it be good news that:

• two competing teams of European academics decide to abandon any pretense that they should not misrepresent their respective work and politicize the issues;
• two colluding teams of engineers based in Cupertino and Mountain View would get to arbiter instead?

[ralfr]

I am explicitly not referring to any political dimension here. I'm emphasizing the fact that PEPP-PT's current protocol suggestion cannot be implemented on iOS. It (a) can't be done technically (and they should probably know from reading Apple's specs) and it would (b) be in direct violation of Apple's specs.

I qualify this as good news, because I'm strongly opposing centralized contact tracing protocols.

[pdehaye]

Instead, you are supporting centralizing decision-making protocols bypassing democratically elected decision-making processes, which is way worse.

I would advise you to read this.

[ralfr]

Instead, you are supporting centralizing decision-making protocols, which is way worse.

I am not. But I am realistic.

There are two major mobile operating systems. iOS has prevented BLE background scanning for a long time and for good reasons. The simple reality is: BLE based contact tracing apps on iOS will only be able to do what Apple facilitates. It is in no way relevant, whether I like that or not.

I do, however, find it confusing that one major European initiative (PEPP-PT) publishes a draft protocol, which knowingly and very obviously cannot be implemented for at least one of the two major mobile platforms. Naturally, this makes me question their entire effort. (I don't judge their hopefully good intentions, just their ability to execute technologically.)

I would advise you to read this.

I am aware of it and disagree. I also published this suggestion which would take care for never exposing any of the IDs to the app, which would effectively prevent any form of abuse.

[pdehaye]

In these troubled times, no one knows what will be realistic by the end of the week.

For instance, the PEPP-PT team German leader is making explicit affirmations that if technological obstacles persist from the Giants, political might will fall on them.

I think we want the same intermediate outcome: infrastructure that securely supports heavily decentralized community-led public health interventions.

Knowing very many people on the DP-3T team professionally, I would posit the DP-3T team would want the same.

Where we disagree is on the process to get there.

• You beg Apple;
• DP-3T seems to want to technically nudge the giants in the right direction, and certainly to block the road for others to implement centralized solutions;
• I want democratic structures to have the ability to force the Giants to change their infrastructure, if needed.

I believe the process does matter. Pick my own circumstances. I live in Geneva, where >50% of the hospital workers live across the border in a country likely to implement the INRIA system. This brings challenges to all those apps, of course. I am certain that by combining the brain power of the various European research teams, a solution can be worked out: decouple consent-to-upload-if-infected (more altruistic) and consent-to-be-uploaded-if-at-risk (more egoistic), and all the security/privacy disagreements will disappear... but only if the Giants have to agree to such granular specification in their API, and to enable government approved apps to leverage that.

It's the same as with your proposal (begging Apple to enable the user to select the accumulating relay servers), but more forceful. BTW, your proposal is very much in line with issue #10, where again I offer a concrete rule-of-law based process to get there.

[ralfr]

For instance, the PEPP-PT team German leader is making explicit affirmations that if technological obstacles persist from the Giants, political might will fall on them.

Are you referring to Christian Boos? Do you have a source for this?

I think you’re describing exactly why so many drop out of PEPP-PT:

• The trend to build the opposite of a privacy-preserving system and trying to enforce it through politics / lobbyists
• Boos broad claims without a lot of objectively provable underpinnings
• Their unrealistic believes they will be able to force Apple into adding features to iOS which would be every privacy advocates worst nightmare

[pdehaye]

He said so in the press call on Friday lunchtime, in the Q&A.

It would be very useful to have a recording of it, but I have not been able to source that yet.

I agree with your two first claims, but as explained earlier disagree on your assessment on the third one. (If you look me up, I think I have strong privacy advocate credentials).

[ralfr]

I agree with your two first claims, but as explained earlier disagree on your assessment on the third one. (If you look me up, I think I have strong privacy advocate credentials).

I did look you up and am impressed. :-) No doubts about your motives. Agreeing to disagree is absolutely fine for me.

I primarily am increasingly worried about German government officials and mainstream media figures pushing a „PEPP-PT or no back to normal“ narrative. They either don’t understand the implications of what PEPP-PT is suggesting or do understand it but support it. The later being even more worrying.

I do agree with DP-3T's „radical“ commitment towards a decentralized solution.

Are you saying that you see a chance for the PEPP-PT players to force Apple to support their design?

[pdehaye]

I see a chance of getting PEPP-PT to amend their design (more like breaking it down into components), in a way that can constructively engage with DP-3T, and enables a collective push of governments, security people and human rights advocates(!) to force Apple in a direction you would support as well. Their power is unaccountable, and if you believe in democracy you can't be cheering that their power prevents legitimate convergence between technical systems.

I just wrote this over at ROBERT's GitHub.

[kholtman]

TL;DR: I support the request made to the project by @pdehaye in the post at the top. Detailed explainer follows about the difficulty of using the GDPR as a measuring stick. Easy to use and much more task-appropriate sticks are identified and promoted.

Findings and request

I want to echo the request made by @pdehaye above that the project updates the GDPR related statement made in the paper on NTK protocol security (version of April 19).

The paper is definitely useful as a contribution to the security analysis debate, because it identifies many different attack scenarios for the NTK protocol. But it is misleading and arguably counter-productive when it starts to imply that anybody could realistically conclude via a technical analysis, right now, that the NTK proposal is incompatible with the GDPR. To quote the relevant text that is misleading:

the [NTK] backend also learns encounters among non-infected users, in contravention of the need-to-know and data minimization principles expressed in the GDPR, as alternatives where this does not occur, such as DP-3T, are readily available​.

Detailed explainer

The GDPR does state that you must pay attention to data minimisation, see e.g. as pasted from

https://www.privacy-regulation.eu/en/article-5-principles-relating-to-processing-of-personal-data-GDPR.htm :

Personal data shall be: [...] (c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed ('data minimisation')

Note that technically, the legal language term 'processed' used above includes both the storage and transmission of data. The key pitfall in the above line that I want draw peoples attention to is

to the purposes for which they are processed

Now, say that the PEPP-PT project has among its stated purpose, the specific stated purpose to minimize or eliminate the risk of certain attack scenarios PQR, whereas the DP-3T project states differently that it wants to absolutely minimise risks XYZ, at the cost of increased risks to P and Q. Both would be legitimate statements of purpose, in the context of the GDPR.

Say that I am a security professional doing a GDPR compliance review of an app that has the stated purpose to implement the PEPP-PT NTK protocol. I will be verifying a condition of data minimisation of the protocol against the purposes PQR. I have no legal basis to reject the app even if I know full well that if I woul evaluate the app against purpose XYZ, the same condition of data minimization is clearly violated.

So the legal framework of the GDPR review has a no real role to play as an arbiter of which risk profile prioritization is better: PQR or XYZ. What matters much more for the GDPR analysis is whether the 'purposes for which they are processed' are defined clearly and unambiguously. Here, in defining and documenting their purposes PQR and XYZ much more clearly and unambiguously, I believe that both projects still have significant work to do.

So what about an alternative yardstick for comparing PQR and XYZ between each other and with a desirable minimum level? EU governments are definitely saying loud and clear that the stated purpose, of any app they will ever consider promoting for general use, will be very high levels of privacy. The implication to be read here is that the levels of privacy sought will be much higher than those which are allowed by the GDPR as the bare minimum under the doctrine of informed consent.

So we can directly compare PQR and XYZ once the projects get done clarifying them, to recent government statements defining stated-purpose levels of privacy for these apps,

I'm not saying this will resolve all controversy, but I hope it help avoid a lot of avoidable ambiguity.

So what about the clear and plain language doctrine?

One other avenue open to anybody who wants to use the GDPR to comment on PEPP-PT or DP-3T, or any other open source project, is the clear and plain language doctrine:

https://www.privacy-regulation.eu/en/article-7-conditions-for-consent-GDPR.htm :

the request for consent shall be presented [...] in an intelligible and easily accessible form, using clear and plain language.

It can be argued that if an app uses a protocol that has been developed via a hidden and unaccountable process, followed by an over-simplified promise that paints a technically unrealistic picture of the real privacy risks that the user of the app and related backend systems will be exposed to, then that app can never meet the clear language test of the GDPR anymore, because the above tactics represent a deliberate muddying of the linguistic waters. But the calibration of this yardstick of 'clear and plain' depends on case law, which is weak to nonexistent at this moment, I believe.

Again, governments have created appropriate yardsticks we can use, there are plenty of statements about openness and transparency which are much easier to interpret and agree on than the meaning of the GDPR doctrine of clear and plain.

To conclude

I have tried to make a contribution that will lead to the more careful use of the word GDPR by open source projects.

As a further suggestion, here is an example of using the term GDPR when one wants to talk about the relation between the project deliverables and European values: 'we are not only aiming to make a design that will comply with the letter of the GDPR, we are also aiming for a design that will best embody the spirit of the GDPR, which we see as implying that ....'