4 ms·

Some quite interesting stuff around how they might be getting around the background iOS restrictions[1] can be found in the Android source. Looking at the Appl

Some quite interesting stuff around how they might be getting around the background iOS restrictions[1] can be found in the Android source. Looking at the Apple documentation on background peripheral bluetooth, they state "All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them"[2] I wonder if they have managed to reverse engineer this overflow area so it is accessible via Android. Someone did some looking into this and it seems at least feasible[3] [1]: https://github.com/nhsx/COVID-19-app-Android-BETA/blob/master/app/src/main/java/uk/nhs/nhsx/sonar/android/app/ble/Scanner.kt#L58 https://github.com/nhsx/COVID-19-app-Android-BETA/blob/maste... [2]: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html https://developer.apple.com/library/archive/documentation/Ne... [3]: https://crownstone.rocks/2018/06/27/ios-advertisements-in-the-background https://crownstone.rocks/2018/06/27/ios-advertisements-in-th...

g_p 6y ago
Yes, this seems to be one of the rather clever aspects of the design - this appears to make it possible to discover iOS devices that are in the proprietary "iOS-only" mode of discovery. It seems that once one of these "overflow" advertisements is discovered, it attempts a connect that is enough to wake the device and carry out normal tracing. I left an iPhone unplugged, stationary, idle and asleep, running the app for about 5 hours. Then introduced an Android device and it was detected immediately. That seems to suggest this aspect works well. There's also a clever "ping-pong" type keepalive system at play - there are multiple characteristics broadcast, and one of them is for keep-alive. It seems devices also use this keepalive to keep the app active over time. That should work with even 2 devices - if I understand it correctly, device A will K/A device B after a period of time, and this will cause B to act. That means B will then K/A device A after a period of time, and the cycle can continue. I see the concerns about "2 sleeping iOS devices might not find each other", but wonder to what extent this will be a realistic scenario, versus an academic one - given the extent to which people are on their phones these days, and the size of that population, the issue likely fades in significance. Especially considering no app will get full adoption, no system will ever be perfect, and it's very much all about probabilities - the app can't determine if your 30 second exposure was higher risk than 30 minutes sitting 5m apart. Hopefully the testing phase currently underway will give some insight as to if this is a problem.
ridewinter 6y ago
I built an exposure notification app that solved the backgrounding issue by simply using the backend to reconstruct the missing Android -> iOS piece: https://medium.com/@dangish/a-solution-to-iphone-backgrounding-w-bluetooth-bb09b3f9a236 https://medium.com/@dangish/a-solution-to-iphone-backgroundi...
- g_p 6y ago
  > I built an exposure notification app that solved the backgrounding issue by simply using the backend to reconstruct the missing Android -> iOS piece: https://medium.com/@dangish/a-solution-to-iphone-backgroundi.. https://medium.com/@dangish/a-solution-to-iphone-backgroundi.... An interesting approach here, although worth noting there are some privacy implications of this, since it requires "healthy and not ill" people to share their full list of contact events (or at least healthy iOS users). And Android users in your approach would need to check in for updates to "what they missed". One thing I'm slightly unsure of is how well this would perform in reality - did you get this to work for two long-sleeping iPhones? That seemed to be the "edge case" that was the most challenging here, and I'm not sure what you're suggesting changes anything there?
  - ridewinter 6y ago
    A variety of countermeasures can be used to keep the app awake in the background, including restarting services and (more controversially) location. And IMO, including a general/non-precise location of contact is incredibly useful for epidemiological purposes and to assist the manual contact tracing teams. The value far outweighing the hit to privacy. In any case, Google-Apple are dictating how these apps need to be built and released, so private innovation doesn't seem welcome at this juncture.
    - g_p 6y ago
      Yep - location listeners can help keep apps open quite well on Android. Not sure about iOS. RE rough location, the NHS currently asks people to enter the first "half" of their postcode, which gives a broad approximate geography, but still is a large area with a large population (probably up to 100k people). This also lets the NHS get an idea of app adoption throughout the country, which will help them know how much attention to give app-based contact tracing on a more localised basis, compared with alternative approaches and the old-fashioned "ask the person for names and phone numbers, and call them up".
