1
00:00:00,000 --> 00:00:01,680
Thanks for coming to my talk.

2
00:00:01,680 --> 00:00:07,380
I'm a first-time speaker at Crypto & Privacy Village, though I've been at Defcon before last year.

3
00:00:07,800 --> 00:00:12,980
Regrettably, we couldn't get together this year, but I sure hope I get to see you all in Vegas next year.

4
00:00:13,520 --> 00:00:21,580
Today, I'll be talking about COVID-19 apps, and how Norway became worst-in-class in digital contact tracing from a privacy perspective.

5
00:00:22,760 --> 00:00:25,140
First off, a short introduction.

6
00:00:25,240 --> 00:00:27,040
My name is Ivan Arvesen.

7
00:00:27,040 --> 00:00:32,900
I work as a consultant at a Norwegian consultancy called Bouvet in Oslo, Norway.

8
00:00:33,540 --> 00:00:42,080
I mainly focus on privacy and security these days, typically via AppSec, pen testing, data PR, advisory, and so on.

9
00:00:43,660 --> 00:00:49,820
My roles these days tend to be tech lead, architect, advisory work, etc.

10
00:00:50,040 --> 00:00:55,960
And day-to-day, I work on a few projects within critical infrastructure.

11
00:00:56,620 --> 00:00:59,040
I'm a huge privacy geek.

12
00:00:59,040 --> 00:01:08,920
I've written and spoken about stuff like GDPR and privacy issues in append-only storage, browser fingerprinting, and mass surveillance of bulk metadata collection.

13
00:01:09,980 --> 00:01:19,360
And earlier this year, I was a part of the government-appointed expert group that were to evaluate the Norwegian solution for digital contact tracing of COVID-19.

14
00:01:20,740 --> 00:01:24,540
Now, before I begin, a few disclaimers.

15
00:01:24,560 --> 00:01:38,460
I do not represent the expert group as such in this talk, as it no longer exists, and as I can only really speak for myself, nor any of its members or any other party you mentioned here.

16
00:01:38,460 --> 00:01:40,360
I can only talk for myself.

17
00:01:40,580 --> 00:01:43,520
So this is my own professional opinion.

18
00:01:43,820 --> 00:01:47,220
I do not represent my employer either.

19
00:01:48,640 --> 00:01:57,640
Additionally, I'm an engineer, not a doctor, so take any health statements or health-related statements with a grain of salt.

20
00:01:57,640 --> 00:02:01,820
Same goes for legal stuff, as I'm not a lawyer.

21
00:02:02,340 --> 00:02:11,180
And most of the media coverage I reference here that originates in Norway has been run through Google Translate for the occasion.

22
00:02:12,400 --> 00:02:23,540
Additionally, some of the materials here are from or based on the final public report of our expert group, and others are my own opinion, but I'll be sure to point that out.

23
00:02:25,540 --> 00:02:39,480
So back in June, Amnesty International published a report naming and shaming the most dangerous contact tracing apps for privacy, where Norway appeared amongst countries like Bahrain and Kuwait.

24
00:02:39,640 --> 00:02:42,920
Now, you might ask, what's Norway anyway?

25
00:02:42,920 --> 00:02:59,700
So for those unfamiliar, Norway is basically a country in the lands of fjords, oil, hygge, never mind that the book says Danish, black metal, and blue parrots apparently.

26
00:03:00,620 --> 00:03:05,800
Long story short, we're a Scandinavian Nordic country, i.e.

27
00:03:05,800 --> 00:03:16,460
we're in the northern part of Europe, and we consistently score highly on a bunch of metrics that basically tell you we're doing pretty all right.

28
00:03:16,640 --> 00:03:22,600
Stuff like Democracy Index and Better Life Index, Happiness Report, and so on.

29
00:03:22,980 --> 00:03:32,200
So additionally, we tend to hold a high level of trust in the government and in public services in general.

30
00:03:32,200 --> 00:03:40,660
We're also a highly digitalized country, and we pride ourselves on knowledge and in trusting experts.

31
00:03:41,460 --> 00:03:49,150
So how then could this happen in Norway, a liberal western democracy and a human rights champion?

32
00:03:50,820 --> 00:03:54,180
Well, a bit of background.

33
00:03:54,900 --> 00:04:00,400
As you're all aware, in the beginning of this year, COVID-19 was spreading like wildfire throughout the world.

34
00:04:00,400 --> 00:04:09,640
And while it had first been reported as another exotic local virus outbreak in China, it was soon seen as a global threat.

35
00:04:09,880 --> 00:04:19,160
Now, pretty early on, I think February, we could read early reports on digital contact tracing in some parts of the world.

36
00:04:20,260 --> 00:04:32,120
For instance, we had Singapore, which used a mainly Bluetooth-based application they developed themselves, which hit upon a few snags we'll get back to.

37
00:04:33,060 --> 00:04:41,120
Then there were South Korea, which used a combination of cell phone data, credit card purchase history, and surveillance cameras.

38
00:04:41,420 --> 00:04:56,960
And then there was Israel, where basically the government would have received geolocation from phone companies and were to download information and call records from mobile phones to track and identify.

39
00:04:57,620 --> 00:05:04,460
So they basically put the intelligence service on surveilling the population.

40
00:05:05,360 --> 00:05:17,540
So these are different approaches, and depending on what vectors and sensors were used, what data were communicated where and to and so on, there were different privacy impacts, obviously.

41
00:05:18,120 --> 00:05:33,840
So while digital solutions can obviously potentially be a valuable tool, it might be useful in this case, it was also evident that certain governments cared more about civil liberties and privacy than others.

