Change 9 for Assembly 2024: Add draft for privacy policy #54

Is there a due process for this? Under what conditions? Will the other person be informed about such a request?

I think we should rephrase this to indicate that we are probably not going to send out a list of email addresses. In practice, if someone demands contact details, we'd probably try to quickly assemble a mailing list or similar approach.

Maybe we should give another example than "email addresses"?

Alternatively, we could inform Codeberg e.V. members transparently about this possibility and ask them to provide us with an alias in case they want to remove their current (potentially private) email address from the records.

I will discuss the exact requirements here with a lawyer.

Result of further investigation were two things:

• The suggestion in general was to keep the privacy policy as broad as possible, and put "how exactly we do things" into less broadly applicable documents like our association's regulation.
• The request is only valid in certain circumstances where the member wants to e.g. start a legal process he has the right to but needs the information for (like the "Minderheitsbegehren" / minority request).

What other technical metadata is collected (and what purpose does the collection serve)?

From 3.1:

for the purpose of providing the platform services

The exact details are dependent on the software used - some may track user agents, usernames, IP geolocation and other info, but AFAIK usernames & IP addresses are the main PII here, anything else mostly can be inferred from the rest.

The new version now has much more details on that, it was also a recommendation from the lawyer.

We should look into whether IP address processing also constitutes a legitimate interest (Art. 6.1.f GDPR). That might be more relevant for non-registered users (site/pages visitors).

I think this shouldn't be an issue, I will take a closer look into this.

I think this shouldn't be an issue, I will take a closer look into this.

We should look into whether IP address processing also constitutes a legitimate interest (Art. 6.1.f GDPR). That might be more relevant for non-registered users (site/pages visitors).

Yes, IP address collecting does fall under legitimate interest. This is a normal use case, for providing services and retaining log files in case of, e.g., a hacker attacking the website.

Is there a chance that the metadata (e.g. access logs) could be retained for a longer period of time in the event of e.g. a security incident?

or supposed criminal investigations?

in the event of e.g. a security incident?

I would prefer requiring for them to be pseudonymized in that case. Access logs themselves are not PII AFAIK.

or supposed criminal investigations?

Even though there was a downvote, that's a good point! We could use a canary here. I will check with a lawyer what's possible, and mentioned in the privacy policy that this is indeed a possibility.

Information about potential lawful requests should not be part of the privacy policy, mostly as I couldn't get more information on that and a "less formal" place probably makes more sense here.

Regarding the logging duration, it was extended to 7 days now.

Backups

How do we deal with the theoretical case of:

• an account is deleted
• our database crashes
• restore a backup from when the account still exists

?

I've added that. We need a list of removed PII (theoretically that's just data retention rules & a list of people who requested GDPR-conform data removal, but we can/should include deleted users as well) for when we restore a backup. We should have a script for that.

7 days right now

storing logs of an atack for post-mortum analysis longer?

3 years ... are you sure this is not longer? I expected that it would be more like 7 or 10 years (which seems to be the case for most tax-relevant documents? Don't we need to proove that someone was a member to mark certain transactions as tax-deductible or something?)

I was also wandering about this, but my quick search only showed information about businesses and not non profits. If we exceed the limits of simplified tax regulations, then it would be 6 or 10 years (differs for different categories of documents).

I will discuss this with a lawyer.

It is indeed 10 years and changed now. Logs are now stored for 7 days, for post-mortum analysis we would have to completely anonymize IP addresses anyways.

s/their/its?

our bylaws -> Codeberg's Bylaws

Where's the data stored? -> Germany, physical servers owned by us

We can't really guarantee that as e.g. Stripe processes personal data for us (albeit by the user's choice) and is not an EU entity. I think this is more something for an infrastructure review than for the privacy policy if we can't guarantee it for all personal data we process. I can try to add it to the list of third parties in the end though in some way.

I have added "All servers of Codeberg e. V. are physically located in Germany." under §4, before the third-party processing clause.

I think we should really find a cool wording here which differentiates from general introductions from most companies ...

I like it. A bit like the GPL preamble that explains the spirit, rather than the legal specifics.

Here's another suggestion:

We don't want to need your data. We therefore want to be fully transparent about how we use it, and are always open to viable suggestions on how to reduce your data footprint on our servers. We try to use privacy-friendly open source software and not rely on third parties whenever possible in our modern world, both as a provider of our public FOSS forge and as a German non-profit organization.

There isn't "one infrastructure team", but rather a lot of individuals teams right now. Some might be able to access all data, others only a subset. But I think we should reflect that there might be a lot of people who have certain access privileges on data, even if it is "just" access logs of a random unimportant service.

"according to their position"

maybe have a full list as an appendix (without the need to update the privacy policy)?

Moderation Team, private repositories, etc.