crushthecurve 6y ago
It's interesting to consider that Bluetooth cannot be used to estimate distance between two devices in any meaningful way in real-world environments. A recent article [1] confirmed this in interviewing the inventors of Bluetooth. The environmental factors were explored in a recent conference on contact tracing [2] with leading researchers. So in a UK context, what is the plan in dealing with the huge number of false positives captured by this system, which in reality cannot estimate a 2 metre distance? The Australian COVIDSafe app sends all contacts in Bluetooth distance, which obviously includes people in other rooms, and on entirely different levels of a building - because there's no directional information. Separate to the issue of proximity is the issue that this system cannot really work unless it's mandatory, as others have outlined. Does any purpoted health benefits have to be modelled, proved and measured against the issues of shifting Western society to one which requires mandatory install and carry of a mobile phone which records all nearby devices? It gets us closer to a society where political actors will be tempted to provide a rationale which justifies permanent extreme surveillance of citizens. The limited analysis of the particular client implementations appears to miss this wider geopolitical point, and responsible technologists might want to consider these more carefully. In the Australian situation all we are currently told is that if the app registers you as a close contact then it is used for 'usual contact tracing' and that contact tracing involves determining whether you are a 'close contact' and have to self-isolate for 14 days - a huge cost in a re-opened society if it is an unnecessary false positive. It's been quite strange to see leading technologists such as Mike Cannon Brookes of Atlassian and Troy Hunt of HaveIBeenPwned strongly urge Australians to download it as an 'unequivocally safe app' when the most important part - the server-side algorithm to 'guesstimate' proximity - has not been shared by the Australian Government [3]. How can a technologist give the thumbs up to a proximity app when there is no evidence of it reliably estimating proximity in the real-world scenarios it is meant to operate in? [1] https://theintercept.com/2020/05/05/coronavirus-bluetooth-contact-tracing/ https://theintercept.com/2020/05/05/coronavirus-bluetooth-co... [2] https://www.youtube.com/watch?v=KgKbllhgESc&feature=youtu.be&t=2988 https://www.youtube.com/watch?v=KgKbllhgESc&feature=youtu.be... [3] https://www.abc.net.au/news/science/2020-05-06/coronavirus-contact-tracing-app-covid-safe-lockdown-lift/12217146 https://www.abc.net.au/news/science/2020-05-06/coronavirus-c...
- 6y ago

g_p 6y ago

Yes, this seems to be one of the rather clever aspects of the design - this appears to make it possible to discover iOS devices that are in the proprietary "iOS-only" mode of discovery. It seems that once one of these "overflow" advertisements is discovered, it attempts a connect that is enough to wake the device and carry out normal tracing. I left an iPhone unplugged, stationary, idle and asleep, running the app for about 5 hours. Then introduced an Android device and it was detected immediately. That seems to suggest this aspect works well. There's also a clever "ping-pong" type keepalive system at play - there are multiple characteristics broadcast, and one of them is for keep-alive. It seems devices also use this keepalive to keep the app active over time. That should work with even 2 devices - if I understand it correctly, device A will K/A device B after a period of time, and this will cause B to act. That means B will then K/A device A after a period of time, and the cycle can continue. I see the concerns about "2 sleeping iOS devices might not find each other", but wonder to what extent this will be a realistic scenario, versus an academic one - given the extent to which people are on their phones these days, and the size of that population, the issue likely fades in significance. Especially considering no app will get full adoption, no system will ever be perfect, and it's very much all about probabilities - the app can't determine if your 30 second exposure was higher risk than 30 minutes sitting 5m apart. Hopefully the testing phase currently underway will give some insight as to if this is a problem.

ridewinter 6y ago

I built an exposure notification app that solved the backgrounding issue by simply using the backend to reconstruct the missing Android -> iOS piece: https://medium.com/@dangish/a-solution-to-iphone-backgrounding-w-bluetooth-bb09b3f9a236 https://medium.com/@dangish/a-solution-to-iphone-backgroundi...

