The Dark Side of SwissCovid


"Ich chume nöd drus mit dem Zügs."
("Je ne comprends pas ce truc.")
(Ueli Maurer - member of the Swiss Federal Council - 4.7.2020)
(impossible to translate)


We followed the evolution of SwissCovid and did our own analysis on it. Lots of consensual opinions have already been expressed. We wish here to present an alternative viewpoint about SwissCovid. Our position on SwissCovid is that

The privacy-by-design and transparency claims are smoke screens. Although it is important that we all protect ourselves and others with such tools, we should not deceive ourselves with unsatisfied promises.

Here is a short summary (in French) written on 24.1.2021.

Content.

What's new? A new paper about the usefulness of the British SwissCovid sibling was added in the Usefulness section.

Disclaimer: We are strong advocates of transparency and objectivity in scientific communication. We reckon that the pandemic has made tools such as proximity tracing (sadly) unavoidable. We respect the political decision to deploy it. The political decision took the way of a voluntary acceptance, which requires trust to be effective. We do not believe in a conspiracy. We have no doubt all involved people, organizations, and companies are in good wills and did their restless best to fight the pandemic. At the same time, we know that the road to hell is paved with good intentions. It has been claimed many times that data is anonymous, that there is no threat, that the app is transparent because of being open source by law, that people should not be scared, that fear is irrational, that communication is monopolized by conspiracy theories. By trying to communicate over-simplified information and giving paternalistic advises for adopting SwissCovid, SwissCovid has failed to be transparent. By failing in providing fair information, by adopting an opaque proprietary solution, and by bypassing the law, we feel that trust is broken. We believe that showing all these facts is helping to support transparency. We do not think open information would affect the acceptance by people because contact tracing is a necessity. People who support SwissCovid will continue to support and skeptical people will be confirmed in their skepticism. We think people deserve to know facts.

Disclaimer 2: The content of this page does not reflect the position of EPFL. EPFL, by the voice of its president, states that SwissCovid is "super-smart", reaches "the highest possible standard on what we can do now today", "influences our Californian friends", but that "Swiss people have difficulties to be proud of what they do" (translated).

Prologue

SwissCovid is based on the DP3T project. DP3T was announced on April 1, 2020 (as part of the bigger project PEPP-PT). Our early analysis of DP3T was published on April 8: It is worth saying that this report was originally meant to be read by the designers of DP3T only, but that they suggested to make it public. This is why it is available there.

In early April, a fight occurred between developers of centralized and decentralized systems, within the PEPP-PT project, with the conquest of countries for the adoption of one or the other system in background. DP3T, which was developing a decentralized system, split from PEPP-PT and won the battle. We reckon that

However, arguments against centralized systems have been overly exaggerated and the ones in favor of decentralized systems have been oversold to a level that we found unethical (at least, against the objectivity rules of scientific communication). We do not think that one approach protects privacy better than the other. Furthermore, other ways have not been investigated enough.

Since all these was also clear for policy makers, we can wonder why decentralized systems succeeded to conquer most of European countries. This is most likely due to the heavy support of Apple and Google. It is known (with the previous experience of Singapore) that access to Bluetooth can drain the battery of the phone quite a lot. Apple and Google announced that they would provide an optimized access to Bluetooth to decentralized contact tracing apps only but would keep on restricting it to other applications.

Our study about centralized versus decentralized systems, as well as directions for a 3rd way, was published on May 6, 2020:

In parallel, we worked with colleagues from France to explain in an as non-technical manner as possible, the risks which eventually come with any automated contact tracing. Our article is available in French (English version available from the link) on April 21, 2020:

Own Analysis

Before the deployment of SwissCovid, there has been a test phase for a pilot version. As tester of the pilot version, we were required to report on our findings. We posted our report on June 5, 2020. However, the report was held under a responsible disclosure clause until June 16, during which the law on SwissCovid was discussed and approved. Meanwhile, our report has been heavily criticized, although we could not even publish it. The link below tells the story of our report and describes the compliance issue. It also gives links to the documents. In summary, our report shows that Our compliance analysis concludes that

Apple & Google

Our main concern about SwissCovid is that the app is outsourcing nearly all its tasks to the Apple-Google implementation called GAEN (as for Google Apple Exposure Notification) and that GAEN is out of public or national control: there is no source code nor any way to verify how it works. As discussed in the above document, this is not compliant with the spirit of the law. We tried to reconstruct the chronology which ended up in this state of affair: Meanwhile, there are bugs in GAEN. They are not easy to find because of no source code. For instance, rolling the ephemeral identifiers and the visible random addresses they look to come from is supposed to be done synchronously. However, we noticed it is not: there is always one broadcast with the new address and the old identifier. This leads to the easy Little Thumb attack to link identifiers. We also noticed that, in some phones, the Bluetooth stack crashes silently and SwissCovid is sending identifiers but collecting none. The user would wrongly believe to be protected by the app.

What Google and Apple do with the data collected by Bluetooth is also out of control. Finally, the resulting difference between centralized and decentralized systems is that, on the former case, data is stored in a central server which is maintained by local authorities, while in the latter case, data is stored in a distributed server (the GAEN memory of the phones) which is maintained by Apple and Google. In the former case, trust is based on a democratic system. In the latter case, trust is based on a commercial system.

France had a controvery about StopCovid - the French app which relies on a centralized system - storing more information than what is necessary. Contact tracing indeed aims at storing only contacts which last long enough and at a close distance (in Switzerland: less than 1.5m during 15 minutes). It was shown that StopCovid was actually sending all contacts (either brief or distant ones) to the central server. A similar controversy could occur in Switzerland: GAEN actually stores all contacts. They are stored locally on the phone, in this distributed decentralized server. However, since there is no control about what Apple and Google are doing with those stored contacts, the same controversy is possible. Apparently, this problem was fixed in France. It is unlikely it will be in Switzerland as it depends on GAEN.

