GDPR: Make stats export more functionable while keeping users safe

[AenBleidd]

Recently there was a discussion about the stats export and the GDPR (among the others me and @davidpanderson were a part of this discussion).

We identified that initially the implementation of the GDPR compliance was made too strict, that prevents data aggregators to show the correct statistics of the BOINC network.
In particular, new users will never be shown in any statistics export by default if they not enable stats export manually.
However, statistics that is exported by the BOINC Projects contains no personal information (with two exceptions explained below) that might identify the BOINC user is one or another way.

Thus I propose next:

• Enable statistics export of all users and all hosts by default
• Rename current statistics export option to 'Not include personal information into the exported statistics' (better wording here is required)
• For those users who don't want to export their personal information, do not include 'name' and 'url' fields (or make them empty) when doing users stats export
• For those users who have their hosts hidden, do not include <userid> tag (or make it empty) when doing hosts stats export (mostly duplicate ticket shouldn't export credit stats if hosts hidden? #3766 is closed)

[davidpanderson]

Have we decided what constitutes private information?
For example: user name.
When we ask for it, we call it 'screen name', which implies that it's public.
It's shown on the project web site, and can't be hidden.
Similar with URL, country, and user ID.
We show these on the project web site -
why not show them in stats export too?

[brevilo]

We identified that initially the implementation of the GDPR compliance was made too strict, that prevents data aggregators to show the correct statistics of the BOINC network.

Devil's advocate speaking now: "so what?". The aggregators aren't a necessary component that a BOINC project needs to fulfill its service. It's a totally independent entity that can't expect anything from a BOINC project or its registered users by default. Just to make sure: I'm not arguing about what might be nicer for the BOINC ecosystem or not; I'm just discussing this from a GDPR perspective, since that's the legal basis, whether we like it or not. More on the issues related to data transfers and defaults below.

Rename current statistics export option to 'Not include personal information into the exported statistics' (better wording here is required)

This at least needs to be accompanied by a privacy policy that details it the other way round: you have to say what you do export, not what you don't. As is, such an opt-out violates GDPR's "transparency" and "data protection by design and by default" principles.

We show these on the project web site - why not show them in stats export too?

There's a difference between agreeing to publish certain details on a single project one willingly signed up for and having those details transferred to various third parties - without consent. Opt-out doesn't constitute an informed consent. Also, from the data controller's (i.e project's) point of view, what is the legal basis for this data transfer, if not consent? Legitimate interest? Very unlikely (see first statement above).

Furthermore, exactly what kind of entity is a stats site (or any stats export recipient) in the GDPR framework? Since a project ("controller") transfers data for a kind of service augmentation (or does it really?), it's probably a "processor", potentially in a third country or even outside the EU. Just have a look at the can of worms that already opens.

Have we decided what constitutes private information?

This isn't really up to us to decide; there's a legal definition for it. Screen name, URL, country and user ID can potentially be used to identify a natural person, indirectly or even directly. So we need to tread carefully here since that definition is, as with many legal definitions, not cut crystal-clear or tailored to every single use case. How could it be? That's why we have courts after all...

As a project I don't want to put myself into a tenuous position just by hoping for my correct definition of personal data. If you think that's overly cautious, let me tell you that there's an industry out there which sole business it is to find data controllers with loopholes in their data processing, privacy policy, etc. - and sue them for profit, which works because of GDPR's large fines. This is the reason why we have such an elaborate, yet transparent and comprehensible privacy policy.

Honestly, coming back to the beginning, why should I take that risk? For the data aggregators only? I mean, if my users want to export their data, they can and will do it, by informed consent. If not, then they don't want to, or they simply don't care. How does that constitute a problem? In other words: what's the actual problem you're trying to solve that's worth wandering into such treacherous territory?

[AenBleidd]

@brevilo

This at least needs to be accompanied by a privacy policy that details it the other way round: you have to say what you do export, not what you don't

That is a very good point. We have a document that describes the data we are exporting: https://github.com/BOINC/boinc/wiki/XmlStats
In this particular ticket I highlighted the exact parts that we're gonna change.

This isn't really up to us to decide; there's a legal definition for it.

This is true however the data that we're exporting is a non-personal data, and it can't be used to identify the person using it.
You need users' consent to export personal data.

If you can point which data from your perspective is a personal data except the one I already mentioned - please do that.

In other words: what's the actual problem you're trying to solve that's worth wandering into such treacherous territory?

Currently, the way the GDPR compliance was implemented, it prevents us from seeing the picture of our users.
The way BOINC designed, is that it's a distributed network of a project, and we can't see who are our users without asking them to export the data that is not a sensitive personal data: we don't see how much users have some particular OS, etc.
You can identify the user by their stats, you can't do that using CPID as well, there is no connection between the data we have and any personal data of our users.

@davidpanderson

Have we decided what constitutes private information?

The data I highlighted in the one that could contain personal information about our users. That doesn't mean that it has it, but it might have it, that's why it's important to not export it by default.

[bema-aei]

In my understanding the GDPR doesn't allow an "opt-out", any personal data which is publicly visible and in particular shared externally needs to be hidden by default. "personal data" here means anything that could possibly be traced back to or help to identify a person.

I don't think it is a "valid interest" of "aggregators" to gather information about each and every host or user that doesn't want to share it, not even for the time between signing up for a project and finding out how to hide his information. Aggregators will not delete any such information once they have it (unless explicitly asked for, which is another hurdle).

What exactly is the goal here?

If the goal is to just gather statistics of e.g. number of host, users, total credit and RAC of a project or the whole of BOINC, projects could publish that aggregated statistics and stats sites could show that without violating the GDPR, as these allow no tracing back to individuals (well, for projects with a reasonable number of participants).

[brevilo]

If you can point which data from your perspective is a personal data except the one I already mentioned - please do that.

What I'm trying to get across is that this isn't only about those data that I already deem to be personal data, but also those that might become personal data when combined with any other data out there. For example, for the user stats I would exclude not just name and url but also id, country, cpid, teamid and has_profile. I'm not saying those data clearly are personal data but I can't confidently deny they could ever be used to help identify a person. There have been enough examples of such cases, even without LLMs and security/data breaches.

Currently, the way the GDPR compliance was implemented, it prevents us from seeing the picture of our users. The way BOINC designed, is that it's a distributed network of a project, and we can't see who are our users

Understood, but in terms of GDPR this is irrelevant. I understand "us" and "we" in your statement as referring to the BOINC community as a whole or the BOINC (software) project itself. Please understand that those aren't the data controllers. It's the individual projects who are the data controllers and who thus carry all duties, responsibilities and legal consequences. Strictly speaking, I could even argue that the current proposal might loosen important legal obligations for projects downstream, potentially without them being fully aware.

I don't think it is a "valid interest" of "aggregators" to gather information about each and every host or user

The correct GDPR term would be "legitimate interest" but, as I said above, that still misses the point. They could gather their own data, on their own legal basis. But what we're discussing here is that the projects transfer those data to them. That's an entirely different scenario.

projects could publish that aggregated statistics and stats sites could show that without violating the GDPR

Exactly. And that's what we do. And we add those individual users who gave their informed consent. I still think that this (the current situation) is most in line with the principles of the GDPR.

[bema-aei]

projects could publish that aggregated statistics and stats sites could show that without violating the GDPR

Exactly. And that's what we do.

I don't think so, at least not in the stats export. Currently this includes only host and users which have given their explicit consent, but no overall project statistics.

Einstein@Home publishes some statistics on the server status page, but this requires additional knowledge (e.g. how the computing power is actually derived from the project's RAC) and is not standard among projects.