g_p 6y ago
> I built an exposure notification app that solved the backgrounding issue by simply using the backend to reconstruct the missing Android -> iOS piece: https://medium.com/@dangish/a-solution-to-iphone-backgroundi.. https://medium.com/@dangish/a-solution-to-iphone-backgroundi.... An interesting approach here, although worth noting there are some privacy implications of this, since it requires "healthy and not ill" people to share their full list of contact events (or at least healthy iOS users). And Android users in your approach would need to check in for updates to "what they missed". One thing I'm slightly unsure of is how well this would perform in reality - did you get this to work for two long-sleeping iPhones? That seemed to be the "edge case" that was the most challenging here, and I'm not sure what you're suggesting changes anything there?
- ridewinter 6y ago
  A variety of countermeasures can be used to keep the app awake in the background, including restarting services and (more controversially) location. And IMO, including a general/non-precise location of contact is incredibly useful for epidemiological purposes and to assist the manual contact tracing teams. The value far outweighing the hit to privacy. In any case, Google-Apple are dictating how these apps need to be built and released, so private innovation doesn't seem welcome at this juncture.
  - g_p 6y ago
    Yep - location listeners can help keep apps open quite well on Android. Not sure about iOS. RE rough location, the NHS currently asks people to enter the first "half" of their postcode, which gives a broad approximate geography, but still is a large area with a large population (probably up to 100k people). This also lets the NHS get an idea of app adoption throughout the country, which will help them know how much attention to give app-based contact tracing on a more localised basis, compared with alternative approaches and the old-fashioned "ask the person for names and phone numbers, and call them up".

crushthecurve 6y ago

It's interesting to consider that Bluetooth cannot be used to estimate distance between two devices in any meaningful way in real-world environments. A recent article [1] confirmed this in interviewing the inventors of Bluetooth. The environmental factors were explored in a recent conference on contact tracing [2] with leading researchers. So in a UK context, what is the plan in dealing with the huge number of false positives captured by this system, which in reality cannot estimate a 2 metre distance? The Australian COVIDSafe app sends all contacts in Bluetooth distance, which obviously includes people in other rooms, and on entirely different levels of a building - because there's no directional information. Separate to the issue of proximity is the issue that this system cannot really work unless it's mandatory, as others have outlined. Does any purpoted health benefits have to be modelled, proved and measured against the issues of shifting Western society to one which requires mandatory install and carry of a mobile phone which records all nearby devices? It gets us closer to a society where political actors will be tempted to provide a rationale which justifies permanent extreme surveillance of citizens. The limited analysis of the particular client implementations appears to miss this wider geopolitical point, and responsible technologists might want to consider these more carefully. In the Australian situation all we are currently told is that if the app registers you as a close contact then it is used for 'usual contact tracing' and that contact tracing involves determining whether you are a 'close contact' and have to self-isolate for 14 days - a huge cost in a re-opened society if it is an unnecessary false positive. It's been quite strange to see leading technologists such as Mike Cannon Brookes of Atlassian and Troy Hunt of HaveIBeenPwned strongly urge Australians to download it as an 'unequivocally safe app' when the most important part - the server-side algorithm to 'guesstimate' proximity - has not been shared by the Australian Government [3]. How can a technologist give the thumbs up to a proximity app when there is no evidence of it reliably estimating proximity in the real-world scenarios it is meant to operate in? [1] https://theintercept.com/2020/05/05/coronavirus-bluetooth-contact-tracing/ https://theintercept.com/2020/05/05/coronavirus-bluetooth-co... [2] https://www.youtube.com/watch?v=KgKbllhgESc&feature=youtu.be&t=2988 https://www.youtube.com/watch?v=KgKbllhgESc&feature=youtu.be... [3] https://www.abc.net.au/news/science/2020-05-06/coronavirus-contact-tracing-app-covid-safe-lockdown-lift/12217146 https://www.abc.net.au/news/science/2020-05-06/coronavirus-c...

6y ago