Mastodon: GDPR Compliance?

[ashfurrow]

Hello! GDPR kicks in next month and I'm just wondering if there's anything that I need to do to make mastodon.technology GDPR-compliant. I've looked and haven't found any other discussions so I thought I'd ask here. Thanks!

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• [x] This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[nynhex]

@ashfurrow I'm working on GDPR compliance for 2 social platforms outside of Mastodon. I can tell you it's NOT easy. But here's the basic gist of what you'll need.

• A very good privacy policy, explaining what PII you collect on EU citizens and how it's used (PII is ip/email/name/browser fingerprint/etc)
• A mechanism to allow the user to exercise their "Right to be forgotten". (i.e. being able to wipe all of their information from your platform as well as anything federated)
• A mechanism to allow the user to export all of their information/details/tracking info (similar to LI/FB does) in a easy to read format (ie csv)

I'm working on an implementation that addresses these things in my Mastodon fork. If you'd like to see progress, let me know and I'll add you or DM you on .technology.

[nightpool]

I dont know if we can offer legal advice to mastodon administrators. it gets us into a tricky legal territory, because it could be mistaken for practicing law without a license which we definitely have NO qualifications for.

I have no idea what GDPR compliance needs. If people want to propose changes to the export or deletion implementation then we would welcome them, but we do have all of these features.

(except for logs which are obviously inaccessible by mastodon, such as nginx logs)

[ashfurrow]

To be clear, I'm not looking for legal advice per se. I'm raising the question "is Mastodon GDPR compliant?"

[nynhex]

@nightpool yes, I'm not a lawyer, nor am I offering legal advice. However I've been doing GDPR implementations for the last year so I'm happy to answer questions.

As for logs, it's as simple as a daily purge/rotate schedule (nginx logs). Just a cron job.

[nynhex]

@ashfurrow in its current state, no.

[nightpool]

the question "is mastodon gdpr compliant" is inherently a legal question. that's the point I'm making.

If you're offering a firm yes or no on that question, you're inherently giving legal advice.

[nightpool]

@nynhex if you could elaborate on what you mean by that, I would be happy to read it. We have already all of the features you mention, so i'm curious what parts of the GDPR you think mastodon currently doesn't satisfy.

[nynhex]

@nightpool yeah, I understood.

Anyhow, for anyone interested in GDPR I encourage you to read this site. May 25th is the deadline to fall into compliance. EU GDPR

[ashfurrow]

@nightpool A user could expect to be able to ask this question here, too. I phrased my initial question poorly, but I don't appreciate being dismissed.

[Gargron]

i'm curious what parts of the GDPR you think mastodon currently doesn't satisfy.

I am seconding this. We do have all the features you listed. What's lacking?

[nightpool]

@ashfurrow i'm not dismissing the question. I'm happy to have the discussion, but i'm saying that we cannot give a firm yes or no answer here.

[ashfurrow]

Okay, thanks.

[nightpool]

Okay, here's some preliminary conclusions after reading the definition of personal data by the GDPR:

These are preliminary, i'm not an expert, and if you believe or are concerned you may be subject to the GDPR (see below for jurisdiction) you should seek legal representation for advice. I could be wildly off base.

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

We do not store or solicit users real names, local data, identification numbers. We do store IP addresses but only to protect against malicious server usage and NOT in combination with any other unique identifiers (except account ids) or information received by servers. and the IP address associated with your account is ALWAYS visible in the security pane.

I don't think storing an IP address counts as an identifiable natural person because large groups of natural people can share the same IP address and a single natural person can trivially have scores of IP addresses, and the same is true for mastodon accounts. If we expected all natural person to normally have at most 1 mastodon account or for no natural persons to normally share the same mastodon account, these together may be identifiable, but we don't, really.

If we think that storing an IP address does count as an identifiable natural person (which is probably going to be the common jurisprudence if not explicitly required by the law) then the other rights, such as right to erasure and right of access does come into play. I haven't looked into those yet.

---

Another question is "who falls under the jurisdiction of the GDPR"? Websites that intend to offer services to EU residents. Here's the language:

Whereas the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention, factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.

The website that nynhex linked breaks it down as such:

