For anyone reading this topic, it’s important to keep in mind that we’re talking about a major law reform that is not yet in force, has not yet been applied in practice by any authority and not been tested in any court. It does build on previous laws, but it also introduces substantive changes.
It is also important to keep in mind that regulators are not going to be focused on your (relatively speaking) small community when they have to deal with companies like Facebook. This is not to say that you should not try to comply with the GDPR (you should!), but it’s important to keep in mind the hierarchy of concerns here.
Beyond Facebook there are a multitude of other companies that are of more interest to regulators, particularly advertisers whose business relies on third party data, before they get to your community. A community which is not built around selling, researching or otherwise processing data beyond what is required for the running of the community itself (assuming you’re using Discourse in a standard way).
That said, I also understand that changes like this are bound to cause anxiety, particularly for smaller operations who will struggle to afford a lawyer and don’t have the time to read and understand the seemingly complex detail in the GDPR, particularly if your business is based around Discourse, heightening your exposure to the issue (e.g. for @RGJ).
@KajMagnus raised the role of ‘consent’, so it’s worth dealing with (albeit, to point out that it probably doesn’t apply to data being processed in Discourse).
As has been pointed out, consent for data processing and the right to erasure are two different things.
If we were to look at consent as it applies to Discourse, there would be a few prior questions we would need to ask before we got to withdrawal, starting with: Is consent the basis on which data is being processed?
The other possible basis is the “legitimate interests pursued by the controller” (i.e. 6.1(f)). In fact, I think it’s much more likely that 6.1(f) is the basis on which most data is processed in Discourse as the user does not give explicit consent to the standard required in the GDPR for most “processing” that goes on in Discourse.
The exception here may be emails, but even if consent were the basis on which emails are being processed in Discourse (which is also open for debate), the withdrawal of consent for emails already exists (i.e. your email settings and the unsubscribe buttons).
I would reiterate that the Right to Access, like the Right to Portability, is really an administrative matter rather than an technical one. If you were to get a request to access, you would not only have to provide the data, but all the other items listed in Article 15. Again, you (i.e. the Data Controller) will have up to one month to comply with the request.
I would also point out that the GDPR states that the reason the Right to Access exists is allow the user to “…be aware of, and verify, the lawfulness of the processing” (Recital 63). This is where the hierarchy of concerns that I mentioned earlier is relevant. For a standard Discourse forum It is highly unlikely that any user would have concerns that their data was being processed illegally. The thrust of the regulation is focused on the digital advertising and marketing industries. Again, this is not to say that the right should be ignored, but the purpose and context matters in both the legal interpretation and how it will be enforced.
Given the tenor of the Art 29 Working Party’s guidelines on data portability, I think it’s likely that a JSON API will be considered just as legitimate as alternatives (e.g. CSV) with respect to all of the rights. I would note that both articles refer to “commonly used” electronic form or format. I would also note that the guidelines on data portability make statements like “commonly used open formats (e.g. XML, JSON, CSV,…)”. I see no reason to think that JSON would not be considered as “common” or less legitimate of a format than CSV for any of the rights.
Recital 63, which discusses the Right to Access in a more a discursive form than Article 15, does contain this sentence:
Where possible, the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to his or her personal data.
It’s important to note that this sentence does not read: “You should have a page where a user can download all their data in one csv zip file”. Having API access (including secure API access using user-tokens), seems to be a plausible implementation of this guideline.
None of this is to say that Discourse shouldn’t consider increasing the amount and types of data included in the download functionality on the user page. Facebook’s new features that allow you to download a copy of your data (which they seemingly launched in preparation for the GDPR) are an interesting point of comparison here (they give a list of what can be downloaded here). Rather, it does not seem that providing that specific functionality is required for GDPR compliance. Or even that it is considered better than providing API access to the same data.
Indeed, given that the GDPR seems quite keen on controllers and processors providing continuing and interoperable access to data, it seems, at this initial stage, that JSON API access is considered desirable.
Which storage of IP addresses do you think are not legitimate?
I’m not sure what the concern is here.
I’m not sure what the concern is here either, as it applies to GDPR rights and responsibilities.
Again, I am not your lawyer and this it not legal advice.