[olliej]

Let's just answer these

* Use stationary beacons to track someone’s travel path

Doesn't work because there's no externally visible correlation between reported identifiers until after the user chooses to report there test result.

* Increased hit rate of stationary / marketing beacons

Doesn't work because they depend on coherence in the beacons, and the identifiers roll every 10 or so minutes. Presumably you'd ensure that any rolling of the bluetooth MAC also rolls the reported identifier.

* Leakage of information when someone isn’t sick

The requests for data simply tell you someone is using an app - which you can already tell if they're using app.

The system can encourage someone to get tested, if your app wants to tell people to get tested, then FairPlay to that app (though good luck in the US).

- Fraud resistance

Not a privacy/tracking concern, though I'm sure devs will have to do something to limit spam/dos

[FartyMcFarter]

> Doesn't work because there's no externally visible correlation between reported identifiers until after the user chooses to report there test result.

So you're saying it works after the user reports their test result.

[olliej]

I'm not sure what you're saying "works" here.

To be very very clear

* The only things published by someone when they report a positive test result are the day keys for whatever length of time is reasonable (I assume ~14 days?)

* Given those day keys it is possible for your device to generate all the identifiers that the reporter's device would have broadcast.

* From that they can go through their database of seen identifiers and see if they find a match.

That means your device can determine when you were in proximity to the reporter, so it would in theory be able to know approximately where the contact happened, but you can't determine anything beyond that.

The server that collects and serves reported day keys doesn't have the list of identifiers any devices have encountered, so it can't learn anything about the reporters from the day keys they upload.

Let's say there's a passive fixed beacon (whatever) in a public space, it can't connect the identifiers to any specific device either, but you could see it being a useful public health tool - "we saw carriers at [some park] at [some times]". It still would not know which specific devices were reporting those keys. Even if that device went through after the day keys were published there's no way to know that its a device that's been seen before.

Only the server is able to link published day keys together because it receives them, so presumably knows who published those. The spec explicitly disallows an implementation from doing this, but assumes a malicious server, so it works to ensure that the only information it can get are day keys with no other information.

[FartyMcFarter]

It is pretty clear that a single piece of data gathered by this system is fairly useless. But the more data an entity has gathered, the better it can be used to paint a whole picture.

If the server is malicious (think a government doing surveillance), it is possible that the data from passive fixed beacons gets linked with the identity of the person uploading keys, via IP address (when keys are uploaded) or facial recognition gathered by cameras next to Bluetooth receivers. This data can also be linked with data from fixed beacons in other places, which would allow for tracking someone throughout a variety of places.