• May be insufficient evidence
  
  
  
  • The firm’s website is accessible to EU residents
  
  
  • The firm’s email or other contact details is accessible to EU residents
  
  
  • The firm is located in a non-EU state that speaks the same language as an EU state
  
  
• May be sufficient evidence
  
  
  
  • The firm markets its goods and services in the same language as that which is generally used in an
  
  
  • EU member state
  
  
  • The firm lists prices in EU member state currencies (the Euro, British pound sterling, Swiss franc, etc.)
  
  
  • The firm cites EU customers or users
  
  

I'm not convinced that mastodon.technology (although it, like all mastodon instances, provides localizations in all languages including those used in EU member states) falls under this category because it does not seek out or promote EU customers and users. (and is run from New York)

So even the jurisdiction of the GDPR on many mastodon instances is probably suspect.

[nynhex]

@nightpool Storing IP is PII even if it's shared. Again, I'm not a lawyer but I have 3 legal teams backing me on this for my work and IP storage was definitely an issue. The problem with GDPR is that it can be interpreted in so many different ways.

My advice to anyone running an instance is to consult a lawyer. I'm off this thread. ☮️

[nightpool]

@nynhex Okay. If you do make changes to mastodon to add more exporting or removal then you should make sure to make us aware of those changes so you we can integrate them upstream.

[jbzdak]

I'm also not a lawyer (there seems to be a lot of not-lawyers) here. Also I'm EU resident.

IP is considered PII, it seems, however Article 6 par 1, states:

(d) processing is necessary in order to protect the vital interests of the data subject or of another natural person;
(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

And I guess if IP's are used for fraud detection and or multiple login attempts blocking it falls into these categories, if logs are stored for a reasonable amount of time (and IPs don't get to other systems). Using IP's for de-anonymisation and creating shadow profiles would be illegal though. (Still bear in mind it is not-a-lawyer).

