Thanks for coming to my talk. I'm a first-time speaker at Crypto & Privacy Village, though
I've been at Defcon before last year. Regrettably, we couldn't get together this year, but I sure
hope I get to see you all in Vegas next year. Today, I'll be talking about COVID-19 apps,
and how Norway became worst-in-class in digital contact tracing from a privacy perspective.
First off, a short introduction. My name is Ivan Arvesen. I work as a consultant at a Norwegian
consultancy called Bouvet in Oslo, Norway. I mainly focus on privacy and security these days,
typically via AppSec, pen testing, data PR, advisory, and so on. My roles these days tend
to be tech lead, architect, advisory work, etc. And day-to-day, I work on a few projects within
critical infrastructure. I'm a huge privacy geek. 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. 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.
Now, before I begin, a few disclaimers. 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. I can only talk for myself. So this is my own professional
opinion. I do not represent my employer either. Additionally, I'm an engineer, not a doctor, so
take any health statements or health-related statements with a grain of salt. Same goes for
legal stuff, as I'm not a lawyer. And most of the media coverage I reference here that
originates in Norway has been run through Google Translate for the occasion. 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. 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. Now, you might ask, what's Norway anyway? 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. Long story short, we're a Scandinavian
Nordic country, i.e. 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. Stuff like Democracy Index
and Better Life Index, Happiness Report, and so on. So additionally, we tend to hold a high level
of trust in the government and in public services in general. We're also a highly digitalized
country, and we pride ourselves on knowledge and in trusting experts. So how then could
this happen in Norway, a liberal western democracy and a human rights champion?
Well, a bit of background. As you're all aware, in the beginning of this year, COVID-19
was spreading like wildfire throughout the world. And while it had first been reported as another
exotic local virus outbreak in China, it was soon seen as a global threat. Now, pretty early on,
I think February, we could read early reports on digital contact tracing in some parts of the world.
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.
Then there were South Korea, which used a combination of cell phone data,
credit card purchase history, and surveillance cameras. 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. So they basically
put the intelligence service on surveilling the population. 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. 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.
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.
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?
So this could be household members, friends, or other that this so-called index patient has
been in close contact with. 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.
Now, in the end of February, the coronavirus was first registered in Norway.
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. 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, which is a government agency under the Ministry of Health and Care Services.
Simula had been chosen as a supplier, producing parts of the solution. So other parts of the
government would do some integrations and extending existing services and stuff like that.
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.
Because when people talk about anonymized data, what they often mean is de-identified data,
which can potentially be re-identified. So it was also made clear that the source code would
not be publicly available. So all of this brought about a bit of criticism and public debate,
and didn't really bode well. There were many that were critical for many reasons in this.
Now, this is what the final app looked like. 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. To break it down, Smittestop was a closed source solution. 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. It's almost
impossible to get a phone number anonymously. So it also collects sensor data from multiple
sources, both Bluetooth and location services. It uploads data from all the users, all the time,
to a centralized storage that the government controls. And there's the use of a static,
device-specific identifier when devices running the app communicate. So they identify themselves
using the same identifier every time. 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. 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.
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. So, the formal basis for processing, in the case of Smittestop, is
a dedicated regulation. So, the app is voluntary to use as such, but its formal basis for processing
is authorized by the Diseases Act, not consent. So, outside of this, the GDPR, or the Norwegian
implementation of GDPR, obviously applies as otherwise. So, the app
is different from most other COVID-19 apps, contact tracing apps, in that most other
apps do contact tracing, and that's it. While Smittestop has two purposes.
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. For instance, looking at public movement patterns, as well as further research
analysis. Maybe input to epidemiological models, for instance. 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. Now, it's obviously not
ideal to not let users explicitly opt-in for either purpose, nor is it really even best
practice. 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. And that may, in turn, hamper user uptake.
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. About location data. So, what one is interested in when performing
contact tracing is really whom met whom. The identity of either party, or the location
of contact, is not necessarily relevant to prove contact itself. So, you thus don't necessarily
need to know who the involved parties are, or where the contact took place.
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. 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. 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. So, that's a factor here as well.
But on the other hand, GPS or location services typically has an accuracy of 3 to 10 meters
under ideal conditions, meaning outdoor usage. So, you know, the quality of location
service data from indoor use is uncertain, let's say.
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. Like, could you get by with spotty Bluetooth data, i.e. data only
from when users were actively using the application? 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. Then there's the Singaporean approach, where they, in practice, implemented
like a faux sleep mode. 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. So that's something. And that also lets you keep getting
Bluetooth data continuously. Or you could collect location data, which is personally
identifiable information, which is what we did in the Norwegian case. 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? 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.
This is really incorrect, because by virtue of being personal and identifiable information,
location data can, by definition, not be anonymous. Because location data can, in itself,
reveal a person's identity. That means there is no such thing as anonymous location data
on an individual basis. Whereas in aggregated datasets, you can have certain quantifiable
guarantees about the degree of privacy, for instance, via k-anonymity, differential privacy.
But this gets complicated pretty quickly for a variety of reasons, such as temporal correlation
or re-identification by combining data sources. But in practice, location data is only really
a clear functional requirement in the case of monitoring public movement. And that's the other
purpose, not contact tracing, but collecting data. About centralized storage. 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. This is in contrast with decentralized systems, where every user's data is stored on
their device until it's needed. 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.
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.
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.
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. 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.
As in, you can't lose or abuse data you don't have. 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. So they had taken cell site data, basically, and had some sort of coarse
estimation of population density at points in time. And the government had used that for
this very purpose already. 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. 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.
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.
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.
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.
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. I think what's illustrated here is
based on DP3T. But basically, Alice's phone broadcasts random messages every few minutes,
and then when she sits next to Bob, their phones exchange messages.
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. And if Alice gets COVID,
she sends her messages to a central server or a hospital. 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. 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. And if his phone recognizes enough of these messages,
then he can isolate. So that's the gist of it.
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. 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. 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. Now, that means that data integrity, at least until the point where this was fixed,
cannot be guaranteed. Additionally, the application connects to a server using
what looks like an everlasting connection string and no other session handling.
Now, in order to use the application, users had to register using their phone number.
In Norway, this is de facto identifying yourself, because it's almost impossible to get a phone
number without identifying yourself. So there is a connection there, which is even public in many
cases, i.e. you can search for a name or a phone number and get the match on public services here.
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. Because one could argue that registration is a mechanism
that protects against bogus uploads to some extent. 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. 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. the keys from your infected period
to the central datastore. 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. 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. from the get-go, from the moment you open your apps,
analytics are firing, without telling users this. And this was not stated in the privacy policy,
and users could not choose whether they want to upload this data or not.
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. 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. But Bluetooth
data, however, isn't mentioned. 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.
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.
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. governments can demand and
secretly obtain data stored on the servers of American providers, even abroad. 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, and or that are compatible with other protocols, such as DP3T. 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.
And here's a slide for Miscellany.
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, other than via security features of the mobile app.
And some of the probabilities stated in the risk assessment seem optimistic.
As I mentioned, using a static identifier that's never rotated is obviously a bad idea
and makes it possible to track users. And there's also something to be desired in transparency here.
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.
That should be clearly and specifically communicated to the public, I think.
But the anonymization process was not finished during our expert group evaluation of the app,
other than involving various forms of aggregation.
So all we can really say about that is we had some meetings with some stakeholders,
but no public information on that.
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.
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.
That's obviously not great. This was, I think it was B2C functionality in Azure in Ireland,
or some such. 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.
They couldn't access logs from health authorities or view audit logs
after requesting deletion of their data, which could obviously be easily decoupled.
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.
And it entails like low quality and a maintainability context, and had weaknesses
both in implementation and in software methodology. And finally, the app also used
text messages, SMS, to notify users if they had been in contact with someone infected with COVID.
Now, it's not really known whether digital contact tracing is even a viable solution
to the problem at hand. It's unknown what value it can bring, and even if it's feasible at all.
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. 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. You know, surveilling movements and contacts of all
users of the app is an extremely invasive measure. And as the effectiveness and usefulness
of this system is not clear, the proportionality of this measure is questionable at best. 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.
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.
So that's the argument that was made to keep the app closed source, basically.
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. They responded that the report also has a recommendation of anonymization
of data for analysis purposes through so-called differential privacy. 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, and doesn't lose data quality to speak of.
Now, while that statement makes sense syntactically, I guess we'll leave evaluating
the logic of it as an exercise for the listener, right? Is it possible to somehow deliver
anonymization to the same extent as differential privacy, but without the formal guarantees?
You decide. 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. And this is obviously possible because of the static identifiers used
by the application. Or you can map infection. And you could potentially, from the long-term data,
the anonymized and aggregated data, so-called, re-identify people, potentially. 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. So the potential for abuse,
if it were to be abused, is obviously much higher. Now that we've discussed this app somewhat,
let's take a look at how events unfolded earlier this year.
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. 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. And none of the participants were connected to any of the other involved parties,
obviously. But we were basically tasked with evaluating all of the involved components
in the solution. 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.
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. 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, discuss that with them, and so on.
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. 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. We waited until we'd seen the entirety, or enough.
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.
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.
Still, we recommended a lot of improvements, most importantly,
related to integrity and scalability of the system.
What happened then was the app was launched to the entire country at the same time.
Well, it was called an evaluation or kind of a trial, right? But it was really launched
countrywide. Everyone could go to the app store and download this app and register and
upload data. What was limited to a couple of select test municipalities was the
tracing functionality. 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. 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. 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, the backend just couldn't handle the pressure, basically. 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. 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,
if you agree that Bluetooth data is enough to do contact tracing, that is.
But this new API demands that you don't use location services for access to the API.
And after that, a large amount of the Norwegian tech community mobilized and
published a petition. 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, well, the supplier mainly.
So when we delivered our final public report on May the 20th, this report included some findings
and recommendations. 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, 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. Now, in evaluating whether security and privacy was properly handled,
our evaluation concluded no on both accounts, unfortunately.
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, 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, 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.
Now, the aftermath was pretty interesting. 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,
and questioning our integrity, claiming that our conclusions were based on personal opinions,
that our recommendations were politically motivated, and so on. 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. But nevertheless, questioning the motives of an
impartial external group tasked with evaluating your work in this way, kind of concerning
nonetheless, I think. But then again, this is another quote from some higher up at the same
company. There are many countries I think should not use the Norwegian solution, precisely because
they don't have a well-regulated democracy. They don't have strong privacy interests and
governments to keep watch. 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. Key point here, data protection and privacy are two different
things. After this, the parliament actually got involved and decided that they'd have to split
the app based on purpose. So one app for contact tracing and another for data collection for those
who want to contribute to that. Then the Norwegian Data Protection Authority concluded that the degree
of privacy invasiveness was not justified. 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. The health authorities, i.e. the Institute of Public Health, then chose to
stop all data collection and to delete all the data they already had. 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. Then international media picked up on this,
went around New York Times, BBC, and all those places.
Now, what can we learn from all of this?
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. But I think we need to be able to still stick to our principles,
especially in times of crises. Because privacy isn't only a compliance issue nor a subset of
security. 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.
And basically argued that the solution works in Norway because we have such a high degree
of trust in the state. Because this misses the point entirely. And as to what happens next,
there were talks of experimenting with the Apple Google API. But now that everything's on ice,
who knows? So quick recap. Norway is hence worst in class in contact tracing for COVID-19.
And that's pretty unexpected. It's not something I would have seen coming like
half a year ago even. But continuously storing where everyone is, at what point,
and who they're meeting with, that's an extremely aggressive move and excessive even. 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.
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. 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. Because privacy is a
foundational human right and it's guaranteed by national constitutions and the EU and the
Universal Declaration of Human Rights. 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.
And that's because our principles, by virtue of being principles, always apply. Also, you know,
privacy is a defining feature of liberal democracies, we should take this stuff seriously.
But where then is this line? That's a hard issue and one that I don't really have a good answer to,
but that discussion is needed anyways. 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, in whatever sense you're evaluating that.
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.
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.
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.
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.
You know, when there are privacy preserving alternatives,
such as other existing protocols and solutions, they should always be explored first.
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. 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. But the design choices were questionable or even arguable at first, but they never really
changed. 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. So this is not a good place to be in.
But as for the future, at least there's hope, because only yesterday I read this.
But only time will tell where we go from here. And that's all I had to say. With that,
I'd like to say thank you. It's been great fun and I appreciate you all being here.
And now for some Q&A.