In widely distributed and important spec like this it may be useful to look for what is conspicuously absent or unstated, rather than simply reading the precise positive language.

To my mind this phrase under 'Privacy Considerations' in the Cryptography Specification stands out:

"A server operator implementing this protocol does not learn who users have been in proximity with or users’ location unless it also has the unlikely capability to scan advertisements from users who recently reported Diagnosis Keys."

That phrase explicitly mentions that server operators cannot learn about user proximities.

What I reckon may be unstated there is that it could be possible for adversaries with sidechannel / network monitoring capability to learn those kind of details about users (i.e. internet, cell data, and other data network operators).

If such a side door did exist, it would seem in the public interest to be aware of the scope of the availability of that data, especially given the potential (physical, social) vulnerability and risk of those users.

I'd also like to be proven wrong about the possibility of such sidechannel attacks by anyone who understands the spec in more detail.

[1] - https://covid19-static.cdn-apple.com/applications/covid19/cu...

> I don't see how you could have a real argument against this unless you are a privacy extremist.

The authors of DP-3T (which seems quite similar to this spec) have a huge list of privacy caveats in their whitepaper [1], in section "5.4 Summary of centralised/decentralised design trade-offs".

I haven't seen any analysis on how the Apple/Google spec prevents those problems.

[1] https://github.com/DP-3T/documents/raw/master/DP3T%20White%2...

One issue I see is that when I query the central repository of infected IDs I expose to the central server the IDs I've been in contact with (unless I always download all of them, but that doesn't seem feasible).

It seems like this could be solved by providing a K-anonymous query interface like the one exposed by Have I Been Pwned. I wrote to the contact email address of Pepp-Py, which is a European initiative do develop a system that seems pretty much the same as this, suggesting this, but I got no answer (not that I was really expecting one).

I think it has a flaw: if you find out you are infected mid-day, then if you reveal your key for the day others can impersonate you for the rest of the day, and if you don't those who you had contact with in the first part of the day won't be notified.

So my suggestion for a minimal fix would be to also reveal all advertised rolling IDs for the current day in addition to the keys for the past days.

A better fix would be to generate ID in a hierarchical fashion from the daily keys with power-of-two-length time slots, so that you only need to share O(d + log(n)) values where d is the number of days and n is the number of subdivisions in a day.

Another potential fix is to use public-key cryptography and only reveal the daily public keys; however, this requires twice as large IDs and matching requires to try to decrypt/signature-check all received IDs instead of being able to generate and lookup.

Now people who simply care about privacy are “extremist”

Perfect way to begin marginalizing people who care for privacy

Could someone smarter than me ELI5 how devices are able to "re-derive the sequence of Rolling Proximity Identifiers" of the infected?

I know that the RPI is derived from the daily key + TimeIntervalNumber. But these devices should only be receiving the daily keys + the current day.

Everything else about the spec is pretty easy to follow and gets my a-okay.