[stephenheron]

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/maste...

[2]: https://developer.apple.com/library/archive/documentation/Ne...

[3]: https://crownstone.rocks/2018/06/27/ios-advertisements-in-th...

[g_p]

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]

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...

[g_p]

> 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....

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]

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]

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]

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-co...

[2] https://www.youtube.com/watch?v=KgKbllhgESc&feature=youtu.be...

[3] https://www.abc.net.au/news/science/2020-05-06/coronavirus-c...

[urbandw311er]

Just to pick up on a couple of these points.

> shifting Western society to one which requires mandatory install

It is not mandatory to install the app here in the UK.

> permanent extreme surveillance of citizens

My reading of the code and solution architecture is that the system is anonymised, with IDs generated using random rotating keys.

Can you expand more on how you feel there are privacy implications to this approach?

My view is that a decentralised approach might not provide enough data to perform adequate contact tracing. One of the reasons being the example you give relating to false positives and unsuitability of RSSI to measure proximity/range.

However, I do feel that, with a centralised approach, there exists a much better chance of doing something useful with the pooled data. For example, correlating patterns, tuning an algorithm to reduce false positives. Even extending the code base to support additional proximity events such as use of public transportation.

[g_p]

> My reading of the code and solution architecture is that the system is anonymised, with IDs generated using random rotating keys.

Yes - the system is arguably about as private as you can get, if you aim for "level" playing field privacy. It is possible to have more privacy if you accept privacy asymmetry. The decentralised contact tracing approaches, for example, give the "infected" less privacy, as they need to broadcast out a list of "infected" people's temporary IDs. If you log the time of each observed contact, then go back and check your calendar, it's pretty likely you can figure out who you met that was infected, just based on time correlation.

In the NHS approach there is a long term (but still randomly generated) identifier for each user, that's encrypted via an ECDH key exchange and included in the "daily" data blob. This lets the clinical model (but not other users) link back together one user's exposure events, and understand the extent to which they've been exposed to the virus, and therefore approximate the likelihood they have it.

> My view is that a decentralised approach might not provide enough data to perform adequate contact tracing [...] However, I do feel that, with a centralised approach, there exists a much better chance of doing something useful with the pooled data.

This is the view of the NHS as well, it seems. They feel it's important to get reports of symptoms, not just "positive tests". Given the incubation period of the disease, and the reports people are most infective a day or two before the symptoms show, this seems to hold true - the sooner you can alert someone to proactively self-isolate, the better. If you wait for the test result (assuming it takes maybe a day to get a test done, and a day for the result), that's the difference between asking a contact to isolate before they hit their suspected "most infective" time, versus asking someone to isolate as they're about to experience symptoms anyway.

Just to demonstrate this:

Imagine A is infected on day 1. On day 4, A met with B and C. A experiences symptoms a few hours into day 6.

With a decentralised approach, you really need the certainty of a test before uploading anything, to stop Sybil-like attacks. Most probably, A would be tested the following day (day 7), and get a result (while isolating at home) a few hours into day 8. Meanwhile, B and C are walking around in the population, on day 7 and 8 (days 3 and 4 of their own infection, the time they are likely to be most infectious). They get asked to return home, and probably experience symptoms the next morning.

In the NHS approach, when A experiences symptoms on day 6, they report this via the app, and are told to go home and self-isolate. B and C might also be asked to isolate, based on their contact with A, at this time. This gets B and C at home and isolated on day 2 of their own infection, and has them at home during their 2 most infectious days. If neither gets symptoms, and others exposed to A don't develop symptoms either, the daily "how are you feeling" polling via the app for symptoms will be able to capture that based on lack of symptoms, there likely wasn't exposure, and the group can leave self-isolation. Testing then augments this for more certainty, but this model does appear to be quite novel and unique, and near impossible to do in the decentralised approach (especially some of the more complex parts like deciding how likely A is to spread the virus, based on A's own exposure to infected people in A's recent past, and the date A reports symptoms).

> Even extending the code base to support additional proximity events such as use of public transportation.