42
00:05:35,480 --> 00:05:49,140
So this is an illustration from Carl Frederik Schoellam and the CDC, illustrating contact tracing, which is a part of the track and trace strategy many countries are taking.

43
00:05:50,840 --> 00:06:02,620
So basically, you want to identify, or when someone is diagnosed with COVID-19, you're trying to find out who's been exposed by that person to the disease, right?

44
00:06:03,500 --> 00:06:10,380
So this could be household members, friends, or other that this so-called index patient has been in close contact with.

45
00:06:10,640 --> 00:06:23,680
Now, this is most commonly done via interviews with diagnosed, like laboratory confirmed patients, and trying to figure out where they've been at what time and with whom during their infectious period.

46
00:06:26,000 --> 00:06:31,400
Now, in the end of February, the coronavirus was first registered in Norway.

47
00:06:31,960 --> 00:06:46,780
And in early to mid-March, the government implemented what they call the most invasive measures in peacetime, shutting down schools and colleges and universities and hairdressers, shopping centers, and so on.

48
00:06:48,280 --> 00:07:13,460
And in March of this year, the Norwegian Public Broadcasting Service stumbled upon a public source code repo on GitHub, which revealed the existence of a digital contact tracing app by a company called Simula Research Laboratory on behalf of the Norwegian Institute of Public Health,

49
00:07:13,460 --> 00:07:17,200
which is a government agency under the Ministry of Health and Care Services.

50
00:07:18,440 --> 00:07:23,640
Simula had been chosen as a supplier, producing parts of the solution.

51
00:07:23,640 --> 00:07:31,000
So other parts of the government would do some integrations and extending existing services and stuff like that.

52
00:07:33,260 --> 00:07:52,700
And we were soon able to read about some of the controversial design choices of this app, such as centralized storage, collection of location data, producing long-term anonymized and aggregated data potentially, which made a few alarm bells go off.

53
00:07:53,940 --> 00:08:05,060
Because when people talk about anonymized data, what they often mean is de-identified data, which can potentially be re-identified.

54
00:08:05,700 --> 00:08:11,920
So it was also made clear that the source code would not be publicly available.

55
00:08:13,140 --> 00:08:21,560
So all of this brought about a bit of criticism and public debate, and didn't really bode well.

56
00:08:21,560 --> 00:08:25,200
There were many that were critical for many reasons in this.

57
00:08:26,180 --> 00:08:29,100
Now, this is what the final app looked like.

58
00:08:29,300 --> 00:08:39,280
On the left, you can see a splash screen, then there's the onboarding process, and on the far right, your run-of-the-mill multi-page privacy policy.

59
00:08:40,460 --> 00:08:46,720
To break it down, Smittestop was a closed source solution.

60
00:08:46,860 --> 00:09:02,420
It required registration and de facto identification of users, because users had to register using their phone number, which in Norway is very tightly connected to a specific person.

61
00:09:02,420 --> 00:09:09,160
It's almost impossible to get a phone number anonymously.

62
00:09:09,660 --> 00:09:16,760
So it also collects sensor data from multiple sources, both Bluetooth and location services.

63
00:09:16,840 --> 00:09:24,580
It uploads data from all the users, all the time, to a centralized storage that the government controls.

64
00:09:25,420 --> 00:09:33,720
And there's the use of a static, device-specific identifier when devices running the app communicate.

65
00:09:33,720 --> 00:09:38,700
So they identify themselves using the same identifier every time.

66
00:09:40,100 --> 00:09:50,260
Now, the degree to which, if any, there is data minimization in such a solution has been questioned by experts in the public debate from the get-go.

67
00:09:51,780 --> 00:10:06,370
And any privacy engineer, and indeed many other with a little amount of technical or practical understanding, will quickly see that these design choices have big privacy implications.

68
00:10:07,740 --> 00:10:28,300
So, comparatively, Norway was fairly early on in rolling out an app, and the app itself is arguably one of the most invasive ones on the market, at least in a European context, where there are few, if any, other countries that have the same configuration of privacy-impacting factors in their applications.

69
00:10:30,160 --> 00:10:42,780
So, the formal basis for processing, in the case of Smittestop, is a dedicated regulation.

70
00:10:44,060 --> 00:10:55,600
So, the app is voluntary to use as such, but its formal basis for processing is authorized by the Diseases Act, not consent.

71
00:10:56,180 --> 00:11:02,820
So, outside of this, the GDPR, or the Norwegian implementation of GDPR, obviously applies as otherwise.

72
00:11:05,160 --> 00:11:08,040
So, the app

73
00:11:12,220 --> 00:11:22,120
is different from most other COVID-19 apps, contact tracing apps, in that most other apps do contact tracing, and that's it.

74
00:11:22,360 --> 00:11:25,100
While Smittestop has two purposes.

75
00:11:28,320 --> 00:11:45,800
It's to notify users of close contact with people that have been infected, but also to collect data that can be used in evaluating interventions that aim to lower infection rates.

76
00:11:45,800 --> 00:11:52,420
For instance, looking at public movement patterns, as well as further research analysis.

77
00:11:52,580 --> 00:11:57,840
Maybe input to epidemiological models, for instance.

78
00:11:58,380 --> 00:12:10,780
But the current app is made in sort of an all-or-nothing fashion, in that users can choose to have their data used for all the app's purposes, or not to use the app at all.

79
00:12:11,840 --> 00:12:20,720
Now, it's obviously not ideal to not let users explicitly opt-in for either purpose, nor is it really even best practice.

80
00:12:21,840 --> 00:12:38,300
And, not to mention, a potential consequence of implementing the app this way is that users feel that they're not in control of their data, and maybe they don't fully understand what happens to their data in what case.

