All right, thanks everyone for coming so early.
I admire your acudos for getting here so early.
I'm very impressed to give up this early in the morning.
I'm David Llewellyn-Jones.
I work for a company called YOLLA O in Finland.
We make an operating system called Selfish OS for mobile
phones like this one.
And today, I'm going to talk to you
about COVID exposure notification.
It's actually a project that was done.
It was a personal project rather than something
related to the company.
But it was something that relates to Selfish OS.
So hopefully, it all comes together
in some kind of sensible way.
OK, so exposure notification.
It's almost certainly something that you've all
come across individually.
It essentially is the apps that people
ran on their phones that did contact tracing.
They pinged.
They would give you an alert if you had been in contact
with someone who had a COVID diagnosis.
And I guess they were a big deal during COVID.
I guess probably they're less of a big deal now.
Although, I mean, I track the numbers on my phone
while I'm at FOSDEM, and there's still
a lot of people at FOSDEM using them.
I can tell that.
And the idea about this talk is that I
want to talk about a very particular implementation of it.
And that's the Google Apple exposure notification
protocol, which was released, I guess, in April 2020.
And it was an implementation that
went out to Android devices and iPhones
in order to basically provide the services needed
in order to allow countries or medical organizations
to build apps on top of it in order
to perform this contact tracing process.
And initially, when it was released,
it was called, as you can see here, the Contact Tracing API.
Later on, I guess that name was a little bit ambiguous,
a little bit confusing.
They changed it to the Google and Apple Exposure
Notification API.
I guess when people think about contact tracing,
they think about maybe people phoning them up
and asking them who they've been close to.
But it is all the same thing.
And this was the original specification.
Like I say, the original one was released in April 2020.
And it's made up of these three documents.
It was initially this was version 1.1.
I think they're up to version 1.4 or later now.
There's been several versions that have come out since.
So they've refined the protocol.
And I guess it's worth putting it in a little bit of context.
Back then, when this was released, there was no vaccine.
So at that point in time, people thought
that the World Health Organization predicted
that vaccine was about 16 months away,
but no one was entirely sure.
In practice, the first vaccine was actually approved
about nine months after this.
But you can imagine that at this point in time,
people were very worried about COVID.
They were concerned about how it was going to be dealt with.
And this was seen as kind of like a kind of one really
quite exciting way to address the problem,
given that there were so few tools at that time
to deal with things.
So let me just talk about these three documents.
The first one on the left here is the Bluetooth specification.
So it's made up of three parts.
The Bluetooth specification, I'll
talk about how it works in practice in a second or two.
But it's sending beacons using Bluetooth from your phone.
So the Bluetooth specification tells you essentially
what how to pack the data into a Bluetooth beacon.
And also other details like, for example, for privacy reasons,
the information in the beacon changes periodically.
And you have to change the MAC address of your phone
in sequence with that in order to avoid privacy problems
coming up.
So that's that part.
There's a cryptography specification,
because the data that is sent in the beacons
is cryptographically, I guess, hidden for privacy reasons.
And then finally, there's the framework documentation,
which is the API, which is really describing
how organizations can make use of these tools.
And I guess another important point about it
is that there are two parts to the process.
So Google and Apple released this API for all phones,
but that's actually only half of it.
That sends out the beacons.
But as those beacons go around, eventually,
you have to do something with that data that's being sent.
And for that, you needed an app that
was going to be written by a government organization,
a government level organization.
Like it could be a health organization.
And Google and Apple had nothing to do with that.
They said, you've got to write that part.
We'll just give you this piece here.
And the project that I'm essentially talking about
is about a re-implementation of this for Salesforce.
And so, of course, we had to also deal with those two parts
separately.
So this is only one part of it.
All right, so one of the nice things about this protocol
is it's actually heavily privacy-focused.
So you can imagine also at that time,
there was a lot of concern about the fact that you're
sending beacons out on your mobile phone.
There are privacy concerns about that.
And the protocol tries to address that in a very careful way.
And that's actually rather a nice feature about it.
All right, so when it was released,
this is actually a slide from Google and Apple.
I did not draw these pictures.
And this basically describes how it works.
So very briefly, Alice and Bob are wandering around the world.
They have the app installed on their device,
sending out beacons.
When they get into close contact with each other,
their phones are communicating via Bluetooth.
Well, they're not exactly communicating.
They're listening for these beacons.
And they're storing the beacons that they hear.
OK, so that's step one.
So when they get close to each other,
Bob's beacons get stored on Alice's phone.
Later on, Bob turns out to have COVID.
And he gets a positive diagnosis.
And he basically goes to his doctor.
He gets an official diagnosis.
And he puts that information into the app.
And he voluntarily uploads data about his beacons
to some cloud server that's run by a government or health
authority.
And he uploads 14 days worth of his beacons.
So in practice, these beacons are actually
generated using a cryptographic process.
So you don't have to store on your phone 14 days worth.
You just store essentially the seed that generates them.
But they change frequently.
So they change between every 10 and 20 minutes.
It's actually a random interval somewhere between those two.
In order to prevent people from tracking you,
they are unlinkable.
So when they change, you can't link one from the other.
And that means that there's a limit to how far you can track
people.
But Bob can regenerate those keys to upload to the server.
Alice just gets random, essentially random numbers.
She can't tell what those numbers are, essentially,
or what they mean.
So then later on, so I guess the next day.
So this happens later.
But then the next day or later on that day,
the keys get uploaded to the server.
And the server then dumps all of the keys
that it receives back to every single device out there.
It downloads these keys to all of their phones,
to everyone's phones.
So it downloads them to Alice's phone.
Alice then, Alice's phone then matches them up
with the keys that she captured along the way.
And she then knows that she was in contact with someone who
has a positive diagnosis for COVID.
She gets an alert on her app.
And then her life is held for two weeks.
That's basically the process.
She has to isolate and go through all of the steps
that you have to go through.
We don't know whether Alice has COVID or not.
The idea is she might have.
So at the time, it was a kind of a big deal, like I said,
because it was seen as a kind of a white horse
to get us out of the problem of COVID.
At that time, everyone was focused
on this thing called the R number,
where the idea being that the R number was the number of people
you essentially go on to reinfect after you have COVID.
And the objective was to keep that down
if the R number was above one.
There was an exponential growth in the number of people
that would have COVID.
If it was below one, then it would be reducing numbers.
And the aim of all of this process
was to keep people isolated if they might have COVID
in order to reduce that R number and prevent it
from spreading.
Google and Apple came out with this protocol
because they immediately identified
that there were going to be serious risks involved
in tracking people with their mobile phone to do this stuff.
So they knew, for example, that there
were privacy risks associated with it.
They knew that if they let governments go ahead and just
do it, they would just collect everyone's data
was the concern.
Or some of them might do.
Maybe not all of them, but some of them might.
They also knew that sending out Bluetooth beacons.
Sorry, you have a question.
Sorry.
If Alice receives keys from infected people,
can she not match that with the relative time
she got the ring detected?
So she knows that the key is the one
that she found two days ago, and two days ago was the time
she met up.
So is there a problem?
So I guess I should make clear.
So I mean, there are privacy controls in this,
but they're not complete, right?
And the idea is that essentially, at the point
when you upload your keys, you've got your diagnosis,
that's essentially when some of your privacy is lost.
So but you voluntarily choose to do that.
That doesn't happen automatically.
Does that make sense?
OK.
But it's a good point.
So yes, but Google and Apple were
concerned about the privacy implications
because it reflects badly on their systems, right,
if their phones are doing this stuff.
Also, the power consumption is a problem,
so they didn't want government organizations to deploy apps
that would have problems in terms of battery on their phone.
And they also wanted it to be effective,
because if it's not effective, that also reflects badly on them.
So they identified that there were all these risks
that they wanted to avoid.
And even at that time, the APIs that Google and Apple
provide prevented people from doing this kind of stuff
for precisely those reasons.
Not, I mean, it was nothing to do with COVID.
I mean, they've always just prevented you
from sending out beacons and collecting beacons
like this in a sensible way.
Primarily for power consumption reasons, right?
They don't want people draining the battery
of the phone to do that.
So my concern as a YOLO employee was that, well,
Google and Apple have released this stuff.
It's probably going to get quite popular.
And I didn't want selfish users who
are using an alternative operating system, which
is not Android or iOS, to essentially get
sidelined by this process and be left in a situation where
they can't basically participate in this scheme.
So the objective then was to create an open source
implementation that could be used on other sorts of phones.
So this is Selfish.
Selfish OS is a Linux distribution
that has a cute UI layer on top of it.
And it is sold by, well, it's released by YOLO.
And then there is also a paid-for license
that you can get for it to get additions on top of that.
So yeah, the idea was to write an application that essentially
mimicked that functionality.
And so this was the app that myself and Oscar Rosler,
I don't know if Oscar is here.
Is Oscar in there?
I guess not.
He said he might turn out.
But I guess he's not here at the moment.
So we developed this together as a kind of a personal project.
And you can see here's the process.
This was like the first time that we actually
got Beacons appearing on the device.
So that was a kind of an exciting moment.
And there are, I guess, like several steps.
There's the collecting Beacons.
There's sending Beacons.
And there's also uploading your data
if you get a positive diagnosis.
So we implemented all those parts.
And we tried to implement it in the same way
that the Google and Apple did in terms of structure.
So you have a service underneath that sends out these Beacons.
And then we had a separate app, which was the equivalent
to the app that had to be developed by governments.
And in theory, other people could
have developed other apps on top of the service.
I don't think that ever happened.
We only implemented one version.
And the version we implemented was the COVID WARN app,
which was Germany's implementation.
And the reason we did that was because it was both very early
in the process in terms of being deployed.
But it was also incredibly open.
It was an open source deployment.
And they were really committed to doing it as an open source
product, I mean, an open source project.
Not just an open source chunk of code,
but the development model was also supposed to be open.
It was actually developed by SAP and Deutsche Telekom.
I think my understanding is that SAP did all the code
development.
Deutsche Telekom provided the infrastructure for it,
the back-end service infrastructure.
So like I say, we did this independently of YOLA.
For those interested, it was Qt-based.
It used Bluezy for the Bluetooth stack
and OpenSSL for the crypto stuff.
And this was the timeline, essentially,
that we worked to.
Or we didn't work to that we ended up with, I guess.
So on the 10th of April, that's when the Google and Apple
specs first came out.
We released our first version implementation
of those specs on the 19th.
So that was quite soon afterwards.
Then the COVID WARN app from Germany
came out on the 16th of June.
And then on the 30th of June, so quite a few weeks later,
but we got our first app that had equivalent functionality.
So we were pretty happy with that.
We thought that could be considered a success.
But it was only possible because the specifications
that Google and Apple rolled out were very good.
There were clear specifications that you could re-implement.
And the COVID WARN app team also did a lot of good work
in releasing source code very early.
They had a huge amount of documentation
that was all on GitHub.
They even had, I guess, a CCC evaluation
of the project in terms of its privacy.
So they were really quite committed to being open
with their stuff.
In practice, what we found was, so they released some reference
versions of the servers.
And we found that really helpful.
That was really important.
They also released the source code for their app
that we re-implemented.
We actually ultimately found that that was not so useful.
It was useful for some edge cases,
but really it was a server deployment that was really
helpful for us.
So I guess the real reason that I wanted to talk today
was to talk about our experience working with these companies
as small developers, as independent developers.
And I guess it was very much as you might expect in terms
of Google and Apple.
They produced, I mean, they're phenomenal at producing
good specifications and good APIs.
That's what they do.
That's their bread and butter.
They're absolutely flummole at it.
But zero engagement.
So we tried to contact them and talk to them about their stuff
to try and get information or to get help.
Nothing at all.
Which is, I guess, not surprising, right?
They're a massive company.
There's no reason why particularly they would.
They promised test data to test stuff against,
and that never materialized.
So there were also some bumps in the road for us.
And although they did release the source code,
they released the source code for a reference app
quite early, but they didn't release the source code
for the underlying system, the Bluetooth system,
until somewhat later, until I guess that was late in July.
So for us, that was already too late.
So working with them, like I say, there were good points,
but they were not really having an open source development
model.
For SAP, working with the SAP code
was a little bit different.
So this is essentially the SAP implementation
that they developed on top of the Google Apple notification
protocol.
So this is the app, and this is the server
back-end on the left-hand side.
And the main parts of it are this verification server,
and from our point of view, and the Corona WARN app server.
So essentially what they do, you have to have a download
server to download all of these keys that
are going to Alice's phone and to everybody's phone.
That happened in the Corona WARN app server.
You have to have a verification server
so that when you get a positive diagnosis,
you can upload it in a secure way with your identity,
essentially proving that, not with your identity,
but proving that you've got a positive diagnosis
from your doctor.
And then you need an upload server to upload your keys to.
And that happened also in the Corona WARN app server.
So in practice, this was actually two servers, not one.
So those were the two bits we were interesting in,
and we had to deploy them to test against.
We couldn't deploy the whole lot.
That was going to be impossible.
That was not really a plausible thing to do.
But they did have a reference implementation
of these two servers.
And so we tried to deploy, we tried to deploy, well,
so we did end up deploying those to an AWS server
and testing our code against those.
And what we found was that the download server implementation
was a little bit broken.
We had to fix it, but it was otherwise pretty good.
There were just some glitches.
Whereas the verification server and the upload server
were pretty minimal.
So we actually essentially had to re-implement parts of those
based on the specification in order to do our testing.
But they did release a lot of code with this stuff.
And the fact that they had these reference servers
was absolutely key in allowing us to re-implement
the protocol.
So our overall experience was that they
produced lots of code and lots of documentation,
which was really good.
They were one of the earliest teams
to get this stuff out into the wild,
which was in terms of source code, which
was also phenomenally good.
They worked through GitHub issues.
So when we found problems, we would submit pull requests
to try and fix the code.
And it was clear that they were trying
to engage with that process.
But in practice, they were just taking way too long.
So by the time, so for example, we
would fix something in one of the reference servers.
And people would be using our PR code to deploy elsewhere.
But by the time they got to actually thinking
about integrating it, it was already too stale.
It was no longer useful.
So they were clearly trying to do that.
But I guess it was just a question of time.
So as a consequence, some of the code
was left broken for quite a long time,
even though there were fixes that they could have just
integrated.
Some of the reference implementations
differed quite significantly from reality
in terms of the servers.
But there was something to work with,
and that was really helpful.
And so our overall impression was
that they had this real commitment to openness.
They were genuinely committed to doing this well.
They had an open development process.
But the team were just a bit overwhelmed
with the amount of effort involved in doing it.
That was the impression we got from the outside.
So we were very impressed by this.
But obviously, there's obviously scope
for learning there in terms of how to do it better.
So my overall reflections on how things went
were that at the time, I think again,
you have to put this into context,
there was huge pressure on governments all over the world
to get this stuff deployed.
So the first deployment was in South Korea,
was I think the COVID 100 meter app.
And that went out really early.
And as soon as that went out,
and that used GPS positioning, GNSS,
so that it uploaded people's locations to the cloud,
I mean, essentially zero privacy in that situation.
But as soon as that was out, all other governments,
there was a lot of pressure for them to do something similar.
There was a huge rush to deploy this stuff.
And so there was a lot of pressure,
and there was a lot of competing requirements.
The requirements for openness was just one requirement.
There was also requirements for efficacy,
requirements for speed, requirements in terms of privacy.
All of these things combined
are actually quite challenging to get right.
And both Google and Apple and the CWA team, the SAP team,
the impression I got was they really got that.
They really understood these competing impressions,
but they also understood the need for openness.
They understood that in order for people,
not just for them to do it well,
but for people to trust the apps that they were running,
they also needed to be open about it,
and that's one of the reasons they did it.
And in that sense, I think they were pretty successful.
Like I say, there was scope for improvement.
With, you know, there was, as I said, with Google and Apple,
there was zero inward flow of information.
With SAP, there was, and so with both teams,
there was a lot of outward flow of information
that was excellent.
With SAP, there was some inward flow,
but not as much as perhaps we as independent developers
would have liked.
And I guess more generally, what we kind of felt was
that there was this commitment to openness,
but not necessarily a full appreciation
of how much effort was involved in that process,
in getting that process to work really well
and effectively for the companies involved.
So, for example, and I guess I should say
that YOLA also works with a lot of open source code,
so we also have an open development process
for a lot of our stuff.
And we have the same challenges, right?
So, people provide PRs for us to integrate into the system,
and knowing what is good to integrate
and what is bad to integrate takes a lot of time and effort,
right?
It sounds like you're getting free implementation,
which I guess in some sense you are,
but there's still a lot of effort involved in that process.
And like I said, I guess with this process
that we as independent developers experienced
from the outside, it felt like that perhaps
these other competing things were impacting on the effort
that they could put into that process.
So yeah, so overall, given that these organizations had
absolutely no duty towards us as independent developers,
we were kind of very happy that we
could work with the things that they'd given us
and that they were actually high quality.
So we're very pleased with how it went,
but like I say, we felt that there was definitely
some room for improvement.
OK, so that's my summary of how things went.
Thanks for taking the time to listen.
There's some links in case you're interested in more.
We are actually on the Linux on mobile to stand in Building
K up the top of the stairs, so if you
want to talk more about it later,
please come and visit us and we'd be happy to do that.
Thanks very much.
Is there time for questions?
Yeah, there's five minutes for questions.
We don't have a microphone.
Yeah, you speak up and have to repeat the questions.
OK.
Especially for the live stream.
Right, understood.
What's your experience with the, like,
they used rootin for the proximity,
but there was some discussion like either you
would get too much notification, contact notification,
because it was too wide, but it would get too little,
because it was too restricted.
Right, so your question is, what's
my experience with the Bluetooth parts,
the Bluetooth notifications?
Because as you were saying, at the time,
there was a lot of discussion about whether it
was going to give enough accuracy in terms of proximity
detection.
So the key thing with the COVID notifications, of course,
is that there was this two meter,
there was always this, like, or some distance
that you were supposed to stay away from people.
And so in terms of the Bluetooth,
you wanted to try and mimic that process.
You wanted to accurately distinguish
that someone was within two meters or some distance
or outside that distance.
That's essentially what you're talking about in terms of proximity.
So it's interesting, actually.
So when we started out the process,
the protocol didn't specify greatly how to tackle that.
So what happened, what actually Google and Apple did,
is they set a bunch of risk parameters
in their implementation that you could tweak,
that you could change.
And they came from the download server.
They were set by the government organizations,
not by Google and Apple.
And they basically said, they gave weightings.
How much risk do you associate with a power level
of this for the Bluetooth?
And how much risk association do you
put with how long that association went on for?
Like, is it five minutes or 10 minutes
that they're within range of this distance?
So you could tweak those parameters.
And later on in the process, Google actually
released a lot of information that
provided essentially weightings for some of the parameters
for almost every phone on the market.
So they had a process where they would basically
put two phones on stands next to each other
and measure the power consumption that came through.
And then based on which phone was communicating
with which other phone, they would then
tweak the parameters to try and make
that proximity more effective.
So we use those parameters.
But I have to say, we were not in a position
to check whether or not they were working effectively.
Because what's happening behind the scene is quite opaque.
We're sending data up to a server.
And the whole point is that you then
know nothing about what happens after that
because of the privacy aspects.
So it's actually very hard for us
to judge whether or not it was working well or working badly.
But it was clear that there was a lot of work going on
to get it to work well in the background.
My more general experience with Bluetooth
is it's not great at this stuff.
If there's a person between you and another person,
then water is a big problem for signal propagation.
So stuff that's in between causes a lot of dampening
of the signal.
So it's quite tough with the impression I got.
But I'm not an expert in that, so.
I'm neither.
OK.
I'm curious, a lot of governments
implement solutions over proprietary solutions.
Or do you have an implemented open source solution?
So I'm just going to come a bit closer so I can hear from you.
A few governments that implemented open source solutions,
but not many.
Most have been implemented proprietary solutions.
But I don't know of any government
that re-implemented another government's open source
product.
Was there any collaboration between governments you're
aware of, or even between projects of government?
You see that one of the projects that have never been
between you and that physical failure in the resource
can't repeat the process.
And share it with the government.
And it's distributed to governments of limited value.
Right.
OK.
So the question was, was there any evidence
that all of this open source release of code
resulted in reuse of code by other governments?
That's essentially your question, right?
And I think there was.
So I can't think of specific instances.
But my understanding was that people
did take the COVID WARN app code and use it
in their implementations.
Or perhaps more generally, I think
people definitely took the Google reference implementation
and used that in their code, which was open source.
And of course, was a yes, sorry, which
I guess was an example of open source being reused.
Perhaps more specifically, with the COVID WARN app,
because the Google and Apple notification protocol
was the foundation for it, it was used really quite widely
across Europe.
Not all countries used it, but a lot of countries did.
And at this point in time, I think
there's 11 countries that all use the same back end.
So they're all uploading their keys to servers.
So now if you use the COVID WARN app, or contract,
our version of it, you actually get keys from countries
across Europe, half of Europe, essentially.
It's quite a large area.
So I mean, you could argue that's more a consequence
of having a common API than it is open source.
But there definitely was benefit in sharing of information,
sharing of code.
It did happen, I think.
It did happen.
But perhaps it's not as clear that it happened as it might
otherwise seem.
All right, I'm being told my time's up, so.