start	end	text
0	4780	Thanks for coming to my talk. I'm a first-time speaker at Crypto & Privacy Village, though
4780	10480	I've been at Defcon before last year. Regrettably, we couldn't get together this year, but I sure
10480	16440	hope I get to see you all in Vegas next year. Today, I'll be talking about COVID-19 apps,
16440	21580	and how Norway became worst-in-class in digital contact tracing from a privacy perspective.
22760	29300	First off, a short introduction. My name is Ivan Arvesen. I work as a consultant at a Norwegian
29300	37200	consultancy called Bouvet in Oslo, Norway. I mainly focus on privacy and security these days,
37200	45460	typically via AppSec, pen testing, data PR, advisory, and so on. My roles these days tend
45460	54440	to be tech lead, architect, advisory work, etc. And day-to-day, I work on a few projects within
54440	61300	critical infrastructure. I'm a huge privacy geek. I've written and spoken about stuff like GDPR
61300	66800	and privacy issues in append-only storage, browser fingerprinting, and mass surveillance
66800	73280	of bulk metadata collection. And earlier this year, I was a part of the government-appointed
73280	79360	expert group that were to evaluate the Norwegian solution for digital contact tracing of COVID-19.
80740	88580	Now, before I begin, a few disclaimers. I do not represent the expert group as such in this
88580	95860	talk, as it no longer exists, and as I can only really speak for myself, nor any of its members
95860	102540	or any other party you mentioned here. I can only talk for myself. So this is my own professional
102540	111360	opinion. I do not represent my employer either. Additionally, I'm an engineer, not a doctor, so
111360	118660	take any health statements or health-related statements with a grain of salt. Same goes for
119340	127120	legal stuff, as I'm not a lawyer. And most of the media coverage I reference here that
127120	134480	originates in Norway has been run through Google Translate for the occasion. Additionally, some of
134480	139820	the materials here are from or based on the final public report of our expert group, and others are
139820	148760	my own opinion, but I'll be sure to point that out. So back in June, Amnesty International published
148960	155360	a report naming and shaming the most dangerous contact tracing apps for privacy, where Norway
155360	163300	appeared amongst countries like Bahrain and Kuwait. Now, you might ask, what's Norway anyway? So for
163300	173880	those unfamiliar, Norway is basically a country in the lands of fjords, oil, hygge, never mind that
173880	183180	the book says Danish, black metal, and blue parrots apparently. Long story short, we're a Scandinavian
183180	193500	Nordic country, i.e. we're in the northern part of Europe, and we consistently score highly on a
193500	198840	bunch of metrics that basically tell you we're doing pretty all right. Stuff like Democracy Index
198840	208060	and Better Life Index, Happiness Report, and so on. So additionally, we tend to hold a high level
208060	214060	of trust in the government and in public services in general. We're also a highly digitalized
214060	222980	country, and we pride ourselves on knowledge and in trusting experts. So how then could
222980	229150	this happen in Norway, a liberal western democracy and a human rights champion?
230820	237820	Well, a bit of background. As you're all aware, in the beginning of this year, COVID-19
237820	243820	was spreading like wildfire throughout the world. And while it had first been reported as another
243820	252480	exotic local virus outbreak in China, it was soon seen as a global threat. Now, pretty early on,
252480	259160	I think February, we could read early reports on digital contact tracing in some parts of the world.
260260	265960	For instance, we had Singapore, which used a mainly Bluetooth-based
267320	272120	application they developed themselves, which hit upon a few snags we'll get back to.
273060	277940	Then there were South Korea, which used a combination of cell phone data,
277940	283800	credit card purchase history, and surveillance cameras. And then there was Israel, where
284360	292380	basically the government would have received geolocation from phone companies and were to
292380	298380	download information and call records from mobile phones to track and identify. So they basically
298380	307580	put the intelligence service on surveilling the population. So these are different approaches,
307580	313280	and depending on what vectors and sensors were used, what data were communicated where and to
313280	321200	and so on, there were different privacy impacts, obviously. So while digital solutions can
321200	328560	obviously potentially be a valuable tool, it might be useful in this case, it was also evident that
328560	333840	certain governments cared more about civil liberties and privacy than others.
335480	342640	So this is an illustration from Carl Frederik Schoellam and the CDC, illustrating contact
342640	349140	tracing, which is a part of the track and trace strategy many countries are taking.
350840	358560	So basically, you want to identify, or when someone is diagnosed with COVID-19,
358560	362620	you're trying to find out who's been exposed by that person to the disease, right?
363500	368680	So this could be household members, friends, or other that this so-called index patient has
368680	375600	been in close contact with. Now, this is most commonly done via interviews with diagnosed,
375600	380120	like laboratory confirmed patients, and trying to figure out where they've
380120	383680	been at what time and with whom during their infectious period.
386000	391400	Now, in the end of February, the coronavirus was first registered in Norway.
391960	398800	And in early to mid-March, the government implemented what they call the most invasive
398800	404640	measures in peacetime, shutting down schools and colleges and universities and hairdressers,
404640	417680	shopping centers, and so on. And in March of this year, the Norwegian Public Broadcasting Service
417680	426160	stumbled upon a public source code repo on GitHub, which revealed the existence of a digital contact
426160	432320	tracing app by a company called Simula Research Laboratory on behalf of the Norwegian Institute
432320	437200	of Public Health, which is a government agency under the Ministry of Health and Care Services.
438440	444680	Simula had been chosen as a supplier, producing parts of the solution. So other parts of the
444680	451000	government would do some integrations and extending existing services and stuff like that.
453260	458800	And we were soon able to read about some of the controversial design choices of this app,
458800	466760	such as centralized storage, collection of location data, producing long-term anonymized
466760	472700	and aggregated data potentially, which made a few alarm bells go off.
473940	481180	Because when people talk about anonymized data, what they often mean is de-identified data,
481180	489760	which can potentially be re-identified. So it was also made clear that the source code would
489760	498380	not be publicly available. So all of this brought about a bit of criticism and public debate,
499480	505200	and didn't really bode well. There were many that were critical for many reasons in this.
506180	511600	Now, this is what the final app looked like. On the left, you can see a splash screen,
511600	517460	then there's the onboarding process, and on the far right, your run-of-the-mill multi-page
517460	528280	privacy policy. To break it down, Smittestop was a closed source solution. It required
528280	533780	registration and de facto identification of users, because users had to register using their
533780	543020	phone number, which in Norway is very tightly connected to a specific person. It's almost
543020	552720	impossible to get a phone number anonymously. So it also collects sensor data from multiple
552720	560380	sources, both Bluetooth and location services. It uploads data from all the users, all the time,
560380	568700	to a centralized storage that the government controls. And there's the use of a static,
568700	575280	device-specific identifier when devices running the app communicate. So they identify themselves
575280	583520	using the same identifier every time. Now, the degree to which, if any, there is
583520	588520	data minimization in such a solution has been questioned by experts in the public debate
588520	599100	from the get-go. And any privacy engineer, and indeed many other with a little amount of technical
599100	606370	or practical understanding, will quickly see that these design choices have big privacy implications.
607740	615440	So, comparatively, Norway was fairly early on in rolling out an app, and the app itself is
615440	621020	arguably one of the most invasive ones on the market, at least in a European context, where
621020	626580	there are few, if any, other countries that have the same configuration of privacy-impacting factors
626580	638320	in their applications. So, the formal basis for processing, in the case of Smittestop, is
640860	650100	a dedicated regulation. So, the app is voluntary to use as such, but its formal basis for processing
650100	659240	is authorized by the Diseases Act, not consent. So, outside of this, the GDPR, or the Norwegian
659240	668040	implementation of GDPR, obviously applies as otherwise. So, the app
672220	678980	is different from most other COVID-19 apps, contact tracing apps, in that most other
678980	685100	apps do contact tracing, and that's it. While Smittestop has two purposes.
688320	695060	It's to notify users of close contact with people that have been infected,
695840	704840	but also to collect data that can be used in evaluating interventions that aim to lower
704840	711280	infection rates. For instance, looking at public movement patterns, as well as further research
711280	719760	analysis. Maybe input to epidemiological models, for instance. But the current app
719760	726140	is made in sort of an all-or-nothing fashion, in that users can choose to have their data
726140	732940	used for all the app's purposes, or not to use the app at all. Now, it's obviously not
732940	739920	ideal to not let users explicitly opt-in for either purpose, nor is it really even best
739920	746660	practice. And, not to mention, a potential consequence of implementing the app this way
747920	755560	is that users feel that they're not in control of their data, and maybe they don't fully
755560	762220	understand what happens to their data in what case. And that may, in turn, hamper user uptake.
762260	768560	So, you might not get as many users installing and using the app, which would lead to a lowered
768560	779020	effect of or from the app. About location data. So, what one is interested in when performing
779020	785400	contact tracing is really whom met whom. The identity of either party, or the location
787060	795900	of contact, is not necessarily relevant to prove contact itself. So, you thus don't necessarily
795900	801020	need to know who the involved parties are, or where the contact took place.
801620	808460	But the argument made for the use of location data, in the case of Smittstop,
808460	815400	is that they wanted to attempt to compensate for the lack of data quality as a consequence of
815400	821620	Bluetooth API limitations at the time. Because Bluetooth wouldn't work reliably in the background
821620	830220	on iOS, and whereas Android might just kill background processes that continuously use
830220	836740	Bluetooth or location services for energy or privacy reasons. Now, there's also another
836740	845580	factor here, which is that Norway, being a country where people have a lot of purchasing power,
845580	853500	iOS has more of a market share here than other places. So, that's a factor here as well.
855120	861260	But on the other hand, GPS or location services typically has an accuracy of 3 to 10 meters
861260	869840	under ideal conditions, meaning outdoor usage. So, you know, the quality of location
870700	878480	service data from indoor use is uncertain, let's say.
879280	884640	So, a proper and transparent evaluation of all the possibilities available here, then,
884640	890960	might include something like looking at how big of a problem the current, or then,
890960	897520	API limitations were in practice. Like, could you get by with spotty Bluetooth data, i.e. data only
897520	905460	from when users were actively using the application? And that's probably a no, because
905460	910700	then you'd always only have data from when users were unlocking their phone and having the app in
910700	917420	the foreground. Then there's the Singaporean approach, where they, in practice, implemented
917420	926000	like a faux sleep mode. Well, this necessitated keeping the app in the foreground, but
926460	931600	you could dim the screen when the device was rotated, like placed upside down, so as to not
931600	939320	totally drain the battery. So that's something. And that also lets you keep getting
940080	946020	Bluetooth data continuously. Or you could collect location data, which is personally
946020	953080	identifiable information, which is what we did in the Norwegian case. And then you'd have to think,
953080	957560	how do the privacy implications of the respective alternatives here size up against each other and
957560	964960	against the issue at hand? And another thing we have to mention here too is that,
964960	972700	though it has been mentioned in many instances, that the data is anonymous in several contexts.
972980	978720	This is really incorrect, because by virtue of being personal and identifiable information,
978720	986880	location data can, by definition, not be anonymous. Because location data can, in itself,
986880	992260	reveal a person's identity. That means there is no such thing as anonymous location data
992260	999240	on an individual basis. Whereas in aggregated datasets, you can have certain quantifiable
999240	1005640	guarantees about the degree of privacy, for instance, via k-anonymity, differential privacy.
1006600	1012980	But this gets complicated pretty quickly for a variety of reasons, such as temporal correlation
1013800	1024880	or re-identification by combining data sources. But in practice, location data is only really
1025040	1032920	a clear functional requirement in the case of monitoring public movement. And that's the other
1032920	1045440	purpose, not contact tracing, but collecting data. About centralized storage. So when we talk about
1045440	1050640	centralized storage in the context of contact tracing apps, we usually mean systems that are
1050640	1055560	based on collection that's continuously uploaded to a central server that holds all of everyone's
1055560	1061820	data. This is in contrast with decentralized systems, where every user's data is stored on
1061820	1068740	their device until it's needed. And one should also note that the most popular decentralized
1068740	1076620	solutions of digital contact tracing are not distributed, and that they still use a central
1076620	1083660	server as a communications channel of sorts, as opposed to purely peer-to-peer communication.
1083660	1091620	So for instance, a central server might hold a list of identifiers from people who are sick
1091620	1097920	in the last two weeks, and then other apps poll the server regularly and then check locally if
1097920	1103700	they've been in contact with any of the publicly known infectious or infected keys.
1106040	1112380	The argument made in favor for data centralization in the case of the Norwegian app is that
1113600	1121060	augmentation of user data with data from other users was needed in order to perform analysis.
1123460	1129160	It's also a prerequisite, of course, for the purpose of looking at movement patterns,
1129160	1135860	like collecting the data, the second purpose of the app, or to do other unspecified research
1136700	1145100	on it. But a centralized data store is really, in principle, a defining factor when dealing
1145100	1151580	with private data in this case, because its very existence makes misuse, function creep,
1151580	1157100	leakage, and so on possible in a way that a decentralized solution just plainly doesn't.
1157100	1165260	As in, you can't lose or abuse data you don't have. Now, alternative sources to
1166120	1173380	the aggregated long-term data they hope to collect here may already exist, such as the
1173380	1180020	data that Norwegian telcos had already provided in aggregate form, and that had been used for
1180020	1188840	the same purpose. So they had taken cell site data, basically, and had some sort of coarse
1191200	1199500	estimation of population density at points in time. And the government had used that for
1199500	1208340	this very purpose already. The downside might be that that data might not be as precise
1208340	1213500	as location data that you could get directly from devices, because resolution would depend
1213500	1221560	on many factors, like cell site density and so on. But the privacy cost of uploading every user's
1221560	1227260	location and movement, as well as who they've met and timestamps for all these events,
1227980	1235060	that's undoubtedly much larger than just uploading what data is needed when you think you need it.
1235060	1242260	For instance, prompting users to upload their movements, or even just use Bluetooth data only
1243180	1247580	once a person has been in contact with someone who's positively diagnosed.
1249080	1255360	There's also, of course, the risk of function creep, like the data could be used for something
1255360	1264140	we haven't thought about as of yet, or misuse in case of a regime change.
1264620	1271120	Additionally, if one didn't think the thought oneself, there were already publicly developed
1271120	1276240	decentralized protocols back then, so there were lots of materials for inspiration.
1277360	1284600	Now, this is an illustration of one of those privacy-first contact tracing schemes, so-called,
1284600	1292280	which Nikki Case has generously donated to the public domain. I think what's illustrated here is
1292280	1299760	based on DP3T. But basically, Alice's phone broadcasts random messages every few minutes,
1299760	1304260	and then when she sits next to Bob, their phones exchange messages.
1305080	1308600	Both their phones remember what they have said and what they've heard, i.e.,
1308600	1318180	what they've transmitted, sent, and received for the past 14 days. And if Alice gets COVID,
1318400	1325920	she sends her messages to a central server or a hospital. Now, you can't identify her from
1325920	1333920	this list of what messages she has sent, and this can be added to the big public list of
1333920	1342660	messages from everyone who's been diagnosed. So then, Bob's phone can query this central place
1342660	1349200	for a list of everyone who's been... or keys from messages from everyone who's been
1349200	1356420	infected for the last 14 days. And if his phone recognizes enough of these messages,
1356420	1361060	then he can isolate. So that's the gist of it.
1361720	1367560	Now, when it comes to data integrity and user traceability,
1367560	1372980	the use and communications of static device identifiers makes it possible to track or
1372980	1380480	impersonate others, to trace users in limited partial leaks, and so on. So this is a bad one,
1380480	1386320	because just about every other proposed solution I've seen, like both protocol specification and in
1386320	1395980	existing apps, use rolling identifiers in one form or another. So there's also the fact that
1395980	1403760	data was temporarily stored unencrypted in a local database on devices before uploading
1404480	1410080	device data to the central server, which made it possible to inject or modify data before
1410080	1418360	uploading it. Now, that means that data integrity, at least until the point where this was fixed,
1418360	1424700	cannot be guaranteed. Additionally, the application connects to a server using
1425460	1430740	what looks like an everlasting connection string and no other session handling.
1432420	1439800	Now, in order to use the application, users had to register using their phone number.
1439800	1446460	In Norway, this is de facto identifying yourself, because it's almost impossible to get a phone
1446460	1451580	number without identifying yourself. So there is a connection there, which is even public in many
1451580	1458020	cases, i.e. you can search for a name or a phone number and get the match on public services here.
1459640	1465780	So functionally, there's no real need to identify any involved party, because even in contact
1465780	1472900	tracing, users could be notified by the application when a contact has been diagnosed
1473640	1481340	with COVID by health authorities. Because one could argue that registration is a mechanism
1481340	1489640	that protects against bogus uploads to some extent. But this, in addition to protection of privacy,
1489640	1495460	is in a way already baked into many of the decentralized approaches that demand human
1495460	1502280	intervention before any upload takes place. So for instance, I think in the case of DP3T,
1502280	1509560	they actually distribute upload codes so that when you're diagnosed, the doctor gives you an
1509560	1515860	upload code that you can use to upload your data, i.e. the keys from your infected period
1515860	1523160	to the central datastore. And many of these other approaches also let users
1524280	1530300	choose specifically what time spans to share, or alternatively edit out some time spans to
1530300	1538500	not share them for any reason. Also, Smith to Stop was found to be uploading a bunch of analytics
1538500	1544080	data, including potentially fingerprintable information, on just about any interaction
1544080	1549700	the users do with the application, i.e. from the get-go, from the moment you open your apps,
1549700	1556570	analytics are firing, without telling users this. And this was not stated in the privacy policy,
1557460	1562380	and users could not choose whether they want to upload this data or not.
1565380	1571260	There are also some legal implications, I think, but note I'm not a lawyer, so you'll need to
1571800	1577860	hear the reflections with this in mind. So the regulation I mentioned earlier, that was
1578480	1584460	the formal basis for processing of the data, mentions that health and location data collected
1584460	1591200	for this purpose cannot be shared with law enforcement or other parties. But Bluetooth
1591200	1602180	data, however, isn't mentioned. Now, I interpret this as saying that sharing of Bluetooth data
1602180	1611300	is permitted, because this would mean that the parties that the data is shared with
1611300	1616300	could be able to, for instance, build social graphs of the data subjects.
1616820	1622580	Though the regulation puts in place certain limitations, like including a sunset clause,
1623280	1629940	the regulation also states that it can be changed at any time by the government via a new regulation.
1632220	1638980	There's also the fact that data was stored on Microsoft servers in Ireland,
1639780	1650660	and Ireland, there's already precedence for delivering user data to American authorities
1650660	1657720	there, which can be done via the Cloud Act, I think, where U.S. governments can demand and
1657720	1666910	secretly obtain data stored on the servers of American providers, even abroad. Now,
1667810	1674090	another consequence of what the Norwegian solution ended up looking like is that
1675750	1679790	it would be hard, if not impossible, to at least automatically achieve
1679790	1685410	data interoperability in collaboration with other European countries,
1685410	1693370	because most of these have already implemented or will implement solutions based on Apple and
1693370	1703210	Google's new APIs, and or that are compatible with other protocols, such as DP3T. Now,
1703210	1708830	other countries' contact tracing systems will, therefore, in theory, be able to register contact
1709530	1715230	events that involve citizens of other countries, and or persons using other apps even,
1715230	1719810	potentially, including apps produced by other countries' health officials.
1721550	1726130	And here's a slide for Miscellany.
1727410	1733130	A few points about the app is that the publicly available DPIA
1734450	1740590	appears to not seriously consider alternative approaches and implementation,
1741410	1750830	nor does it really consider malicious use of the data by the legitimate party itself,
1750830	1757110	or data breach, or data leakage, other than via security features of the mobile app.
1757630	1763430	And some of the probabilities stated in the risk assessment seem optimistic.
1765330	1770690	As I mentioned, using a static identifier that's never rotated is obviously a bad idea
1770690	1778810	and makes it possible to track users. And there's also something to be desired in transparency here.
1779590	1786430	Both the purpose of the application, which wasn't very well communicated in the app itself,
1786430	1793030	as well as just how the data was planned to be anonymized and aggregated for long-term use.
1793030	1797210	That should be clearly and specifically communicated to the public, I think.
1799370	1806670	But the anonymization process was not finished during our expert group evaluation of the app,
1807490	1811910	other than involving various forms of aggregation.
1814270	1820690	So all we can really say about that is we had some meetings with some stakeholders,
1820690	1823650	but no public information on that.
1825890	1833090	If the code were open-sourced, the public would be able to verify the functionality of the app,
1833090	1839990	as opposed to depending on security by obscurity, or as opposed to trusting,
1839990	1843490	for instance, the expert group and their interpretations.
1844250	1853010	Now, the fact that the functionality used to bind phone numbers to the cloud device ID
1853010	1860870	is implemented using a so-called preview feature, which the supplier says one should not use to
1860870	1866590	process personal data or any other data that's subject to heightened compliance requirements.
1866590	1873390	That's obviously not great. This was, I think it was B2C functionality in Azure in Ireland,
1873390	1880770	or some such. But there were also various logging and compliance issues, such that
1881310	1886770	users weren't able to see any data about their Bluetooth contacts in the audit solution.
1887110	1891530	They couldn't access logs from health authorities or view audit logs
1891530	1896770	after requesting deletion of their data, which could obviously be easily decoupled.
1900110	1905310	Additionally, the contact analysis code was very complicated and complex,
1905310	1914970	which means it was both, you know, kind of hard to understand what was actually going on there.
1914970	1921690	And it entails like low quality and a maintainability context, and had weaknesses
1921690	1934730	both in implementation and in software methodology. And finally, the app also used
1935270	1944190	text messages, SMS, to notify users if they had been in contact with someone infected with COVID.
1947980	1954260	Now, it's not really known whether digital contact tracing is even a viable solution
1954260	1960440	to the problem at hand. It's unknown what value it can bring, and even if it's feasible at all.
1961180	1966320	So most scientists with direct experience, like the ones involved with the Singaporean
1966320	1973900	program, they claim that digital contact tracing is at best a complementary addition to manual
1973900	1979000	contact tracing. Then there's the fact that the Norwegian app is not in accordance with
1979000	1984180	common European guidelines, such as the EU Commission's recommendations for these sorts
1984180	1990480	of apps, the EU resolution on coordinated work against COVID-19, nor the guidelines from the
1990480	1998740	European Data Protection Board. You know, surveilling movements and contacts of all
1998740	2004140	users of the app is an extremely invasive measure. And as the effectiveness and usefulness
2004140	2010800	of this system is not clear, the proportionality of this measure is questionable at best. One might
2010800	2018340	expect some sort of explanation as to why or how this would be effective and why this outweighs
2018340	2024060	the invasiveness of these actions, but this remains to be seen pretty much.
2026800	2032640	Now, as I said earlier, the app is an open source, and this is because it was claimed that
2032640	2040300	while open sourcing the code would, in the long run, potentially lead to better security,
2040300	2045620	but in a shorter perspective, it might lead the attackers or would-be attackers to
2045620	2053200	be able to exploit any vulnerabilities before anyone else could see them or fix them or so on.
2053200	2057230	So that's the argument that was made to keep the app closed source, basically.
2061260	2070920	And about anonymity in the long term, you know, there was a quote, a comment on our final report
2070920	2078500	where we commented on the state of anonymity in the long-term data, which would be aggregated
2078500	2086060	and anonymized so-called. They responded that the report also has a recommendation of anonymization
2086060	2096880	of data for analysis purposes through so-called differential privacy. The Norwegian Institute of
2096880	2104100	Public Health has at this point already developed an elaborate system for anonymization that is,
2104100	2110440	in their view, will have an equally anonymizing effect as so-called differential privacy,
2110440	2116300	but which is easier to implement, communicate, and doesn't lose data quality to speak of.
2117000	2126520	Now, while that statement makes sense syntactically, I guess we'll leave evaluating
2126520	2132400	the logic of it as an exercise for the listener, right? Is it possible to somehow deliver
2132400	2138320	anonymization to the same extent as differential privacy, but without the formal guarantees?
2138760	2150200	You decide. There are also a bunch of potential possible attacks here, like relay attacks,
2150200	2155500	tracking attacks, where if many people collaborated on this, you'd basically have
2155500	2161540	distributed surveillance. And this is obviously possible because of the static identifiers used
2161540	2172820	by the application. Or you can map infection. And you could potentially, from the long-term data,
2172820	2181700	the anonymized and aggregated data, so-called, re-identify people, potentially. And also
2181700	2191320	potential risk of data theft, leak, or misuse, which this risk is obviously magnified because
2191320	2197760	there's a state actor that's in control of all of this data. So the potential for abuse,
2197760	2204300	if it were to be abused, is obviously much higher. Now that we've discussed this app somewhat,
2205020	2209280	let's take a look at how events unfolded earlier this year.
2211000	2218720	Back in early April, after the public had been informed that this app was in development,
2218720	2225340	and it was going to look like what we just discussed. As a consequence of the criticism,
2225340	2231760	probably, as well as in order to increase transparency and so on, the Ministry of Health
2231760	2237240	and Care Services appointed a group of experts based on recommendations from an organization
2237240	2245640	called IKT Norway. And none of the participants were connected to any of the other involved parties,
2246360	2253060	obviously. But we were basically tasked with evaluating all of the involved components
2253060	2261000	in the solution. This includes mobile apps on respective platforms, a backend encompassing
2261000	2268720	many components, including analysis in order to figure out what's a contact event,
2268720	2273820	and reporting code, and connected services running in the cloud, integrations,
2273820	2278200	and new solutions in existing government systems.
2282600	2288580	We had mostly direct access to all the source code repositories, so we basically just dove into
2288580	2295680	the code and looked at it, and also had a bunch of meetings with all the stakeholders. But
2296600	2304080	our mandate said that we had to deliver an open report, like a public report,
2304080	2308180	where we would assess whether security and privacy are properly taken care of,
2308180	2313300	and also that we communicate with them and tell them about any vulnerabilities,
2313300	2316560	we found any issues, discuss that with them, and so on.
2319460	2326720	So, we delivered a preliminary report after four or five days, and because of that very limited
2326720	2337240	time, we had to limit ourselves to just the smartphone apps and a select part of the backend,
2337240	2346540	and only the technical security aspects. And also, because of the fact that not all the parts of this
2346540	2352140	entire system were finished at this point, or had even been started at that point,
2352140	2361780	we refrained from commenting on privacy. We waited until we'd seen the entirety, or enough.
2362400	2371280	So, deletion of data was not implemented either at this point, but long story short,
2371280	2375360	we pointed to some data integrity issues and the static ID, obviously,
2375360	2380360	as one of the main reasons that the apps shouldn't be launched as is,
2381020	2388360	you know, since there were issues and you'd have to view data as potentially compromised or bad.
2388360	2396100	So, then we recommended that maybe you could do a soft test in a couple of test municipalities,
2397580	2400840	but no more than that would be responsible in our view.
2401640	2405860	Still, we recommended a lot of improvements, most importantly,
2405860	2409960	related to integrity and scalability of the system.
2411160	2420980	What happened then was the app was launched to the entire country at the same time.
2422580	2430200	Well, it was called an evaluation or kind of a trial, right? But it was really launched
2430200	2434360	countrywide. Everyone could go to the app store and download this app and register and
2434360	2443000	upload data. What was limited to a couple of select test municipalities was the
2444360	2451580	tracing functionality. So, they only provided notification services
2452660	2456500	based on the data from the system to the people in the test municipalities,
2456500	2465920	whereas everyone could and would upload data. And some of the reason might be because some of
2465920	2473140	the issues we reported in our preliminary report, but the app was promptly reversed engineered and
2473140	2480720	inspected by a critical tech community. And there were also, as I mentioned on the previous slide,
2480800	2488460	a few scalability issues that we pointed out, which led to the fact that the backend didn't
2488460	2494540	quite scale so that when so many people in the country tried to download and register at the
2494540	2502480	same time, the backend just couldn't handle the pressure, basically. Also, the fact that they
2502480	2511860	hadn't had time to focus on energy efficiency led to a bunch of low user scores and negative reviews
2511860	2521080	and so on. Shortly thereafter, Google and Apple announced their API collaboration, which would fix
2521080	2527740	all the Bluetooth issues in the platform, basically, which would enable you to do
2529380	2535700	Bluetooth activity in a background app, leaving no real reason
2536440	2540660	to use location services for the purpose of contact tracing,
2541840	2547600	if you agree that Bluetooth data is enough to do contact tracing, that is.
2548800	2556180	But this new API demands that you don't use location services for access to the API.
2558480	2566360	And after that, a large amount of the Norwegian tech community mobilized and
2567920	2573740	published a petition. Over 300 professionals in security and privacy and tech in general
2574400	2578220	basically stated that we don't have to choose between privacy and health,
2578220	2582820	and that we have the knowledge and technology to implement a better solution,
2583700	2594040	which was met with some scorn from, well, the supplier mainly.
2597520	2606580	So when we delivered our final public report on May the 20th, this report included some findings
2606580	2611920	and recommendations. Now, most of the findings I've mentioned already, but they included
2611920	2616200	aggressive analytics, static identifiers and Bluetooth contact,
2616200	2620600	eternal connection strings, using preview features for personal data,
2620600	2627840	limitations in auditing solutions, data deletion, also deleting the audit logs,
2627840	2633620	quality issues in the contact analysis code, as well as using SMS, which is an insecure channel,
2633620	2642540	as a notifications channel. Now, in evaluating whether security and privacy was properly handled,
2642540	2647700	our evaluation concluded no on both accounts, unfortunately.
2649320	2656560	And then we delivered a few recommendations, which were basically clarifying the regulation,
2656560	2661400	splitting the app in two based on purpose, so one for contact tracing and one for
2662100	2669160	the data collection for those who wanted to contribute to that, to remove all data that
2669160	2673600	they didn't need at any point in time, so basically work towards more of a data minimization
2674000	2680660	thing, to implement differential privacy in their data aggregation plans,
2681440	2689380	to consider to rewrite towards a more decentralized solution, and to potentially
2689380	2695800	implement differential privacy before uploading user data, like differential privacy locally on
2695800	2702500	the device, and also make as much of the source code as possible open source so that people could
2702500	2709580	verify the functionality for themselves, and to regularly re-evaluate.
2711460	2719440	Now, the aftermath was pretty interesting. At the same government press conference that we
2720040	2724960	delivered our conclusions on, the Institute of Public Health basically just disagreed with
2724960	2731260	our conclusion, and then the supplier, Simula Research Laboratory,
2731680	2738160	basically just wrote a blog post publicly attacking the expert group,
2740100	2746060	and questioning our integrity, claiming that our conclusions were based on personal opinions,
2746060	2751520	that our recommendations were politically motivated, and so on. So here you can see the original
2752460	2758220	blog post translated by me from Norwegian to English, though they've since edited it
2758220	2765400	exchanging political for personal a few times. But nevertheless, questioning the motives of an
2765400	2770200	impartial external group tasked with evaluating your work in this way, kind of concerning
2770200	2778780	nonetheless, I think. But then again, this is another quote from some higher up at the same
2778780	2784480	company. There are many countries I think should not use the Norwegian solution, precisely because
2784480	2789200	they don't have a well-regulated democracy. They don't have strong privacy interests and
2789200	2797700	governments to keep watch. Now, following this logic in the Norwegian app, privacy would then
2797700	2804860	by definition not be handled responsibly, as any privacy guarantees would be contingent on trust,
2804860	2811820	which isn't much of a guarantee. Key point here, data protection and privacy are two different
2811820	2822820	things. After this, the parliament actually got involved and decided that they'd have to split
2822820	2829280	the app based on purpose. So one app for contact tracing and another for data collection for those
2829280	2837320	who want to contribute to that. Then the Norwegian Data Protection Authority concluded that the degree
2837320	2842580	of privacy invasiveness was not justified. Now, this was based on both things like data
2843600	2849480	minimization issues, but also on the current situation in Norway with a low amount of
2850000	2859820	infection, I guess. The health authorities, i.e. the Institute of Public Health, then chose to
2859820	2866280	stop all data collection and to delete all the data they already had. And the next day, Amnesty
2866280	2871920	International stated that they found the Norwegian app to be amongst the most dangerous tracing apps
2872440	2879020	for privacy, which was where we started out. Then international media picked up on this,
2879660	2884700	went around New York Times, BBC, and all those places.
2887320	2890080	Now, what can we learn from all of this?
2891460	2895320	Well, you don't want to be in the position of trying to figure out this stuff while the world's
2895320	2904180	crumbling around you, I think. But I think we need to be able to still stick to our principles,
2904180	2910120	especially in times of crises. Because privacy isn't only a compliance issue nor a subset of
2910120	2918160	security. And it's pretty problematic, I think, that the supplier has consistently been led
2918160	2924460	to do all the communications and just refuse to listen to or even understand criticism.
2925740	2931400	And basically argued that the solution works in Norway because we have such a high degree
2931400	2941340	of trust in the state. Because this misses the point entirely. And as to what happens next,
2941340	2946980	there were talks of experimenting with the Apple Google API. But now that everything's on ice,
2946980	2957840	who knows? So quick recap. Norway is hence worst in class in contact tracing for COVID-19.
2957840	2962000	And that's pretty unexpected. It's not something I would have seen coming like
2962000	2970620	half a year ago even. But continuously storing where everyone is, at what point,
2970620	2976160	and who they're meeting with, that's an extremely aggressive move and excessive even. Whereas other
2976160	2982600	protocols and solutions make as little of an impact on privacy as possible and make users
2982600	2988580	take active, explicit choices about their data, the Norwegian app Smittestop did not do that.
2991170	2996050	Now, I think this highlights the need for a drastic improvement in general understanding
2996050	3000930	of privacy, even amongst technologists, so that people will know how to make solutions
3000930	3006610	that are private by design and we don't end up in this situation again. And there are, of course,
3006610	3011450	also discussions to be had on a more principled level, which might illuminate this issue to even
3011450	3019450	more people like decision makers, directors, politicians, and so on. Because privacy is a
3019450	3026550	foundational human right and it's guaranteed by national constitutions and the EU and the
3026550	3032150	Universal Declaration of Human Rights. And that means there is a minimum of how much of these
3032150	3037890	rights that people must always have, meaning that states can only go so far in any case,
3037890	3041250	even though they, of course, might get more leeway in emergencies.
3042090	3049370	And that's because our principles, by virtue of being principles, always apply. Also, you know,
3049370	3054090	privacy is a defining feature of liberal democracies, we should take this stuff seriously.
3054610	3061650	But where then is this line? That's a hard issue and one that I don't really have a good answer to,
3061650	3070050	but that discussion is needed anyways. Because, you know, I experienced, even in working with
3070050	3074230	the expert group, that there are people that honestly believe that privacy costs are a pure
3074230	3080610	balancing act, that any degree of invasiveness can be warranted if it leads to effectiveness,
3080610	3086210	if the results are good enough, in whatever sense you're evaluating that.
3087250	3091310	I tend to think the laws and regulations are pretty clear that this is not the case,
3092090	3095830	and, you know, also protection against the tyranny of majority is another
3095830	3098650	defining feature of liberal democracies after all.
3102690	3110990	So, I think the head of Amnesty Security Lab had a pretty good quote here in that,
3110990	3114910	you know, privacy doesn't need to be a causality in rolling out of these maps.
3114910	3122410	And after all, we have to remember Amnesty, the DPA, Parliament, EU, Google and Apple,
3122410	3128310	our expert group and 300 professionals have all warned the involved parties several times.
3128390	3133350	And the fact that there's been no change until the entire app was put on hold is very strange,
3133350	3138010	given the degree of trust we usually pride ourselves in placing in experts in Norway.
3139230	3142870	You know, when there are privacy preserving alternatives,
3142870	3148590	such as other existing protocols and solutions, they should always be explored first.
3149190	3156470	Of course, it's laudable to want to solve this very real and very big problem with the means
3156470	3162010	available to us, but we really can't excuse bad work and lack of understanding by claiming that
3162010	3170330	the ends justify the means, in my opinion. Now, hopefully, you would rewrite the app in a more
3170330	3174950	privacy preserving way and try to learn from what went wrong here in order not to make this mistake
3174950	3185870	again. But the design choices were questionable or even arguable at first, but they never really
3185870	3192890	changed. And now that it's put on hold, this is the worst that could happen because now we're
3192890	3197650	seeing a bit of a rise again and the government is maybe having to crack down a bit and implement
3197650	3206490	more safety issues, and now we have no app. So this is not a good place to be in.
3207690	3213430	But as for the future, at least there's hope, because only yesterday I read this.
3213990	3221090	But only time will tell where we go from here. And that's all I had to say. With that,
3221090	3224890	I'd like to say thank you. It's been great fun and I appreciate you all being here.
3225630	3226970	And now for some Q&A.