Apple and Google could further abuse their dominant position to have their parallel contact tracing system, in order to identify people who had any contact (long or not, at distance or not) with a targetted category of people. This category would not necessarily be the category of diagnosed people. For instance, it could be the category of people who used a given commercial product. Identifying the contacts of users of a product could be a good target for advertisement. If maliciously used, GAEN could become a gold mine for Apple and Google.

ENE actually strengthens the dominant position of Apple and Google. Citizens have no longer anything to say about it except taking it as a whole or refusing it. This is a major loss of government's digital sovereignty. So far, there is no plan in switching from SwissCovid to ENE, but we cannot predict what Apple and Google will impose next.

How it Works

The app and GAEN. SwissCovid devices permanently broadcast an ephemeral identifier which changes every 10-12 minutes. They are called RPI as for Rolling Proximity Identifier. Every ephemeral identifier is derived from a daily key which is selected at random. This daily key is called TEK as for Temporary Exposure Key. Given the ephemeral identifier, we cannot recover the daily key. However, given the TEK, we can recover all RPI of the day. As specified in the Apple/Google specifications, GAEN is We will see below that GAEN plays two more roles.

If a user is diagnosed, his app gets the daily keys of the last few days from GAEN and uploads them on a public server. Those uploaded TEKs are called the Diagnosis Keys.

This server can be observed by anyone. Apps regularly download the diagnosis keys and give them to GAEN. GAEN checks if those keys derive one of the collected ephemeral identifiers RPI, to check if a diagnosed user was in contact. GAEN reports the contacts with diagnosed users with information about the date, the duration, and the distance to the app. The app decides to raise a notification or not.

SwissCovid Principle
SwissCovid Principle:
    (1) phones (GAEN) generate daily keys, derive and exchange ephemeral identifiers; (2) Alice gets diagnosed; (3) Alice's app gets the keys making identifiers she used from GAEN and reports to the server; (4) Bob's app downloads the reported keys, GAEN compares with the collected identifiers, and reports matchings to the app; (5) Bob's app decides to raise a notification.

To estimate the distance of a contact, phones compare the power of the Bluetooth signal when being sent and when being received. However, the power of the sending signal is encrypted (using the daily key) inside the Bluetooth message. Consequently, it is not visible by the receiving phone until it obtains the daily key of the sender (because he was diagnosed and reported). Hence, it is only at the time of the comparison that the distance can be estimated.

Similarly, the ephemeral identifiers are rolling every 10-12 minutes. Normally, a receiver cannot link two identifiers until it receives the daily key which derived them. Hence, the duration of a contact (and that it was at least 15-minute long) can only be determined at the time of the comparison.

The server. The "server" is actually an infrastructure of several servers within a network. The app regularly downloads reports from the server and also the configuration parameters to be used to calculate the at-risk notification. Both types of downloads are supposed to be done by millions of devices every day. To provide the download service reliably, SwissCovid uses a Content Delivery Network (CDN) which is provided by Amazon. When we try to download from anywhere in the world, it is a local Amazon server which responds. The content is obtained from the servers of Swiss Federal offices and signed by them so that Amazon cannot tamper with the content.

The "server" also includes another site where to upload daily keys after diagnosis. As this operation is (hopefully) rare, there is no need for a third party service for this operation. Essentially, a diagnosed user is in contact with the public health authorities which give them an access code, called covidcode, of 12 decimal digits. With this 12 decimal digit, the app gets from another server another code (namely, a JWT code) which allows the app to upload the daily keys on the server.

One problem is that the network sees all requests to the server made by the app and can possibly identify the phone. One trick to protect privacy is to make "fake" queries once a while at random. Queries are encrypted, so the network cannot see if they are fake or real.

What the app is doing. We can list the roles of the app below.

Except for the decision to notify, the app is not processing any data. It is only passing information between the GAEN, the servers, and the user.

Effectiveness

Regarding the ability of SwissCovid to capture close-enough and long-enough encounters, we can just observe that it is a controversial topic. (We can see discussions here and there.) Lots of tests were made during the design of SwissCovid. We have not seen any result about it. However, some independent project observed on June 26 that capturing those encounters does not work in a tram. Like other results in this field, this result has not been confirmed or denied by peers. However, we can see that the radius for contact detection in SwissCovid was increased on July 6, as explained in the following article. It was increased again on September 11 as explained by FOPH. Increasing this distance has no impact on the previous computation which assumed that encounters are always captured. However, it may increase the number of false at-risk notifications which we do not know, and henceforth the number of quarantines. A document from FOPH explains the impact on those parameters in exposure notification. There, we can read that in a lab experiment, the probability that SwissCovid thinks of a close proximity (attenuation less than 55dB) when the distance is 1.5m is 57.3%. When the distance is 3m, this probability becomes 45.6%. So, the difference it makes between 1.5m and 3m is tiny.

Usefulness

To know if SwissCovid is useful at all, we should wonder how many people satisfy all following criteria: In any other case, either SwissCovid does not notify, or the notification is not taken into account, or it was a false alarm, or it was not telling any new information. Those cases can only be measured by appropriate surveys from the health authorities. It is not available at the moment. Hence, we shall look at other metrics.

The usefulness of SwissCovid can be analyzed with several factors. First of all, FOPH reports to FSO an estimate for the number of "SwissCovid activations" per day as well as the number of entered covidcodes, a number of downloads, and the number of people who made a phone call to the infoline after having received an alert from SwissCovid. FOPH also reports the number of COVID-positive cases in Switzerland.

Second, we can compare the number of reported keys to the server and the official number of diagnosed cases in Switzerland. The site below is comparing the data we obtain from several countries which use GAEN-based contact tracing. We should keep in mind that a diagnosed user typically reports keys for the previous few days. We should also be careful that FOPH was inserting 10 fake keys every day to "exercise" the software until July 17 (when they realized this was introducing a vulneraility in the system). We could see that since end of September, Switzerland is the only country (together with Spain and Guam) not to report statistics during weekends.