Something like "Repository contents, including issues, comments and contents of private repositories, are not treated as personal data. It is your responsibility to not store any personal data here, or obey the GDPR when specifically using it to store personal data of other persons." might make sense 🤔

Must be checked, it's more like 6-10y.

See https://www.dsgvo.tools/aufbewahrungsfristen/

why is the appendix commented out?

We should keep this internal and only provide it on request.

• We do not instead of We do not.
• wherever possible in our modern world is not appropriate for a legal document. What does modern mean?
• We try to use privacy-friendly open source software: Do we publish our member management tools? What do we classify as privacy-friendly? I find this too ambiguous and in contradiction to how we present ourselves on the homepage.

I rewrote the same content in three sentences:

• We strive to minimize the amount of data on Codeberg e.V. members and Codeberg.org users.: This removes the ambiguity behind you, and removes the need for the last sentence. It is also more clear than public FOSS forge, as we host more than Forgejo.
• As such, we strive to be transparent about how we use your data, and are open to suggestions for reducing your data footprint on our servers.
• We share your personal information only when strictly necessary.: whenever possible is way too ambiguous and not in line with how we currently do things.

We strive to minimize the amount of data on Codeberg e.V. members and Codeberg.org users.

Is data on Codeberg e.V. members and Codeberg.org users made more concrete later on? e.g. it doesn't indicate where data is stored (e.g. on hardware owned/operated by whom?) and is still a bit vague, but that would be okay if it is specified later.

Additional note: We do not just host software.

We strive to minimize the amount of data on Codeberg e.V. members and Codeberg.org users. As such, we strive to be transparent about how we use your data, and are open to suggestions for reducing your data footprint on our servers. We share your personal information only when strictly necessary.

This unfortunately sounds like every company's privacy policy ever to me - I think we should be creative with this first paragraph.

It is the introduction of the privacy policy, everything in there is made more concrete later on.

We do not just host software.

I don't see where that is implied in the original sentence.

I agree with the point you've raised.

Marking as resolved.

• This documents helps to achieve that goal: Could be simplified or removed - it feels like an opinion. I think that describing it as a goal, then following up with DSGVO ("legal obligation") is a bit contradictory.
• DSGVO -> GDPR (or use both); not everyone speaks German.

Alternative suggestion:
This document outlines our responsibilities and duties regarding the processing of your personal data, as defined by Article 13 of the European Union's General Data Protection Regulation (GDPR). It also provides information on the rights that you have as a data subject.

Wrong link? Nitpick: account registration

non-revokable -> irrevocable (typo, vocabulary)
time-limited -> apply indefinitely (time-limited is vague)
The author details will never have to be deleted, as: ->Commit author records cannot be deleted, as...

Also, users of the software may have a legitimate interest in keeping the authorship records to prove who granted them the license.

may?

Apparently, nonrevokable, nonrevocable and irrevocable are equivalent words you can find in a dictionary. Although I prefer irrevocable, the dash should probably be dropped.

during donation -> when donating
during membership application -> when a member application is sent

"during" can mean that we collect data before the information is sent.

fulfil -> fulfill

British vs. American english - seems like we're mostly using American english, but I'm sure we have similar mistakes elsewhere ;)

When you're a... -> As a member of Codeberg e.V., we process the following information

you're is informal. We keep a copy of the said data. need can be dropped. respective -> following

In some cases, every: Moving In some cases to the beginning of the sentence makes the sentence much easier to read.

typo: internet services providers -> internet service providers

a full list of what?

typo: as required according to -> as required by

This sounds challenging. If we need to restore a backup, how do we know the data was purged?

Also, is one year really how long we want to store a backup?

AFAIK, the best way is to keep a list of UUIDs that were deleted at a certain point in time, and keep that alongside our backup. I can't find the page where I read that though, but that said I haven't found any other suggested solution yet, just sites saying "it's complicated".

At least I don't think we want to store backups for longer than 1 year.

We should stay grounded and work with what we know and what we have. The two past replies raise the following questions:

• What do we seek to protect ourselves from with a retention period of over a year? Say, some supposed corruption caused over the longer-term that might require reverting the database state to over a year ago?
• Is the list of UUIDs actually technically feasible right now?

I think something like 90 days is more reasonable. I imagine the following use for less frequent backup pruning:

• We might want to check historical things, e.g."When was this (issue) introduced?".
• Backup pruning takes resources and running it not too might be a good thing. For instance, I run the backup machine for our mail server at home, which does less frequent backup and even less frequent pruning.
• Technical issues: Back when we had backups running on a Raspberry Pi, there was a time when it was unable to compact the backup due to RAM constraints. Giving some time to detect and fix issues with backups is good.

But one year is rally long, I do agree.

