The French state is making a glosing about the "privacy-preserving", "anonymous" contact tracing app they are developing with Inria (national informatics research agency). You can check about the protocol proposal, ROBERT, here: https://github.com/ROBERT-proximity-tracing/documents (in English!)
As you would expect, the proposal is not privacy-preserving unless you believe the State would never ever misbehave, e.g. link IP address to identity with the help of ISPs etc. There is some relevant criticism here: https://github.com/ROBERT-proximity-tracing/documents/issues/6
ROBERT should not be considered privacy preserving because uninfected users reveal everything. Yes, the IP address makes this much worse, but metadata like timing and the time in the exposure status request (ESR) in section 7 on pages 11 of https://github.com/ROBERT-proximity-tracing/documents/blob/master/ROBERT-spe...
Aside from privacy, I think bandwidth also dictates that uninfected users should not reveal anything anything in their queries, like DP-3T, but unlike ROBERT
I'd like to propose a really private "contact tracing" counter-proposal, which would use Tor's onion services for sender-receiver anonymity. Not that I am a proponent of the idea, but we need to come up with alternatives in the debate.
There are a few decent privacy-preserving contact protocols.
I think this is being overly generous. ;) There are less horrible designs like DP-3T that reveal infected user information, which sounds unfortunate but legal for reportable diseases, but reveal nothing about uninfected users. Implicitly, there are extremely few infected users because contact tracing becomes far less helpful as the infected user population grows, which makes for quite an interesting assumption.
At least one Swiss group that advocate for contact tracing thinks 25 new cases per day sounds small enough given Switzerland’s density, but 25 new cases per day was clearly not small enough for Singapore’s contact tracing effort, so they eventually needed a lockdown. There are also countries like the U.S. and U.K. where media ignores such subtleties and where contact tracing could simply become some justification for increased economic activity.
You might agree with revealing reportable disease data for public health, and parameterise a contact tracing app around the public health assumptions, only to discover governments use it for economic reasons that harm public health, and then make your privacy preserving aspects into the scape goat.
I'm sure we'd love to help. But maybe the Tor network can't scale to hundreds of millions of people using an app?
Ignoring the nasty political realities, there are cute mixnet tricks for contact tracing apps:
All users create and broadcast tiny single-use reply blocks (SURBs) over Bluetooth LE. There are no SURB designs that fit into one single Bluetooth LE announcement, but you could manage with two using erasure coding, ala https://github.com/TracingWithPrivacy/paper/issues/10 which sounds acceptable given the MAC address rotates more slowly anyways. We’ve no MAC tags inside these SURBs so imagine them living partially between Sphinx and a voting mixnet, but both non-verifiable and verifiable mixnet designs work.
Infected users reveal the SURBs they downloaded over Bluetooth LE to a health authority who sends the SURB. After many hops, the SURB arrives with some mailbox maintained by a user. We'd expose the sender to the receiver if we allow the receiver to unwind their SURB, so instead we simply drop the message and notify the receiver that they received one warning message.
We’re not really more privacy preserving than schemes in which uninfected users download all ephemeral identifiers for all infected users. We do avoid revealing infected user data however and use almost no bandwidth. We’d need some cover traffic that might generate false positives depending upon the SURB size. Anonymity degrades under conditions where contact tracing actually works, meaning a health authority could discover a user’s mailbox by listening to their bluetooth LE beacon and sending a false message, but mixing parameters like one batch per day reduce this risk.
Jeff