A nice comic version of DP-3T, by Nicky Case, is available here: https://ncase.me/contact-tracing/
(But is the Apple-Google protocol identical to DP-3T, or does the headline mention “Apple-Google approach” just for simplicity? I heard there are some minor differences…)
DP-3T also explains how records are uploaded to a central server and the interactions with health-care providers. Apple-Google omit this part and focus on proximity data collection.
Edit: Formatting + I wrote a survey paper on a few of the distributed protocols and how they defend against linkage attacks (de-anonymization): https://github.com/robertTheHub/ContactTracingSurvey/blob/ma...
Edit: I see now that it's specifically iOS that doesn't provide for granting the required permissions. I find such lack of control over a device that one supposedly owns highly concerning at best.
More generally, how are background streaming services supposed to work on the iPhone? Does Apple have to individually approve every app that wishes to do so (ex Spotify, Pandora, ...)?
In many situations we may not have better solutions, but that doesn‘t change the fact that this is terrible.
I'm having trouble interpreting this in any way other than a claim that granting users control over their devices is a fundamentally broken idea. I won't dispute that users often choose to do dumb things in practice, but it seems the two of us have a fundamental disagreement in our underlying worldviews.
> Even technically competent users ... no matter what you actually write
I'd argue that such users aren't actually technically competent then, despite the high opinion they might have of themselves. On the other hand, perhaps the users are technically competent and it's actually the relevant software developers that have done a poor job of communicating? If an actual technically competent user is experiencing significant difficulties using a program, then perhaps the program doesn't work as well as the developers thought it did.
Government-mandated alternative applications will probably be excepted, too.
"Those privacy principles are not going to change," said Gary Davis, Apple's global director of privacy. "They are fundamental privacy principles that are needed to make this work."
[1] https://appleinsider.com/articles/20/04/24/apple-google-in-a...
I'd like to mention the TCN Protocol here (https://github.com/TCNCoalition/TCN), another very similar specification. I bring it up because the readme goes into quite a bit of (easily understandable!) detail regarding the trust assumptions of such a protocol and associated rationale.
Ultimately I think Apple and Google are right to omit record upload and authentication concerns from the base protocol. The low level implementation should be as interoperable and generalized as possible in order to facilitate immediate uptake and maximum reusability. Higher level concerns such as who to trust and how to interact with users can be handled by the various app implementations.
Could this be a feature rather than a bug here? Help maintain tracing to a very high level statistically while still giving plausible deniability for personal privacy?
Feel free to hit me up henriquez AT protonmail if you'd like to discuss!
https://m.youtube.com/watch?v=Z3DZ3St3QRw
Starts at about 1:19.
Edit Gibson is a good explainer, but it's just a video of the two podcasters. It could be much clearer with visual aids.
It's a good idea to show how it could be privacy "OK" , but doesn't even hint on a reality that this might not be a road we want to go down - paved best intentions and all that.
2. The number of minutes is a threshold decided by epidemiologists, programmed into people's phone, as a public-policy heuristic. It doesn't need to be perfect, just to catch a lot of the actual contacts in its filter while avoiding too many false positives - even quarantining 50 or 60% of contacts can reduce spread by a lot!
3. You could be compelled to release data, but all you would get is a list of beacons; you'd then have to also subpoena/steal everyone else's records of whose beacons they saw (this data stays on local devices!) and correlate encounters with actual locations. This is HARD - like, nation-state actor hard. Like, nation-state intelligence agency hard, probably beyond the reach of your average criminal-justice apparatus.
4. DP3T already has open-source implementations (e.g. https://github.com/DP-3T/dp3t-app-android).
5. If your threat model is "my phone/OS manufacturer will publish code that doesn't follow the protocol", then you're screwed anyway. (And in fact, Apple and Google aren't following this protocol, they're coming out with their own joint system that they claim is DP3T-inspired.)
3. Yea, that’s great and all. The point is that you may compelled to upload your contacts - NOT your beacons. You are collecting people you met. You likely do understand some of the ways contract testing could be abused. Think about police trying to prove contact with someone they do have beacons for.
5. So why bother with passcodes, or any security at all anywhere for any new or existing feature? This is a slight evolution on “I have nothing to hide”.
3. Indeed, they can use this to prove that two people who are both under surveillance/investigation were in the same area as each other. That's a risk, but not as severe of a risk as the general fear I've seen around this protocol.
5. That's my point. If you don't trust your implementer to actually implement the security feature, you're screwed anyway. You have to trust someone, and by using a modern phone you are implicitly trusting Apple and Google. Or at least trusting their employees to make a big stink if lines are crossed.
Not with the "Apple/Google protocol", you can't; your beacons are derived from a key, and only the key is uploaded.
> (And in fact, Apple and Google aren't following this protocol, they're coming out with their own joint system that they claim is DP3T-inspired.)
Criticisms of DP3T should be separated from criticisms of the Apple/Google system.