Who is talking to us about cutting Gordian's end years of focus versus privacy.
Not. Take it away. Yeah, thanks.
It's good to see you here and I'm happy you managed to make it to our celebration
today because we're going to celebrate the year of the Linux desktop.
Hey! Oh no. Wait a second. I need better glasses.
We are celebrating the 25th consecutive announcement of the year of the Linux desktop year party.
But, I mean, why is this so? I mean, the amazing thing is the whole backend
of the Internet runs Linux, right?
But why is the only thing that runs on the desktop is a running joke?
Well, actually, because we have values. And don't get me wrong,
I'm not criticizing this.
Values are the backbone of our community. It is what makes us strong in a world
where values seem to lose their value.
But right now, they're holding us back from conquering the desktop world.
And we're going to change this. I mean, not our values,
of course, but we're going to harmonize our values of privacy and end-user focus
and make the year of the Linux desktop perhaps become reality at some point.
And even more, let's bring our values of digital privacy and sovereignty into
larger society and have everyone benefit from them.
Privacy is the backbone of a free and an open society.
And I truly believe this is possible. And I truly believe this needs to start within our community.
In my talk, I'll outline how this will work.
I'll show what we have already achieved. And I hope that I can inspire you,
dear friends, to help build this better future together. KDE is actually crucial
for this long overdue change in society.
For a society with real and working digital privacy for everyone.
Let's dive right in.
Our manifesto is a great reminder to focus on the end user.
This is why we have an amazing UX group doing incredible work.
Some of the older ones might even remember I had my shares in creating it.
But do you know what UX stands for? It is user experience.
And to truly excel in this art, we need to know a lot about our users.
Because one important pillar of UX work is data-driven.
It's based on the experiences and expectations of our actual or potential users.
And this doesn't fit with our passion for digital privacy, one of the core values of our vision.
We don't want our users to unveil personal information.
We want them to stay private.
And this is actually not only the struggle of KDE. This is the struggle of my
life, being a UX professional and a privacy activist at the same time.
And it's something that we share with most user-facing free software projects out there.
We all value privacy, so we don't know who our users are or what they want,
and thus we cannot innovate our products.
We are missing one of the most important pillars of doing effective UX work.
Commercial user-facing software is doing just the opposite.
They're invading users' privacy and shamelessly use this data next to other
things to innovate their products.
And we can just copy them. We follow up on them, coming second place.
Ways, we as free software have a hard chance on winning the battle of creating
the most innovative user interfaces.
Just imagine for a moment how a world could look like if this were different.
In this world, users would have total control over their personal data.
A world where personal data, without compromising its owner's privacy,
is used for the good of the individual and the good of society and not mainly
for profit-oriented companies.
A world where KDE knows exactly the same things about their users as every other player on the market.
A world with a working and reliable digital privacy for everyone.
What an amazing place that would be.
And this is the vision we at the nonprofit private EV work on.
All of us are users, and we have a right for digital privacy.
Our mission is to ensure that this right is realized in an easy and manageable way for everyone,
and not only for an elite that can arguably do this already today.
So we are creating the ecosystem needed. Technology, legal frameworks and social pervasion.
And I'm here to ask you to help us achieve this vision.
I'm going to explain this ecosystem now and let me first introduce the relevant players.
To start there's us, the users, everyone.
We have a right for digital privacy. At the Pryvect EV we are representing this group.
We do what we as individuals cannot do ourselves.
So all our personal data and hence our digital privacy is protected.
We always work only in the interest of the users.
We at Pryvect follow a very broad definition of personal data.
Everything we do because of our active actions or even our passive existence,
we consider as personal data.
And we all use products, we call them services here, that provide some value to us.
KDE software, any internet service you use, your IoT bulb, your car are just a few examples.
We have a one-to-one relation to them and usually we have to accept their terms and conditions.
These services nowadays consist of something that you install or use on your
computer or your property.
And something that happens in the cloud.
In the example of KDE, you install KDE applications on your devices And then
user feedback sends some data into the KDE cloud.
While we do this very privacy conserving and well thought, you all know of those
services where the local part is basically for presenting information and surveillance.
While everything else happens in the cloud. And the entire idea of the ecosystem
we are developing is pretty straightforward.
We want that storage and processing of personal data only happens locally.
That's it. So, if you want to be in control of your data, you cannot store it in the cloud.
Storing in the cloud means you have to trust. And trust is the opposite of control.
In our new ecosystem, data needs to be stored in a way that you have control over.
Locally or in places you actively choose.
Computations have to be done locally again, not in the cloud.
And any data transfer into the cloud should be a real exception and well justified.
Of course, for example, if you buy something in an online store,
that store will have to know what you bought, where to send it to and how to get paid.
And to be even more specific, in the new ecosystem, if a service wants or needs,
for legal reasons, for example, to store personal data in the cloud,
handling of this data will automatically get authorized by you.
For this, each data point will get a digital contract assigned by you,
stating for what purpose and how long the service is allowed to store this data.
Additionally, this data will be signed by the service's public key,
so only the service can actually use your data.
And this has advantages for you and for the service.
You will always know which data is stored where, for how long and for what purpose.
And the services on the other side can always prove the data they store is legally
OK, it is GDPR compliant. find.
The rest of the ecosystem I'm going to present now is there to make this pretty simple change work.
The change again is allowing local storage and processing of personal data.
But let's first go through the players. Another important player we call research organizations.
They are not interested in your or your or your or my data. They are interested
in how we as a group behave.
This could be KDE trying to figure out what their users like about the software
or what they dislike about the software.
This could also be a university research group trying to understand human behavior
or your local initiative trying to understand how your neighborhood works or what.
Also, startups and commercial companies fit in here as well.
And it is crucial that every research organization has the same access to our collective data.
After all, our collective data is what drives innovation nowadays.
The challenge with implementing something as simple as a traffic jam detector
is not in the code. It is in the access to the needed underlying data.
And this access needs to be broadly available, but always requires the consent
of the individual and must never compromise the individual's privacy.
To make this all work, we'll need another institution that can act as a trustee
and as an advocate for the users.
It will do what we as individuals cannot do on our own.
At the moment, we're calling it the foundation because it's not named yet and
will be legally set up as a foundation.
This, just to be clear, is not the private EV. The goal of the Private EV is
to find partners to help us get the foundation set up and running.
The Private EV is there to kickstart the software development,
to get the legal bit sorted and to work on the social pervasion.
Once the foundation is set up and running, it's time for the EV to bow out.
But like the EV, the foundation will be non-profit and always act in the best
interest of you, of us, the users.
The heart of the foundation's work is maintaining what we call a central database schema.
It doesn't contain any personal data. It just a catalog, it lists and describes
all the data points local databases can potentially contain.
All actual personal data is always and only stored at the user's local databases.
For this to work, services need to tell the foundation about new data points they want to introduce.
The foundation will then check if this data point already exists.
If not, it will create it. And all this process is not about censorship.
This process is about respecting standards and avoiding duplications.
Once the schema is updated with the new data points, it is synced with the local user databases.
From now on, services can store data in the local user database.
And this workflow is non-negotiable. The local database won't accept any data
that hasn't previously been registered at the central database schema.
The main reason for this is to make it efficient to handle your data.
You'll want to share your data with other services too.
Services that only want to read, but didn't write the data in the first place.
They will need a comprehensive catalog of potentially available data points
to find the data they actually need to provide the service you expect from them.
A good example for this is your address data. Lots of services will need it,
but when you move house, You will want to change it once and for all of these services.
But you also need to control which service is allowed to access which part of your personal data.
So for the foundation maintaining the central database scheme,
this also includes the categorization of data points.
These categories could be anything from health data to location data to financial
data. Again, this categorization gets synced with the local databases.
When a service now asks you to access your personal data, you can choose to
allow or deny access to any categories.
This is just like today you allow apps on your phone, for example,
to access your camera, your address book, or whatever.
In consequence, you will always have full control over which services can access
which categories of your personal data.
And finally, we need to get all of this into a legal framework.
If a service wants to join the ecosystem, it'll have to sign the foundation's terms and conditions.
These terms and conditions will give the foundation the right to audit whether
the service follow the rules of local processing and storage of data.
And this is a big win for us users in terms of legal protection.
If we want to use a service, we have to agree to their terms and conditions.
But these now have to be in line with the Foundation's terms and conditions.
And this is a civil law obligation for services to follow the Foundation's rules,
which we will enforce if needed.
For example, in the EU we don't have to wait for the Irish Data protection commission
to take legal action against services that aren't following the rules.
The foundation will handle this on behalf of those affected by data fraud.
This is going to be a big improvement in the legal situation for all of us.
And services will get something valuable in return.
They can use the foundation seal at the point of sale or the point of usage
to show they they respect users' privacy and take part in the ecosystem.
This is important because from the user's perspective.
Using this system will be just as easy as buying ecological food.
As a user, you will just have to look for the seal to be on the safe side.
Technically, the first compliance service will install all the needed dependencies.
This is just a few clicks for you as a user. And after this,
you as a user just have to choose the right products, the ones carrying the
seal, to reliably protect your privacy.
Everything else will just work.
And this is how the system works from the services perspective.
To sum it up, services are one-on-one services, products that make your life
easier. You choose to use them.
And in the new ecosystem, they are required to store and process data locally.
In return, they can use the foundation seal. and to differentiate on the market against a competition.
And they will be compliant with all legal requirements.
Personally, I would love to see a local running AI assistant that can access
all my personal data and help me to stay healthy or manage my day-to-day tasks.
But as I said before, Therefore, the Envisioned ecosystem isn't just about what's
good for us as individuals.
As I said before, our collective data is what drives innovation nowadays.
Our collective data will help us solve the big and small problems we face in society.
At the same time, we need to make sure our individual data is always protected.
And we probably don't want to support research from every institution.
So I'd be happy to participate in a KDE survey, but there are lots of companies
out there I wouldn't want to donate my data to.
So how do evaluations on our collective data work in the new ecosystem?
How can we make sure that everyone involved has given their full consent and
that their privacy is protected?
To start.
The foundation is going to provide a web service where research organizations
can ask their research question in a way the system can understand.
Once again, the central database schema is the source for all the data points
that are available for research.
Once the research gets started, it hops through all the users following what
we call the federated secure aggregation protocol.
Then it goes back to the foundation server where we do last privacy breaching
checks. This could be something like low numbers in certain cells.
We're going to mask those and send the data to the research organization.
So how do we get user consent for the query issuer? And how does the federated
secure aggregation protocol work?
Let's first look at the consent part.
Research organizations can report on their social impact and behavior on a number of categories.
These categories will evolve over time.
But to give you a heads up, some possible examples are the industry they work
on. Are they for profit or nonprofit?
How about employee insurances like unemployment insurances or health insurances?
The existence of unions? Or how many women are on the board?
What about their current CO2 balance? And how are they planning to reach carbon neutrality?
These are just a few questions they can answer. And just like with services.
The foundation will get the right to audit these research organizations,
this time focusing on the before-mentioned categories to make sure that the
information the research organizations provided are actually true.
Now, as a user, you don't have to accept or decline to individual queries. theories.
Instead, you can define how you want an organization to socially behave and
exact the same categories the research organizations had to answer before.
If the organization that's asking for your data behaves the way you expect,
then your data will automatically be included in the actual query.
If not, you will not contribute your data.
We are matching you and the research organizations.
As an example, when you think proportion of women in company management should be more than 40%,
then your data will only be included in research from research organizations
that actually have more than 40% women on board.
And this mechanism basically turns your access to your data into a direct political instrument.
You can directly express what you expect from organizations in terms of how
they should socially behave.
And this will, in return, encourage organizations to work on improving their behavior.
That's because if they do, they'll get access to larger pools of people who
will take part in the surveys.
Meanwhile, the companies will always be aware of the bias in the queries because
they always know who's taking part and who's not.
There's one notable exception to this rule. And this is a research organization,
or as a research organization, services can always query the data they've entered
into the local user databases.
Let's look at KUserFeedback for an example.
KUserFeedback writes data into the local user database as a service.
Now KDE can query this data as a research organization without having to fulfill
all users' requirements.
That is because as a user you have a one-to-one service relation with KDE.
This overrides the other rule.
If on the other hand GNOME wants to query the KUser feedback data,
which they can, then they would have to match users' expectations as an organization.
So, they will only get the information from users where this matching works.
That's for the consent part. Let's at last point look at the federated secure aggregation protocol.
Once the query is published, clients can check if they want to participate and register.
Register and once there are enough clients that have registered the server will
assign randomly one of those clients as the aggregation client.
This aggregation client will create a private public key pair for encryption
used for message encryption and send the public key to the server.
This key is used for message encryption. Next the server will create another
key pair this time using the PAYE ecosystem, the PAYE crypto system.
PAYE is an additive homomorphic encryption system and this is used for data encryption.
The server now shares the two keys and the survey itself with all the clients.
Each client now fills out the survey, encrypts the data using the PAYE key,
encrypts the message using the message key and sends all the data to the server,
which will forward it to the aggregation client.
The aggregation client is now able to decrypt the message, not the data,
but it can aggregate the encrypted data using the PAYE system.
Once that's done, the still PAYE encrypted data gets sent back to the server,
which can then decrypt the aggregated data without knowing any details whatsoever
other than the final result.
This federated secure aggregation protocol is a combination of well-established
data protection and analysis methods.
It combines the benefits of
federation with encryption and includes final checks for privacy breaches.
This way we can be sure that everyone is protected while we can make statements about groups of users.
You now have a first overview of how the new ecosystem is going to work.
There are lots of more details and we'll hopefully have some time to answer
your questions at the end.
We also offer two Birds of Feathers events on Monday and our developers,
who unfortunately couldn't make it today, will be around then to answer questions
which I can't answer, so the more technical ones.
And we'll show you a demo of what we got.
We were in the lucky situation that we got funding from the German prototype
fund and let me take the chance to say thank you for that, it was a great opportunity
and the German prototype fund is a real good great funding program.
And to give you more insight into the current state,
we have created a patch that allows KUser feedback to store data as a service
in a local database and we've created the server that allows KDE to evaluate
this data using the federated secure aggregation protocol protocol,
and thus to get insights into our user base.
So as a result, we will be able to learn about our users, what they're trying
to do, what they like about our software, what they don't like about our software,
and all of this without compromising their privacy.
This lets us do great work without having to compromise our values.
Gordian's knot has been cut. And who knows, there might be a chance for the
year of the Linux desktop to become a reality.
We can finally start to innovate driven by real data from our actual users.
So, what's the plan for the next steps? First of all, let us start a discussion
about how we want to adopt this new technology into our tech stack.
What we have is a demo, a proof of a concept, not a finished product.
Together with you, we can take the demo and turn it into a product.
A product we are willing to upstream.
Once we've launched our first product, we'd also love to see our friends benefit from it.
We are not the only community that respects privacy, but in return does not
know enough about their users.
LibreOffice, for instance, is eagerly waiting for us. If we team up with them,
we can take the product beyond the Linux world into Mac and Windows space.
This way, we want the ecosystem to mature, step by step.
Because basically, all user-facing free software communities have the same problem
as we do. and we'd love to help them out.
This is also why we did not set this up as a KDE project.
We're definitely rooted in KDE, but the whole project is meant to grow beyond.
Once we've grown to the point where several free software projects have adopted
the technology, it is time to officially establish the foundation.
We want free software to benefit from it, but we also want everyone to reclaim
privacy in their digital lives.
That's why we need commercial proprietary services to get involved.
And at that point, there are plenty of reasons for proprietary services to join.
EU legislation, for example, the EU Data Act, requires services to open up access
to the data they produce.
And they will need a working marketplace.
With lots of free software projects using the ecosystem, there'll be millions
of users that have already installed the needed software.
It'll be a proven solution and we provide a legal partner and a transparent marketplace for data.
So services will only have to adjust their technology to work locally again
and they can join a working ecosystem system and save a lot of money because
they need less cloud services and less overhead to stay for example GDPR compliant.
And once commercial services are up and running, we'll have a business model
that lets us keep the infrastructure in good shape and make it better where it needs to be.
We've created an ecosystem that saves everyone's privacy for the benefit of us, the users.
And as a free and open society. An ecosystem that will always remember its roots. The KDE community.
Well, thanks for your attention. We have some time for questions now.
So thanks for your talk. One question, like here we have many developers and
we see homeographic encryption, that makes sense to us and we can trust it and we can look at the code.
But how would I convince my mother that it's really safe for her to share us
the data? You don't need to.
Because, well, we would do. We as KDE adopt the technology.
It's not private or the foundation trying to convince anybody,
but it is trusted parties like the KDE community, like LibreOffice,
like other free software projects that sort of stand there and say, this is safe.
And we have not sort of asked for your personal data in the last years because
there was no safe way, but now we trust it.
So basically, we are sort of, you know, instrumentalizing other trusted instances
to get distributed and to find users.
Yeah, thanks for the talk. I think it's a very cool idea to have this secure aggregation protocol,
but I don't quite understand how it works because I understand that the splits
between the server and the aggregation client is for the purpose that the server
cannot see the individual data.
But how can the other clients trust that the server doesn't select a device
that the server controls as the aggregation client?
If I, as the server, want to get all the individual data points,
I can just make the server select
my smartphone as the aggregation client and then I have all the keys.
So what do you really win by doing this pattern?
Well, you can't remove trust from the whole equation. We can only try to minimize
the needed amount of trust.
And obviously the foundation is an institution that will have to earn the trust
that is needed so you can rely on it not working as a bad actor.
We've set up the technology in a way that it sort of minimizes the need to trust,
but in the sense if you want to attack a system, you can attack any system.
And there is trust left that the foundation needs to earn and needs to justify that it has.
And we want to try to use best patterns there are.
So we obviously do everything open source. We want to, you know,
have the foundation, the foundation itself needs to get audited by external
instances that it actually does what it claims to do.
Yeah, we want to encourage white hat hackers to, you know, find flaws in our
system and so on and so on.
So we want to improve, we want to apply all the best practices that are out there.
But in the end, you're right, if you want to sort of criticize it to the end,
there is trust needed. Yeah.
So you talked about the conditions that you would like the research organizations
to answer about themselves that would be used to select which end users,
and the end users have answered and similar questions about which of which they're willing to share with.
That's going to require a lot of thought is the place I sort of need to put.
For example, you go, okay, we will ask a question that is, does your board comply
with 50% female representation, for example, and as an end user I said I want that.
But then the research organization that gets set up.
Need for by businesses that
do not conform to those rules and is
set up with enough funding to do that and is independent once it's set up can
gather that information and sell it to the available customers and in order
to survive as a business it's going to need to do that and so it's going to
sell the data on to people who don't necessarily conform to those constraints rates.
So some care may be required in formulating the conditions on research organizations.
Yeah, well, you point to a problem that can't be solved technically.
That's a problem that has to be solved legally.
So basically, that's something that will have to be addressed in our terms and conditions.
And we'll have to audit organizations to behave well. And if they don't, we have to sue them.
But this is something we can do as a foundation because this is something you
can't do as a user. You can't sue Google.
That just won't work out. But this is something we want to do and this is why
I said it's not only technology, it's also the legal bits and pieces and it
is the social pervasion.
These are the three important pillars we have to work on and technology is only one of those.