81
00:12:38,440 --> 00:12:42,220
And that may, in turn, hamper user uptake.

82
00:12:42,260 --> 00:12:51,280
So, you might not get as many users installing and using the app, which would lead to a lowered effect of or from the app.

83
00:12:53,960 --> 00:12:56,360
About location data.

84
00:12:56,560 --> 00:13:02,780
So, what one is interested in when performing contact tracing is really whom met whom.

85
00:13:02,960 --> 00:13:13,760
The identity of either party, or the location of contact, is not necessarily relevant to prove contact itself.

86
00:13:13,760 --> 00:13:21,020
So, you thus don't necessarily need to know who the involved parties are, or where the contact took place.

87
00:13:21,620 --> 00:13:38,180
But the argument made for the use of location data, in the case of Smittstop, is that they wanted to attempt to compensate for the lack of data quality as a consequence of Bluetooth API limitations at the time.

88
00:13:38,400 --> 00:13:55,500
Because Bluetooth wouldn't work reliably in the background on iOS, and whereas Android might just kill background processes that continuously use Bluetooth or location services for energy or privacy reasons.

89
00:13:55,500 --> 00:14:09,660
Now, there's also another factor here, which is that Norway, being a country where people have a lot of purchasing power, iOS has more of a market share here than other places.

90
00:14:10,880 --> 00:14:13,500
So, that's a factor here as well.

91
00:14:15,120 --> 00:14:24,580
But on the other hand, GPS or location services typically has an accuracy of 3 to 10 meters under ideal conditions, meaning outdoor usage.

92
00:14:25,380 --> 00:14:38,480
So, you know, the quality of location service data from indoor use is uncertain, let's say.

93
00:14:39,280 --> 00:14:53,240
So, a proper and transparent evaluation of all the possibilities available here, then, might include something like looking at how big of a problem the current, or then, API limitations were in practice.

94
00:14:53,240 --> 00:14:56,820
Like, could you get by with spotty Bluetooth data, i.e.

95
00:14:56,820 --> 00:15:00,240
data only from when users were actively using the application?

96
00:15:03,000 --> 00:15:11,600
And that's probably a no, because then you'd always only have data from when users were unlocking their phone and having the app in the foreground.

97
00:15:13,580 --> 00:15:19,860
Then there's the Singaporean approach, where they, in practice, implemented like a faux sleep mode.

98
00:15:21,540 --> 00:15:33,640
Well, this necessitated keeping the app in the foreground, but you could dim the screen when the device was rotated, like placed upside down, so as to not totally drain the battery.

99
00:15:34,400 --> 00:15:35,980
So that's something.

100
00:15:36,520 --> 00:15:41,800
And that also lets you keep getting Bluetooth data continuously.

101
00:15:42,440 --> 00:15:50,300
Or you could collect location data, which is personally identifiable information, which is what we did in the Norwegian case.

102
00:15:51,080 --> 00:15:59,660
And then you'd have to think, how do the privacy implications of the respective alternatives here size up against each other and against the issue at hand?

103
00:16:00,100 --> 00:16:12,700
And another thing we have to mention here too is that, though it has been mentioned in many instances, that the data is anonymous in several contexts.

104
00:16:12,980 --> 00:16:23,200
This is really incorrect, because by virtue of being personal and identifiable information, location data can, by definition, not be anonymous.

105
00:16:24,520 --> 00:16:28,720
Because location data can, in itself, reveal a person's identity.

106
00:16:29,260 --> 00:16:34,420
That means there is no such thing as anonymous location data on an individual basis.

107
00:16:35,200 --> 00:16:45,640
Whereas in aggregated datasets, you can have certain quantifiable guarantees about the degree of privacy, for instance, via k-anonymity, differential privacy.

108
00:16:46,600 --> 00:17:00,100
But this gets complicated pretty quickly for a variety of reasons, such as temporal correlation or re-identification by combining data sources.

109
00:17:01,760 --> 00:17:10,560
But in practice, location data is only really a clear functional requirement in the case of monitoring public movement.

110
00:17:10,560 --> 00:17:17,400
And that's the other purpose, not contact tracing, but collecting data.

111
00:17:20,920 --> 00:17:23,760
About centralized storage.

112
00:17:23,920 --> 00:17:36,520
So when we talk about centralized storage in the context of contact tracing apps, we usually mean systems that are based on collection that's continuously uploaded to a central server that holds all of everyone's data.

113
00:17:36,820 --> 00:17:43,980
This is in contrast with decentralized systems, where every user's data is stored on their device until it's needed.

114
00:17:44,260 --> 00:18:03,660
And one should also note that the most popular decentralized solutions of digital contact tracing are not distributed, and that they still use a central server as a communications channel of sorts, as opposed to purely peer-to-peer communication.

115
00:18:03,660 --> 00:18:23,700
So for instance, a central server might hold a list of identifiers from people who are sick in the last two weeks, and then other apps poll the server regularly and then check locally if they've been in contact with any of the publicly known infectious or infected keys.

116
00:18:26,040 --> 00:18:41,060
The argument made in favor for data centralization in the case of the Norwegian app is that augmentation of user data with data from other users was needed in order to perform analysis.

117
00:18:43,460 --> 00:18:58,460
It's also a prerequisite, of course, for the purpose of looking at movement patterns, like collecting the data, the second purpose of the app, or to do other unspecified research on it.

118
00:18:59,080 --> 00:19:17,100
But a centralized data store is really, in principle, a defining factor when dealing with private data in this case, because its very existence makes misuse, function creep, leakage, and so on possible in a way that a decentralized solution just plainly doesn't.