here -> Codeberg's services
inconsistent use of GDPR and DSGVO
it -> what?
repository's owner? (not comments, contents, private repositories)

Actually, I will remove this point - it is better suited for the Terms of Service, and we can not just escape from the DSGVO by saying where it doesn't apply.

I think this part should stay in some form (albeit it might be fine to shorten it a bit), it should at least be mentioned.

Seconded, I think it is best to actively disclose this to set an expectation in the event of a highly hypothetical security vulnerability that might expose the contents of private repositories.

Not that we want this to happen and should not work towards preventing something like that from happening (i.e. internal team conversations), but still. If a person hosts closed-source NDA-bound patented software - it might be best not to have to have to answer to them if they were breaking the rules in the first place.

Another suggestion that might make it clear that it is more of an obligation to users and not primarily a limitation of our liability:

5. When projects hosted on Codeberg process personal data using Codeberg's resources (e.g. within our CI, by using repos as storage, or through a website hosted on Codeberg Pages), the project owner is primarily responsible for the data processing and must make sure to adhere to the GDPR independently from these terms.

Concerning the CI and that sort of stuff: Does that mean that there is a "Shared Responsibility" (Art. 26 GDPR; § 62 BDSG) or do we have a "Processor"-"Controller"Relationship (Art. 28 GDPR). If it's the latter one, a data processing agreement needs to be made. Also, one may need to have a formal data protection officer (see § 38 BDSG). Whatever the case, the clear relationship should be stated.

Is there actually a data protection officer now, re. Codeberg-e.V./Discussion#110? Per Art. 13 (1) (c) GDPR, the contact details of a data protection officer only need to be specified "where applicable".

Yes, @phrogg volunteered to be one - we don't strictly need one yet, but having one is better than not and doesn't really have any disadvantages. We can appoint him together with the privacy policy.

Доброго, но а мне это зачем и кто сказал что, Я не против, а не оборот

I would expect the processing of this data to be constituted through our usage agreement, wouldn't it? We are not momentarily asking for consent when users sign up. It also wouldn't make sense, since singing up is not possible without certain data.

Would it be a sufficient fix if the Register page provided a link to a Privacy Policy?

I am not lawyer:

I would expect the processing of this data to be constituted through our usage agreement, wouldn't it?
We are not momentarily asking for consent when users sign up.

By law, you seem to be required to have a dedicated privacy policy.
It may? be part of the Terms of Use,
but the privacy policy has to be linked from every page,
and the link basically has to state,
that it is a link to the privacy policy.

The terms of use are not linked in the registration form as well.

It also wouldn't make sense, since singing up is not possible without certain data.

Depends, what is done with the users' data, which is not only the registration data.

but the privacy policy has to be linked from every page,
and the link basically has to state,

technically linked in the footer already - but I offered something actionable with a yes/no that concerns the registration form, so I don't see the relevance with the substance of my question here.

I would expect the processing of this data to be constituted through our usage agreement, wouldn't it? We are not momentarily asking for consent when users sign up. It also wouldn't make sense, since singing up is not possible without certain data.

The user voluntarily shares data during registration under the conditions of the terms of use, and then the data is processed according to the privacy policy. We as Codeberg do not have contractual obligations (which would be point b) from the terms of use.

Agree that this needs to be reflected in the signup process a bit more.

We are not momentarily asking for consent when users sign up

Addressed here: Codeberg-Infrastructure/forgejo#108

I'm confused why membership fees are brought up here, as we are talking about "Platform users". Members can certainly be Platform users, but not every Platform user donates or pays membership fees. Thus I would add both as separate sections.

or just (when applicable)

It is contradictory to say that the IP address (which is personal data) is stored "anonymously" and separately from itself. The URL might also contain personal information, e.g. if a repository can only be accessed by one person, then nobody else would know the links to its contents and it is thus easily identifiable who accessed the site.

Maybe it makes more sense like this:

When stored in logs, the IP address is truncated so that this data is not associated with your personal data.

"pursuing our association purposes" does not sound like a well-defined purpose to me. The purposes could change with time, thus it would seem to me to be too vague.

We need to specify that it is not possible to enter into a membership contract without providing this data, and that not providing the data can prevent members from exercising the membership rights (Art. 13 (2) (e) GDPR).

The "association purposes" are clearly defined in our bylaws (§2, https://codeberg.org/Codeberg/org/src/branch/main/en/bylaws.md#2-purpose-and-tasks), I will add a reference to that so it's clear that this exact section is referenced.

Per §5 (1) of the statute, one can theoretically also become a member "in writing".

Is this point really needed at all?

Yes, we must list all locations (URLs etc.) where data is collected according to the lawyer I talked with, or at least it is strongly recommended.

All URLs? I personally have never seen that one.
If this is the case, why does this not include the user's settings page?

Two letters are listed here. So it would seem like there are two different legal grounds, but only one is mentioned in the text. I would distinguish "archiving" (per legal requirements) and "active use" (for membership management) as separate purposes. Same in line 58, except there it also sounds strange to talk about collecting membership fees as our contractual obligation, when it is much rather our contractual right.

Thanks, good point, I'll change this.

Regarding your point "it also sounds strange to talk about collecting membership fees as our contractual obligation" - obligations is the wording used in DSGVO, and the contract obligates us to various things like e.g. send invitations for the general assembly, keeping records of our members, collecting the membership fee (it is our right to receive the membership fee, but our obligation to collect it when a SEPA mandate is given), etc.

Why only upon request? It is okay to make this a separate document but I don't see why it couldn't be public. It will need to be prepared anyhow.

For context: A previous revision of the commit contained such a list - I can only theorize as to why it was removed.

To my knowledge in Germany,
this info is required to be available when the data processing is being done,
and therefore should be available without any request.

What does this info mean here? The third parties here, as listed by the commit, were, for instance, the Individual Network Berlin e.V. - aka. our colocation provider. I don't think I've seen anybody say that they host their servers on Hetzner, for example.

Like, I agree it would be cool and I'm 200% for documenting this somewhere, but there's a difference between cool and obligations - like, if in-berlin were to hypothetically burn down, it'd be great if we didn't, hypothetically (I'm not sure if this is the case), have to send everyone a new version with 30 days to opt out with a new hosting provider + an urgent member assembly.

I think we need more information about the problem before we try finding a solution for the problem.

I don't know, what was listed in the list beforehand,
so I assumed third party in the sense of DSGVO.

Third party has a specific meaning.
Third party is not someone like the colocation provider.
A third party is, when personal information is given to someone else,
so it can be processed with permission by the third party.

The content of the server is not allowed to be processed colocation provider,
as you probably have not given any permission regarding this.

A third party could be an advertiser, that uses/buys personal data, or
a SaaS storage provider, that writes in its EULA,
that data is sent to third countries for not backup or similar reasons.

The list of third parties should actually be very short, or even zero for Codeberg.

PS: Some are actually stating, that the server is hosted at Hetzner.

PPS: A variant I have also seen is, to just state, that data is being processed by the hoster for hosting purposes without stating the hoster exactly: https://www.flyeralarm.com/de/i/datenschutzerklaerung?hide-cookie-banner

Not including a full list was recommended by the lawyer I contacted because the list may change often and "better safe than sorry" as the privacy policy is a binding legal document and shouldn't contain much more than neccessary.

I would love to have a full public list, but that is something for our documentation or a separate file.

AFAIK for Codeberg, the list mainly contains payment processors (PayPal & Stripe) and hosters (Hetzner & NetCup, both are only used for specific stuff like email as well as as an emergency fall-back solution when there are issues with our physical infrastructure). Also in the future possibly stuff like payroll management etc.

"may not be" → "are not"?

This sounds like a new kind of processing not reflected above, that needs its own justification and should be contained in one of the above sections.

Storing encrypted backups are not deemed processing of personal data, as long as the data is purged upon restoration.

See e.g. https://blog.quantum.com/2018/01/26/backup-administrators-the-1-advice-to-deal-with-gdpr-and-the-right-of-erasure/, I think there was also a German ruling regarding this but can't find it right now.

CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it. Organizations will have to clearly explain to the data subject (using clear and plain language) that his or her personal data has been removed from production systems, but a backup copy may remain, but will expire after a certain amount of time (indicate the retention time in your communication with the data subject). Backups should only be used for restoring a technical environment, and data subject personal data should not be processed again after restore (and deleted again). While this adds some complexity, it allows organizations to have some time to re-engineer their data protection processes.

This is not very specific. As a reader I do not know more after reading this paragraph than I did before. What kinds of data are subject to what kinds of regulations?

Here as well, the lawyer recommended against stating this more closely in the privacy policy, as the obligations may change, there are some we miss or there are other requirements only affecting us in some circumstances.

Note that this should probably say either "the German Legislature" or "German legislation"

This section is quite standard nowadays, but reads very boilerplate. I think it would be much better to indicate on which areas the rights can be employed exactly, instead of just referring to "certain conditions", and if technical measures allow users to employ those rights, then to indicate which. I feel this would underline the fact that we actually care as we claim in the first section.

We are not allowed to change much here, the section is required by DSGVO and must just plainly list the legal rights. We also do not really have an automated process we could link to for most of the rights right now. I'll change the "certain conditions" to the correct DSGVO paragraph though.

As I understand it, the reasons in Art. 6 GDPR are required for legality of processing, but not sufficient for processing to be necessary. A better reason to cite is Art. 17 (3) GDPR.