Chirp Chat

This is an adaptation of the MIT PACT contact tracing scheme where we eliminate BLE and use a central server to facilitate communication between devices. This is more a thought experiment than a serious suggestion since this introduces privacy problems PACT was specifically designed to avoid.

The reason for exploring this path is that exhange of chirps via BLE isn’t really practical given the limitations placed on BLE in iOS and Android. Note that this is probably entirely superfluous since Apple and Google are working on Privacy-Preserving Contact Tracing which relaxes some of the BLE restrictions, but also introduces some new constraints on what apps that use this technology are allowed to do.

The technical challenges in designing and building this seem quite managable.

Description

• Divide the map into two overlaid grid systems where the second map has grids that are translated ½ the edge length along x and y.

• Implement MIT PACT seed and chirp generation on the device (app)

• Each mobile sends position and chirp to server. New chirps are not sent until the device is more than N meters away from the point where the last chirp was sent.

• Server models each grid cell in a map as a virtual chat room (so a given device will be in at least two cells at the same time)

• Within each virtual chat room, the server compares positions to determine if two units are close enough to each other to constitute a contact.

• When a contact is determined, the chirp value (and only the chirp value) is sent back to all devices within the same virtual chat room. (Deduplicate on output - this can be done as part of the delay/Nagle mechanism).

• The server never stores any data. All data is discarded as soon as it is no longer needed. Ideally all data should be in RAM. The problem is trivially partitioned by cell.

• Other than that, mimic what MIT PACT does (eg. keep seed values in app, and share them when positive diagnosis is made etc). One can make the choice to store a GPS trace for one’s own movements and have the option of sharing this. (However that will make deniability very hard to implement) Problems You would have to trust the central server to discard the data.

Problems

• You would have to trust the central server to discard the data. In many ways this invalidates the whole idea in MIT PACT of doing this with no central party that sees all the data.

• You have to trust the app to some degree - it has to be assumed that bad actors can connect dodgy clients. To deal with bad actors you need some abuse detection heuristics, a blacklist and a throttling mechanism.

• GPS isn’t frightfully accurate, but this is a bit beside the point.

• Synchronicity may leak information, chirp data going to clients should be batched and possibly follow a Nagle-like algorithm so as not to exhaust resources. Scaling Split system into connection handling and cell handling where both parts can scale independently. (Shard cell handlers). Tempting to use DTLS as transport to avoid connection overhead, but might be more susceptible to DDOS attacks.

It should be possible to handle all cell handling in a single server, but it is advisable to shard this across multiple servers and reshard on outages or when capacity is added.