Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mistake in communicating how information is passed around, in CH implementations of the apps #321

Open
pdehaye opened this issue Jun 4, 2020 · 3 comments

Comments

@pdehaye
Copy link

pdehaye commented Jun 4, 2020

The model DPIA commissioned by the DP-3T consortium says quite explicitly that the beacon data transferred by one user to another should be treated as sensitive personal data (p 17).

Screenshot 2020-06-04 at 21 20 24

One the other hand, the interfaces of both the Android and iOS apps communicate in a few places that different processing operations are "anonymous".

Anonymous data has a specific meaning in EU data protection law, i.e. data that is not re-identifiable, and therefore not considered personal data.

Again, the model DPIA states that it is generally understood that what constitutes personal data is the same in Swiss and European law.

Screenshot 2020-06-04 at 21 25 33

We see that there is thus a clash, between how the apps present what they do, and what they actually do from a legal standpoint, as interpreted by the lawyers hired by the DP-3T collaboration.

I have thus created specific issues addressing those problems, on the app-specific repos:

While this concerns strictly the implementation of the apps themselves (i.e. not the protocol), it does create interesting problems at protocol level as well.

Indeed if the goal is to guarantee interoperability, in cross-app situations (say Swiss and Italian apps), regardless of where the Bluetooth exchange takes place (Switzerland, Italy or a third EU country), regardless of the respective roles (broadcasting or scanning beacons), at least one person gets misled. One might argue that it would be ok, as the apps could be updated by the time we get there, but I don't see how this would be done given EphIDs are stored for a while. Additionally this might lead to problems in case of multiple apps being installed on the same device.

I have seen the Interoperability spec, but it does not seem to be concerned by such matters.

@pdehaye
Copy link
Author

pdehaye commented Jun 26, 2020

I see the language has been updated to say "no personal data is stored centrally" (English version). This is also incorrect, e.g. in light of the fact that Google Play Services on the receiving end then uploads this data to Google. (but there are many more actors to consider)

@gbaudoin
Copy link

gbaudoin commented Jul 1, 2020

the fact that Google Play Services on the receiving end then uploads this data to Google.

Any source/packet dump for this ?

@pdehaye
Copy link
Author

pdehaye commented Jul 1, 2020

I believe this is well known.

See #222 for a summary of Google's role there, and this article for more details.

And Google is just one of a large class of actors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants