Hey mastodon admins, the 25th may is coming closer and so the #GDPR. I don't think the Data Protection Authorities will be a big problem at the moment, they are also overwhelmed by the new regulations and they would try to solve the problem in a favorable way before sanctioning an instance.
The real problem will be lawyers trying to gain money from instances which don't follow the regulations imposed by the GDPR. So the big question is, what do we need to do to comply these rules? #mastoadmin
I think mastodon and similar are in a good position regarding GDPR.
Probably all of the data processing done falls under "needed to provide the service", and there's no(*) shady other processing going on (e.g. tracking, facial recognition) which would not have been obvious to users when signing up.
That is, I think it's fair to say that users have given active, informed consent to the processing of their data for the purpose of posting and receiving short messages.
I think data export, subject access, data portability is the only thing might come up, so maybe 'export users data' is a needed function?
(*) -- (Assuming there's not secret things beyond that, in which case...
And,; generally speaking, https://github.com/tootsuite/mastodon/labels/legal
@leah of course we should. But GDPR is such a big maze. But I don't think we get US-like lawsuits in the EU... So don't worry too much!
@xvilo well, I'm from germany, so we have a small problem with that kind of lawyers. In the past there was a big problem for free wifi for example because of a thing called "Störerhaftung" which means you are liable for what others do over your internet connection. So I think there are a lot of lawyers here waiting for this.
@Xowap sorry, my school french is't good enough to also answer in french. No not at all, there are also sanctions without a binding to the turnover I think. But hey I'm not a specialist for the GDPR
@leah oh sorry, I thought I read your toot in French
Honestly the GDPR might be a good thing, but it is really opaque and it doesn't look like the official instances care much about explaining what it is to people
@Xowap I think the problem is that it is so vague that also the official instances don't know exactly how to interpret it. It is written for multinational companies with a big legal department. So we have to wait a few years and let the courts define the stuff more precisely
I extracted this table https://search-and-deploy.gitlab.io/cheat-sheets/gdpr-quick-reference/ from https://blog.acolyer.org/2018/04/16/privacyguide-towards-an-implementation-of-the-eu-gdpr-on-internet-privacy-policy-evaluation/ if you know of other sources please share :)
@leah I think in a sense it is a pretty big clusterfuck for any federated network, isn't it? Because the point of Masto is to send personal data to other servers, but GDPR mandates that you have some sort of contract with said servers that you rely data to, no?
Equivalently, how would you implement a "right to forget"? You don't have a contract with other servers that obliges them to delete e.g. a toot. You can't do shit. How could Masto ever be GDPR compliant?
@manu @leah Not exactly, because mail is not federated like Mastodon is. When user A sends a mail from their provider PA to user B's provider PB, this can be seen as implying consent of the user that PA communicates with PB to transmit the data of the mail.
With the Fediverse, there is no single recipient - by default, *all* servers who want to can retrieve the public messages. I can make a new server PC and access all (future?) messages, even though A didn't know about PC at that time.
Perhaps, when I post to my personal website that is publicly accessible, the issue is similar. I am making information accessible to anyone.
When I post on Mastodon, it's the same situation, I'm posting to my personal website. I'm also sending this content to the fediverse just like with RSS, for anyone to access.
With email, A writes to B, but the PB server is run by Google, is Google allowed to use that data ?
@leah i don't think it is #gdpr compliant probably. Information about who is handling info, how info is being processed and for what purposes, making sure logging and auditing don't save any personal info like ips, opt in stuff probably needed in some places, make sure requests to delete user data are actually followed up and that you can delete all the data of a user... Etc... I'm probably not correct on most of these things, but throwing some points around that could be missing.
chaos.social – a Fediverse instance for & by the Chaos community