Reading data portability section it seems that Mastodon has had it built in from the start (purpose of this article seems to be to allow futute federation and/or moving data from and to other services). Only problem I see is that no login logs (with IP's) are in this export data.

If you want to consult a lawyer, I think that asking for funds to do this from members of mastodon.technology would get a good response. I see a lot of EU folks there!

[nightpool]

the question was not if IP collection was allowed but whether it qualifies as connecting the other mastodon data to "an identifiable natural person" (thus triggering the other requirements of the GDPR).

I think a close analysis of the way mastodon uses IP information implies that we don't have any data on "identifiable natural persons" but i do accept that this is probably not going to be the standard interpretation, and we're better erring on the side of caution and assuming mastodon instances that ARE subject to the jurisdiction of the GDPR (most american-run instances probably aren't? and many more european ones probably fall under "personal data collection"? it's complicated) will have to abide by the other rights of export and data deletion. (i haven't looked in to the specific details on those yet)

[t-m-w]

Skimmed over the "online identifier" bit from the text? That term is super vague.

[SoniEx2]

Why not wait and see?

[coreyreichle]

I do believe a huge question to consider here: Are non-EU instances, who recieve PII from EU instances, impacted by the GDPR?

Since I don't have the resources to get legal support for my instance, at this point, I'm considering blacklisting any EU IP address, until the question is resolved.

[Gargron]

The above post is the exact reason why we should be discussing this and not just waiting, because people are gonna make hasty decisions. A week ago or so @mal0ki sent an e-mail to the EFF asking for them to publish a legal resource for GDPR compliance for ActivityPub servers, so far no response.

Anyway, instances do not exchange PIIs. Only public profiles and posts.

[coreyreichle]

Public posts/pictures/etc are considered PII as far as I know.

[coreyreichle]

Also, I do not know of a way to ensure a right to be forgotten for EU residents who have shipped PII to my server, either. I mean, I'm sure there is some way to purge all toots/DMs via a pgsql query, but again, what would the impact be on the rest of the DB structure?

[coreyreichle]

And to support pictures/media/toots being PII:

What constitutes personal data?
Any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer IP address.

Source: https://www.eugdpr.org/gdpr-faqs.html

[SoniEx2]

We need a way to store the posts on clients and synchronize them with a p2p mechanism.

[sn0w]

Is GDPR compliance even relevant for instances that are run by individuals on an "as is" basis?

Their FAQ states:

The GDPR not only applies to _organisations_ located within the EU but it will also apply to _organisations_ located outside of the EU if they offer goods or services to, or monitor the behaviour of, EU data subjects. It applies to all _companies_ processing and holding the personal data of data subjects residing in the European Union, regardless of the _company’s_ location.

and

_Organizations_ can be fined up to 4% of _annual global turnover_ for breaching GDPR or €20 Million. This is the maximum fine that can be imposed for the most serious infringements e.g.not having sufficient customer consent to process data or violating the core of Privacy by Design concepts. There is a tiered approach to fines e.g. a _company_ can be fined 2% for not having their records in order (article 28), not notifying the supervising authority and data subject about a breach or not conducting impact assessment.

Emphasis on the terms organisation, company and annual global turnover

[mal0ki]

I emailed the EFF the other day, and have now received a reply.

They are directing me to this for resources: https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/bird--bird--guide-to-the-general-data-protection-regulation.pdf?la=en

But also, saying that they can help provide us with an attorney to figure this stuff out. I'll talk more with @Gargron about this today (or tomorrow, as it's Mayday)

[coreyreichle]

So, it does appear non-organizations (Natural persons) who run instances are exempted:

by a natural person as part of a “purely personal or household
activity”. This covers correspondence and the holding of
address books – but it also now covers social networking and
online activities undertaken for social and domestic purposes.
It represents a possible widening of the exemption from the
principles set out in Bodil Lindqvist (C-101/01), before the
advent of social media. In this case, the CJEU noted that
sharing data with the Internet at large “so that those data are
made accessible to an indefinite number of people” could not
fall within this exemption, which it stated should be limited
to activities “carried out in the course of the private or family
life of individuals”. Note also that the GDPR will remain
applicable to controllers and processors who “provide the
means for processing” which falls within this exemption.

However, if the instance is owned/operated by an organization (Cooperative, non-profit, or other such corporate structure) would be expected to comply.

[kr428]

Curious to see what outcome this will have. Having been halfway through GDPR by now too, I think the most important thing should be trying not to fall into a category of organization structure that has to comply. Otherwise it could get difficult as, no matter which features the software itself might (not) have, bottom line seems that most of GDPR actually is about how the organization operating the software works. You don't per se need software that is able to support a "right to be forgotten" it'll just makes things easier. Manually deleting things would be perfect too. But if, in example, running a mastodon instance on some shared infrastructure, you would also have to figure out if any of your hosting providers systems or team members could have access to relevant data and make sure they comply with GDPR too - provider HTPP proxy / loadbalancer in front of your infrastructure that is able to 'identify'' actual users?

Best outcome here possibly would be a basic set of rules and guidelines for instance admins on how to behave.

[phoe]

IANAL.

Quoting someone from a discussion on Mastodon:

Who is the designated data controller for federated information?
It must be each individual instance, but the user did not agree to any data sharing with each instance.

Mastodon is a federated network by design and by signing up to an instance that is connected to other instances by design, you must agree to your data being sent to an indefnite number of other instances as an effect of the functioning of the federated system. This is simply how things work. If the user is not okay with that, they may join a service that is not connected to other nodes by design and therefore has a centralized entity for controlling data, such as an "offline" Mastodon instance whose responsibilities are traceable to a single organization, or a centralized service, such as Facebook.

As for the risk of unsolicited data-sharing, for any Mastodon instance, either that Mastodon instance is disconnected from the network to avoid sharing data, which defies Mastodon's whole purpose, or the designated data controller of that instance is going to be burdened with sharing information with an indefinite amount of other instances and therefore an indefinite amount of other people - and that seems like something punishable by GDPR.

To anyone more skilled in law than me - is the above statement a real risk? This law does not seem to take federated networks into account. It implies that there exists a centralized data controller for a decentralized network, which is an impossibility.

[bortzmeyer]

@phoe I agree with your analysis. And you're right that the european authorities considered only centralized services, federation is completely unthinkable for them.

Now, practically speaking, my guess (IANAL, etc) is that there is not a lot of risk, short term. The data protection authorities will have a lot of work to do with traditional corporations, I don't think they will care about a small federation. It does not mean we should deny the reality (like the people who claim that IP addresses or public posts are not personal data, despite many years of legal evidence) but we should not panic either.

Reminder: most provisions of the GDPR were in most western european data protection laws, often for years. This is not a novelty. See for instance https://github.com/tootsuite/mastodon/issues/6474

[ed-davies]

phoe: “Mastodon is a federated network by design and by signing up to an instance that is connected to other instances by design, you must agree to your data being sent to an indefnite number of other instances as an effect of the functioning of the federated system.”

Absolutely. However, the terms of service should probably reflect this. Looking at a couple of terms of service at random I see things like this from mastodon.xyz's: “We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information.” I'd suggest that this should be re-written to indicate that they do transfer PII to other instances in the federation and to users of their own instance and of federated instances.

Maybe it would be best if it was specific about what PII was transferred in that way: user name, toots, follows, what else?, but not, e.g., IP address, password, sign in/out times, … I assume.

[bortzmeyer]

It is also very important to keep in mind that being compliant with the GDPR is only a part of the general issue (although an important part for the instance admin who doesn't want legal troubles). The big goal is to protect the privacy of users (unlike Facebook, Twitter, etc).

[Gargron]

Maybe it would be best if it was specific about what PII was transferred in that way: user name, toots, follows, what else?, but not, e.g., IP address, password, sign in/out times, … I assume.

New privacy policy in master reflects this.

“Mastodon is a federated network by design and by signing up to an instance that is connected to other instances by design, you must agree to your data being sent to an indefnite number of other instances as an effect of the functioning of the federated system.”

It's not quite indefinite. For follower-only and direct messages, only the recipients will receive them, and therefore making sure they're deleted is straightforward. Public posts that can be accessed and cached from anywhere, not so much, but: Public blog posts cannot be PII. (IANAL etc but it would not make sense)

[git-marijus]

I wonder if there is a guideline for email providers somewhere. I think their situation is comparable to the situation of other federated services.

[bbqsrc]

@Gargron I would strongly recommend seeking legal advice, as a "privacy policy" is no longer sufficient for conformance with the GDPR, as my company recently found out. The software itself isn't the problem, but the hosting.

Due to the nature of this being a federated service, it is likely that all mastodon nodes will be considered both controllers and processors according to the GDPR, and as a result will require specific phrasing that constitutes a data processing agreement.

I am not a lawyer but one did very much upset me about this recently. This is a massive kick in the face for Facebook, but unfortunately the kicks don't stop there. Fortunately, this is a proportionality-based regulation so unless egregious abuse occurs, it seems unlikely we will receive a Facebook-grade punishment.

A fairly useful site for GDPR stuffs I've been reading has been this: https://www.netskope.com/blog/gdpr-data-processing-agreements/

[ed-davies]

Gargron: “but: Public blog posts cannot be PII. (IANAL etc but it would not make sense)”.

The legislation (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN Article 4 (page L 119/33)) says “For the purposes of this Regulation: 1) ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); …”.

Read straightforwardly, that would mean that a toot is personal data: it's information and it relates to an identifiable natural person. If a toot isn't personal data then that definition needs to be tightened up.

Obviously public toots don't need to be kept private but the right to be forgotten bit could well apply, it seems to me, in that somebody could expect to have their old toots deleted on request. Across the fediverse? After their original instance went out of existence?

[Gargron]

@ed-davies Is a Guardian article "information relating to an identified or identifiable natural person"? Since it's written by an author? Does the right to be forgotten extend to newspaper articles? Medium articles? WordPress blog posts?

All of those can be cached by Google, Archive.org, and a variety of news aggregators. Such caching is roughly equivalent to federation for the purposes of this discussion.

[t-m-w]

An article from 2015: "Telegraph stories affected by EU 'right to be forgotten'"
https://www.telegraph.co.uk/technology/google/11036257/Telegraph-stories-affected-by-EU-right-to-be-forgotten.html
Snippet: "EU ruling demands Google removes links to content deemed 'inadequate, irrelevant or no longer relevant' following complaint from anyone named in it. Here we will maintain an up-to-date list of Telegraph content which has been removed from search results"

An article from February: "'Right to be forgotten' claimant wants to rewrite history, says Google"
https://www.theguardian.com/technology/2018/feb/27/right-to-be-forgotten-claimant-wants-to-rewrite-history-says-google

