Implementation of Room Beacons

[misterbuchi]

In many Countries certain locations (for examples Restaurants) are requested to collect Name and Phone Numbers of there visitors to enable manual contact tracing. If such locations could have a device with dp-3t app running, that represents a room. The visitors could choose either to have the app running or to register with name and phone number on the entrance of the restaurant.

If a person that has visited the location get a positiv test result. The location just uploads the codes for the timeperiod, where that person was present and contacts the visitors without the app on phone about the possible exposure.

In this case it would be a great solution to use the app, because it preserves the privacy of the user more than, the analog contact tracing. With a beacon, that represents a location and not a person, it would be possible to connect the manual and the app based contact tracing.

[pdehaye]

See for instance what the Geneva canton government imposed for food businesses and churches.

See also such a commercial system deployed in a supermarket) by @oseiskar's company, with a very interesting blog post here. [see below]

See this paper (from yesterday) on how to mathematically model the utility of the use of Room Beacons alongside the app (it would be an additional type of "Gatherings" as defined in that paper). I actually think the mathematical modeling in that paper shows - even if not entirely explicited in the paper - that contact tracing apps have been badly conceptualized from the outset, and that contact tracing protocols such as DP-3T offer many more opportunities in tracing the virus than peer-to-peer as has been envisioned by the DP3T collaboration.

[pdehaye]

(note that Gatherings don't fully need to be deployed according to DP-3T, they could be deployed according to ROBERT for instance cc @oseiskar)

[oseiskar]

@pdehaye Note that dedicated BLE beacons (like iBeacons that we sometimes use at IndoorAtlas) are not BLE-sniffers.

Even though a battery-powered iBeacon device may have the same BLE chipset that can be used for BLE-sniffing in other hardware, their battery life, storage capabilities (usually none) and internet connectivity (also usually none) make it impossible to use them as BLE-sniffing devices. BLE-sniffing requires you to keep the antenna active for longer which makes this operation more power-hungry and unsuitable for battery-powered devices.

For BLE-sniffing, one would need to use mains-powered devices like "IoT hubs", WiFi APs or other hardware that happens to also have a BLE antenna.

[pdehaye]

Thank you for the clarification, it can get very hard to tell sometimes (you know the specifics of what IndoorAtlas uses, but how do I tell from the outside?)

Is there anything I need to correct about you/your company beyond what I just scratched above?

[oseiskar]

I also just read the comments more thoroughly and I'm not sure if there was actual confusion about the matter in the first place. I just wanted to ensure the difference between beacons and sniffers was stated explicitly.

The IndoorAtlas system uses multiple sources for information and the demo video actually uses ambient WiFi signals instead of iBeacons for the "first fix" combined with other technologies to stabilize the tracking. The position of the device is computed on the device itself based on the signals it receives and not anything the device broadcasts - after the user has knowingly installed an app with our SDK and given their consent to using their location data to provide them an indoor wayfinding service.

Regarding the actual topic of this ticket, I think the approach where, instead of broadcasting contact tracing tokens, the phones would listen to, e.g., BLE beacons signals from fixed devices (or just built-in phone location data, since it's essentially the same thing) and those would be sent to the trusted health authorities, sounds like a better approach from the privacy perspective than what is currently proposed by Apple & Google.

[oseiskar]

Replying to this comment https://github.com/DP-3T/documents/issues/44#issuecomment-624602731 (@pdehaye )

[...] "in-background device-based listening of DP3T-compatible beacons emitted by a possibly-centralized system" (potential problem: such deployments would be prevented by Apple and Google).

Just to ensure that we are talking about the same thing: A solution where devices are installed in restaurants etc. and those devices transmit BLE beacons signals, which would be passively recorded by the mobile phones of the visitors.

Such a system is not be blocked by Apple or Google (at least currently), actually quite the contrary: if the fixed devices in the public venues would transmit iBeacon signals, then both Android & iOS devices can constantly listen to those signals in the background, and wake up any application when the user first enters a restaurant with such beacons (to cut a few corners, but this is roughly the case).

This feature was first designed for proximity marketing but it's currently used for many other things as well. It is possible to either use dedicated (possibly battery-powered) beacon devices or Android phones (preferably connected to a charger during operation) for broadcasting the beacon signals.

What Apple & Google can block is submitting such an app to their app stores if it refers to COVID and they do not approve of its mode of operation.

[pdehaye]

Yes, this is exactly the technical infrastructure that would be possible: active broadcasting by a restaurant, passive listening by an individual's device. It could co-exist with "regular" contact tracing, but legal considerations (to be described elsewhere) might actually dictate deployment timelines in relation to each other.

It is indeed quite likely Apple would oppose such move, particularly if they default OS X 13.5 to broadcasting BLE signals even without users installing any app (indeed, the beta is on an opt-out basis, not yet confirmed by journalists the release will also be). This is what worries me actually: deploying contact tracing apps without advanced coordination might limit our options in the future.

[misterbuchi]

The idea of my suggestion is, that there could be a device, with an app, that represents not a person but a room. The difference is not how it operates by sending keys and storing the keys of other devices. With the device in a room, it could work as a gateway between analog contact tracing and the app-based contact tracing. I try to explain it by an example: A person without a DP3^T App visits a restaurant. Someday later the person gets symtoms and a positiv covid test. Then the public health department call the restaurant owner, and ask which persons where in the restaurant in the crucial time. Either the restaurant owner needs to have the all the phone numbers and call each person. or there is a device with the dp 3^t technology, that can handle the part for the guest with the app. So the guests can choose to leave their phone number when visiting a restaurant, or the use the app. A such a solution would improve the efficacy of an app on a lower install base. And in the same time it would be a good incentive for people to install the app, because then they don't have to leave their name an phone numbers that often. If such an special dp 3^t app operate on a ios or android phone or tablet, i dont see any restrictions on the API from Apple and Google.

[pdehaye]

If such an special dp 3^t app operate on a ios or android phone or tablet, i dont see any restrictions on the API from Apple and Google.

• health authorities would have to have a way of enabling the restaurant owner's device to trigger the set of identifiers;
• this would be a different kind of signal than in the "classic" operation: rather than proximity to an infected individual's device, proximity to a beacon (or set of beacons) serving as a more-distant proxy.
• to be epidemiologically useful, this would need some distinction in the risk computing functions between the two cases, in order to leverage the APIs effectively (see A/G docs)

What Apple & Google can block is submitting such an app to their app stores if it refers to COVID and they do not approve of its mode of operation.

Indeed: access to those special APIs require meeting additional conditions outlined in the G/A doc. Such an app would not meet the "restaurant owner" situation.

[timoll]

This could be used to detect superspreading events, a "halve step" behind.

If we quarantine everyone in every room that a positive case visited, we will have to quarantine many more people than necessary.

However if we wait until two people who visited the same place at the same time test positive, we could have a more efficient way to detect a superspreading event and inform all people that were at this place at that time. So we would be halve a step behind but catch up on the next step.

To increase the probability of detecting such clusters early, we could send a warning to everyone who visited the same room as a positive case at the same time. It would be important communicate that the probability of infection is still very low for such a person and a quarantine is not necessary.

The expected benefit of this warning would be that warned persons adhere better to hygiene recommendations, have less contact with at risk persons and are more likely to get tested earlier should they show symptoms.

[pdehaye]

Indeed, mathematical modeling has been available for a few weeks showing that this cluster busting approach would be more productive than the traditional contact tracing, principally due to the high heterogeneity of spreading events.

https://arxiv.org/abs/2005.02362 and https://www.medrxiv.org/content/10.1101/2020.05.04.20091009v1.full.pdf+html

I do not understand how these epidemiological insights have not yet trickled to the technical team developing the protocol.

[dspinellis]

Under the current design, identification of contact with infected persons is performed on the user's device, not centrally. Furthermore no position data are recorded. This does not allow the central identification of super-spreader events. Also the Cuckoo filter downloaded to the devices provides only yes/no exposure information for a given affected contact, not the time when this occurred. The best that can be done is to issue a higher level exposure alert if the device detects contact with more than one affected persons. That would be an indication that the user might had been present in a super-spreader event.

[pdehaye]

identification of contact with infected persons is performed on the user's device, not centrally

This system does not exist in isolation. Depending on the Public Health Authority strategy in leveraging the system, there might be an explicit effort to connect chains of infections, and to say: "We know A and B are infected, that we issued a notification code to A, that B contacted us saying they were notified, and that A and B lived in the same region where we think the disease is almost extinct. Were A and B at any point in close contact?"

[pdehaye]

The best that can be done is to issue a higher level exposure alert if the device detects contact with more than one affected persons. Additionally, some notifications could be issued whose meaning would be "we don't exactly think you are at risk, but we think you might help us figure out where an important event happened". This could be issued by deploying multiple apps in the same geographic area, all leveraging the Google/Apple API but with different configurations regarding risk calculation (and UI on communication of the risk calculated). For instance you could configure the system so that a contact within 5m for a very long time would mean "help us find the people who were in that same room, but closer to the infectious person". The finality would just be asking (phone) questions, not quarantine for the person notified.

[timoll]

It is possible to detect clusters decentralized.

Infected persons share their detected room beacons.

If two (or three) infected persons share the same room beacon for the same time, then officials can be alerted about the cluster.

Other phones owners are alerted the same way a close contact is alerted.

[pdehaye]

The app is failing to convince Swiss users:

https://www.20min.ch/fr/story/l-app-swisscovid-ne-convainc-pas-242468390880

It opens up an interesting point though. Why can't Eat's Me and Eat's You use half of the Google/Apple API each? This would drastically increase the utility of the protocol, as seen here:

https://github.com/DP-3T/documents/issues/281#issuecomment-641888305