The estimate for the "number of activations" was changed on July 23. Before July 23, it was estimated based on the number of requests to the server to retrieve the configuration parameters. In the source code, we can see that the app is configured to make such query every 6 hours. FOPH has no means to figure out if two different queries come from the same app (otherwise, it would be a violation of the design principles). Actually, the queries are not directly visible by FOPH as FOPH is outsourcing the reception and treatment of those queries to Amazon. Hence, the "number of daily activations" was simply the total number of queries (provided by Amazon) divided by 4 (because always running apps makes queries 4 times per day). However, this rather indicates an average number of queries. For instance, 1 million of activations could be an average number between 500'000 nightly activations and 1.5 million daily activations. Someone who was activating his app for only one minute every 6 hours was counted as a full activation although someone who was activating his app only when useful (e.g. when taking public transport or at the restaurant) was counted as a fraction of activation. However, the second user was clearly making an effective use of the app compared to the first who was not using it at all. Hence, the figures provided by FOPH was probably underestimating the effective number of active users.

number of activations number of activations
Number of activations (old system) Number of activations (new system)

Since July 23, the "number of activations" is estimated based on a new system: the number of fake reports that the app submits at random (to hide from the network when it is really submitting a report). In the source code, we can see that the next fake report is scheduled after a random duration which follows an exponential probability distribution with an average of 5 days. Hence, FOPH essentially multiplies the daily number of received fake reports by 5. This is a probabilistic estimate which has a standard deviation of about 3000 (the square root of 5 times the number of apps). Hence, this number is rounded with a 10'000 precision to be significant. With this method, an app which is activated a few seconds every day is fully counted (as its scheduled fake report may be sent during these few seconds and another fake report can be scheduled). Hence, the "number of activations" estimates the number of apps which have been activated at least once during the day, which is the number of effective users. If users do not always have their app turned on precisely when this is useful, this number may be over-estimated. The number may also have a few days delay to reflect the reality: if the number of users changes a lot today, it may take a few days to observe it on the estimate. Here is the evolution of the number of activations. (Average over a 7-day rolling period.) We can see in the plot that it reached a cruising altitude and that the number of activations is quite stable. It was actually stable until January 15 when a big unexplained increase of 25% in two days was observed for no reason (it went from 1'840'000 on January 12 to 2'290'000 on January 14 then down to 1'990'000 on January 16; the above curve is a bit smoothened due to the 7-day rolling period). The way to count following this new system was suspended on January 19.

We however stress that this number of activations is based on the received queries but nothing proves that they were made by a SwissCovid app. Indeed, anyone could buy several millions of malicious queries from a botnet on the darknet to maliciously inflate this number. (This would be illegal.)

Another interesting measure of usefulness is based on the number of reports from diagnosed users. This corresponds to the number of entered covidcodes. If, during a given period, we have a total of r reports of diagnosed users for c positive diagnoses, we can deduce the probability rc for a random diagnosed person to be a willing-to-report SwissCovid user. We represent below the obtained ratio by using the official figures.

ratio entered covidcodes over number of diagnosed cases
The goal of SwissCovid is to notify a (possibly contaminated) person who encountered close enough and long enough (in an epidemiologically relevant sense) a (possibly contagious) person who was diagnosed. When this event happens, the probability that SwissCovid succeeds to notify the possibly contaminated person is the probability that all what follows occurred:
  1. the contaminating person uses SwissCovid and is willing to report using SwissCovid after diagnosis;
  2. the contaminated person is an active SwissCovid user;
  3. both had their SwissCovid active when they encountered;
  4. SwissCovid succeeded to notice their encounter.
We take the most favorable case assuming that the last two conditions always occur. (The last one will be discussed hereafter.) We assume that both participants are uniformly distributed and independent. The first condition occurs with the probability rc from the plot, which is between 9% and 18%. The second condition occurs with probability up, where u is the number of active SwissCovid users and p is the total population. We can approximate it to 21% based on the recent figures from FOPH. (u=1'800'000 and p=8'600'000.) Hence, if the app catches encounters with 100% reliability, the probability that SwissCovid spots this infecting contact can be approximated to This approximation assumes ideal probability distributions and that the Bluetooth measurement works perfectly. We obtain e=3% with most favorable figures. This is probably the order of magnitude of the probability for SwissCovid to spot an infecting contact. The computation is however very imprecise due to the assumptions.

The next interesting question is whether SwissCovid, which spots an infecting contact, is able to alert infected people before a human-based contact tracing does. Indeed, in between the time the infecting person is diagnosed, the time he reports (he has 24h for that), and the time the infected person's app downloads the new report (which can take a few more hours), the traditional contact tracing may be done. Most likely, SwissCovid is only useful when the contaminated person is completely unknown by the contaminating person, e.g. in the case they encountered in public transportation or they were seated close to each other in a restaurant.

Although FOPH communicates the number of entered covidcodes, the SwissCovid design does not directly reveals how many at-risk notifications were raised and how many of them led to a diagnosis case. However, users receiving a notification may call a infoline, as recommended by the app. Statistics through the infoline is feasible. We plot below the number of cases, the number of entered covidcodes, and the number of calls to the infoline. There is no scale on purpose. This way, we clearly see that the curves follow each other (until mid-December for the number of calls).

number of COVID-19 positive cases number of entered covidcodes number of calls to infoline
Number of cases Number of covidcodes Number of calls
We observe an artefact in the number of calls in the end of 2020. Since mid-December 2020, SwissCovid alerts no longer recommend to call the infoline but rather to go though an online questionaire on the foph-coronavirus.ch web site. While reducing the workload of the infoline, this opens new privacy issues. It affects the count. The way the number of online forms are counted as a number of calls is not documented at the moment.