[Gargron]

That's specifically about search results linking to news stories, not the news stories themselves. (Also strictly speaking "right to be forgotten" is a different legal topic than GDPR, though there are similar effects)

[bbqsrc]

Right to be forgotten was replaced with "right to erasure" in this regulation.

[nightpool]

The idea that federated mastodon posts constitute Personal Data is absolutely ridiculous and doesn't hold up to the facts. While it's important to be talking about these concepts this conversation seems to have devolved into straight-up FUD.

The GDPR applies to data from which a living individual
is identified or identifiable (by anyone), whether directly or
indirectly. The Directive’s test of ‘all means reasonably likely
to be used’ to identify is retained.

The GDPR’s recitals highlight that certain categories of online
data may be personal – online identifiers, device identifiers,
cookie IDs and IP addresses are referenced. In October
2016 the CJEU provided long awaited clarity on the status of
dynamic IP addresses in the case of Patrick Breyer v Germany
(C-582/14), holding that an IP address is personal data when
held by an ISP, but does not constitute personal data if held by
a party that does not have the “means likely reasonably to be
used to identify the individual”.

You HAVE to be able to draw a full link from "a mastodon post" to "a specific natural person" for it to count as identifiable data. That's the key word here. Mastodon users do not count as natural people, I would have to create a chain of data back to a real-world identity before it becomes personal information. While some people do post their full names on mastodon or take other actions to render themselves identifiable, this is a rare case and can be handled by instance admins on a case-by-case basis, not something that needs an automated process.

Now, again, IANAL, and if there's information contrary to this from a reliable source (the eugpdr.org FAQ is very informal and was taken out of context) i'd love to hear about it. But until I hear otherwise, talking about federated owners being liable for content sent to them by remote users is just fearmongering, plain and simple.

[t-m-w]

"Mastodon users do not count as natural people" is a questionable statement. One could argue that GDPR doesn't apply to ANY social service where people are allowed to use fake information.

I'm not so certain that the responsibilities of data controllers end just because platform usage is voluntary or because it was the user's choice to share sensitive data. Are you?

Until we see definitive proof of that, dismissing people's concerns as FUD seems misleading at best, dangerous at worst.

[nynhex]

Just get a lawyer. Call it a day.

[mal0ki]

Just get a lawyer. Call it a day.

@nynhex we are talking with the EFF and getting an attorney through them. (As was said more than once earlier in this very thread).

[steckerhalter]

here's an article from a german lawyer debunking some of the gdpr myths: http://www.rechtzweinull.de/archives/2558-mein-erster-dgsvo-rant-zu-viele-mythen-und-gefaehrliches-halbwissen-zum-neuen-europaeischen-datenschutzrecht.html might come in handy

[Flaburgan]

Hi, fla (developer not lawyer) from diaspora* here. As you guess, we're facing the exact same questions. I worked on GDPR for the last 2 weeks at work, and from what I know, questions like

To be clear, I'm not looking for legal advice per se. I'm raising the question "is Mastodon GDPR compliant?"

Does make any sense. The question is "Is the service provider compliant?". Of course, that implies checking the software, but asking if Mastodon as a whole is compliant would be the same than asking if email is compliant. GMail could be compliant when Yahoo could not. So that question is down to every instance. And as you already figured out, it looks like instances run by individuals are not concerned. I don't know for Mastodon, but for diaspora*, this represents >90% of the nodes.

[mal0ki]

Thank you @Flaburgan this is helpful indeed. So I guess social.coop would have more to worry about than single providers?

And I guess the mastodon-hosting services (eg. MaaStodon and masto.host) would need to think about it on a completely other level.

I still think it's worth to note what we can do _on a software level_ and what guidelines we can provide for people spinning up an instance. I feel that that is within our sphere of responsibility.

@nightpool has volunteered to take lead and speak with the attorney that EFF will help us get in touch with. And also provide such a guideline. :+1:

[mal0ki]

And because I didn't want to go on and on in the same comment:

I just came over this on mastodon:

https://toot.berlin/@jan/99952462338961444
https://plan.io/blog/gdpr-requirements-needed-for-compliance/

[hellekin]

I really wonder why this discussion is happening here and not there

https://discourse.joinmastodon.org/search?q=gdpr

[mal0ki]

@hellekin because most people congregate here, so sometimes the question ends up here, and we don't want to cut people off by telling them to go somewhere else to talk about it.

It's messy and confusing, I know.

[rzr]

Hi,

Nice to see this thread.

I am wondering if there are any generic technical propositions to implement GDPR operations on social web?

If not maybe we can start to (open issues) and implement some basics rules such as:

1/ right to be forgotten:
HTTP DELETE on http://host/@user/

2/ archive data
HTTP GET on http://host/@user/archive/
(eventually use header for specifying formats)

My question is not mastodon specific but I see this project as a very good candidate for experimenting, and showcase a pattern that other projects could replicate.

Regards

Ping me if interested:
https://mastodon.social/@rzr

[nightpool]

@rzr Because the Right to be Erasure (the GDPR's version of the right to be forgotten) and the right to data transparency are legal issues, not primarily technical, there are a lot of specific carveouts and nuances that I don't think a uniform client API is designed to provide. While part of our GDPR work will be building more tools to support admins in fulfilling these obligations, we can't do everything in Mastodon on our own—it needs to be backed up by a human operator. Nginx logs are a clear and easy example: any right to erasure request made on mastodon data may need to include log data stored in various systems that mastodon shouldn't have access to, as well as from backups of mastodon.

[ThisIsMissEm]

I have a few thoughts here, but IANAL.

One thing that we could do is give users a settings page which lists all instances that your instance is federated with, and give a way to "opt-out" of having any of those instances be able to read your information, likewise, when we federate, we should be federating:

• instance URL
• instance contact
• instance ToS/Privacy Policy

Such that in the list of federated instances, users can clearly find and read the information about who and how the federated instances use their information.

As for access of PII, I think through the admin panel we should hide the IP Addresses and Emails, and then only reveal them based on active selection, perhaps with the entry of the account password, and upon revealing that information, add an event to the audit log: "Moderator A viewed User B's email address at Date"

Furthermore, at the database level, we should use symmetric encryption to prevent users' emails from being read by SQL queries. I'm not sure if there's anything that we can do to prevent reading the emails via Rails Console (perhaps an accessor that generates the audit log event?)

Likewise, we should log audit events for searches of users by email and IP address.

[Hasimir]

Some additional info on debunking GDPR myths came up recently with regards to another project (the SKS key servers for distributing OpenPGP keys), I believe this message may fill in a lot of blanks for people. Especially those of us outside of the EU who may not be familiar with the preceding laws and organisations involved:

https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html

Coupled with this follow-up recommendation:

https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033709.html

The entire thread begins here:

https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033704.html

And is indexed here:

https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/thread.html

[tscs37]

At the moment the Mastodon ToS states that IPs are retained for up to 12 months in mastodon and to my knowledge this is affecting the "last login ip" field in the administration interface.

I would recommend that atleast a config option is added to reduce this amount, defaulting to 7 or 14 days at maximum, 12 months is definitely not compliant nor do I want to store user IPs for that long.

Additionally as german administrator I will need to have an option to add an always visible link to my imprint. Currently the "about this instance" link which I abuse for an imprint requires 2 clicks when the "getting started" section is visible, which is not compliant with german law to my knowledge. Since I do have a dedicated site for the imprint, I would like an option to add custom links always visible to the user somewhere on the page, preferably the bottom.

Example:

[pfigel]

I'm a bit late to this thread, but I'd like to point out that it's a bit far-fetched to say individuals running Mastodon instances are in the clear because GDPR doesn't apply to them. It's true that there is an exemption for "[data processed] by a natural person in the course of a purely personal or household activity", but what the language is trying to cover is something like keeping a personal address book. There's some further clarification in Recital 18:

This Regulation does not apply to the processing of personal data by a natural person in the course of a purely personal or household activity and thus with no connection to a professional or commercial activity. Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities. However, this Regulation applies to controllers or processors which provide the means for processing personal data for such personal or household activities.

There's also some case law from the European Court of Justice where they looked at a similar section in the Data Protection Directive (which is kind of a predecessor of the GDPR):

As regards the exception provided for in the second indent of Article 3(2) of Directive 95/46 [the one with "purely personal or household activity"], the 12th recital in the preamble to that directive, which concerns that exception, cites, as examples of the processing of data carried out by a natural person in the exercise of activities which are exclusively personal or domestic, correspondence and the holding of records of addresses.

That exception must therefore be interpreted as relating only to activities which are carried out in the course of private or family life of individuals, which is clearly not the case with the processing of personal data consisting in publication on the internet so that those data are made accessible to an indefinite number of people.

On the bright side, Recital 148 should somewhat limit the fines for individuals, stating:

In a case of a minor infringement or if the fine likely to be imposed would constitute a disproportionate burden to a natural person, a reprimand may be issued instead of a fine.

(IANAL etc. etc.)

[sn0w]

@mal0ki @nightpool anything new from the EFF/Lawyer?
All the "IANAL" takes on GDPR in here are nice but not really helpful in the end.

[bortzmeyer]

@sn0w Layers are not magicians. They cannot predict the outcome of future legal actions, specially since the GDPR is complex, and recent (there are not yet relevant cases). EFF's lawyers can always give an advice but, from my experience with lawyers in the field of digital networks 1) it won't be crystal-clear 2) it will contain a lot of "may be" 3) it could be wrong, or, more precisely, an actual judge may do something unexpected

