You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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.
The text was updated successfully, but these errors were encountered:
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)
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).
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.
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.
The text was updated successfully, but these errors were encountered: