[feature] Explicitely tell what data is stored (GDPR compliance)

[rdelaage]

Is your feature request related to a problem ?

To be GDPR compliant, we must explicitly tell what data is stored about the users.

Describe the solution you'd like.

We could add a GDPR.txt file to the root of this repository. We can also serve a /.well-known/gdpr.yml like Castopod does

Describe alternatives you've considered.

NONE

Additional context.

Note: I can draft a PR if you are ok with this feature

[tsmethurst]

Hrmmm is there a reason to put it in a machine readable format at a .well-known endpoint? If not, I'd rather just do this with a document served up as HTML or something.

Also, we'll have to investigate whether it's actually our responsibility as developers of server software to provide GDPR information alongside the source code. My intuition would be that it's not, since by working on GoToSocial and providing the software to people, we're not running a service that could infringe on GDPR, we're only making it available for others to run if they like. Again though, we need to confirm this properly, since 'my intuition' is not a legal guarantee (fortunately!).

That said, it might be beneficial to provide a template for server admins to generate some suitable GDPR blurb for their instance, and make it easier for them to comply with GDPR in other ways. We obviously don't want people to run up against GDPR violations by accident just by running the software.

Related (because they also mention GDPR):

• https://github.com/superseriousbusiness/gotosocial/issues/707
• https://github.com/superseriousbusiness/gotosocial/issues/1749

[rdelaage]

A machine readable format would help to generate some report about data usage of various software, and thus helping users to compare these softwares (I don't known if such a tool exists).

As a software editor, I think this is not mandatory for GoToSocial to provide GDPR information, but software developers are in the best position to know which personal data are used and why. It would greatly helps users to provide a ready-to-use document with this information. (I'm not a lawyer, so this is just my thoughts, no legal guarantee too :D)

[mirabilos]

I think this boils down to the information in the logs; you can disable IP addresses there, so it’s left to some variations on timestamp, user agent and API endpoint accessed. (That plus whatever the proxy you use does.)

Anything else is either coming in from machines or published by the users themselves, although (for nōn-solo instances especially) it might be worthwhile to support extracting all known data for any given account ID from the database in a semi-automated way. If I ever get a request from a remote user about the info my solo instance stores about them, I’ll probably just wing that in psql though.

I don’t think there is a need for anything machine-readable. The service operator needs to take into account what each thing they use collects, and then merge all that into an easily comprehended human-readable version anyway.

[tsmethurst]

I'm going to close this as won't implement. Instance admins should be able to provide GDPR stuff in the terms and conditions for the instance, so I don't think there's much else for us to do here.