GDPR: Make stats export more functionable while keeping users safe #5398
Comments
|
Have we decided what constitutes private information? |
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.
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.
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.
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? |
That is a very good point. We have a document that describes the data we are exporting: https://github.com/BOINC/boinc/wiki/XmlStats
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. If you can point which data from your perspective is a personal data except the one I already mentioned - please do that.
Currently, the way the GDPR compliance was implemented, it prevents us from seeing the picture of our users.
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. |
|
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). |
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
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.
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.
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. |
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. |
|
@brevilo, |
|
Regardless of the GDPR I find it nowadays questionable to require anyone to share any information that he might not want to share (for whatever reason), here in BOINC not only with the single project he is in direct contact with, but also beyond that. At least for him this is linked to him personally, and if e.g. it's a pretty unusual host, it can still be traced back to him. Instead of opening all information that we consider not to be personal to virtually everyone, at the risk of violating GDPR or scaring people away, I'd rather like to know what exact information (OS? CPU?) on what level (project, BOINC) is lacking, and find a way to collect it in a way that is certainly compliant to GDPR and individual people's preferences. So, what information do you think is necessary and missing? (@brevilo : What's the official equivalent for "Datensparsamkeit")? |
|
I think my position boils down to: BOINC is volunteer computing, and if we want to retain volunteers, we should try to satisfy their wishes and needs before ours (here: do what we might be allowed to). |
Which is reverse engineering at its worst, because RAC (and credit as a whole) is neither controlled or normalised.
User ID and Team ID together could be used, in most cases, to identify the user name and team name. If the team allows open joining (and many of the big ones do), a bad actor could join the same team and see that member's postings in the team message board - where, in my experience, people may feel more relaxed in disclosing personal information. My team has certainly organised "in real life" meet-ups for drinks in a pub, or weekends in the hills. |
I was not party to those discussions. I am confused about both the context and the details. I would be grateful if proponents could address the following. To get global stats, exporting aggregate data is sufficient, and removes GDPR risk. Who is proposing to change this, and why? If we go beyond exporting aggregate data, then GDPR adds complications:
Since we can not say for sure which data is "personal", the sensible approach is to stay on the safe side of GDPR, which argues for opt-in rather than opt-out. This is also consistent with GDPR core principles such as transparency and data minimization. Another motivation to stay on the safe side: GDPR imposes additional requirements about data transfer to third parties (such as stats sites), especially if they are outside the EU. Cheers, |
@bema-aei Just to make sure, I'm talking about |
@bema-aei It's "data minimisation" in conjunction with "purpose limitation" and "storage limitation". |
Oh, you're right. I thought this was just the number of the entries in user.xml (which it probably was before user.xml was filtered by consent). My bad. So there is already some aggregated statistics that we publish. So again: what's missing and desired? And what for? |
@AenBleidd Sorry, but I beg to differ. They probably aren't readily personal data on their own but they might be used with other data, as others said before as well. With regards to the GDPR, unless I can't prove that the Also, like @bema-aei just said, I think we ought to ask those questions the other way round: why should I publish Bottom line: we should only ever store, process and transfer data that serve a purpose (for the data controller's services) and that we (as projects, a.k.a data controllers) have a legal basis for. That's the spirit and purpose of the GDPR and adhering to these will make the difference if someone sues you. We as the ones bearing the actual responsibilities, together with experts in the field, have spent a considerable amount of time on this topic over the years. I hope BOINC does not weaken the current implementation for the sake of (smaller) projects who can't afford dealing with this matter on their own on such level of detail. Please help them to reduce their attack surface as much as possible by keeping safe defaults. |
|
Ok, let's think about this: |
|
@AenBleidd could you please elaborate on what statistical information you are missing and for what purpose you need that? You will have to specify that anyway for the data policy declaration. Remember that by GDPR you are required to not collect and process (let alone publish) information that doesn't serve a legitimate and documented purpose. After that we may discuss how to collect that without violating the GDPR or the wishes and standards of our volunteers. Stretching and bending the regulations of the GDPR or its interpretation to suit (currently undisclosed and possibly even future) desires of some of us (which also aren't disclosed to me yet) is something I consider the wrong approach and that I don't really feel comfortable with. |
That is quite a clear answer, from my point of view: we need to know:
As you can see from the list above, none of the information could be used to identify the person. What is more important, all this information (excluding User CPID and Host CPID) is publicly shown on any Project, but none of it really contains any personal data. The only field (that is not in the list above but was mentioned in the original message) is the 'name', that is actually not the real name of the user (unless they put it there) but a screen name, that could be literally anything. You can go to your profile, put there my name, but this will not make this account mine, and not will impersonate me in any way.
We're not gonna collect any other information but just the one that is already there and collected for years. And still, there is no any personal and/or sensitive information here.
BOINC doesn't collect any personal information, so you can't use CPID to get any of it. CPID is the unique identifier that have sense only within the BOINC, but since there is no personal information in BOINC - you can't identify the user by using their CPID.
ID and TEAM_ID are just the indexes in the database, and they are even not unique across the projects. You can basically use the enumeration and load project page to get all the profiles of the users in that particular project.
That's a very correct point! We have a data that is anonymous and have a purpose. This information could be used by BOINC to get a clear picture about our userbase, and provide them a better service, also this data could be used by third-party data aggregators to show a valuable but still anonymous statistics (and possibly do some other useful stuff). Exposing this information doesn't open any vulnerabilities, and can't target any BOINC user in any way.
At the moment of the GDPR implementation, it was read incorrectly, and all the information was treated as personal (including the posts on the forums) but eventually it was clearly defined what is the information is personal and can't be exported and what is the non-personal information. All the data I wrote above is not personal and completely anonymous.
You don't need exported data to get this information, you can just go to the Project web page and scrape the data by just going from '0' to 'infinity' as the ID and/or TEAM_ID.
Bad actor can do that without using the exported data, because in this case it will not give any additional personal information to them. E.g. you will know that one of the users has one of the hosts running Windows 10. So what? WIll you target them with the ads to buy MacOS or what? What I have seen from the initial discussions here on the first implementation of GDPR, is that people had no understanding what is the GDPR about. Now, years later, this topic became more clear and obvious. Even now I see that some of you are very scared about this, but if you dig a little bit deeper into the topic, you will clearly see that there is nothing scary at all, and that the GDPR is not so strict as you think about it. And please keep in mind one very important topic: BOINC is providing software solution that is open source, and thus you should this proposal as an optional recommendation. Yes, we plan to implement this change, but if any of you thinks that it's too dangerous for you and you're too afraid of the GDPR - you may not follow it, and patch it to be exactly the same as before. |
While I can guess the reason for collecting some of that data across projects (RAC, number of hosts and users), the purpose for most of these is not clear to me. Why e.g. has the internal ID of a host or user that has absolutely no meaning outside the project to be exported elsewhere? Most of these data items make sense to me in the context of the project, mostly for assigning "work" to a host, but what is e.g. the RAM or disk space available at last scheduler contact of a host needed for outside the project? |
I might agree on this, but from the other hand this is a completely anonymous information, and can't make any harm. You can find a good use of it if needed (even if I currently don't see a good example how it could be used).
You can use the 'last scheduler contact' to get a list of the users that were active between two data exports, and thus you can see the dynamics (e.g. if you see that yesterday there was 100 people active and today 100 people active, that doesn't meant that these are the same 100 people, maybe it's 80 same people, 20 of them gone and there are 20 completely new people). Speaking about the RAM and hard disk space, imagine you want to run a completely new project. And you want to understand, if your application uses 10 GB of RAM, are there will be enough users that could run your Project? Of if you want to save 100GB of data, are there any sufficient amount of the users who could ever run this Project's application? |
|
The GDPR requires you to collect, process and in particular export only information that is needed for documented legitimate reasons and purpose. The possibility of a purpose you may think about in the future isn't a valid justification IMHO, and the fact that you can't think of any harm that it may do certainly isn't either. |
|
The currently available RAM and even more so disk space doesn't help you much when deciding upon a new application or project, there are e.g. user preference settings that influence what is actually usable etc., and a lot of information that I consider even more important (CPU features, GPU properties like CUDA CompCap or OpenCL level) aren't even stored in the DB. |
|
First a question: |
|
@bema-aei, you are missing the point of GDPR. GDPR is trying to minimize the amount of personal information that is collected. Statistics is not a personal information.
We (BOINC) need to be able to identify every user anonymously but in a unique way. We can discuss this, and probably you might be right, and CPID would be enough for our purposes, but still: id is just an identifier, and it doesn't disclose any personal information.
Better understanding of the userbase. I already explained this above.
Do you know how much projects implemented GDPR on their side during last 5 years? You will be very surprised with the numbers. |
And what service for this userbase is that detailed understanding required for? Facebook also has a vital interest in understanding its userbase, which doesn't make that desire legal or beneficial to the users. |
|
In my understanding your "proposal" would violate the GDPR in at least two aspects:
|
What harm exactly does this "current implementation" do to which "users" here? |
|
And if you change something for the projects that already implemented the GDPR in the current way, they will need to gather consent again for that change from every volunteer. I don't think that this will ultimately achieve what you want, at least for quite some time you will rather get less data than more. |
|
You asked for our opinions on this and I tried to my make case, referencing the GDPR to contextualize the issues I see. We apparently continue to have a fundamentally different understanding on the subject and I don't need to convince anyone. Rest assured, we as a BOINC project and data controller, together with our data protection officer, have spent a considerable amount of time on this topic over the years - and continue to do so. In this discussion I tried to focus on data transfers and the legal bases for those, in a context where the personal nature of data is at least (obviously) debatable. We, as a project and (sole) data controllers, reached our conclusion on how to implement those in accordance with (our interpretation of) the GDPR and in the interest of our users and their data. We don't have a reason to change that. You are of course free to change whatever you want in BOINC itself. But again, you asked for our opinions. My opinion on this proposal is that it would be a mistake. Not for us but primarily for new and/or smaller projects without the resources to tackle the ins and outs of the GDPR on the level we have. |
To be fair, that's incorrect. The GDPR only comes into play when personal data are involved. |
Facebook uses the data to advertise their users with a personalized ads. BOINC doesn't do that, and the data we are collecting can't be used for this purposes.
BOINC development.
No. We are not asking our users to disclose any kind of the personal information.
We have no clear picture of our users. E.g. do we still need to support Windows7/Android4/etc? We can't answer this question because we don't know exactly how much users we have with this particular OSs. Yes, every Project has their own statistics, but it's distributed, and, as I described above, 100 users of the Project A and 50 users of the Project B doesn't give us an exact number of unique users.
We don't need a users' consent to show anonymized data. Again, you're mixing personal and non-personal data and treat all the data as a personal one. This is not correct.
Obviously, both you and your data protection officer have incorrect understanding of the personal information. As I already told: personal information is clearly defined. All the information, except the 'name' and 'url' that might contain personal information, is not a personal information, and it can't be used to identify the user. You can't identify your user by the CPU they used, you can't do that by the amount of RAM available, etc.
Obviously, the conclusion is not correct, because you treat every piece of the information as a personal information, and this is again, not correct. And this strictness is the topic users are complaining about. User want to participate in the competition, but in order to do that, they need to manually allow statistics export. If they forgot to do that - they're fucked, and they will just lose their points.
I see the clear reason: we (BOINC) want to make BOINC better for our users, and the incorrect implementation of the GDPR prevent us from doing our job. That is why we have initiated this discussion, that is definitely currently goes in incorrect direction.
And this is a very correct point. But do you clearly understand what data is personal and what is not? |
It's not just that. I see an even greater danger here. Above I wrote "strictly speaking, I could even argue that the current proposal might loosen important legal obligations for projects downstream, potentially without them being fully aware." What I meant by that is, that, depending on how this proposal gets implemented, projects downstream could pull those changes (as part of their regular updates) and have their opt-in policy changed without being fully aware of that. Yet only them are legally accountable for what happens on their site. That means any such change must not alter the current opt-in in policy when pulled downstream. IOW, projects must always switch to opt-out explicitly, if they they choose to. |
I don't think the pure number of projects matters much here. When we first implemented the GDPR, the five largest projects (SETI, CPDN, WCG, LHC/Cern, E@H) were actively involved and did implement that changes. Three of these were based in the EU (at that time), IBM (WCG) had a vital interest in conforming to EU regulations, and SETI doesn't exist anymore. These are the main projects that "aggregators" get by far the most data from, and all these are GDPR compliant for their own vital interest. From your point I would care more about the number of users than the number of projects. |
You know what is the most interesting? I don't know how much users decided to not export their data. We just don't have this information. Yes, you as a Project have this information, but we (BOINC) simply have no way to get this. |
Well, as @bema-aei just said, the vast majority of the BOINC ecosystem can be represented by a few projects and those could be asked to report their statistics to a get a statistically significant overview. I don't see why you need the "exact number of unique users" where relative shares of, say, OSs or histograms of disk sizes should be sufficient.
As I said, that's a pretty bold statement. I won't engage in this part any further.
I'm not aware that this is a thing in our project's community. Also, every user had been made aware of the opt-in prior to the roll out and it's written in our privacy policy. There's also no loss of data, since all absolute values are exported as soon as the user opted in to export those. |
You don't have that information because people decided not to share it (with you). I can hardly find anything wrong with that. If you think that BOINC development relies on that information, then tell that to the people that you claim to develop for, and base BOINC development on the information you got. In my research on E@H I understood that the people that contribute by far the most to the project are competitive and like to see their hosts published. There might be others, but whatever their reasons are for hiding their hosts, these don't contribute much to the productivity of the project. |
I don't agree with this statement even if this is currently correct.
Maybe this is a communication problem on your side. Because I saw a lot of complains.
Please clarify: is this the decision of your users or this is a decision that you made on their behalf? |
Not sure what you're trying to tell me here and I fail to see how this could be relevant. As @bema-aei said, you should specifically ask CPDN, WCG, LHC/Cern for their takes in this topic. We were all involved in the original implementation. Which of those (most relevant, in terms of total participants) projects has reverted its stance on opt-in vs. opt-out or plans to do so? This isn't to disrespect the many smaller projects doing very important research but they're frankly not that relevant with regards to your goal of gathering of representative figures for the BOINC ecosystem as a whole. If those projects above don't move to opt-out, your figures are arguably not that meaningful and this whole proposal can't instill a real benefit. |
And this is what I'm currently doing.
This is a correct point. And again that is why I initiated this discussion. Yes, you're a big project, but you can't dictate either how the whole network should operate. |
Unfortunately it's the lawyers and experts that we will ultimately have to deal with in court, not you who certainly knows it better than all of them. |
|
@bema-aei, I see your point. This is not a healthy attitude, but thank you for sharing it with me |
Where exactly did I do that? I can only recite myself. I tried to be constructive by getting an understanding of the actual problem and asked questions that could have lead to alternative approaches but got ignored. Now your responses are getting more and more personal and hostile. I won't put up with this and I have nothing more to add. |
I haven't said you did that. I said that you should not act in this way. @brevilo, I clearly described what is the actual problem. You continue to insist, that from your point of view there is no problem. I can understand this, but you're not correct telling that since you're the bigs projects, and you represent the majority, we (BOINC) can rely on you only. Previously you said that BOINC doesn't exist in vacuo. But this applies to you as well. Please think about it. |
Doesn't make sense. I have no say over BOINC, let alone other projects.
Nope, I do in fact understand the problem you see with the current implementation.
I'm not saying we're any better or more important than other projects. My statement only concerned the statistical significance for what you're trying to do.
First paragraph for instance.
Nope, I said it's our GDPR interpretation and only that is relevant to us because only we are legally accountable for what we do with the data entrusted to us.
It's solely up to the projects to leave the silo you're seeing them to be in. BOINC doesn't have to leave any silo since it doesn't control any data, so "we" doesn't apply. Also, opt-in doesn't constitute a silo. That would be no exports whatsoever. Opt-in is proactive freedom of choice by user-empowerment.
So why mention them at all...
I'm not open for discussions that resort to personal attacks and where your view is definite and others' expertise is incorrect beyond doubt. I'm not even questioning your expertise on this complex subject matter since that is in fact (legally) irrelevant for this discussion. But I repeat myself and I should really stop that.
I know, and neither do I. I provided my mere opinion, on your request. If it doesn't fall in line with yours, it can't be helped. That's normal. That's life. Take from it what you want or leave it. Consider it as food for thought or not. That's entirely up to you. Bye PS:
I don't recall any smoke, let alone fire. If you're looking at us, then we can only say that it didn't and doesn't work for us. Nothing more, nothing less. But please let's not move there now. |
|
I think there are two very different approaches: You were used to collect a certain amount of information, that may or may not be useful and necessary. Now you find you don't get that much information anymore, and identified the implementation of GDPR in some projects as a reason. Rest assured this implementation has been developed over months with advise from lawyers and experts. You're now looking for a way to get that same information again, and try to find reasons why it could be collected, e.g. you now judge this as not personal and thus not relevant to the GDPR. You take it for granted that your understanding of personal data is the only correct one, and everyone else therefore must be wrong. Thus you request to try to change the GDPR implementation, intentionally for all projects. I'd call that risky at least, and the problem is that ultimately it's not you taking that risk, but the projects. Our approach (as I wrote initially) was to find out what information is actually relevant and needed and in what level of detail, and then find a way to gather that information. We proposed a couple of solutions, but you aren't open to that approach, you just rejected all that. If you think you have the only solution to what you think is your problem, and anyone is free to implement that or get nothing, why did you ask for opinions at all? |
This is exactly my point: you are saying that you (big Projects) are representing the vast majority, and thus we (BOINC) should rely on your data only:
And I don't agree on that, because in this case we are ignoring all the others, and this not the correct behavior from my point of view.
What I wanted to say there, is that you can't say for sure that the decision made 5 years ago are still valid and correct, because at that period of time GDPR interpretation was sometimes wrong, and there is a room for improvements, if we are willing to take another look at the situation.
I apologize, if my words were understood in this way. I have nothing personal against anyone. I am open to the discussion and collaboration, but I see a block from your side at almost the very beginning of the discussion:
By saying this you literally telling that your opinion is the one that is correct. What I'm saying is that your interpretation of the personal information is not correct, because every time I told you the data we are collecting is non-personal, you still continue the discussion in a way like this is indeed a personal information. You haven't provided any arguments why you think this information is personal, and instead questioning me why I need this information. I provided my arguments on why the information in non-personal, and you haven't said anything against, so I assume you agree that this information is non-personal, then why we have this discussion? GDPR is about personal information that directly identifies the user, or mixed information, that could be used to identify the user when used together, but this is not the case we have, because none of the information can identify a user in any way (except the 'name' and 'url'). All the other information (except IDs and CPIDs) is publicly available, and you can agree with me, that if this information would be a sensitive and/or personal one - you need a users' consent to show it on the web page as well. Data export we're talking here about is just the another representation of this information (collected in one place). So the my question is: why you think that it's safe to show it (for example, if you take my name, you will find my profile on different BOINC projects indexed by the search engines) but not to export it? Yes, exported data contains some additional information like credits, etc, but this information is not personal either, and you can't identify the user just using these numbers. Here's the position of you I don't understand: you see it safe to export the users' data to search engines but completely against exporting it as an XML file. For me it looks like you contradict yourself. I'm not hostile, but your position is very strange from my point of view. |
I refer to the law: https://gdpr.eu/eu-gdpr-personal-data/#:~:text='Personal%20data'%20means%20any%20information,location%20data%2C%20an%20online%20identifier
We're not talking about any kind of new information to collect. This is still the same information that is already collected and could be just seen by using any search engine. |
|
This is just from the search engine (and I even don't logged in, so this is completely open): |
For hopefully the last time: all I have said pertains to our well-informed interpretation of the GDPR that is relevant to us and to our project only. I'm not here to sell my view to you and, again, I'm certainly not the sole keeper of the universal truth - and neither are you. No one is. Please understand and respect that.
That's because we have a different understanding of the GDPR. Please at least respect that there can be different views and interpretations on any given law. Once again, we, for us and for our project only treat the exports as a data transfer. GDPR differentiates between data processing and data transfers, I presume you know. This particular treatment of exports is our considered choice based on our assessment, since it's our responsibility. We chose to employ our users' consent via opt-in to establish the legal basis for those transfers for our project. As such, it follows that this as well isn't a universal truth or rule. Again, it's up to the individual projects to deploy what they see fit for their individual situation. We're not going to reconcile our views on that one. And that's fine. It's time for other projects to chime in... |
Thank you for the clarification. It doesn't contradict what I said before (including the search engines) but it's very important to say it loud and clear to understand the opinions of each other. |
|
Sorry, but "data transfer" was mentioned six times in four different comments before (and that doesn't include my citations of my main summary). I presumed that to be "loud and clear". Good that's settled now. |
|
@brevilo, no, I mean, exposing data for the search engines for me and according to the GDPR is the data transfer as well, but looks like you have a different opinion on that. But you treat the XML export as a data transfer, and the most important, is:
For me this explains why you are against all this changes. I will not argue about the definition of the 'data transfer' because this is clearly defined in the law. You have your own interpretation of it - I'm ok with that. That doesn't mean I agree with you, but again, it's up to you to decide how you interpret the GDPR. |
|
Sounds good. Thanks. |
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:
<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)The text was updated successfully, but these errors were encountered: