[dmurray]

A "C+ grade", but the report seems a little nitpicky.

It loses marks for not being a "single-purpose app" as the same app also provides you a way to track your own symptoms.

It loses a lot of marks for "necessity and proportionality" on the grounds of not providing documents that prove or support such an app as being useful for contact tracing, even if it works. Surely they could give the benefit of the doubt here. And in a separate section they give it a D for "effectiveness" citing studies that it probably just won't work and will have too many false positives.

More marks lost for relying on closed Google/Apple APIs, using Twilio to send text messages, not having a Github issue tracker...

I think they make a lot of good points but when I think about what it would take for an app to move from a C+ to an A under this framework, it looks like 80% box ticking and 20% addressing serious privacy concerns.

[dmurray]

To continue, when they actually address the privacy and security implications of the design, they call out the possibility of a replay attack "when an outsider intercepts a communication and fraudulently delays or resends it...there is no known significant mitigation for replay attacks and yet they are not identified in the DPIA."

Firstly, surely there's a known mitigation here - replay attacks involving a delay can be mitigated by including a cryptographically signed timestamp in your beacon messages. Secondly, the damage from an attacker sending false negatives and false positives seems small compared to the privacy implications of deanonymization attacks (e.g. attacker listens for the beacons in several buses, offices or shopping centres, later identifies which ones were reported covid-positive, groups those into clusters each likely associated with an individual, and cross-references the location data with identifying data from another source). Why call out one but not the other?

[colmmacc]

There isn't enough space in bluetooth IDs to include a cryptographically signed timestamp, there isn't even really enough space to include a cryptographic signature for everything ... in the the Apple/Google design the Bluetooth power level is left unsigned due to space constraints. It really is a very very small amount of space.

An alternative design involved bluetooth IDs broadcasting small 63-bit ECDH shares and devices performing pair-wise key agreement. This would raise the difficulty level of replay attacks; they'd need to be bi-directional and roughly time synchronized (within a ~15 minute window) but it had other trade-offs including reducing the efficacy of the app due to bi-directional message receipt being required, and ballooning the amount of data that needs to be distributed to detect infection risk. So it wasn't taken.