The August 28 press conference. Interesting figures were announced by FOPH: since July 20, 13 people did a test after being notified by SwissCovid and this test revealed positive. We do not know if this was helpful to prevent them from contaminating other people. However, we can see that 13 positive cases out of 7483 (in this period) are spotted by SwissCovid. This is 0.17% of all positive cases. Those 13 cases are also to be compared to 857 entered covidcodes in this period. Hence, 1.5% of entered covidcodes generate a useful notification. It is argued by SwissCovid promoters that those numbers can only increase with the adoption of SwissCovid. It is actually weird that this number 13 is the only figure from FOPH which is not given over the period of the last 7 days. The same press conference also reveals that "over the last 7 days", 250 covidcodes were entered (for 350 generated covidcodes, for actually 800 SwissCovid users who were tested positive). By entering those codes, among the notifications to other users they generated, 150 contacted the infoline. How to compare the above 13 cases since July 20 and the 150 infoline contacts over the last 7 days? If we estimate that about 700 people contacted the infoline for the same reason since July 20 and that they include the 13 cases, this means that SwissCovid generates a population of people calling the infoline less than 2% of among whom are useful to identify. Contrarily to the above computation, there is no reason to believe that this fraction can increase with adoption. In comparison, the fraction of positive tests among all the tests being done in Switzerland was around 3.2%. It is now around 15-20% at this time while the 2% from SwissCovid did not increase. Hence, SwissCovid is clearly underperforming.

Early Evidence of Effectiveness of Digital Contact Tracing for SARS-CoV-2 in Switzerland. A paper posted on September 4 gives other information. This paper (which was subsequently formally published here) is cowritten by 20 scientists which are mostly from EPFL, but also from FOPH and several Swiss universities. Besides, eight of the coauthors are members of the Swiss National COVID-19 Science Task Force. Hence, this paper is likely to be the mainstream supporting argument of SwissCovid. The original paper was revised on September 19 by giving new figures. Below, we give the table of both figures (and the number H from the August 28 press conference) but we comment only on the latest ones.
A B C D E F G H I J K L M N O P
28.8.2020 13
4.9.2020 8522 1593 1054 874 5491 4426 331 26 37 7.Aug-28.Aug.20 96 53 48 82 60 23
19.9.2020 12'456 2447 1645 1695 7842 6380 487 41 65 7.Aug-11.Sept.20 235 148 127 185 132 46
The figures given by this paper are as follows.

The paper derives a smart formula epsilon=n/(c.mu) to measure the effectiveness of SwissCovid, where n=65 (I) (the adjusted number of people who get positively tested because of SwissCovid), c=1645 (C) (the number of entered covidcodes), and mu=16.7% (the proportion of active users in Switzerland). They obtain epsilon=24% which is comparable to the similar value obtained in known studies about the efficiency of contact tracing (which obtained 23% and 38%). The conclusion of this paper is that SwissCovid is "an effective complementary tool for controlling the spread of SARS-CoV-2". It is a bit strange that such epsilon suffices to reach this conclusion as we could easily make an app reaching a much higher epsilon: just make an app doing nothing but alerting all users. We would obtain n as high as 2447 (B) with the same c and mu so epsilon=891%... (As a matter of fact, this epsilon is not a percentage.) We could also alert all users at random with a fixed probability to obtain the epsilon that we want. What this analysis is missing is the ability to spot positive cases without making too many false alerts. All evaluations on medical tests report such analysis and comparison with a placebo but SwissCovid. Finally, this paper lacks of verifiable results and critical self-analysis on the relevance of the results. The adjective "early" in the title "Early evidence" rather means "pseudo-scientific". We wonder whether such a biased paper, cowritten by 20 renowned experts, serves science well.

The contribution of the SwissCovid digital proximity tracing app to pandemic mitigation in the Canton of Zurich. On October 29, a new paper was posted. It is mentioned as an "in progress" document (v1.5 on October 29) in which a single author is mentioned as a "corresponding author". This author is a co-author of the previous paper and also member of the national COVID-19 science task force. Although this new report provides more precise figures and computations, by focusing on the Canton of Zurich, it was again written in a biased manner, with a clear objective to reach a pre-written conclusion: that SwissCovid is useful and that more people should use it. As usual, the release of this report was synchronized with the release of articles in the press (like in Le Temps).

A subsequent paper appeared on February 2. It revisits the figures over the same period in the same population, but also applies a similar study over the two halves of October 2020 and for the entire country. We keep below the numbers of the original report. However, we give in the table the new numbers.

The report ignores the comments which were mentioned above and uses the number of tests which were done with SwissCovid as a reason in the same way. It provides new figures for the Canton of Zurich during September 2020 (J): 1715 (A) cases, 429 (B) of which being SwissCovid users, 344 (C) entered covidcodes, 756 (D) calls to infoline, and 30 (H) cases with a SwissCovid alert as a reason to be tested. Contrarily to the previous paper in which numbers are real counts, most of these numbers are estimates following one or two methods. The value H is obtained in the same way as in the previous paper, as provided by FOPH, and confirmed by multiplying a total of 1715 cases by a percentage 1.9% coming from a "Zurich Sars-CoV-2 Cohort Study". It is not clear at all where this 1.9% is coming from, but given that it may comes from the health authority of the Canton of Zurich, who gave the data to FOPH, the source of the data is likely to be the same in both computations. The canton has a population of 1.54 Million (T).
A B C D H J Q R S T
29.10.2020 1715 429 344 756 30 1-30.Sept.20 (ZH) 1418 166 3000 1'540'000
3.2.2021 1923 537 324 722 30 1-30.Sept.20 (ZH) 1374 170 1'540'000
3.2.2021 3736 1042 422 1289 67 1-15.Oct.20 (ZH) 2457 280 1'540'000
3.2.2021 13'185 3818 1426 3091 78 16-31.Oct.20 (ZH) 5886 711 1'540'000
3.2.2021 11'463 3205 1867 2430 67 1-30.Sept.20 4633 522 8'600'000
3.2.2021 22'555 6296 2916 3696 121 1-15.Oct.20 7020 733 8'600'000
3.2.2021 100'057 28'931 12'453 9889 180 16-31.Oct.20 18'708 2015 8'600'000

