11.04.2020
A new proposal for digital contact tracing has unique strengths, writes Koi Tū Research Fellow Dr Andrew Chen.
Another week has passed, with a lot of activity in the digital contact tracing space. The Prime Minister announced that a local solution is being developed, which could also use the TraceTogether protocol from Singapore if they agree to release it in time. More development groups popped up, with a lot of activity in the PEPP-PT consortium in the European Union and local companies going to the media to offer their products to the government for free. But this was all eclipsed by tech giants Apple and Google announcing over Easter weekend that they are working together to develop contact tracing technology.
Why is this so important? Google effectively controls the Android operating system (even though strictly speaking it is an open-source project), which is used on about 87% of smartphones globally. Apple’s iOS is used on the other 13% – Windows Phone and other operating systems disappear during rounding. These two companies have the ability to control how software works on pretty much every smartphone in the world. They control how apps interface with sensors on the phone, they control how apps request permission for activities that could be privacy-infringing, they control the app stores themselves. Small technical things like the iOS limitations on devices using Bluetooth when not in the foreground (which has been a significant issue with TraceTogether) are now resolvable because the Google and Apple can change those rules.
And now they have announced a plan that uses Bluetooth technology to let phones keep records of other phones that have been physically proximate, essentially keeping a log of contacts, not locations. They use standard cryptography measures to ensure security, and use anonymous identifiers that change regularly (at least daily) to help protect privacy. Data is stored on the device, and only shared with the government if someone reports they have been diagnosed with COVID-19. At a high-level, this is essentially the same sort of protocol used by TraceTogether (Singapore), DP3T (EU), and covid-watch (Stanford-led). The big difference is that instead of doing Bluetooth logging at the app level, Apple and Google can bake the functionality in at the operating system level, which is likely to be more effective and energy efficient.
To be clear, an app is still likely needed. The design is that Apple and Google will add the functionality to all devices, probably turned off by default (so that participation is voluntary). Then each government can have their own app that meets their local requirements – apps can connect that functionality to their national health databases (or not), they can adjust the time that people need to be in proximity to each other to be considered close contacts as our understanding of COVID-19 changes, and they can integrate it into their manual contact tracing and testing systems. It means that the app doesn’t have to be one-size-fits-all, and separates the “technology functionality” part from the “how it is used” part. In the New Zealand context, it is clear that an app like this would not replace the need for manual contact tracing, but would help keep the situation manageable if we face community spread. This is where the perspective of epidemiology and public health will inform the system design on what is the most useful for containing the spread of the disease.
Of course, this proposal is not without its problems, many of which are shared with similar solutions. Using such an app is still voluntary and opt-in, unless a government compels everyone to use it, or it becomes necessary to use it in order to participate in society (e.g. the red/yellow/green system being used in China). It still misses people who don’t have smartphones, or people who fail to update their software/OS. It still has the risk of producing false positives where people who aren’t at risk get caught up in the net (e.g. people living in apartment buildings who are physically separated but connected via Bluetooth). It will still miss quick interactions or environmental spread (e.g. spread via surfaces without personal physical proximity). Phones will probably need to connect with the central server at least once a day to ensure all the keys/identifiers are up-to-date, which consumes data and energy and may be a problem for people with poor internet coverage.
For those of us who have been talking about digital contact tracing for awhile, it can be hard to avoid falling into the trap of the false dichotomy. We want technology to produce a perfect solution, and it becomes easy to criticise the technology for all its shortcomings. So we start saying that because there are false positives we can’t use the technology, or that because we can’t guarantee a high uptake rate, we shouldn’t bother with the technology. In reality, nothing is perfect and we need a combination of tools working together to achieve the best result we can hope for. Just like how contact tracing augments a good testing regime, digital contact tracing technologies should be there to augment and not replace manual contact tracing. If the information provided by these digital systems can help reduce the load on manual contact tracing, or help find cases that would otherwise have been missed, then even if it’s not 100% perfect it can still be helpful.
An important idea to add to the discourse is ensuring legitimate reporting of cases. A number of the apps allow people to push a button that effectively self-reports that they have COVID-19 to the government, thus triggering the contact tracing and isolation/quarantine process. Malicious actors could quickly overwhelm a system with false reports, or use the system to force other people to be unnecessarily isolated. There is a relatively simple solution – if the health system develops and controls the app that sits on top of the Bluetooth contact tracing protocol, then public health officials can issue randomly generated codes along with positive test results, so that only people who have a code can report they are infected and release their data to the government. It’s important to say that protocols like the one announced by Google/Apple have some security concerns, but these are likely to be identified and worked through before release (as much as they can be). A big opportunity here is that since Android is technically open source, Google may release their implementation of the protocol and allow everyone to inspect it to check for issues and ensure there is nothing dodgy happening with the data.
Yes, there are reasons to distrust Google and Apple based on their history of harvesting user data for reuse elsewhere. On a technical level, what is proposed here shouldn’t put people at more risk than if they were checking their e-mail on a smartphone. But that doesn’t necessarily undo a lot of the suspicion and (healthy) paranoia. Governments will have to decide if they can trust this technology before they integrate it, and that includes understanding whether their people, the end users, trust this technology. A bit of inclusive and deliberative democracy would be quite helpful here. It may come down to whether we assume good intentions here or not, because despite our best efforts, we may not be able to fully inspect or understand what is happening behind the scenes – more than anything else, sometimes technology is just complex and insufficiently transparent.
And there are still hard decisions that government has to make about how they use this technology to inform their policy. Will the data just be used for contact tracing, or will it also lead to social control with people being allowed or denied access to services? How long do we use it for, and when will the government shut down their systems? How do we incentivise people to use the technology and the related app, while maintaining equity and not disadvantaging vulnerable people?
But if Google and Apple can make this work, it could have a huge impact and could be our path to achieving an effective digital contact tracing solution. This is a big risk on their part – it opens them up to all sorts of legal liability and perception risks that they could have decided were easier to avoid. But they have complete dominance of the market share and plenty of resourcing, they have access to some of the best engineering talent, they can ensure interoperability between Android and iOS, and they have formal quality assurance and testing processes that can ensure that the technology works. IT projects have a high risk of failure, but Apple and Google are probably some of the most knowledgable and successful in mitigating those risks.
To me, the biggest problem here is time – they expect to make the APIs available in mid-May, with more functionality built-in over the subsequent months. This is pretty fast by normal tech standards, but given how quickly the COVID-19 situation changes and the massive cost of continued lockdowns (and the even bigger cost of not going into lockdown), we may need something sooner. Governments will need time to integrate the functionality with their existing systems, including testing to ensure that everything works before they launch an app. The proof is not only in the pudding – that pudding has to be made faster than it has ever been made before.
This article has been peer-reviewed by Peter Gluckman.
Andrew is a Research Fellow with Koi Tū: The Centre for Informed Futures. He comes from a technical background with a PhD in Computer Systems Engineering from the University of Auckland. His PhD research focused on the use of camera-based person tracking, as well as how might use technology to help protect the privacy of people. Andrew also has a background in civics education and policy analysis, and is now using that to explore how we can bring technical expertise with other forms of evidence to form pragmatic and practical policy suggestions that can help our society find a path forward through the digital revolution.
