Split/proxy implementation for BLE enabled smart-watches, fitness trackers etc.

[kugelfish42]

BLE enabled wearable devices might be more suitable than smartphones to run the BLE proximity token exchange part of the protocol, as they are often less obstructed and more permanently attached to their humans. But they might typically not have internet connectivity and be short on storage.

How is the protocol best partitioned to support a split implementation between a wearable and its host/controller device?

[lbarman]

The smartwatch is a good idea, as one limitation is that phones in pockets/backpack have higher Bluetooth loss rates. Would you know if an apk for Android can be simply run "as is" on WearOS ? I'm also more worried about the battery life (since these kind of wearable are fairly silent without user interaction typically), would you have any insights ? edit: word

[kugelfish42]

As of recently WearOS did not have support for arbitrary BT access for 3rd party apps. This would presumably have to be done by and/or with support of the device manufacturer.

[jaromil]

FYI here @danielinux has started a RIOTOS+nimble implementation for low-power hardware https://github.com/dyne/decode-proximity-hw we'll update it in the coming days and align it with DP-3T starting from design 1

[danielinux]

The primary purpose for an (open source) embedded device should be to remove the need for a phone (see #177), and in general to provide alternatives to decrease the dependency on proprietary software from google et similia, so looking into wearOS would not improve things here IMHO.

[danielinux]

PineTime seems an interesting target due to the storage required by the protocol, as it has a extra 4MB SPI flash on board and it can run decode dp3t app (100% Free Software)

[pzboyz]

This is probably a solution needed for the other 2 billion people on the planet who do not own an Apple or Google device.

Targeted devices should be those with many days of battery life, so think about the sub US$200 kind of devices. But how do those devices upload ephID's if they test positive? Do we assume they have a USB interface?

[kugelfish42]

All these devices have by definition an Bluetooth interface and most probably would use USB for charging and probably also for management.

The other problem is how would such devices learn about their potential at risk status? They would need to get a nomadic network connection through a proxy device (via BT or USB tethering) every few days.

This connection service could be offered by pharmacies etc. which might also be qualified to counsel about next steps if the blinking red alarm LED goes on.

[danielinux]

Targeted devices should be those with many days of battery life, so think about the sub US$200 kind of devices. But how do those devices upload ephID's if they test positive? Do we assume they have a USB interface?

@pzboyz I assume you are talking sub-$20 and not sub-$200.

Inexpensive smart watches that are based on nRF52 could already run the decode firmware (see link posted by @jaromil above). Uplink connection can be run over IPv6/6LoWPAN/BLE through public access points. The whitepaper suggests that 4MB storage should be enough to keep EphIDs collected from the surroundings. Battery life should be reasonable as no BLE connections are ever established while operating.

The embedded system we are working on is fully open source (no proprietary drivers or any other closed-source dependencies). So far it can communicate using BLE with the android-sdk (in low-power scan/adv mode). All the cryptography to generate local EphIDs has been aligned to the reference implementations (see issue #62). The connection with the infrastructure to downloade the lists daily can be built using TLS/DTLS on 6LoWPAN/BLE, supposedly with a linux-based gateway/access point (or perhaps there is a way to provide IPv4 connectivity using a mobile phone Bluetooth tethering).

[zoobab]

A 4EUR ESP32 could be used as a BT to Wifi gateway.

[zoobab]

Maybe this would do the job? https://es.technikum-wien.at/aignerb/esp32-rfc7668-public

[danielinux]

@zoobab is it possible to do IP routing between PAN and WLAN? The gateway should just forward IP traffic