The new report makes interesting estimates for new numbers.

Since there were overall 3000 (S) quarantines in the entire canton for this period, the article concludes that R/S=5% of all quarantines are due to SwissCovid. We can however observe that the ratio of cases which - they claim - are found thanks to SwissCovid is H/A=1.75%. The ratio between those two percentages shows that SwissCovid creates nearly 3 times more quarantines than overall methods to find cases. The burden of this task is put on people working at the infoline and health authorities: there are 756 (D) calls for 30 (H) cases in the end. We can observe that SwissCovid identified a population of 1418 (Q) under-risk people in which only H/Q=2% became cases to credit to SwissCovid, although the ratio of positive tests among all performed tests in Switzerland is around 15-20% at the moment. Also, alerting 1418 (Q) people for 30 (H) cases has a social cost which looks high. The adoption of SwissCovid is often used as an excuse for underperformances. Actually, the report concludes that increasing the adoption rate would increase the contribution of SwissCovid. Although it is true that H would increase, we can observe that the above performance indicators, the contribution to quarantines over the contribution to find cases (3) and the ratio of found cases per alerted people (2%), are independent of the adoption rate. To be clear, a higher adoption rate would imply more discovered cases, but also more quarantines, more alerts, and more calls to infoline, in proportions which have a social cost.

Note that the figures for the second half of October 2020 in entire Switzerland give H/A=0.18% and H/Q=1%. This indicates that in a period when the number of cases is much higher, the proportional performance of SwissCovid is even lower. Clearly, the performance does not scale.

Digital proximity tracing app notifications lead to faster quarantine in non-household contacts: results from the Zurich SARS-CoV-2 Cohort Study. On December 23, a new paper was posted. This time, the Zurich cohort is analyzed for the speed to go to quarantine. The authors make interesting observations. Namely, for contact cases, the duration between exposure and the time to start quarantine has a distribution which depends on some factors. If we omit household contact cases, for whom the proximity is such that quarantine starts almost immediately, the median duration for people who were notified by SwissCovid within no more than 7 days is one day less than the median duration for people who were not (i.e. who were notified after 7 days, who were not notified, or who were not using the app). We quote below the conclusion:

We already note a semantic shift in "notified by the app" which omits the "within no more than 7 days" in order to facilitate the interpretation to the sense "using the app". There is further a classical mistake in the transition between the two sentences. Indeed, observing a correlation between "using the app" and a shorter time to quarantine implies by no mean a causality relation. If more people use the app, there is no guaranty that they will reach quarantine faster. Actually, this may simply indicate that people who made the genuine choice to use the app are more zealous to observe quarantine recommendations than others.

The paper was written by a member of the national COVID-19 science task force. Of course, this conclusion were even more overstated in public and in the press by other members of the task force. For instance here on slide 26, it is written "1 day faster notification" instead of "1 day faster to quarantine". There (written from this at 3:30), it is clearly stated that SwissCovid is faster than classical contact tracing and users receive the notification for exposure one day before, which is incorrect.

Is it picky to argue that "faster to quarantine" does not mean "faster notification"? Actually not. In the same paper, we can clearly read:

This is not a typo. We can verify the numbers in Table 3 on p.14. Hence, SwissCovid is faster to notify in only 12% of the cases where it succeeds to notify in no more than 7 days. We infer that in the remaining 88%, SwissCovid is slower. In the remaining cases where it fails to notify in no more than 7 days, it is most likely slower too. Hence, 9 out of 192 contact cases using the app (less than 5%) received a notification by SwissCovid faster than contact tracing. It simply means that SwissCovid is mostly slower than manual contact tracing. The 192 contact cases include household contacts. Hence, some of these 9 (most likely half of them) are household contacts. Probably the others had learned about their contact status before SwissCovid told them. They could have been in self-quarantine before the SwissCovid notification. Hence, it is highly likely that the speed to quarantine has no link with the SwissCovid notification at all. It is plausible that SwissCovid plays no role at all in the speed to quarantine. Again, a more plausible explanation to the observed correlation is that SwissCovid users are more proactive than others in following sanitary measures.

The problems in this paper are extensively discussed in

LotoCovid. An interesting idea is to design an app which would alert people at random, possibly using some biases but without using any exchanged information. This is a placebo app. Such app was ironically proposed on Twitter as LotoCovid by Gaëtan Leurent. If we alert 1418 (Q) people completely at random in Zurich, making them test would find A*Q/T=1.6 cases. This is twenty times lower than the score 30 (H) by SwissCovid but it is a much simpler app and infrastructure. Most likely, adding biases on the probability to alert (for instance, increasing the probability to clubers, to commuters, decreasing the probability to people living alone and teleworking) would certainly find many more cases by keeping the number of alerts the same. The performance of SwissCovid should seriously be compared to this trivial approach.

LotoCovid - Gaëtan Leurent

The epidemiological impact of the NHS COVID-19 App. Another paper launched another gust of public comments. The article was published in Nature on May 12, 2021 by authors who are mainly from the University of Oxford. It is about the British sibling of SwissCovid and proving its usefulness, so somehow related. The paper shows impressive numbers which are carefully selected and which are not reproducible so far. It is interesting to observe the public Hourra from colleagues who were working on SwissCovid, although it was nothing new for them since the preprint was released on February 9 and they already cited it many times. The only new event was the publication in Nature (which is indeed an achievement). Immediately, this success was self-creditted by EPFL. (See the public release.) The EPFL release starts relaying the impressive conclusion of the paper stating that "between 300'000 and 600'000 COVID-19 cases have been prevented in the UK alone thanks to the NHS COVID-19 app" during the 3-month period October-December 2020. Roughly, each entered covidcode avoided one case. These results are based on some hard-to-verify numbers and on the assumption that all notified app users who became diagnosed have been solely discovered by the app. Hence, notifying them would avert all cases of the infection chains they would start.