119
00:19:17,100 --> 00:19:21,440
As in, you can't lose or abuse data you don't have.

120
00:19:22,780 --> 00:19:41,460
Now, alternative sources to the aggregated long-term data they hope to collect here may already exist, such as the data that Norwegian telcos had already provided in aggregate form, and that had been used for the same purpose.

121
00:19:41,460 --> 00:19:56,860
So they had taken cell site data, basically, and had some sort of coarse estimation of population density at points in time.

122
00:19:57,400 --> 00:20:02,460
And the government had used that for this very purpose already.

123
00:20:03,640 --> 00:20:17,880
The downside might be that that data might not be as precise as location data that you could get directly from devices, because resolution would depend on many factors, like cell site density and so on.

124
00:20:18,080 --> 00:20:35,060
But the privacy cost of uploading every user's location and movement, as well as who they've met and timestamps for all these events, that's undoubtedly much larger than just uploading what data is needed when you think you need it.

125
00:20:35,060 --> 00:20:47,580
For instance, prompting users to upload their movements, or even just use Bluetooth data only once a person has been in contact with someone who's positively diagnosed.

126
00:20:49,080 --> 00:21:04,140
There's also, of course, the risk of function creep, like the data could be used for something we haven't thought about as of yet, or misuse in case of a regime change.

127
00:21:04,620 --> 00:21:16,240
Additionally, if one didn't think the thought oneself, there were already publicly developed decentralized protocols back then, so there were lots of materials for inspiration.

128
00:21:17,360 --> 00:21:30,520
Now, this is an illustration of one of those privacy-first contact tracing schemes, so-called, which Nikki Case has generously donated to the public domain.

129
00:21:30,520 --> 00:21:34,300
I think what's illustrated here is based on DP3T.

130
00:21:34,840 --> 00:21:44,260
But basically, Alice's phone broadcasts random messages every few minutes, and then when she sits next to Bob, their phones exchange messages.

131
00:21:45,080 --> 00:21:55,580
Both their phones remember what they have said and what they've heard, i.e., what they've transmitted, sent, and received for the past 14 days.

132
00:21:55,780 --> 00:22:02,520
And if Alice gets COVID, she sends her messages to a central server or a hospital.

133
00:22:02,840 --> 00:22:17,000
Now, you can't identify her from this list of what messages she has sent, and this can be added to the big public list of messages from everyone who's been diagnosed.

134
00:22:17,280 --> 00:22:31,620
So then, Bob's phone can query this central place for a list of everyone who's been... or keys from messages from everyone who's been infected for the last 14 days.

135
00:22:31,620 --> 00:22:38,520
And if his phone recognizes enough of these messages, then he can isolate.

136
00:22:39,220 --> 00:22:41,060
So that's the gist of it.

137
00:22:41,720 --> 00:22:58,420
Now, when it comes to data integrity and user traceability, the use and communications of static device identifiers makes it possible to track or impersonate others, to trace users in limited partial leaks, and so on.

138
00:22:58,500 --> 00:23:11,540
So this is a bad one, because just about every other proposed solution I've seen, like both protocol specification and in existing apps, use rolling identifiers in one form or another.

139
00:23:13,320 --> 00:23:31,460
So there's also the fact that data was temporarily stored unencrypted in a local database on devices before uploading device data to the central server, which made it possible to inject or modify data before uploading it.

140
00:23:33,140 --> 00:23:40,140
Now, that means that data integrity, at least until the point where this was fixed, cannot be guaranteed.

141
00:23:41,100 --> 00:23:50,740
Additionally, the application connects to a server using what looks like an everlasting connection string and no other session handling.

142
00:23:52,420 --> 00:23:59,800
Now, in order to use the application, users had to register using their phone number.

143
00:23:59,800 --> 00:24:08,020
In Norway, this is de facto identifying yourself, because it's almost impossible to get a phone number without identifying yourself.

144
00:24:08,020 --> 00:24:12,920
So there is a connection there, which is even public in many cases, i.e.

145
00:24:12,920 --> 00:24:18,020
you can search for a name or a phone number and get the match on public services here.

146
00:24:19,640 --> 00:24:36,280
So functionally, there's no real need to identify any involved party, because even in contact tracing, users could be notified by the application when a contact has been diagnosed with COVID by health authorities.

147
00:24:37,140 --> 00:24:45,300
Because one could argue that registration is a mechanism that protects against bogus uploads to some extent.

148
00:24:45,760 --> 00:24:58,260
But this, in addition to protection of privacy, is in a way already baked into many of the decentralized approaches that demand human intervention before any upload takes place.

149
00:24:58,660 --> 00:25:13,140
So for instance, I think in the case of DP3T, they actually distribute upload codes so that when you're diagnosed, the doctor gives you an upload code that you can use to upload your data, i.e.

150
00:25:13,580 --> 00:25:18,280
the keys from your infected period to the central datastore.

151
00:25:19,060 --> 00:25:32,200
And many of these other approaches also let users choose specifically what time spans to share, or alternatively edit out some time spans to not share them for any reason.

152
00:25:33,320 --> 00:25:47,060
Also, Smith to Stop was found to be uploading a bunch of analytics data, including potentially fingerprintable information, on just about any interaction the users do with the application, i.e.

153
00:25:47,060 --> 00:25:53,760
from the get-go, from the moment you open your apps, analytics are firing, without telling users this.

154
00:25:53,900 --> 00:26:02,380
And this was not stated in the privacy policy, and users could not choose whether they want to upload this data or not.

155
00:26:05,380 --> 00:26:14,600
There are also some legal implications, I think, but note I'm not a lawyer, so you'll need to hear the reflections with this in mind.