In essence, public transport is the real goal of this app. The traditional contact tracing approach (people asking you for names and phone numbers, then calling them up to alert them) will catch the social contacts. It's the random encounter type situations, where strangers may be proximate, where the app plays a part. The app itself isn't going to be a single solution.

[crushthecurve]

One of the numerous problems with the very concept of Bluetooth-based contact tracing is: it doesn't work.

Due to all the hardware and environmental factors, it really works as a large spreadsheet of all devices in Bluetooth range over the last 21 days (in the case of the Australian COVIDSafe app).

All it can do to grasp at the environmental context is to record the phone model, and the RSSI over time.

In a dynamic, real-world environment that will vary hugely, especially on public transport, as human bodies could be in the exact same close spot, but due to phone position and rotation the RSSI will vary wildly (as mentioned in the video), making two people close to each other actually look 20 metres or more away.

The huge amount of contacts each have to be manually contacted and interviewed to determine whether they're epidemiologically relevant. That also relies on the recall of the infected and the false 'close contacts' who are at risk of having to isolate for up to 14 days regardless of test or symptoms (according to a reading of the Australian rules).

This reality is extremely divorced from the Oxford University paper, which imagined a system that could accurately determine proximity of users and instantly notify them to isolate. This rapid notification and isolation was, in fact, the central proof of the impact of a digital contact tracing system.

So we have a centralised system that:

* only 'works' in a 'mandatory install' context

* can't determine proximity in the real-world (too much variability)

* would introduce huge numbers of false positives into a system that has to manually follow-up every one

* normalises carrying a tracking device of all nearby people (which in future would be far more useful as a societal monitoring system than as an epidemiological tool)

[g_p]

Interestingly, and purely anecdotally (so not designed to replace the study itself), I've been experimenting with the RSSI being reported by the NHSx app through the debug menu. At least based on what I've seen so far on my devices (and noting the NHSx model considers device model ID to allow for antenna variations going forwards), there was a ~25 dBm change in signal strength (from -32 to around -57) between phones being sat together, and through a wall yet still close.

Clearly this is going to vary depending on building construction, but I suspect the most relevant factor will be determining whether a contact event takes place through a wall or not. The real question is whether or not this can be modelled into the app and it proves reproducible.

My understanding is there's no claimed intention to measure the 2m distance, and this is accepted as a known factor, at least for now. I suspect in an indoor setting the initial challenge will be preventing spurious triggers from indoor use (although arguably if people are that close they might live in an apartment block, and they could have been exposed through contact with door handles or lift buttons etc). But once people are outside more and returning to normality, all bets seem to be off - I imagine a lot of false positives.

My instinct would be that contact exposure duration will become more of a factor than the RSSI, or that a min/max/median/standard deviation might be captured in addition to a "raw" RSSI, to perhaps get a better idea. If the RSSI never goes "above" -60 (noting it's a negative number) then that's not likely to be a hugely close contact event.

[crushthecurve]

It would be interesting to model two humans standing close to each other, and each phone on the closest side of the pairing, then on the opposite side, with the phones rotated at every angle.

Having to traverse two human bodies will create significant variation, and antenna angle will also add to that.

As mentioned in the video [1] this can make people look much further away, making it rather useless at estimating real distance.

[1] https://www.youtube.com/watch?v=KgKbllhgESc&feature=youtu.be...

[7952]

I wonder if WiFi connection information could help. Being on different networks would suggest greater social distance.

[g_p]

During current "distance under all circumstances, stay at home", that is likely going to be true (modulo people using multi-AP setups that aren't meshed under one SSID, assuming you use SSID, or who use 2.4 and 5 GHz SSIDs).

Going forward though, I imagine that as restrictions loosen, the usefulness of WiFI connections would drop significantly, as people aren't always at home. It would also not really help in the workplace, assuming a large campus WiFi setup, since everyone would probably be joined to the same network anyway.

The challenge would be privacy - you'd have to send some kind of information (or unique derivative) of the BSSID/SSID, which would introduce some privacy impact too. At that point, assuming you got access to the hashed SSID/BSSIDs, someone like Google with a street view dataset of AP MAC addresses could "enrich" the anonymised dataset with "ordinary location".