The paper actually presents figures in a different way than the Swiss ones. It reports 16.5 Millions of app users, which represents 28% of the population in England and Wales. 560'000 app users have been positively tested with COVID. Among those cases, 72% gave consent to report (i.e. they entered a covidcode). Each entered covidcode generates 4.4 notifications, on average. Overall, 1.7 Million app users have been notified. With manual contact tracing, each case generates 1.8 notifications by contact tracers, including 1.2 household contacts, on average. For notified contacts, the probability to have a positive test is of 6.9% for manual contact tracing and of 6.02% with the app. So, the number of positive contacts traced per consenting index case is respectively of 0.2 and 0.27. This makes the authors conclude that manual contact tracing and digital contact tracing have similar performances. The announced number of cases which have been prevented during this period is estimated using two different approaches which give 300'000 and 600'000, which is of same order of magnitude as the number of entered covidcodes. Henceforth, "each entered covidcode averts one case". These estimates are based on modeling or statistics. The paper also estimates the number of averted deaths (between 4000 and 9000) based on other modeling.

We could only verify the number of app users who have been diagnosed as K28+K29=561'014 in this spread sheet from the NHS web site. The number of notifications in this spread sheet is substantially different: M28+M29=1'175'232. In a private communication, the authors maintain their numbers are correct and are in the process to release the data.

First of all, the study is again silent on that contact cases being already aware of their status before the app notification. To obtain averted cases, we need some of the "positive traced contacts" to be cases discovered by the app. There are 0.27 positive traced contacts per entered covidcode. It is highly likely that some of the 0.27 positive traced contacts are household contacts. The paper says that with manual contact tracing, there are 1.2 household contacts per reported case. The contact tracers also contact more contact persons (1.8 per case). There are also notifications made outside of any official contact tracing. It is unrealistic that all these notified people would be totally disjoined from the app notifications. So, as it is the case in SwissCovid, it is relevant to think that a huge part (is not all) of the 0.27 positive traced contacts are not discovered cases but also include a big fraction of the 1.8 notified contacts and other notifications. In what follows we take the most favorable assumption (that the paper implicitely makes) that each of the 0.27 positive traced contacts are discovered cases but call them "allegedly discovered".

Second, to obtain that "each entered covidcode averts one case", it should be the case that each of the 0.27 allegedly discovered cases per entered covidcode would have made one more person infected if the app did not exist. The reproduction number R in the UK never exceeded 1.6 as this BBC article shows. (More data in this spread sheet from the gov.uk web site.) This means that each case does not infect more than 1.6 other people on average. In the worst case of R=1.6, we can estimate for each app user primary case, the number of allegedly averted tertiary cases to 72%*0.27*1.6=0.31. So, 560'000 app user primary cases make 175'000 allegedly averted tertiary cases. To reach more than 300'000 averated cases, we need to include quaternary and quinary cases (and assume that none would be spot by other contact tracing so that the chain is not broken). The computation made in the article models the evolution of the entire infection chain until the end of December 2020. Due to the exponential epidemiologic growth, it is not surprising that numbers are huge. However, such computations are not always reliable so the results should be taken with a grain a salt.

We infer the figures like for the Swiss study for comparison. (We took the data in Switzerland over the 16-21.Oct.20 period in the table below.) According to gov.uk, the total number of cases in England and Wales from 24.Sept to 31.Dec (included) is A=1'914'020. The number of positive app users is B=560'000. The number of entered covidcodes is C=560'000*72%=403'200. The number of allegedly discovered cases H is strictly upper bounded by 1.7M*6.0%=102'000. The period of study J is 24.September-December 2020. The number of notified app users is Q=1.7M. The population of England-Wales is T=59.5M. We can check that the ratio B/A (the app adoption rate among cases) is the same as in Switzerland. C/B (the consent to report rate among positive app users) is about 1.7 times smaller in Switzerland (fewer people enter covidcodes). Q/C (the number of notification per entered covidcode) is 4.2 in the UK (the paper says 4.4), which is 2.8 larger than in Switzerland. As for the allegedly discovered cases per case, we have H/A<5.3% (it was much lower in Switzerland: 0.18%). For the probability to be an allededly discovered case when we receive a notification, we have H/Q<6.0% (it was again much lower in Switzerland: 1%).
A B C H J Q T
3.2.2021 (Switzerland) 100'057 28'931 12'453 180 16-31.Oct.20 18'708 8'600'000
12.5.2021 (England+Wales) 1'914'020 560'000 403'200 <102'000 24.Sept-Dec.20 1'700'000 59'500'000

Using B=561'014 and Q=1'175'232 from the public NHS figures (as above mentioned), we obtain Q/C=2.9 notifications per entered covidcode (the paper claims 4.4), H<70'514 alegedly discovered cases, and H/A<3.7%. The notifications per covidcode Q/C is now only 1.9 times larger than in Switzerland, which could now be explained by the difference in adoption rates between the countries.

Overall, this comparison raises a few questions to which we suggest answers.

Possible Attacks

Several types of attacks against SwissCovid are possible. It is important for users to understand them. Indeed, SwissCovid is recognized as a medical device. Hence, the aware consent of users is fundamental. In normal medicine, awareness is guaranteed by providing the medicine together with objective information about possible side effects or observed risks. Having a clear and objective communication about the risks for taking SwissCovid can only strengthen trust.

Some attacks are easy to be done by anyone. Some of them are clearly illegal and people must not try them. For other attacks, which are based on collecting data, the legality is not clear at all because we are not sure the collected data are considered as personal data or not. Thus, we suggest not to try them.

Surveillance