156
00:26:15,160 --> 00:26:30,140
So the regulation I mentioned earlier, that was the formal basis for processing of the data, mentions that health and location data collected for this purpose cannot be shared with law enforcement or other parties.

157
00:26:30,180 --> 00:26:33,920
But Bluetooth data, however, isn't mentioned.

158
00:26:34,280 --> 00:26:56,300
Now, I interpret this as saying that sharing of Bluetooth data is permitted, because this would mean that the parties that the data is shared with could be able to, for instance, build social graphs of the data subjects.

159
00:26:56,820 --> 00:27:09,940
Though the regulation puts in place certain limitations, like including a sunset clause, the regulation also states that it can be changed at any time by the government via a new regulation.

160
00:27:12,220 --> 00:27:36,720
There's also the fact that data was stored on Microsoft servers in Ireland, and Ireland, there's already precedence for delivering user data to American authorities there, which can be done via the Cloud Act, I think, where U.S.

161
00:27:36,720 --> 00:27:43,160
governments can demand and secretly obtain data stored on the servers of American providers, even abroad.

162
00:27:46,090 --> 00:28:15,950
Now, another consequence of what the Norwegian solution ended up looking like is that it would be hard, if not impossible, to at least automatically achieve data interoperability in collaboration with other European countries, because most of these have already implemented or will implement solutions based on Apple and Google's new APIs,

163
00:28:15,950 --> 00:28:21,910
and or that are compatible with other protocols, such as DP3T.

164
00:28:22,550 --> 00:28:39,810
Now, other countries' contact tracing systems will, therefore, in theory, be able to register contact events that involve citizens of other countries, and or persons using other apps even, potentially, including apps produced by other countries' health officials.

165
00:28:41,550 --> 00:28:46,130
And here's a slide for Miscellany.

166
00:28:47,410 --> 00:29:13,370
A few points about the app is that the publicly available DPIA appears to not seriously consider alternative approaches and implementation, nor does it really consider malicious use of the data by the legitimate party itself, or data breach, or data leakage,

167
00:29:13,370 --> 00:29:17,110
other than via security features of the mobile app.

168
00:29:17,630 --> 00:29:23,430
And some of the probabilities stated in the risk assessment seem optimistic.

169
00:29:25,330 --> 00:29:33,110
As I mentioned, using a static identifier that's never rotated is obviously a bad idea and makes it possible to track users.

170
00:29:33,630 --> 00:29:38,810
And there's also something to be desired in transparency here.

171
00:29:39,590 --> 00:29:53,030
Both the purpose of the application, which wasn't very well communicated in the app itself, as well as just how the data was planned to be anonymized and aggregated for long-term use.

172
00:29:53,030 --> 00:29:57,210
That should be clearly and specifically communicated to the public, I think.

173
00:29:59,370 --> 00:30:11,910
But the anonymization process was not finished during our expert group evaluation of the app, other than involving various forms of aggregation.

174
00:30:14,270 --> 00:30:23,650
So all we can really say about that is we had some meetings with some stakeholders, but no public information on that.

175
00:30:25,890 --> 00:30:43,490
If the code were open-sourced, the public would be able to verify the functionality of the app, as opposed to depending on security by obscurity, or as opposed to trusting, for instance, the expert group and their interpretations.

176
00:30:44,250 --> 00:31:06,590
Now, the fact that the functionality used to bind phone numbers to the cloud device ID is implemented using a so-called preview feature, which the supplier says one should not use to process personal data or any other data that's subject to heightened compliance requirements.

177
00:31:06,590 --> 00:31:08,910
That's obviously not great.

178
00:31:09,290 --> 00:31:14,910
This was, I think it was B2C functionality in Azure in Ireland, or some such.

179
00:31:16,050 --> 00:31:26,770
But there were also various logging and compliance issues, such that users weren't able to see any data about their Bluetooth contacts in the audit solution.

180
00:31:27,110 --> 00:31:36,770
They couldn't access logs from health authorities or view audit logs after requesting deletion of their data, which could obviously be easily decoupled.

181
00:31:40,110 --> 00:31:54,970
Additionally, the contact analysis code was very complicated and complex, which means it was both, you know, kind of hard to understand what was actually going on there.

182
00:31:54,970 --> 00:32:10,950
And it entails like low quality and a maintainability context, and had weaknesses both in implementation and in software methodology.

183
00:32:11,110 --> 00:32:24,190
And finally, the app also used text messages, SMS, to notify users if they had been in contact with someone infected with COVID.

184
00:32:27,980 --> 00:32:35,800
Now, it's not really known whether digital contact tracing is even a viable solution to the problem at hand.

185
00:32:35,800 --> 00:32:40,440
It's unknown what value it can bring, and even if it's feasible at all.

186
00:32:41,180 --> 00:32:55,220
So most scientists with direct experience, like the ones involved with the Singaporean program, they claim that digital contact tracing is at best a complementary addition to manual contact tracing.

187
00:32:56,160 --> 00:33:13,080
Then there's the fact that the Norwegian app is not in accordance with common European guidelines, such as the EU Commission's recommendations for these sorts of apps, the EU resolution on coordinated work against COVID-19, nor the guidelines from the European Data Protection Board.

188
00:33:14,680 --> 00:33:21,900
You know, surveilling movements and contacts of all users of the app is an extremely invasive measure.

189
00:33:21,900 --> 00:33:29,200
And as the effectiveness and usefulness of this system is not clear, the proportionality of this measure is questionable at best.

190
00:33:29,680 --> 00:33:44,060
One might expect some sort of explanation as to why or how this would be effective and why this outweighs the invasiveness of these actions, but this remains to be seen pretty much.

