Feature: Use bluetooth for proximity-based checking

[rparet]

Goal: Allow customers to record proximity-based contact of other customers with the app on their devices. This potentially allows for a more precise definition of "contact" than being in the same geo-location at the same time.

[scottleibrand]

The BLE proximity parts of this (the difficult stuff) have been implemented by CoEpi.org and COVID-watch.org - see https://github.com/Co-Epi/mobile-app, https://github.com/covid19risk/covidwatch-ios, and https://github.com/covid19risk/covidwatch-android

[scottleibrand]

Detailed architectural descriptions of the BLE contact tracing model can be found at https://www.coepi.org/vision.html and https://www.covid-watch.org/articles/

[scottleibrand]

And if anyone wants to join CoEpi or COVID19risk Slacks to discuss integration or any other sort of collaboration, please LMK: we'd be happy to join forces in whatever ways are feasible.

[E3V3A]

The BLE proximity parts of this (the difficult stuff) have been implemented by CoEpi.org and COVID-watch.org see: https://github.com/Co-Epi/mobile-app, https://github.com/covid19risk/covidwatch-ios https://github.com/covid19risk/covidwatch-android

I'm already confused! How many apps do we need in parallel?

[vitorpamplona]

We are working with them. CovidWatch, CoEpi and PrivateKit will have the exact same implementation

[harryjkp]

Just a thought, but would it make sense/be practical to extend alerts to second or third order connections as determined by BLE? I.e. if person A has symptoms, and was in contact with person B during a time-frame where A was likely to be infected, also let people know who have been in contact with person B after that as a precaution. I realise one that there may be a privacy issue to resolve there and two that if extended indefinitely there aren't that many degrees of separation between the entire population. Nonetheless it seems a good way to get ahead of the spread if contact detection is reliable.

[scottleibrand]

The current plan for CoEpi is that anyone receiving a notification for a severe (likely COVID-19) exposure would have the ability to decide whether it's appropriate to put out an exposure warning to all of their own BLE-proximity contacts. We currently don't believe third-order connections would be useful, given that even close contacts only have a ~10% chance of transmission.

[Nautman]

We currently don't believe third-order connections would be useful, given that even close contacts only have a ~10% chance of transmission. @scottleibrand

Do you have a source for this? :)

[scottleibrand]

No, I don't remember where exactly I saw that.

[acooley]

Please PLEASE please let me help. I have a fully functional BLE implementation for Android...

https://github.com/kunai-consulting/OpenTrace

It has some features which the other projects do not that I think are important:

1 The implementation starts the service at boot without any kind of activity or any interaction from the user.

2 The implementation does not scan all the time. Scanning all the time will have a serious impact on battery performance and result in a ton of redundant information over time. Instead all the devices start scanning at EXACTLY the same time and remain active for a short period of time. They broadcast for a little longer than they scan. This makes for a massive improvement in battery performance. With BLE, scanning is a massive battery killer.

3 The implementation works on very old in expensive Android handsets. I've tested for support all the way back to Samsung S7 with the original version of Android that came on the handset and it works correctly. It's pretty easy to get something running on an iPhone or a Pixel. You'll pull your hair out to get things working on older handsets.

4 The implementation doesn't use a connection, just discovery. I played around with them, but they are unstable and reduce the chance that you will successfully scan a device.

5 The implementation is thread safe, and thus it will work correctly in the background. All the documentation and reference applications that are floating around assume that you are doing the scanning from an activity or that the app is running. This one does not, but that also means that you have to use lots of thread synchronization, etc.

6 The implementation is efficient. It gets the system resources once when the application starts and then keeps them around. This saves on battery, but it also makes the code run faster which is pretty key when you want to scan for 4 second and make sure that you see all the devices.

7 Because of the way that it's written you can use any of the power settings and it will still work, but since this is about contact tracing I think the default settings for power are the best. They are less likely to see another phone that isn't near by. This solves the above mentioned problem of seeing a beacon from a car as you drive by it. You aren't likely to see many of these and since there is a scan interval, you can eliminate or de-prioritize phones that you saw once.