Using a Bluetooth receiver (for instance, a phone), anyone can collect the ephemeral identifiers which are broadcasted around by phones. SwissCovid is not allowed to store the geolocalisation but other apps are not forbidden. Collecting identifier-time-location records allows to build a surveillance system. It can be enriched with the reported keys that anyone can collect from the server.

Here are a few attacks which are easy to mount. Welcome to the brave new world!

Those attacks are clear privacy threats to people. Users concerned about these should set/unset SwissCovid tracing responsibly.

Legal issues. We believe such attacks should be illegal. However, what they only collect is the ephemeral identifiers which are broadcasted over the air. (Own location and time belongs to whoever wants to store it.) If such data is not considered as personal data, such attack may be perfectly legal, which we find absurd.

The notion of personal information is actually a key issue here, because of the law on data protection. On the FOPH website we can read "The phone does not send any personal or location data to a central storage location or server". On another page we can read "The CDN only gives users access to information that cannot be used to obtain personal information (i.e. anonymous keys)". SwissCovid beams via Bluetooth some ephemeral identifiers which are derived (and can be recomputed) from keys. Diagnosed people post their keys on a publicly available server. Clearly, the position of SwissCovid promoters is that keys are anonymous. Anonymous information is not considered as personal information, thus not subject to regulation. If keys are anonymous, the identifiers which can be recomputed from them is anonymous too. Consequently, it is legal to make keys transit through a CDN, possibly abroad, without any regulation constraint. However, ephemeral identifiers become anonymous too hence no personal information. Therefore, they can be collected by anyone without regulation.

Instead, we believe that information which is exchanged via Bluetooth between phones and the one which is posted on the server are pseudonyms in the sense of the European regulation GDPR. They are not anonymous. Following GDPR, pseudonyms are private information. Hence, they should be subject to regulation on data protection. However, such recognition may have consequences on how the data stored on the server be regulated, and even on how phones collect ephemeral identifiers.

Extension with (other) personal data. We can of course improve the previous attacks by collecting more (personal) data. For instance, the Bluetooth surveillance can be enriched with a video-surveillance system so that ephemeral identifiers would link to a recorded video. If a reported key happens to generate an identifier which was collected, we can see the holder on the video, even though the contact was very brief and at distance.

An organization which identifies people can at the same time collect an ephemeral identifier and later one recognize if this person has become sick. This can be made at the reception of a hotel, at the cashier of a shop for people using a loyalty card, or at the entrance of a company for visitors or employee. Essentially, diagnosed people can be identified if they have even be seen by such surveillance system.

The basic attack was called the paparazzi attack in our April 8 report on DP3T. Essentially, a paparazzi can capture from far away one ephemeral identifier of a celebrity and regularly check on the server if this celebrity reported as diagnosed. Such information can be sold to tabloids. In a variant of this attack, a paparazzi can check which politicians are using SwissCovid and report. As acceptance of SwissCovid is becoming a political act, this could be a valuable information.

Data leakage. SwissCovid regularly connects to the server which is done through the Amazon SDN service. This means Amazon potentially sees and collects information about SwissCovid users such as their IP address.

Users who received an at-risk notification by SwissCovid are invited to submit an online survey. The deduced date of exposure is transmitted. The server which hosts the survey is located in England and belongs to Microsoft. This means that Microsoft sees the IP address, the used browser, the date of exposure, and many information entered by the at-risk user. The data travels outside Switzerland (and outside EU).

False-Alarm Injection

The ephemeral identifier of a person which is going to be diagnosed can be captured (even from far away) and maliciously be replayed somewhere else to simulate a risky encounter. This is likely to create a (false) at-risk notification. This way, we can get rid of some people by making them go to quarantine. According to specifications, an ephemeral identifier is supposed to be sent at some approximate time but the reception accepts it 2h before and 2h after. So, there is a lot of time to replay it. The network can also see a request made to the online survey which could mean it comes from an at-risk user. (The rest of the communication is encrypted and cannot be understood by the network.)

In the (imaginary) lazy student attack, a student runs this attack on their classmates to send the entire class in quarantine and have an exam cancelled. Presumably, we can turn an event or an organization down in the same way.

In another type of attack, a group of people could use a malicious app which mimics the Bluetooth ephemeral identifier broadcasting but synchronize all devices on the same keys. The effect is that all those people would be considered as a single person. They can try to broadcast with high intensity to make a wide neighborhood think of a close encounter. If one person of the group is diagnosed, this can create a very high number of false at-risk notifications. This is a kind of terrorist attack which sends a huge number of people to quarantine.

Those attacks could exploit a problem in the GAEN implementation (namely, that the encrypted metadata in the Bluetooth signal is malleable). They could even be done from abroad, to escape from legal jurisdiction, by using sponsored add-ons in benign apps, as described in the following paper.

Finally, a more drastic attack could be to corrupt a diagnosed user to buy his covidcode, then meet the persons we want to send to quarantine, then use the covidcode to report our keys. A covidcode can be used only once, but it remains valid during 24 hours. Interestingly, a much easier attack was possible during the first three weeks of SwissCovid. FOPH was adding on the server 10 fake keys per day for maintenance reasons. However, the validity period of those keys was posterior to the date of insertion. Consequently, a malicious person could download them and use them during their validity period to simulate the broadcast of a diagnosed person. This problem was announced to be corrected on July 20.

The attack based on buying/selling covidcodes can be organized in a black market in a secure way (for the seller and the buyer). This can be automatized using the blockchain technology. A complete descriptions and analysis is provided in

Another option is to corrupt time, as described by Vincenzo Iovino. The adversary could replay identifiers derived from already reported keys on the server and send his victim to the past to receive those identifiers. Sending a phone to the past should be easy by corrupting the NTP protocol when the victim is connected to WiFi (for instance, when the adversary owns the WiFi network). When the victim is connected to the cellular network, it is also possible with a fake base station. We succeeded to send a phone to the past and receive a false alert. This was successfully tried for SwissCovid and its Italian relative Immuni as the following video explains.