191
00:33:46,800 --> 00:34:13,200
Now, as I said earlier, the app is an open source, and this is because it was claimed that while open sourcing the code would, in the long run, potentially lead to better security, but in a shorter perspective, it might lead the attackers or would-be attackers to be able to exploit any vulnerabilities before anyone else could see them or fix them or so on.

192
00:34:13,200 --> 00:34:17,230
So that's the argument that was made to keep the app closed source, basically.

193
00:34:21,260 --> 00:34:40,440
And about anonymity in the long term, you know, there was a quote, a comment on our final report where we commented on the state of anonymity in the long-term data, which would be aggregated and anonymized so-called.

194
00:34:41,460 --> 00:34:50,960
They responded that the report also has a recommendation of anonymization of data for analysis purposes through so-called differential privacy.

195
00:34:52,060 --> 00:35:13,200
The Norwegian Institute of Public Health has at this point already developed an elaborate system for anonymization that is, in their view, will have an equally anonymizing effect as so-called differential privacy, but which is easier to implement, communicate,

196
00:35:13,200 --> 00:35:16,300
and doesn't lose data quality to speak of.

197
00:35:17,000 --> 00:35:30,220
Now, while that statement makes sense syntactically, I guess we'll leave evaluating the logic of it as an exercise for the listener, right?

198
00:35:30,220 --> 00:35:38,320
Is it possible to somehow deliver anonymization to the same extent as differential privacy, but without the formal guarantees?

199
00:35:38,760 --> 00:35:40,620
You decide.

200
00:35:43,840 --> 00:35:57,300
There are also a bunch of potential possible attacks here, like relay attacks, tracking attacks, where if many people collaborated on this, you'd basically have distributed surveillance.

201
00:35:57,580 --> 00:36:03,340
And this is obviously possible because of the static identifiers used by the application.

202
00:36:03,660 --> 00:36:06,420
Or you can map infection.

203
00:36:08,100 --> 00:36:19,760
And you could potentially, from the long-term data, the anonymized and aggregated data, so-called, re-identify people, potentially.

204
00:36:20,240 --> 00:36:34,580
And also potential risk of data theft, leak, or misuse, which this risk is obviously magnified because there's a state actor that's in control of all of this data.

205
00:36:34,820 --> 00:36:41,020
So the potential for abuse, if it were to be abused, is obviously much higher.

206
00:36:41,020 --> 00:36:49,280
Now that we've discussed this app somewhat, let's take a look at how events unfolded earlier this year.

207
00:36:51,000 --> 00:37:01,920
Back in early April, after the public had been informed that this app was in development, and it was going to look like what we just discussed.

208
00:37:03,280 --> 00:37:19,800
As a consequence of the criticism, probably, as well as in order to increase transparency and so on, the Ministry of Health and Care Services appointed a group of experts based on recommendations from an organization called IKT Norway.

209
00:37:21,080 --> 00:37:27,660
And none of the participants were connected to any of the other involved parties, obviously.

210
00:37:27,980 --> 00:37:34,920
But we were basically tasked with evaluating all of the involved components in the solution.

211
00:37:34,920 --> 00:37:58,200
This includes mobile apps on respective platforms, a backend encompassing many components, including analysis in order to figure out what's a contact event, and reporting code, and connected services running in the cloud, integrations, and new solutions in existing government systems.

212
00:38:02,600 --> 00:38:15,060
We had mostly direct access to all the source code repositories, so we basically just dove into the code and looked at it, and also had a bunch of meetings with all the stakeholders.

213
00:38:15,500 --> 00:38:34,780
But our mandate said that we had to deliver an open report, like a public report, where we would assess whether security and privacy are properly taken care of, and also that we communicate with them and tell them about any vulnerabilities, we found any issues,

214
00:38:34,780 --> 00:38:36,560
discuss that with them, and so on.

215
00:38:39,460 --> 00:39:00,120
So, we delivered a preliminary report after four or five days, and because of that very limited time, we had to limit ourselves to just the smartphone apps and a select part of the backend, and only the technical security aspects.

216
00:39:01,820 --> 00:39:16,600
And also, because of the fact that not all the parts of this entire system were finished at this point, or had even been started at that point, we refrained from commenting on privacy.

217
00:39:17,120 --> 00:39:21,780
We waited until we'd seen the entirety, or enough.

218
00:39:22,400 --> 00:39:48,360
So, deletion of data was not implemented either at this point, but long story short, we pointed to some data integrity issues and the static ID, obviously, as one of the main reasons that the apps shouldn't be launched as is, you know, since there were issues and you'd have to view data as potentially compromised or bad.

219
00:39:48,360 --> 00:40:00,840
So, then we recommended that maybe you could do a soft test in a couple of test municipalities, but no more than that would be responsible in our view.

220
00:40:01,640 --> 00:40:09,960
Still, we recommended a lot of improvements, most importantly, related to integrity and scalability of the system.

221
00:40:11,160 --> 00:40:20,980
What happened then was the app was launched to the entire country at the same time.

222
00:40:22,580 --> 00:40:27,020
Well, it was called an evaluation or kind of a trial, right?

223
00:40:27,020 --> 00:40:31,220
But it was really launched countrywide.

224
00:40:31,220 --> 00:40:35,680
Everyone could go to the app store and download this app and register and upload data.

225
00:40:36,540 --> 00:40:46,100
What was limited to a couple of select test municipalities was the tracing functionality.

226
00:40:46,840 --> 00:40:59,620
So, they only provided notification services based on the data from the system to the people in the test municipalities, whereas everyone could and would upload data.