8 The implementation calculates the distance you are from the other phone.

I've been working on this non-stop since I got sick. I'm better now but I don't want anybody else to get sick. My symptoms were pretty mild and I didn't know what I had but because of that and the nature of my wife's job I probably passed the virus along to 300 other people. That means that because I didn't have something like this someone has already died after catching COVID-19 from me. I want to help.

[scottleibrand]

@acooley that all sounds quite promising. Would you be interested in helping us integrate the appropriate portions of your BLE implementation to improve the shared CovidWatch/CoEpi BLE code that covid-safe-paths has incorporated into their Android beta? If so, please drop me an email to scottleibrand@gmail.com and I can get you invited to our Slack to discuss. Our repos are at https://github.com/Co-Epi and https://github.com/covid19risk

[lottafederico]

Hi guys, I worked a lot with BLE on iOS, if your plan is to force the iPhone to scan for peripherals this probably won't work.
The right way to use ble in this use case is to use beaconing. But as you know iBeacon and Eddystone won't be compatible until the end of may. The work-around is to make the iphone act both as peripheral and central. As central it should scan for devices nearby, check the services ad exchange some data to get an ID. This beacuase iOS will change the ble UUID, it's a iOS security standard vs ble sniffing. Another problem is the scan part. Generally Apple ask to make scans only when needed, if you ask the central to scan every 10 sec (exmpl) after some minutes this will not work. The OS will slow down the scan. A work-around is to create an extension that can be triggered somehow but it's still a work-around of a work-around. Probably the easiest thing is to develop an ibeacon and an eddystone system and ask to Apple and Google how will they manage this merge of technologies. You can take this time to work on the cloud db of beacons UUID, and how, when and how many of them a user should download, this beacuse the iphone will wake up only if a nearby beacon as a known uuid. Hope this help a little bit.

[vitorpamplona]

Hi @lottafederico,

Let me know if you can help you code this. We are trying to separate the development of the BLE hacks into a react-native library: https://github.com/vitorpamplona/react-native-ble-advertiser It's already deployed into PrivateKit.

It does what you were saying (central and peripheral) and is seeing the Android phones.

Looking forward to hacking this thing together

[lottafederico]

Hi @vitorpamplona, I develop MEAN Stack and native iOS (swift). I can help you doing some experiments on the native side but I’m really new to react native I think that I can’t help on that side. So sorry!

[vitorpamplona]

Well, half of the library is Native iOS, the other half is Native Android. The 10% rest is just a JS bridge and a demo app inside it. :)

[lottafederico]

@vitorpamplona ok I’ll take a look tomorrow!

[lottafederico]

@vitorpamplona I took a look at the code. If I understood you aim to use a central to scan for devices with a particular service and then get the "id" of the peripheral using its "peripheral name" without actually creating a connection. How are you going to handle background mode and app killed?

[E3V3A]

Ok, great and insightful, but

• What's the current status of this?
• Who's working on this, and who is doing what exactly?
• i was also told in a different thread on slack that the development of this had moved elsewhere, to another repo.
• Last time I asked, I was told that the BLE code was pulled out or disabled. So?

Clarity please!

[lottafederico]

@E3V3A, Actually I’m not doing anything, I just comment on this thread because I worked on ble in several iOS projects and I think that there will be some issues that will need some kind of work around to make it work. Personally I think that will be hard to reach a very good result but maybe just a good result in enough at the moment. Apple and Google are working to make this available because at the moment a “perfect” solution is not reachable thanks to all the limitation that they put on top of the ble stack. I’m here to help if needed!

[Cetkat]

@acooley This may have already been discussed elsewhere, but the distance combined with the number of devices discovered could be used to add risk prioritization. For instance, GPS could tell you if it's an enclosed space like supermarket vs an outdoor area; however, something like a house party (where much of the current transmission has been taking place in Boston) is harder to see.