What’s going on with the UK’s coronavirus contacts tracing app? Reports in the national press today suggest a launch of the much delayed software will happen this month but also that the app will no longer be able to automatically carry out contacts tracing.
The Times reports that a repackaged version of the app will only provide users with information about infection levels in their local area. The newspaper also suggests the app will let users provide personal data in order to calculate a personal risk score.
The Mail also reports that the scaled back software will not be able to carry out automated contacts tracing.
We’ve reached out to the Department for Health and Social Care (DHSC) with questions and will update this report with any response. DHSC is the government department leading development of the software, after the NHS’s digital division handed the app off.
As the coronavirus pandemic spread around the world this year, digital contacts tracing has been looked to as a modern tool to COVID-19 by leveraging the near ubiquity of smartphones to try to understand individual infection risk based on device proximity.
In the UK, an earlier attempt to launch an NHS COVID-19 app to support efforts to contain the virus by automating exposure notifications using Bluetooth signals faltered after the government opted for a model that centralized exposure data. This triggered privacy concerns and meant it could not plug into an API offered by Apple and Google — whose tech supports decentralized coronavirus contacts tracing apps.
At the same time, multiple countries and regions in Europe have launched decentralized contacts tracing apps this year. These apps use Bluetooth signals as a proxy for calculating exposure risk — crunching data on device for privacy reasons — including, most recently, Northern Ireland, which is part of the UK.
However in the UK’s case, after initially heavily publicizing the forthcoming app — and urging the public to download it in its daily coronavirus briefings (despite the app not being available nationwide) — the government appears to have stepped almost entirely away from digital contacts tracing, claiming the Apple -Google API does not provide enough data to accurately calculate exposure risk via Bluetooth.
Decentralized Bluetooth coronavirus contacts tracing apps that are up and running elsewhere Europe have reported total downloads and sometimes other bits of data. But there’s been no comprehensive assessment of how well they’re functioning as a COVID-fighting tool.
There have been some reports of bugs impacting operation in some cases, too. So it’s tricky to measure efficacy. Although the bald fact remains that having an app means there’s at least a chance it could identify contacts otherwise unknown to users, vs having no app and so no chance of that.
The Republic of Ireland is one of the European countries with a decentralized coronavirus contacts tracing app (which means it can interoperate with Northern Ireland’s app) — and it has defended how well the software is functioning, telling the BBC last month that 91 people had received a “close contact exposure alert” since launch. Although it’s not clear how many of them wouldn’t have been picked up via manual contacts tracing methods.
A government policy paper published at the end of last month which discussed the forthcoming DHSC app said it would allow citizens to: identify symptoms; order a test; and “feel supported” if they needed to self isolate. It would also let people scan a QR codes at venues they’ve visited “to aid contact tracing and help understand the spread of the virus”.
The government paper also claimed the app would let users “quickly identify when they have been exposed to people who have COVID-19 or locations that may have been the source of multiple infections” — but without providing details of how that would be achieved.
“Any services that require more information from a citizen will be provided only on the basis of explicit consent,” it added.
Ahead of the launch of this repackaged app it’s notable that DHSC disbanded an ethics committee which had been put in place to advise the NHS on the app. Once development was handed over to the government, the committee was thanked for its time and sent on its way.
Speaking to BBC Radio 4’s World at One program today, professor Lilian Edwards — who was a member of the ethics committee — expressed concern at the reports of the government’s latest plans for the app.
“Although the data collection is being presented as voluntary it’s completely non-privacy preserving,” she told the program, discussing The Times’ report which suggests users will be nudged to provide personal data with the carrot of a ‘personal risk score’. “It’s going to involve the collection of a lot of personal, sensitive data — perhaps your health status, your retirement status, your occupation etc.
“This seems, again, an odd approach given that we know one of the reasons why the previous app didn’t really take off was because there was rather a loss of public trust and confidence in it, because of the worries partly about privacy and about data collection — it not being this privacy-preserving decentralized approach.”
“To mix the two up seems a strange way to go forward to me in terms of restoring and embedding that trust and confidence that your data won’t be shared with people you don’t want it to be,” Edwards added. “Like maybe insurers. Or repurposed in ways that you don’t know about. So it seems rather contrary to the mission of restoring trust and confidence in the whole test and trace endeavour.”
Concerns have also been raised about another element of the government’s digital response to the coronavirus — after it rushed to ink contracts with a number of tech giants, including Palantir and Google, granting them access to NHS data.
It was far less keen to publish details of these contracts — requiring a legal challenge by Open Democracy, which is warning over the impact of “Silicon Valley thinking” applied to public health services.
In another concerning development, privacy experts warned recently that the UK’s test and trace program as a whole breaches national data protection laws, after it emerged last month that the government failed to carry out a legally required privacy impact assessment ahead of launch.
In the monitoring world, typically when you spin up a new instance, you pay a fee to monitor it. If you are particularly active in any given month, that can result in a hefty bill at the end of the month. That leads to limiting what you choose to monitor to control costs. New Relic wants to change that, and today it announced that it’s moving to a model where customers pay by the user instead with a smaller less costly data component.
The company is also simplifying its product set with the goal of encouraging customers to instrument everything instead of deciding what to monitor and what to leave out to control cost. “What we’re announcing is a completely reimagined platform. We’re simplifying our products from 11 to three, and we eliminate those barriers to standardizing on a single source of truth,” New Relic founder and CEO Lew Cirne told TechCrunch.
The way the company can afford to make this switch is by exposing the underlying telemetry database that it created to run its own products. By taking advantage of this database to track all of your APM, tracing and metric data all in one place, Cirne says they can control costs much better and pass those savings onto customers, whose bills should be much smaller based on a this new pricing model, he said.
“Prior to this, there has not been any technology that’s good at gathering all of those data types into a single database, what we would call a telemetry database. And we actually created one ourselves and it’s the backbone of all of our products. [Up until now], we haven’t really exposed it to our customers, so that they can put all their data into it,” he said.
New Relic Telemetry Data. Image: New Relic
The company is distilling the product set into three main categories. The first is the Telemetry Data Platform, which offers a single way to gather any events, logs or traces, whether from their agents or someone else’s or even open source like Prometheus.
The second product is called Full-stack Observability, which includes all of their previous products, which were sold separately such as APM, mobility, infrastructure and logging. Finally they are offering an intelligence layer called New Relic AI.
Cirne says by simplifying the product set and changing the way they bill, it will save customers money through the efficiencies they have uncovered. In practice he says, pricing will consist of a combination of users and data, but he believes their approach will result in much lower bills and more cost certainty for customers.
“It’ll vary by customer so this is just a rough estimate but imagine that the typical New Relic bill under this model will be a 70% per user charge and 30% data charge, roughly, but so if that’s the case, and if you look at our competitors 100% of the bill is data,” he said.
The new approach is available starting today. Companies can try it with 100 GB single user account.
Lightrun, a Tel Aviv-based startup that makes it easier for developers to debug their production code, today announced that it has raised a $4 million seed round led by Glilot Capital Partners, with participation from a number fo engineering executives from several Fortune 500 firms.
The company, which was co-founded by Ilan Peleg (who, in a previous life, was a competitive 800m runner) and Leonid Blouvshtein, with Peleg taking the CEO role and Blouvshtein the CTO position.
The overall idea behind Lightrun is that it’s too hard for developers to debug their production code. “In today’s world, whenever a developer issues a new software version and deploys it into production, the only way to understand the application’s behavior is based on log lines or metrics which were defined during the development stage,” Peleg explained. “The thing is, that is simply not enough. We’ve all encountered cases of missing a very specific log line when trying to troubleshoot production issues, then having to release a new hotfix version in order to add this specific logline, or –alternatively — reproduce the bug locally to better understand the application’s behavior.”
With Lightrun, as the co-founders showed me in a demo, developers can easily add new logs and metrics to their code from their IDE and then receive real-time data from their real production or development environments. For that to work, they need to have the Lightrun agent installed, but the overhead here is generally low because the agent sits idle until it is needed. In the IDE, the experience isn’t all that different from setting a traditional breakpoint in a debugger — only that there is no break. Lightrun can also use existing logging tools like Datadog to pipe its logging data to them.
While the service’s agent is agnostic about the environment it runs in, the company currently only supports JVM languages. Blouvshtein noted that building JVM language support was likely harder than building support for other languages and the company plans to launch support for more languages in the future.
“We make a point of investing in technologies that transform big industries,” said Kobi Samboursky, founder and managing partner at Glilot Capital Partners . “Lightrun is spearheading Continuous Debugging and Continuous Observability, picking up where CI/CD ends, turning observability into a real-time process instead of the iterative process it is today. We’re confident that this will become DevOps and development best practices, enabling I&O leaders to react faster to production issues.”
For now, there is still a bit of an onboarding process to get started with Lightrun, though that’s generally a very short process, the team tells me. Over time, the company plans to make this a self-service process. At that point, Lightrun will likely also become more interesting to smaller teams and individual developers, though the company is mostly focused on enterprise users and despite only really launching out of stealth today and offering limited language support, the company already has a number of paying customers, including major enterprises.
“Our strategy is based on two approaches: bottom-up and top-down. Bottom-up, we’re targeting developers, they are the end-users and we want to ensure they get a quality product they can trust to help them. We put a lot of effort into reaching out through the developer channels and communities, as well as enabling usage and getting feedback. […] Top-down approach, we are approaching R&D management like VP of R&D, R&D directors in bigger companies and then we show them how Lightrun saves company development resources and improves customer satisfaction.”
Unsurprisingly, the company, which currently has about a dozen employees, plans to use the new funding to add support for more languages and to improve its service with new features, including support for tracing.
The UK has given up building a centralized coronavirus contacts-tracing app and will instead switch to a decentralized app architecture, the BBC has reported. This suggests its any future app will be capable of plugging into the joint ‘exposure notification’ API which has been developed in recent weeks by Apple and Google.
The UK’s decision to abandon a bespoke app architecture comes more than a month after ministers had been reported to be eyeing such a switch. They went on to award a contract to an IT supplier to develop a decentralized tracing app in parallel as a backup — while continuing to test the centralized app, which is called NHS COVID-19.
At the same time, a number of European countries have now successfully launched contracts-tracing apps with a decentralized app architecture that’s able to plug into the ‘Gapple’ API — including Denmark, Germany, Italy, Latvia and Switzerland. Several more such apps remain in testing. While EU Member States just agreed on a technical framework to enable cross-border interoperability of apps based on the same architecture.
Germany — which launched the decentralized ‘Corona Warning App’ this week — announced its software had been downloaded 6.5M times in the first 24 hours. The country had initially appeared to favor a centralized approach but switched to a decentralized model back in April in the face of pushback from privacy and security experts.
The UK’s NHS COVID-19 app, meanwhile, has not progressed past field tests, after facing a plethora of technical barriers and privacy challenges — as a direct consequence of the government’s decision to opt for a proprietary system which uploads proximity data to a central server, rather than processing exposure notifications locally on device.
Apple and Google’s API, which is being used by all Europe’s decentralized apps, does not support centralized app architectures — meaning the UK app faced technical hurdles related to accessing Bluetooth in the background. The centralized choice also raised big questions around cross-border interoperability, as we’ve explained before. Questions had also been raised over the risk of mission creep and a lack of transparency and legal certainty over what would be done with people’s data.
So the UK’s move to abandon the approach and adopt a decentralized model is hardly surprising — although the time it’s taken the government to arrive at the obvious conclusion does raise some major questions over its competence at handling technology projects.
Michael Veale, a lecturer in digital rights and regulation at UCL — who has been involved in the development of the DP3T decentralized contacts-tracing standard, which influenced Apple and Google’s choice of API — welcomed the UK’s decision to ditch a centralized app architecture but questioned why the government has wasted so much time.
“This is a welcome, if a heavily and unnecessarily delayed, move by NHSX,” Veale told TechCrunch. “The Google -Apple system in a way is home-grown: Originating with research at a large consortium of universities led by Switzerland and including UCL in the UK. NHSX has no end of options and no reasonable excuse to not get the app out quickly now. Germany and Switzerland both have high quality open source code that can be easily adapted. The NHS England app will now be compatible with Northern Ireland, the Republic of Ireland, and also the many destinations for holidaymakers in and out of the UK.”
Perhaps unsurprisingly, UK ministers are now heavily de-emphasizing the importance of having an app in the fight against the coronavirus at all.
The Department for Health and Social Care’s, Lord Bethell, told the Science and Technology Committee yesterday the app will not now be ready until the winter. “We’re seeking to get something going for the winter, but it isn’t a priority for us,” he said.
Yet the centralized version of the NHS COVID-19 app has been in testing in a limited geographical pilot on the Isle of Wight since early May — and up until the middle of last month health minister, Matt Hancock, had said it would be rolled out nationally in mid May.
Of course that timeframe came and went without launch. And now the prospect of the UK having an app at all is being booted right into the back end of the year.
Compare and contrast that with government messaging at its daily coronavirus briefings back in May — when Hancock made “download the app” one of the key slogans — and the word ‘omnishambles‘ springs to mind…
NHSX relayed our request for comment on the switch to a decentralized system and the new timeframe for an app launch to the Department of Health and Social Care (DHSC) — but the department had not responded to us at the time of publication.
Earlier this week the BBC reported that a former Apple executive, Simon Thompson, was taking charge of the delayed app project — while the two lead managers, the NHSX’s Matthew Gould and Geraint Lewis — were reported to be stepping back.
Back in April, Gould told the Science and Technology Committee the app would “technically” be ready to launch in 2-3 weeks’ time, though he also said any national launch would depend on the preparedness of a wider government program of coronavirus testing and manual contacts tracing. He also emphasized the need for a major PR campaign to educate the public on downloading and using the app.
Government briefings to the press today have included suggestions that app testers on the Isle of Wight told it they were not comfortable receiving COVID-19 notifications via text message — and that the human touch of a phone call is preferred.
However none of the European countries that have already deployed contacts-tracing apps has promoted the software as a one-stop panacea for tackling COVID-19. Rather tracing apps are intended to supplement manual contacts-tracing methods — the latter involving the use of trained humans making phone calls to people who have been diagnosed with COVID-19 to ask who they might have been in contact with over the infectious period.
Even with major resource put into manual contacts-tracing, apps — which use Bluetooth signals to estimate proximity between smartphone users in order to calculate virus expose risk — could still play an important role by, for example, being able to trace strangers who are sat near an infected person on public transport.
Update: The DHSC has now issued a statement addressing reports of the switch of app architecture for the NHS COVID-19 app — in which it confirms, in between reams of blame-shifting spin, that it’s testing a new app that is able to plug into the Apple and Google API — and which it says it may go on to launch nationally, but without providing any time frame.
It also claims it’s working with Apple and Google to try to enhance how their technology estimates the distance between smartphone users.
“Through the systematic testing, a number of technical challenges were identified — including the reliability of detecting contacts on specific operating systems — which cannot be resolved in isolation with the app in its current form,” DHSC writes of the centralized NHS COVID-19 app.
“While it does not yet present a viable solution, at this stage an app based on the Google / Apple API appears most likely to address some of the specific limitations identified through our field testing. However, there is still more work to do on the Google / Apple solution which does not currently estimate distance in the way required.”
“Based on this, the focus of work will shift from the current app design and to work instead with Google and Apple to understand how using their solution can meet the specific needs of the public,” it adds.
We reached out to Apple and Google for comment. Apple declined to comment.
According to one source, the UK has been pressing for the tech giants’ API to include device model and RSSI info alongside the ephemeral IDs which devices that come into proximity exchange with each other — presumably to try to improve distance calculations via a better understanding of the specific hardware involved.
However introducing additional, fixed pieces of device-linked data would have the effect of undermining the privacy protections baked into the decentralized system — which uses ephemeral, rotating IDs in order to prevent third party tracking of app users. Any fixed data-points being exchanged would risk unpicking the whole anti-tracking approach.
Norway, another European country which opted for a centralized approach for coronavirus contacts tracing — but got an app launched in mid April — made the decision to suspend its operation this week, after an intervention by the national privacy watchdog. In that case the app was collecting both GPS and Bluetooth — posing a massive privacy risk. The watchdog warned the public health agency the tool was no longer a proportionate intervention — owing to what are now low levels of coronavirus risk in the country.
Personal-symptom trackers, digital contact-tracing and exposure-notification tools are under development in the United States and around the world — their adoption could help healthcare workers mitigate the impact of further waves of COVID-19. These technologies also have significant privacy and security issues. The COVID Tech Task Force has a conference scheduled in 10 days to discuss the key issues related to COVID technologies.
As part of our work preparing for that conference, we collected and reviewed the leading apps in the U.S. With the goal of helping the public, and state and local governments, better understand the privacy and security features of leading applications, we’re sharing the information and demos we gathered from the teams building these applications.
We have sorted the demos into three broad categories: (1) contact-tracing/exposure-notification applications using Google/Apple API, (2) contact-tracing/exposure-notification applications not using Google/Apple API, and (3) personal-symptom-tracking applications.
We surveyed teams regarding privacy, security and commercialization of personal data. We’ve made the results of the surveys available here. We encourage you to look through the responses and share your thoughts on how different applications have approached these important issues.
The applications featured in this article were to be demoed at the Contact Tracing and Technology Conference originally scheduled for this week — in light of the significant conversations around racial injustice and police brutality against Black Americans we rescheduled it to ensure we are not taking up unnecessary space. The conference is now rescheduled or June 17th — if you RSVP’d, we look forward to seeing you there; if you haven’t, please do!
The conference will be hosted by the COVID Tech Task Force, in collaboration with TechCrunch, Harvard’s Berkman Klein Center, NYU’s Alliance for Public Interest Technology, Betaworks Studios and Hangar. The COVID Tech Task Force is composed of a group of volunteers who came together in March to help convene a forum for state and local governments and the tech community to work together to mitigate the impact of COVID-19.
Google and Apple have collaborated to create development tools in order to provide a cross-platform way for public health agencies to notify individuals of a potential exposure.
SafePaths is developing free, open-source, privacy-by-design tools for individuals, public health officials and larger communities to flatten the curve of COVID-19, reduce fear and prevent a surveillance-state response to the pandemic.
If you want further information, reach out to email@example.com.
CoEpi is an open-source project developing a decentralized, privacy-first app for anonymous Bluetooth-based exposure notification based on symptom sharing. Communities of close contacts can begin protecting themselves with CoEpi without requiring widespread adoption among the general population; there is no scale required to achieve benefit to small user groups. CoEpi helps you anonymously alert the people with whom you interact about symptoms of a contagious illness, or alert you if you might have been exposed in an interaction.
If you want further information, reach out to Dana+CoEpi@OpenAPS.org.
COVID Shield is a free exposure notification solution built with privacy as its top priority. It was built by a group of volunteers, many from Shopify, in order to help Canadians and the rest of the world safely return to work.
If you want further information, reach out to firstname.lastname@example.org.
The team consists of a group of public health officials, doctors, researchers and engineers based out of the University of Washington and Microsoft who are working together to keep the public safe and to help public health systems in managing the outbreak.
If you want further information, reach out to email@example.com.
COVID Trace is a nonprofit offering a COVID-19 exposure-notification app for iOS and Android using the Apple/Google exposure-notification APIs. People using COVID Trace can expect privacy and simplicity. With COVID Trace, health departments get an app and metrics that are an extension of their efforts. COVID Trace is ready to be used today.
If you want further information, reach out to firstname.lastname@example.org.
Zero is a citizen-led nonprofit that leverages technology for pandemic response, focused on facilitating safe social behavior and peace of mind. Their goal is to stem the spread of COVID-19 and give citizens the information they need to feel safe and confident engaging with their local economy.
If you want further information, reach out to email@example.com.
COVID Watch uses the Apple/Google GAEN protocol, which it claims its developers explained to Apple how to build based on their original TCN protocol. The Covid Watch team was founded by researchers from Stanford and Waterloo and claims to be the first in the world to invent, develop and open-source a decentralized Bluetooth exposure alert protocol in early March.
If you want further information, reach out to firstname.lastname@example.org.
Note that some of these organizations have indicated they might use the Google/Apple API in the future. Some of them intend to and are waiting on confirmation from Google/Apple.
NOVID claims to be the first (and currently only) completely anonymous contact-tracing app published in the USA that uses no personal information. No GPS, no phone number, no email — it’s completely anonymous. The app utilizes ultrasound to provide extremely accurate measurements of interaction distance, overcoming the known inaccuracies of Bluetooth. The team is led by Carnegie Mellon professor and internationally renowned mathematician, Po-Shen Loh.
If you want further information, reach out to email@example.com.
Healthy Together is an end-to-end COVID-19 response platform that is fully integrated into public health and the enterprise. Launched in April for the State of Utah, Healthy Together’s mobile applications support self-assessment, COVID-19 testing access and results, and augmented contact tracing, as well as enterprise contact tracing, workflow tools, data integrations and visualizations. Leveraging existing technology that has scaled to millions of users and informed by public health experts, Healthy Together will soon be announcing additional states and enterprise customers that are using the platform to protect the health of residents and employees.
If you want further information, reach out to firstname.lastname@example.org.
Sharetrace is a health passport and contact-tracing application that’s privacy-preserving by design. Built on user-owned personal data accounts, pioneering personal data privacy technology, it can safely use sensitive data without the risk of sovereign surveillance by either companies or governments. Sharetrace is a collaboration between U.K. and U.S. universities, including Case Western Reserve University in Ohio. Learn more online at sharetrace.org.
If you want further information, reach out to email@example.com.
Coalition Network is a nonprofit whose founders and team have been building and implementing decentralized, Bluetooth-based network solutions on mobile for the past decade. Coalition’s open source Whisper Tracing Protocol has been peer reviewed by cryptographers at MIT, Stanford, USC and Oxford, and adopted by the government of Senegal.
If you want further information, reach out to firstname.lastname@example.org.
Safe2 is a COVID-19 exposure warning system for smarter social distancing. The mobile app uses anonymized data from GPS and Bluetooth technology to privately share real-time exposure alerts to help prevent community spread of the virus. Safe2 was founded by Jamison D. Day, Ph.D., data scientist and expert in disaster relief, with an international team specializing in global health, technology and crisis management, with a focus on improving health, economic well-being and privacy.
If you want further information, reach out to email@example.com.
VIRI is a contact-tracing platform driven by the ethos of privacy and anonymity, on a mission to allow cross-entity contact tracing without the need to share any personal identifying information. It can be incorporated into an existing enterprise app as an API seamlessly allowing compatibility between enterprises and institutions at a global scale while letting the entities adhere to various healthcare-data regulations. VIRI deploys a hybrid back-end architecture that leverages permissive blockchain technology.
If you want further information, reach out to firstname.lastname@example.org.
COVID Near You, a crowdsourced COVID-19 symptom tracker, was created by epidemiologists and software developers within the Innovation and Digital Health Accelerator at Boston Children’s Hospital. The Boston Children’s Hospital team has background and expertise in developing platforms in infectious disease surveillance, and provides technical capacity in building visualization-based tools for public health response efforts. The COVID Near You team aims to support public health surveillance measures of COVID-19 and conduct research using the self-reported data to better understand the impact of this disease across North America.
If you want further information, reach out to email@example.com.
How We Feel lets you self-report your age, sex, ZIP code and any health symptoms you experience. The app was built by an independent, nonprofit organization called The How We Feel Project. Their tech team includes Ben Silbermann, CEO of Pinterest, and a volunteer group of current and former Pinterest employees. They are working with scientists, doctors and public health professionals from leading institutions including, the Harvard T.H. Chan School of Public Health, the McGovern Institute for Brain Research at MIT, Broad Institute of MIT and Harvard, Howard Hughes Medical Institute, University of Pennsylvania, Stanford University, University of Maryland School of Medicine and the Weizmann Institute of Science.
If you want further information, reach out to firstname.lastname@example.org.
Exposure notification and contact tracing are two related but distinct measures many public health authorities are either considering or already implementing.
Contact tracing is a practice almost as old as epidemiology itself, but today’s technology means the way that we go about tracking the spread of a contagious illness within and between communities is changing very quickly. This presents an opportunity for learning more about the opportunities and challenges presented in extending contact tracing and exposure notification via digital means.
To that end, we’re happy to be working with the COVID-19 Technology Task Force, as well as Harvard’s Berkman Klein Center, NYU’s Alliance for Public Interest Technology, Betaworks Studios and Hangar. We’ll be playing host on TC to their live-streamed discussion around contact tracing and exposure notification applications, including demonstrations of some of the cutting-edge products that will be available in the U.S. to tackle these challenging, but crucial, tasks. The day’s events will include a roundtable discussion followed by a series of product demos, and will take place starting at 11 AM EDT (8 AM PDT) on Wednesday, June 3.
Below, we’ve included an agenda of the confirmed speakers and demonstrations for the day so far. Note that this is work in progress, and that more speakers and demos will be added to the day’s slate as we get closer to Wednesday. To RSVP for this free event, check out this link.
11am-1pm EDT: Roundtable Discussion – Hear from researchers, healthcare professionals, and technologists, including:
1pm-2pm EDT: Contact Tracing/Exposure Notification Product Demos – Leading organizations developing applications to mitigate the impact of COVID-19, primarily through contact tracing and exposure notification, will each demo their product. Teams include:
We’ll have a live stream available on June 3 so you can follow along, as mentioned, but you can also RSVP here to register your interest. It should be a day full of interesting, expert discussion of why there’s a need to extend contact tracing and exposure notification through connected and digital means, as well as the privacy, public health and policy implications such extension necessarily carries with it.
France's data protection watchdog CNIL has released its second review of StopCovid, the contact-tracing app backed by the French government. The CNIL says there’s no major issue with the technical implementation and legal framework around StopCovid, with some caveats.
France isn’t relying on Apple and Google’s contact-tracing API. Instead, a group of research institutes and private companies have worked on a separate solution.
At the heart of StopCovid, there’s a centralized contact-tracing protocol called ROBERT. It relies on a central server to assign a permanent ID and generate ephemeral IDs attached to this permanent ID. Your phone collects the ephemeral IDs of other app users around you. When somebody is diagnosed COVID-19-positive, the server receives all the ephemeral IDs associated with people with whom they’ve interacted. If one or several of your ephemeral IDs get flagged, you receive a notification.
ROBERT has been a controversial topic as it isn’t an anonymous system — it relies on pseydonymization. It means that you have to trust your government that it isn’t collecting too much information and it doesn’t plan to put names on permanent IDs.
But the CNIL says that ROBERT focuses on exposed users instead of users who are diagnosed COVID-19-positive — it is “a choice that protects the privacy of those persons,” the agency says. The CNIL also says that ROBERT tries to minimize data collection as much as possible.
Inria released a small portion of the source code that is going to power StopCovid a couple of weeks ago. The research institute originally said that some parts wouldn’t be open-sourced. The CNIL contested this decision and Inria has now reversed its stance and the government promises that everything will be released, eventually.
The StopCovid development team is also launching a bug bounty program in partnership with YesWeHack following recommendations from France’s national cybersecurity agency (ANSSI).
On the legal front, the draft decree excludes data aggregation in general. For instance, the government won’t be able to generate a heat map based on StopCovid data — StopCovid doesn’t collect your location anyway.
The CNIL says that the government promises that there won’t be any negative consequence if you’re not using StopCovid, nor any privilege if you’re using it. The government also promises that you’ll be able to delete pseudonymized data from the server. All of this is still ‘to be confirmed’ with the final decree.
Finally, the CNIL recommends some changes when it comes to informing users about data collection and data retention — it’s hard to understand what happens with your data right now. There should be some specific wording for underage people and their parents as well.
In other news, the government has sent me some screenshots of the app. Here’s what it looks like on iOS:
France’s digital minister, Cédric O, will be in front of parliament members tomorrow to debate the pros and cons of StopCovid. It’s going to be interesting to see whether the French government has managed to convince parliament members that a contact-tracing app is useful to fight the spread of COVID-19.
Apple has released iOS 13.5, which includes support for the Exposure Notification API that it co-created with Google to support public health authorities in their contact-tracing efforts to combat COVID-19. The API requires third-party apps developed by public health authorities for use, and none have yet been released, but iOS device users already have access to COVID-19 Exposure Logging global settings.
As previewed in the beta release, you can access the Exposure Logging settings under the Settings app, then navigate to the Privacy subsection. From there, you can select the Health submenu and find the COVID-19 Exposure Logging setting, which will be off be default. It can’t be turned on at all until you actually get an authorized app to enable them, at which point you’ll receive a pop-up asking you to authorize Exposure Notifications access. Once you do, you can return here to toggle notifications off, and also manually delete your device’s exposure log should you choose to opt out.
Apple and Google both have emphasized that they want as much user control and visibility into the Exposure Notification API as possible. They’re using randomized, temporary identifiers that are not centrally stored to do the exposure notification, and are also forbidding the simultaneous use of geolocation services and the Exposure Notification API within the same app. This manual control is another step to ensure that users have full control over what info they share to participate in the system, and when.
Contact tracing is a time-tested strategy for combating the spread of infectious disease, and has traditionally worked by attempting to trace potential exposure by interviewing infected individuals and learning as much as possible about their movements during their infectious period. Modern connected devices mean that we can potentially make this far more efficient and accurate, but Google and Apple have worked with privacy experts to try to determine a way to make this happen without exposing users to privacy risks. Matching also happens locally on a user’s device, not in any centralized database.
Apple and Google are currently working with public health authorities who are building apps based on this API, and the companies also have noted that this is a temporary measure that has been designed from the beginning to be disabled once the threat of COVID-19 has passed.
Apple and Google today made available the first public version of their exposure notification API, which was originally debuted as a joint-contact tracing software tool. The partners later renamed it the Exposure Notification system to more accurately reflect its functionality, which is designed to notify individuals of potential exposure to others who have confirmed cases of COVID-19, while preserving privacy around identifying info and location data.
The launch today means that public health agencies can now use the API in apps released to the general public. To date, Apple and Google have only released beta versions of the API to help developed with the development process.
To be clear, this launch means that developers working on behalf of public health agencies can now issue apps that make use of it – Apple and Google themselves are not creating an exposure notification or contact tracing app. The companies say that many U.S. states and 22 countries across five continents have already asked for, and been provided access to the API to support their development efforts, and they anticipate more being added going forward. So far, Apple and Google say they have conducted over 24 briefings and tech talks for public health officials, epidemiologists, and app developers working on their behalf.
The exposure notification API works using a decentralized identifier system that uses randomly generated temporary keys created on a user’s device (but not tied to their specific identify or info). Apple and Google’s API allows public health agencies to define what constitutes potential exposure in terms of exposed time and distance, and they can tweak transmission risk and other factors according to their own standards.
Further, Apple and Google will allow apps to make use of a combination of the API and voluntarily submitted user data that they provide through individual apps to enable public health authorities to contact exposure users directly to make them aware of what steps they should take.
During the course of the API’s development, Apple and Google have made various improvements to ensure that privacy is an utmost consideration, including encrypting all Bluetooth metadata (like signal strength and specific transmitting power) since that could potentially be used to determine what type of device was used, which offers a slim possibility of associating an individual with a specific device and using that as one vector for identification.
The companies have also explicitly barred use of the API in any apps that also seek geolocation information permission from users – which means some apps being developed by public health authorities for contact tracing that use geolocation data won’t be able to access the exposure notification API. That has prompted some to reconsider their existing approach.
Apple and Google provided the following joint statement about the API and how it will support contact tracing efforts undertaken by public health officials and agencies:
One of the most effective techniques that public health officials have used during outbreaks is called contact tracing. Through this approach, public health officials contact, test, treat and advise people who may have been exposed to an affected person. One new element of contact tracing is Exposure Notifications: using privacy-preserving digital technology to tell someone they may have been exposed to the virus. Exposure Notification has the specific goal of rapid notification, which is especially important to slowing the spread of the disease with a virus that can be spread asymptomatically.
To help, Apple and Google cooperated to build Exposure Notifications technology that will enable apps created by public health agencies to work more accurately, reliably and effectively across both Android phones and iPhones. Over the last several weeks, our two companies have worked together, reaching out to public health officials scientists, privacy groups and government leaders all over the world to get their input and guidance.
Starting today, our Exposure Notifications technology is available to public health agencies on both iOS and Android. What we’ve built is not an app — rather public health agencies will incorporate the API into their own apps that people install. Our technology is designed to make these apps work better. Each user gets to decide whether or not to opt-in to Exposure Notifications; the system does not collect or use location from the device; and if a person is diagnosed with COVID-19, it is up to them whether or not to report that in the public health app. User adoption is key to success and we believe that these strong privacy protections are also the best way to encourage use of these apps.
Today, this technology is in the hands of public health agencies across the world who will take the lead and we will continue to support their efforts.
The companies previously announced plans to make Exposure Notification a system-level feature in a later update to both their respective mobile operating systems, to be released sometime later this year. That ‘Phase two’ portion of the strategy might be under revision, however, as Google and Apple said they continue to be in conversation with public health authorities about what system-level features will be useful to them in development of their COVID-19 mitigation strategies.
A major question mark attached to national coronavirus contact-tracing apps is whether they will function when citizens of one country travel to another. Or will people be asked to download and use multiple apps if they’re traveling across borders?
Having to use multiple apps when travelling would further complicate an unproven technology which seeks to repurpose standard smartphone components for estimating viral exposure — a task for which our mobile devices were never intended.
In Europe, where a number of countries are working on smartphone apps that use Bluetooth radios to try to automate some contact tracing by detecting device proximity, the interoperability challenge is particularly pressing, given the region is criss-crossed with borders. Although, in normal times, European Union citizens can all but forget they exist thanks to agreements intended to facilitate the free movement of EU people in the Schengen Area.
Currently, with many EU countries still in degrees of lockdown, there’s relatively little cross-border travel going on. But the European Commission has been focusing attention on supporting the tourism sector during the coronavirus crisis — proposing a tourism and transport package this week which sets out recommendations for a gradual and phased lifting of restrictions.
Once Europeans start traveling again, the effectiveness of any national contact-tracing apps could be undermined if systems aren’t able to talk to each other. In the EU, this could mean, for example, a French citizen who travels to Germany for a business trip — where they spend time with a person who subsequently tests positive for COVID — may not be warned of the exposure risk. Or indeed, vice versa.
In the U.K., which remains an EU member until the end of this year (during the Brexit transition period), the issue is even more pressing — given Ireland’s decision to opt for a decentralized app architecture for its national app. Over the land border in Northern Ireland, which is part of the U.K., the national app would presumably be the centralized system that’s being devised by the U.K.’s NHSX. And the NHSX’s CEO has admitted this technical division presents a specific challenge for the NHS COVID-19 app.
There are much broader questions over how useful (or useless) digital contact tracing will prove to be in the fight against the coronavirus. But it’s clear that if such apps don’t interoperate smoothly in a multi-country region such as Europe, there will be additional, unhelpful gaps opening up in the data.
Any lack of cross-border interoperability will, inexorably, undermine functionality — unless people give up travelling outside their own countries for good.
EU Member States recognize this, and this week agreed to a set of interoperability guidelines for national apps — writing that: “Users should be able to rely on a single app independently of the region or Member State they are in at a certain moment.”
The full technical detail of interoperability is yet to be figured out — “to ensure the operationalisation of interoperability as soon as possible,” as they put it.
But the intent is to work together so that different apps can share a minimum of data to enable exposure notifications to keep flowing as Europeans travel around the region, as (or once) restrictions are lifted.
“Whatever the approach taken with approved apps, all Member States and the Commission consider that interoperability between these apps and between backend systems is essential for these tools to enable the tracing of cross-border infection chains,” they write. “This is particularly important for cross-border workers and neighbouring countries. Ultimately, this effort will support the gradual lifting of border controls within the EU and the restoration of freedom of movement. These tools should be integrated with other tools contemplated in the COVID-19 contact-tracing strategy of each Member State.”
European users should be able to expect interoperability. But whether smooth cross-border working will happen in practice remains a major question mark. Getting multiple different health systems and apps that might be calculating risk exposure in slightly different ways to interface and share the relevant bits of data in a secure way is itself a major operational and technical challenge.
However, this is made even more of a headache given ongoing differences between countries over the core choice of app architecture for their national coronavirus contact tracing.
This boils down to a choice of either a decentralized or centralized approach — with decentralized protocols storing and processing data locally on smartphones (i.e. the matching is done on-device); and centralized protocols that upload exposure data and perform matching on a central server which is controlled by a national authority, such as a health service.
While there looks to be clear paths for interoperability between different decentralized protocols — here, for example, is a detailed discussion document written by backers of different decentralized protocols on how proximity tracing systems might interoperate across regions — interoperability between decentralized and centralized protocols, which are really polar opposite approaches, looks difficult and messy to say the least.
And that’s a big problem if we want digital contact tracing to smoothly take place across borders.
(Additionally, some might say that if Europe can’t agree on a common way forward vis-à-vis a threat that affects all the region’s citizens, it does not reflect well on the wider “European project”; aka the Union to which many of the region’s countries belong. But health is a Member State competence, meaning the Commission has limited powers in this area.)
In the eHealth Network “Interoperability guidelines” document, Member States agree that interoperability should happen regardless of which app architecture a European country has chosen.
But a section on cross-border transmission chains can’t see a way forward on how exactly to do that yet [emphasis ours] — i.e. beyond general talk of the need for “trusted and secure” mechanisms:
Solutions should allow Member States’ servers to communicate and receive relevant keys between themselves using a trusted and secure mechanism.
Roaming users should upload their relevant proximity encounter information to the home country backend. The other Member State(s) should be informed about possible infected or exposed users*.
*For roaming users, the question of to which servers the relevant proximity contacts details should be sent will be further explored during technical discussions. Interoperability questions will also be explored in relation to how a users’ app should behave after confirmed as COVID-19 positive and the possible need for a confirmation of infection free.
Conversely, the 19 academics behind the proposal for interoperability of different decentralized contact-tracing protocols do include a section at the end of the document discussing how, in theory, such systems could plug into “alternatives”: aka centralized systems.
But it’s thick with privacy caveats.
The academics warn that while interoperability between decentralized and centralized systems “is possible in principle, it introduces substantial privacy concerns” — writing that, on the one hand, decentralized systems have been designed specifically to avoid the ability of an central authority being able to recover the identity of users; and “consequently, centralized risk calculation cannot be used without severely weakening the privacy of users of the decentralized system.”
While, on the other, if decentralized risk calculation is used as the “bridge” to achieve interoperability between the two philosophically opposed approaches — by having centralized systems “publish a list of all decentralized ephemeral identifiers it believes to be at risk of infection due to close proximity with positive-tested users of the centralized system” — then it would make it easier for attackers to target centralized systems with reidentification attacks of any positive-tested users. So, again, you get additional privacy risks.
“In particular, each user of the decentralized system would be able to recover the exact time and place they were exposed to the positive-tested individual by comparing their list of recorded ephemeral identifiers which they emitted with the list of ephemeral identifiers published by the server,” they write, specifying that the attack would reveal in which “15-minute” period an app user was exposed to a COVID-positive person.
And while they concede there’s a similar risk of reidentification attacks against all forms of decentralized systems, they contend this is more limited — given that decentralized protocol design is being used to mitigate this risk “by only recording coarse timing information,” such as six-hour intervals.
So, basically, the argument is there’s a greater chance that you might only encounter one other person in a 15-minute interval (and therefore could easily guess who might have given you COVID) versus a six-hour window. Albeit, with populations likely to continue to be encouraged to stay at home as much as possible for the foreseeable future, there is still a chance a user of a decentralized system might only pass one other person over a larger time interval too.
As trade-offs go, the argument made by backers of decentralized systems is they’re inherently focused on the risks of reidentification — and actively working on ways to mitigate and limit those risks by system design — whereas centralized systems gloss over that risk entirely by assuming trust in a central authority to properly handle and process device-linked personal data. Which is of course a very big assumption.
While such fine-grained details may seem incredibly technical for the average user to need to digest, the core associated concern for coronavirus apps generally — and interoperability specifically — is that users need to be able to trust apps to use them.
So even if a person trusts their own government to handle their sensitive health data, they may be less inclined to trust another country’s government. Which means there could be some risk that centralized systems operating within a multi-country region such as Europe might end up polluting the “trust well” for these apps more generally — depending on exactly how they’re made to interoperate with decentralized systems.
The latter are designed so users don’t have to trust an authority to oversee their personal data. The former are absolutely not. So it’s really chalk and cheese.
At this point, momentum among EU nations has largely shifted behind decentralized protocols for coronavirus contact-tracing apps. As previously reported, there has been a major battle between different EU groups supporting opposing approaches. And — in a key shift — privacy concerns over centralized systems being associated with governmental “mission creep” and/or a lack of citizen trust appear to have encouraged Germany to flip to a decentralized model.
Apple and Google’s decision to support decentralized systems for the contact-tracing API they’re jointly developing, and due to release later this month (sample code is out already), has also undoubtedly weighted the debate in favor of decentralized protocols.
Not all EU countries are aligned at this stage, though. Most notably France remains determined to pursue a centralized system for coronavirus contact tracing.
As noted above, the U.K. has also been building an app that’s designed to upload data to a central server. Although it’s reportedly investigating switching to a decentralized model in order to be able to plug into the Apple and Google API — given technical challenges on iOS associated with background Bluetooth access.
Another outlier is Norway — which has already launched a centralized app (which also collects GPS data — against Commission and Member States’ own recommendations that tracing apps should not harvest location data).
High-level pressure is clearly being applied, behind the scenes and in public, for EU Member States to agree on a common approach for coronavirus contact-tracing apps. The Commission has been urging this for weeks. Even as French government ministers have preferred to talk in public about the issue as a matter of technological sovereignty — arguing national governments should not have their health policy decisions dictated to them by U.S. tech giants.
“It is for States to chose their architecture and requests were made to Apple to enable both [centralized and decentralized systems],” a French government spokesperson told us late last month.
While there may well be considerable sympathy with that point of view in Europe, there’s also plenty of pragmatism on display. And, sure, some irony — given the region markets itself regionally and globally as a champion of privacy standards. (No shortage of op-eds have been penned in recent weeks on the strange sight of tech giants seemingly schooling EU governments over privacy; while veteran EU privacy advocates have laughed nervously to find themselves fighting in the same camp as data-mining giant Google.)
Commission EVP Margrethe Vestager could also be heard on BBC radio this week suggesting she wouldn’t personally use a coronavirus contact-tracing app that wasn’t built atop a decentralized app architecture. Though the Brexit-focused U.K. government is unlikely to have an open ear for the views of Commission officials, even piped through establishment radio news channels.
The U.K. may be forced to listen to technological reality though, if its workaround for iOS Bluetooth background access proves as flakey as analysis suggests. And it’s telling that the NHSX is funding parallel work on an app that could plug into the Apple-Google API, per reports in the FT, which would mean abandoning the centralized architecture.
Which leaves France as the highest-profile hold-out.
In recent weeks a team at Inria, the government research agency that’s been working on its centralized ROBERT coronavirus contacts-tracing protocol, proposed a third way for exposure notifications — called DESIRE — which was billed as an evolution of the approach “leveraging the best of centralized and decentralized systems.”
The new idea is to add a new secret cryptographically generated key to the protocol, called Private Encounter Tokens (PETs), which would encode encounters between users — as a way to provide users with more control over which identifiers they disclose to a central server, and thereby avoid the system harvesting social graph data.
“The role of the server is merely to match PETs generated by diagnosed users with the PETs provided by requesting users. It stores minimal pseudonymous data. Finally, all data that are stored on the server are encrypted using keys that are stored on the mobile devices, protecting against data breach on the server. All these modifications improve the privacy of the scheme against malicious users and authority. However, as in the first version of ROBERT, risk scores and notifications are still managed and controlled by the server of the health authority, which provides high robustness, flexibility, and efficacy,” the Inria team wrote in the proposal.
The DP-3T consortium, backers of an eponymous decentralized protocol that’s gained widespread backing from governments in Europe — including Germany’s, followed up with a “practical assessment” of Inria’s proposal — in which they suggest the concept makes for “a very interesting academic proposal, but not a practical solution”; given limitations in current mobile phone Bluetooth radios and, more generally, questions around scalability and feasibility. (tl;dr this sort of idea could take years to properly implement and the coronavirus crisis hardly involves the luxury of time.)
The DP-3T analysis is also heavily skeptical that DESIRE could be made to interoperate with either existing centralized or decentralized proposals — suggesting a sort of “worst of both worlds” scenario on the cross-border functionality front. So, er…
One person familiar with EU Member States’ discussions about coronavirus-tracing apps and interoperability, who briefed TechCrunch on condition of anonymity, also suggested the DESIRE proposal would not fly given its relative complexity (versus the pressing need to get apps launched soon if they are to be of any use in the current pandemic). This person also pointed to question marks over required bandwidth and impact on device battery life. For DESIRE to work they suggested it would need universal uptake by all Europe’s governments — and every EU nation agreeing to adopt a French proposal would hardly carry the torch for nation state sovereignty.
What France does with its tracing app remains a key unanswered question. (An earlier planned debate on the issue in its parliament was shelved.) It is a major EU economy and, where interoperability is concerned, simple geography makes it a vital piece of the Western European digital puzzle, given it has land borders (and train links into) a large number of other countries.
We reached out to the French government with questions about how it proposes to make its national coronavirus contact-tracing app interoperable with decentralized apps that are being developed elsewhere across the EU — but at the time of writing it had not responded to our email.
This week in a video interview with BFM Business, the president of Inria, Bruno Sportisse, was reported to have expressed hope that the app will be able to interoperate by June — but also said in an interview that if the project is unsuccessful “we will stop it.”
“We’re working on making those protocols interoperable. So it’s not something that is going to be done in a week or two,” Sportisse also told BFM (translated from French by TechCrunch’s Romain Dillet). “First, every country has to develop its own application. That’s what every country is doing with its own set of challenges to solve. But at the same time we’re working on it, and in particular as part of an initiative coordinated by the European Commission to make those protocols interoperable or to define new ones.”
One thing looks clear: Adding more complexity further raises the bar for interoperability. And development time frames are necessarily tight.
The pressing imperatives of a pandemic crisis also makes talk of technological sovereignty sound a bit of, well, a bourgeois indulgence. So France’s ambition to single-handedly define a whole new protocol for every nation in Europe comes across as simultaneously tone-deaf and flat-footed — perhaps especially in light if Germany’s swift U-turn the other way.
In a pinch and a poke, European governments agreeing to coalesce around a common approach — and accepting a quick, universal API fix which is being made available at the smartphone platform level — would also offer a far clearer message to citizens. Which would likely help engender citizen trust in and adoption of national apps — that would, in turn, give the apps a greater chance of utility. A pan-EU common approach might also feed tracing apps’ utility by yielding fewer gaps in the data. The benefits could be big.
However, for now, Europe’s digital response to the coronavirus crisis looks messier than that — with ongoing wrinkles and questions over how smoothly different nationals apps will be able to work together as countries opt to go their own way.