227
00:41:00,820 --> 00:41:15,420
And some of the reason might be because some of the issues we reported in our preliminary report, but the app was promptly reversed engineered and inspected by a critical tech community.

228
00:41:16,260 --> 00:41:35,520
And there were also, as I mentioned on the previous slide, a few scalability issues that we pointed out, which led to the fact that the backend didn't quite scale so that when so many people in the country tried to download and register at the same time,

229
00:41:35,520 --> 00:41:39,080
the backend just couldn't handle the pressure, basically.

230
00:41:40,680 --> 00:41:53,100
Also, the fact that they hadn't had time to focus on energy efficiency led to a bunch of low user scores and negative reviews and so on.

231
00:41:55,760 --> 00:42:20,660
Shortly thereafter, Google and Apple announced their API collaboration, which would fix all the Bluetooth issues in the platform, basically, which would enable you to do Bluetooth activity in a background app, leaving no real reason to use location services for the purpose of contact tracing,

232
00:42:21,840 --> 00:42:27,600
if you agree that Bluetooth data is enough to do contact tracing, that is.

233
00:42:28,800 --> 00:42:36,180
But this new API demands that you don't use location services for access to the API.

234
00:42:38,480 --> 00:42:49,880
And after that, a large amount of the Norwegian tech community mobilized and published a petition.

235
00:42:50,320 --> 00:43:10,340
Over 300 professionals in security and privacy and tech in general basically stated that we don't have to choose between privacy and health, and that we have the knowledge and technology to implement a better solution, which was met with some scorn from,

236
00:43:10,340 --> 00:43:14,040
well, the supplier mainly.

237
00:43:17,520 --> 00:43:29,280
So when we delivered our final public report on May the 20th, this report included some findings and recommendations.

238
00:43:29,280 --> 00:43:44,500
Now, most of the findings I've mentioned already, but they included aggressive analytics, static identifiers and Bluetooth contact, eternal connection strings, using preview features for personal data, limitations in auditing solutions, data deletion,

239
00:43:44,500 --> 00:43:55,640
also deleting the audit logs, quality issues in the contact analysis code, as well as using SMS, which is an insecure channel, as a notifications channel.

240
00:43:57,640 --> 00:44:07,700
Now, in evaluating whether security and privacy was properly handled, our evaluation concluded no on both accounts, unfortunately.

241
00:44:09,320 --> 00:44:30,900
And then we delivered a few recommendations, which were basically clarifying the regulation, splitting the app in two based on purpose, so one for contact tracing and one for the data collection for those who wanted to contribute to that, to remove all data that they didn't need at any point in time,

242
00:44:30,900 --> 00:44:53,760
so basically work towards more of a data minimization thing, to implement differential privacy in their data aggregation plans, to consider to rewrite towards a more decentralized solution, and to potentially implement differential privacy before uploading user data,

243
00:44:53,760 --> 00:45:09,580
like differential privacy locally on the device, and also make as much of the source code as possible open source so that people could verify the functionality for themselves, and to regularly re-evaluate.

244
00:45:11,460 --> 00:45:15,920
Now, the aftermath was pretty interesting.

245
00:45:16,340 --> 00:45:38,160
At the same government press conference that we delivered our conclusions on, the Institute of Public Health basically just disagreed with our conclusion, and then the supplier, Simula Research Laboratory, basically just wrote a blog post publicly attacking the expert group,

246
00:45:40,100 --> 00:45:49,920
and questioning our integrity, claiming that our conclusions were based on personal opinions, that our recommendations were politically motivated, and so on.

247
00:45:49,920 --> 00:46:01,940
So here you can see the original blog post translated by me from Norwegian to English, though they've since edited it exchanging political for personal a few times.

248
00:46:02,460 --> 00:46:12,040
But nevertheless, questioning the motives of an impartial external group tasked with evaluating your work in this way, kind of concerning nonetheless, I think.

249
00:46:12,720 --> 00:46:19,840
But then again, this is another quote from some higher up at the same company.

250
00:46:20,220 --> 00:46:26,960
There are many countries I think should not use the Norwegian solution, precisely because they don't have a well-regulated democracy.

251
00:46:26,960 --> 00:46:31,080
They don't have strong privacy interests and governments to keep watch.

252
00:46:31,660 --> 00:46:47,240
Now, following this logic in the Norwegian app, privacy would then by definition not be handled responsibly, as any privacy guarantees would be contingent on trust, which isn't much of a guarantee.

253
00:46:47,880 --> 00:46:52,920
Key point here, data protection and privacy are two different things.

254
00:46:56,200 --> 00:47:04,480
After this, the parliament actually got involved and decided that they'd have to split the app based on purpose.

255
00:47:04,480 --> 00:47:10,940
So one app for contact tracing and another for data collection for those who want to contribute to that.

256
00:47:12,000 --> 00:47:20,240
Then the Norwegian Data Protection Authority concluded that the degree of privacy invasiveness was not justified.

257
00:47:20,240 --> 00:47:31,520
Now, this was based on both things like data minimization issues, but also on the current situation in Norway with a low amount of infection, I guess.

258
00:47:34,040 --> 00:47:36,620
The health authorities, i.e.

259
00:47:36,620 --> 00:47:43,700
the Institute of Public Health, then chose to stop all data collection and to delete all the data they already had.

260
00:47:44,820 --> 00:47:55,700
And the next day, Amnesty International stated that they found the Norwegian app to be amongst the most dangerous tracing apps for privacy, which was where we started out.

261
00:47:57,060 --> 00:48:04,700
Then international media picked up on this, went around New York Times, BBC, and all those places.