Missed Goals

Legal basis. Some legal requirements as defined in LEp and OSTP are not satisfied:

DP3T goals. The DP3T White Paper (accessible here) lists a few goals of the project which are supposed to be implemented by SwissCovid. We list here the goals which have not been met.

Goal Meaning SwissCovid
Provide data to epidemiologists (This goal was originally present but was dropped in the May 25 version) Only the numbers of fake and genuine reports are available
Open-source Code available and runnable with changes Code not runnable, protocol in GAEN with partial/sample code
Decentralized Data stored on users's phone Data stored on Apple/Google distributed storage
Privacy-by-design Preserves the privacy of users Bluetooth technology creates severe privacy threats
Complete All proximity cases (<1.5m) are captured Some people living together do not seem to be captured
Precise Only proximity cases are captured Some far away cases (>1.5m) may be captured
Authentication Proximity cases cannot be faked Proximity cases can be faked
Interoperability Should work across borders Works only in Switzerland

The first three goals are due to GAEN (we suspect providing data to epidemiologists was dropped because of being incompatible by the GAEN regulations to authorize the app). Completeness and precision are due to the well predicted hardness to measure distances with Bluetooth. The privacy loss is due to Bluetooth and to the DP3T decentralized architecture. The authentication problem is due to the DP3T scheme which is implemented by GAEN.

Lobbying. SwissCovid promoters made over 300 academic people sign a petition on digital contact tracing in order to ruin the reputation of their competitors and to advertise their solution. Besides claiming that their system was secure and privacy-preserving while others were not, this letter demands that those systems respect several criteria. The following one is clearly not respected because of GAEN.

Privacy. Clearly, the primary objective of SwissCovid was privacy. We however believe that it gave a wrong answer to a wrong question.

It gave the wrong answer because there are clear privacy threats created by SwissCovid. Furthermore, the taken approach for privacy by SwissCovid has ethical side effects. Recently, Lanzing described three pitfalls related to ethics in digital contact tracing. The first common mistake is to associate privacy with anonymity. Privacy relates to the control on who uses people's data. For that, anonymity is neither necessary nor sufficient. Second, this technology currently means encouraging the monopoly of Apple and Google in framing digital public health. Finally, it creates some form of coercion by adding social pressure to adopt the technology, if not restrictions, and by excluding people who are already threatened by the digital divide.

Privacy was also built by making sure SwissCovid will have almost no utility to FOPH. Health authorities cannot monitor where clusters of infections occur nor fine tune the sensibility parameters (while Apple of Google could). Actually, SwissCovid was more made to resist to a corrupted FOPH than to help it, while creating privacy risks which may come from third parties. In our April 8 report we already claimed that this dogmatic approach of decentralization was creating more privacy threats than it was solving.

Actually, privacy may be the wrong question. Of course, it is important, but this should not be made against utility. There are many other important factors to consider. For instance, the following report, issued from Armasuisse, considers the efficiency of the system for contact tracing, the battery usage, and the adoption likelihood in addition to security and privacy.

This report compares various technologies and adopts a scoring scheme (which is subjective). Although it concludes that the technology with the best average score is the one from SwissCovid, we can see that the second best (with almost equal average score) is the technology which has the most terrible score for privacy protection. This illustrates that privacy may be a not-so-important factor.

The following paper supports that

It actually shows that the myopic focus on the concept of "privacy by design" without any proper risk analysis have led to the adoption of a system with more ethical risks.

Lessons. We collected encountered problems about SwissCovid in

Our concerns are about broken promises. SwissCovid was aimed to be transparent with open source but is not. SwissCovid was aimed to be privacy-preserving but is not. SwissCovid was aimed to be secure but is not. SwissCovid was aimed to be precise and complete but is not.

In addition to this, SwissCovid digs more the digital divide, makes users captive of Apple/Google, and strengthens their monopoly and control on mobile digital technologies. With respect to digital sovereignty, it moved in the wrong direction.

So What?

SwissCovid was developed and deployed in a rush, with the pressure of the pandemic. It is remarkable that SwissCovid was fully deployed so fast. We find the adoption rate to be currently quite high (although it does not match the dreams of the developers). We however believe that the scientific debate was sabotaged by scientific lobbying and that we were mostly faced to a fait accompli. A vast conflict-of-interest factory around SwissCovid was built by having the same people being the developers, the evaluators, the advisors, the communicators, the operators, and the rulers. Alternate solutions were trashed. Criticisms were downplayed. Potential threats were ignored. Positive evaluation reports were posted and negative ones were not. Pseudo-scientific proofs were forged to support pre-agreed conclusions. Press was manipulated to spread conclusions. Essentially, SwissCovid begs Swiss residents to keep faith in that SwissCovid is or will be useful without any objective evidence. The security and privacy claims are smokescreens. We think that people were deceived.

Since SwissCovid was deployed, there was time to correct technical issues. We can assume that this system is mature and there is almost no chance it will improve any more. We can see that it played no role to avoid the second and third waves and their semi-lockdown. Its role is to spot at-risk contacts at a distance of up to 1.5m which last at least 15 minutes while FOPH has been constantly requiring social distances of at least 1.5m and measures were taken to make many of such contacts illegal. We doubt SwissCovid has any utility, besides generating academic praises.

The law specifies that the Government should shut down SwissCovid if it appears that it is not efficient enough to fight against the pandemic LEp Art.60a al.8. We find abnormal that since June 2020, there is still no reliable efficiency evaluation. There is no established objective metric to measure the efficiency, nor any precision about what "efficient enough" would mean, nor any plan to have any independent audit which is exempt from conflict of interest. There is no agenda to terminate SwissCovid besides the expiration of the legal basis on June 30, 2022. However, SwissCovid has a cost. We think it is high time to have an objective evaluation of SwissCovid and to consider to shut it down if the evaluation is not good.



Last update: May 16, 2021.