ESP32 could be used?

[zoobab]

Hi,

The ESP32 SoC could be used for that purpose?

It has Wifi and BLE, and could download the list every day from a central location, and compare it with its log list.

That would avoid the requirement of a smartphone.

[gardners]

This is exactly what I have been discussing with some hardware folks. It has the advantage that it can be cheap as chips to make, and the ESP32 supply chain is already there. The thing to bear in mind, though, is if ESP32 stocks get depleted, modern IC production processes can take several weeks to get silicon out from when it goes in. Not a show-stopper, but well worth keeping in mind.

Having the tracking not on your phone has obvious advantages for de-coupling the tracking from your phone, and avoiding some of the privacy-intrusion creep that will surely come if phones gain this kind of contact tracking capability that can be easily turned on easily.

[stef]

i'll have a bunch of nrf51 devboards coming today, i'll try to prototype this on nrf51-s, which do BLE and have a cortex-m0 on board, i think it will be enough...

[jaromil]

It should definitely be enough, we even have Zenroom running on ESP32.

These notes may come handy: https://github.com/DECODEproject/Zenroom/wiki/Cortex

Also in our repo you will find the boilerplate code for cortex_m by @danielinux

[danielinux]

Mind that ESP32 is not a cortex-M. In my opionion nRF51 or even nRF52 might be a better choice, in the same price range, ARM-based and probably will result in better crypto performance.

Also, full open source BLE stacks exist that run on that board (my pick would be nimBLE, which is also integrated in RIOT-OS) - so no proprietary SoftDevice stack.

I can try and make a GPL prototype on a nRF52DK.

[zoobab]

@danielinux those nRF51 watches costs 5EUR on Ali. But they don't have Wifi, so users would need an ESP32 home gateway (4EUR) to do a wifi to bluetooth.

[zoobab]

@danielinux and nRF52 might be better then nRF51, which has less flash to store all the IDs.

[donothingloop]

The power consumption of the ESP32 is too high. Ideally you want to use this as a key-fob with a coin cell battery as power source with a minimum runtime of half a year but one can barely manage to do this with an nRF52 chipset for contact tracing and this chip uses far less power than the ESP32 during the BLE RX cycle. Source: I'm currently working on an SDK for contact tracing on nRF52 / DA14531 chips.

[danielinux]

@zoobab 6LoWPAN can be used to sync daily to a computer via TLS/DTLS over IPv6 over BLE, making a software-only alternative possible to the home gateway if you have a PC. Not having wifi on board could improve the power profile (and impact on battery size/life).

No RTC and limited storage (even if we consider 1MB Flash) would indeed require the device to be synced often, and I agree that a Cortex-M0 is undersized, while the M4 based nRF52 has plenty of resources

[zoobab]

I just did a small script to see how many UUIDs we could store:

$ cat script.sh
#!/bin/bash
x=1
count=100000
while [ $x -le $count ]
do
  cat /proc/sys/kernel/random/uuid >> ${count}.file
  x=$(( $x + 1 ))
done

For 100K records, I end up with a file of 3.6MB.

[danielinux]

From the whitepaper:

A single entry requires around 32 bytes. Given a very conservative estimate of 140k different observations over the course of 14 days (i.e., 100 people observed per epoch), this would require around 4.2 MB.

[jaromil]

OK I'm not an hardware expert obviously :^) thanks for proving me wrong and for all the pointers!

[noci2012]

So these devices are perfect to deanonymize by spreading them around and couple them with some video recording on the side..

[jaromil]

You are right this could be a malevolent application. Before going away please reassure me you are well aware of alternatives and if any can improve this. I know at the other end of this privacy spectrum there are national TELCO monopolies gearing up for surveillance with centralized DBs run by state-actors. I also believe deployment of DP-3T personal devices should be voluntary BTW.

[zoobab]

@jaromil we also lack an EFF Europe alternative that can do strategic litigation, such as suing states and telcos that share the 'anonymized' data of our mobile phones. My phone is in airplane mode since the announcement of data sharing with some companies.

[danielinux]

Work in progress proximity app, based on BLE advertisement/scan. For now only device-to-device bluetooth is working to exchange EphId, I'll be porting the DP3T mechanism and the IoT part later.

https://github.com/dyne/decode-proximity-hw

Feedback welcome.

[jaromil]

@danielinux amazing!! deserves an issue on its own

@zoobab theoretically that should be EDRi

[stef]

@danielinux may i ask what ble stack you are using? the official nrf stack seems to be a proprietary binary blob.

[danielinux]

@stef sure, I'm using apache's nimBLE which is an open-source replacement for nordic's binary blob. It's been recently integrated in RIOT-OS so everything is magically working out of the box. :)

[stef]

ohwow, great! exactly what i was looking for.

[ijdoc]

Ouch... https://estimote.com/wearable/

The logo for infection is just... 🤦🏽‍♂️