there is no need to have a single supplier for a contact tracing app if the interoperability problem could be solved.
by Arjen Schoneveld
Original post: https://medium.com/@arjenschoneveld/a-case-for-a-diversity-of-contact-tracing-modalities-862eec99da23
After watching the pitch videos of the seven companies/consortia that were selected to supply the Dutch Corona Contact Tracing app I felt that I needed to express my thoughts. Out of the 750 submitted apps seven “carefully” selected parties were put on the shortlist and invited to give a pitch that can be liked or disliked using a very simple poll. I won’t comment on the selection procedure (too much) and I am not going to analyse the privacy aspects of these apps. There has been enough criticism on the selection procedure. Privacy is very important, but in my opinion a solved problem. Privacy issues can be mitigated when using for example the DP-3T protocol, vividly depicted here. In this post I will make three different claims: (1) it is not a good idea to have a single supplier, (2) there is no need for a single supplier and (3) the space of possible contact tracing devices is larger than just only mobile phones.
Think of the scenario of a single supplier. It will likely cause a much lower uptake of the app compared to the situation where multiple app suppliers are offering solutions. Apps are very personal and might appeal to people and communities for different reasons. Also, some app developer may be more equipped to attract certain communities than others. Some users might be persuaded to use an app because of interesting statistics that it offers, other users could be attracted simply by a nice color scheme and the ability to choose their own avatar.
In addition, there is no need to have a single supplier for a contact tracing app if the interoperability problem could be solved. Interoperability means that different apps can communicate with each other using standardised protocols. Such a standardised protocol is suggested by Apple and Google. If each contact tracing device implements the Google/Apple contact tracing protocol, the interoperability problem is solved. In that way, any app developer can create a contact tracing app. All apps are compatible, because they are using the same protocol. What remains to be standardised (per country) is a cloud service hosted by the appropriate country’s health authority for uploading the so called Daily Keys, as defined in the crypto part in the Google/Apple specification, of a person that got infected. In addition, the cloud service should provide for downloading “infected” Daily Keys on a frequent basis. A simple certification process can be designed to let these apps integrate with the health authority’s cloud service. Apps that are not certified cannot communicate with the this service because they won’t have access to a supplied secret “integration key”. For the users it should be made clear by means of some kind of logo that the app is indeed certified. This approach promotes inclusivity and will not monopolise Covid-19 by a single large IT company, causing unnecessary bureaucracy and wasting significant amounts of tax payer money on armies of consultants.
Just as it is not rational having a single company monopolise the contact tracing app space, there is a case for not letting mobile phones monopolise the device space. An interesting alternative is the use of wearables in controlling the Covid-19 outbreak. Some ideas about using wearables to help diagnose Covid-19 symptons are already suggested here. However, I would like to suggest the use of wearables for contact tracing. Besides mobile apps, also smart watches and other wearables can implement the same standardised contact tracing protocol. As as result, all devices, mobile phones, smart watches, wearables, hearables, can interact with each other.
For anonymous proximity tracing, Bluetooth (BLE) seems to be the only wireless option that is available. BLE uses signal strength (RSSI) to measure the distance between two devices. RSSI decreases with increasing distance according to some well known mathematical function. Wearables have several advantages in this respect. Measuring distance using RSSI is more reliable for devices worn on the arm. Mobile phones can reside in the pockets of users that in turn can result in serious attenuation of the radio signal, making nearby devices (and therefore persons) look artificially further away. In addition, the case for wearables, that can be relatively cheaply produced, is also very evident for those users that do not own or are unable to use mobile phones; for example, think about school going children. Special apps on the phones of parents can be used to pair/synchronise the wearables of their children. As a daily routine parents can check the infection risks of their school going little children. Also for nursery- or elderly homes wearables can be used since there is high chance that mobile phones are not always available. Moreover, people with certain kinds of impairments (visual etc.) or disabilities would welcome the use of wearables, as well as the elderly. In certain types of environments, in e.g. chemical plants, the use of mobile phones is restricted or not allowed. In conclusion, a wearable is more friendly to all kinds of users, not only for mobile phone holders. Additionally, the technology used in wearables can be made more reliable, targeted and accurate and therefore can provide for more specific solutions.
I pledge for using a standardised contact tracing protocol as a separate service on the BLE stack, like Apple and Google are currently developing. This allows for an open space of mobile apps, smart watches and wearables that all cooperate towards one common goal: decreasing and keeping R_0 of SARS-Cov-2 below 1.