[nynhex]

I'm not a lawyer, however I have just completed GDPR compliance with the assistance of our EU legal team at work. While I agree lawyers are not magicians, I will say it's important to engage with lawyers who specialize in EU law and regulation. It cost us an astronomical feed to get into compliance, but the feed was a pittance compared to not being in compliance.

I'm happy to share what I've learned as I've been researching and studying GDPR and EU law for the last 12 months, but again IANAL.

[nightpool]

I have more updates and have been learning a lot from open source communities who already looked into this issue. unfortunately I didn't finish in time for May 25th and I was on vacation last week, so stuff is still forthcoming. I'm happy people are still interested in this issue though, I'll try to get back to it tomorrow when i have some time.

after my preliminary research though, I don't expect any major changes are needed for compliance, which is why it's been pretty low priority. it's just a matter of getting a document together that better informs admins.

[nynhex]

@tscs37 Fork it? I've already forked 2.4.0 and am retooling internals to do this.

[tscs37]

@nynhex Sadly not an option, I don't understand Ruby, I have no idea where I would even begin making such a patch. Any patch I do end up producing eventually will be bandaid, not a proper and maintainable solution, so it would be great if there was a upstream option.

[ashfurrow]

@nightpool Thanks for the update, looking forward to hearing more. Thank you for your work on this.

[nynhex]

@tscs37 Not a problem. Once I finish my fork with this scrub feature (actually going to strip out IPs 100%), I'll link you to my fork and you are free to test it against your prod dataset.

[nightpool]

@nynhex @tscs37 IPs for local users are retained for 12 months which is compliant and justified processing for network security and moderation purposes, as per Recital 49. https://gdpr-info.eu/recitals/no-49/

[nightpool]

(this is extremely common practice for resisting spam/DoS attacks and mastodon is following industry best practices here)

[tscs37]

I don't think there is a reason to keep an IP for 12 months, most home connections recycle IPs after a day and any spammer can easily recycle IPs. Additionally under german law (TKG §97) I'm not allowed to keep an IP for longer than 6 months, longer only if I need it for billing purposes.

I would argue that at minimum the time limit should be configurable.

[tscs37]

Actually, reading through some related paragraphs, notably §15 Abs. 8 TMG I might not even be able to store an IP for abuse purposes unless I have a well founded reason on basis of abuse already, so there should be an option to completely disable it.

The GDPR does not apply there as the local law in my jurisdiction is more strict but others might have similar concerns.

[nynhex]

@nightpool understood, however if I choose to wipe IP addresses from my fork, it's my choice. Besides I already have DDoS mitigation in place and if I really want to track IP's I have app nodes aggregating to ELK.

[nightpool]

for sure. But there's no real benefit that not storing IP addresses there gives you if you're already storing them in logs.

[nynhex]

@nightpool I already have a log purge function built into my fork on a system level.

[tscs37]

@nightpool I don't store IP addresses in logs other than the firewall where I purge them once the connection is closed.