262
00:48:07,320 --> 00:48:10,080
Now, what can we learn from all of this?

263
00:48:11,460 --> 00:48:16,980
Well, you don't want to be in the position of trying to figure out this stuff while the world's crumbling around you, I think.

264
00:48:18,660 --> 00:48:25,900
But I think we need to be able to still stick to our principles, especially in times of crises.

265
00:48:26,080 --> 00:48:31,280
Because privacy isn't only a compliance issue nor a subset of security.

266
00:48:32,360 --> 00:48:44,460
And it's pretty problematic, I think, that the supplier has consistently been led to do all the communications and just refuse to listen to or even understand criticism.

267
00:48:45,740 --> 00:48:52,860
And basically argued that the solution works in Norway because we have such a high degree of trust in the state.

268
00:48:53,420 --> 00:48:55,740
Because this misses the point entirely.

269
00:48:57,960 --> 00:49:05,140
And as to what happens next, there were talks of experimenting with the Apple Google API.

270
00:49:05,180 --> 00:49:08,100
But now that everything's on ice, who knows?

271
00:49:10,000 --> 00:49:11,620
So quick recap.

272
00:49:13,500 --> 00:49:17,840
Norway is hence worst in class in contact tracing for COVID-19.

273
00:49:17,840 --> 00:49:19,940
And that's pretty unexpected.

274
00:49:19,940 --> 00:49:24,060
It's not something I would have seen coming like half a year ago even.

275
00:49:25,700 --> 00:49:35,500
But continuously storing where everyone is, at what point, and who they're meeting with, that's an extremely aggressive move and excessive even.

276
00:49:35,580 --> 00:49:48,580
Whereas other protocols and solutions make as little of an impact on privacy as possible and make users take active, explicit choices about their data, the Norwegian app Smittestop did not do that.

277
00:49:51,170 --> 00:50:04,890
Now, I think this highlights the need for a drastic improvement in general understanding of privacy, even amongst technologists, so that people will know how to make solutions that are private by design and we don't end up in this situation again.

278
00:50:05,390 --> 00:50:16,010
And there are, of course, also discussions to be had on a more principled level, which might illuminate this issue to even more people like decision makers, directors, politicians, and so on.

279
00:50:16,010 --> 00:50:28,130
Because privacy is a foundational human right and it's guaranteed by national constitutions and the EU and the Universal Declaration of Human Rights.

280
00:50:28,130 --> 00:50:41,250
And that means there is a minimum of how much of these rights that people must always have, meaning that states can only go so far in any case, even though they, of course, might get more leeway in emergencies.

281
00:50:42,090 --> 00:50:47,670
And that's because our principles, by virtue of being principles, always apply.

282
00:50:48,370 --> 00:50:54,090
Also, you know, privacy is a defining feature of liberal democracies, we should take this stuff seriously.

283
00:50:54,610 --> 00:50:57,230
But where then is this line?

284
00:50:57,450 --> 00:51:05,090
That's a hard issue and one that I don't really have a good answer to, but that discussion is needed anyways.

285
00:51:06,090 --> 00:51:22,570
Because, you know, I experienced, even in working with the expert group, that there are people that honestly believe that privacy costs are a pure balancing act, that any degree of invasiveness can be warranted if it leads to effectiveness, if the results are good enough,

286
00:51:22,570 --> 00:51:26,210
in whatever sense you're evaluating that.

287
00:51:27,250 --> 00:51:38,650
I tend to think the laws and regulations are pretty clear that this is not the case, and, you know, also protection against the tyranny of majority is another defining feature of liberal democracies after all.

288
00:51:42,690 --> 00:51:54,910
So, I think the head of Amnesty Security Lab had a pretty good quote here in that, you know, privacy doesn't need to be a causality in rolling out of these maps.

289
00:51:54,910 --> 00:52:08,310
And after all, we have to remember Amnesty, the DPA, Parliament, EU, Google and Apple, our expert group and 300 professionals have all warned the involved parties several times.

290
00:52:08,390 --> 00:52:18,010
And the fact that there's been no change until the entire app was put on hold is very strange, given the degree of trust we usually pride ourselves in placing in experts in Norway.

291
00:52:19,230 --> 00:52:28,590
You know, when there are privacy preserving alternatives, such as other existing protocols and solutions, they should always be explored first.

292
00:52:29,190 --> 00:52:44,970
Of course, it's laudable to want to solve this very real and very big problem with the means available to us, but we really can't excuse bad work and lack of understanding by claiming that the ends justify the means, in my opinion.

293
00:52:46,150 --> 00:52:55,830
Now, hopefully, you would rewrite the app in a more privacy preserving way and try to learn from what went wrong here in order not to make this mistake again.

294
00:52:56,930 --> 00:53:06,790
But the design choices were questionable or even arguable at first, but they never really changed.

295
00:53:07,270 --> 00:53:21,390
And now that it's put on hold, this is the worst that could happen because now we're seeing a bit of a rise again and the government is maybe having to crack down a bit and implement more safety issues, and now we have no app.

296
00:53:23,110 --> 00:53:26,490
So this is not a good place to be in.

297
00:53:27,690 --> 00:53:33,430
But as for the future, at least there's hope, because only yesterday I read this.

298
00:53:33,990 --> 00:53:36,570
But only time will tell where we go from here.

299
00:53:37,170 --> 00:53:40,190
And that's all I had to say.

300
00:53:40,530 --> 00:53:42,230
With that, I'd like to say thank you.

301
00:53:42,230 --> 00:53:44,890
It's been great fun and I appreciate you all being here.

302
00:53:45,630 --> 00:53:46,970
And now for some Q&A.