[GDPR] Cookie free usage #4373

Originally created by @Pingger on GitHub (Nov 22, 2019).

EDIT: Round up (from 2019-11-22 21:40 UTC)

Things that should be done:

Add a privacy page (at least in english with reference to gdpr-page)
- explaining what the cookies do (GDPR strong suggestion)
- explaining what data is collected and why (GDPR requirement)
Add option to disable all non required cookies (GDPR requirement)
Add option for user to dump all his data (GDPR requirement)
Add option to delete that data (GDPR requirement)

See here:
https://gdpr.eu/cookies/

Old Post:

Gitea version (or commit ref): 1.9.4

Git version: irrelevant

Operating system: irrelevant

Database (use [x]):

PostgreSQL

MySQL

MSSQL

SQLite

Can you reproduce the bug at https://try.gitea.io:

Yes (provide example URL)

No

Not relevant

Log gist: irrelevant

Description

Not a bug, instead a Law Compliance issue. In a few weeks our local Government will start suing > Website owners, if it not possible to decline Cookies being set. (AKA if you use something like "by using this site you automatically accept cookies")
To comply I either need to password protect the whole subdomain for the gitea server or don't use gitea at all.
Or gitea needs to have an option for cookie free usage. Like instead sending the session id as a GET request, so adding that session key to all Links on the site and upon serving the request checking if the browser, ip, ... still match up. This would disallow the "Remember me"-Function
...

Screenshots

—

Originally created by @Pingger on GitHub (Nov 22, 2019). EDIT: Round up (from 2019-11-22 21:40 UTC) Things that should be done: - [ ] Add a privacy page (at least in english with reference to gdpr-page) - [ ] explaining what the cookies do (GDPR strong suggestion) - [ ] explaining what data is collected and why (**GDPR requirement**) - [ ] Add option to disable all non required cookies (**GDPR requirement**) - [ ] Add option for user to dump all his data (**GDPR requirement**) - [ ] Add option to delete that data (**GDPR requirement**) See here: https://gdpr.eu/cookies/ Old Post: >  >  > > - Gitea version (or commit ref): 1.9.4 > - Git version: irrelevant > - Operating system: irrelevant > - Database (use `[x]`): > - [ ] PostgreSQL > - [x] MySQL > - [ ] MSSQL > - [ ] SQLite > - Can you reproduce the bug at https://try.gitea.io: > - [ ] Yes (provide example URL) > - [ ] No > - [x] Not relevant > - Log gist: irrelevant > > ## Description > Not a bug, instead a **Law Compliance issue**. In a few weeks our local Government will start suing > Website owners, if it not possible to decline Cookies being set. (AKA if you use something like "by using this site you automatically accept cookies") > To comply I either need to password protect the whole subdomain for the gitea server or don't use gitea at all. > Or gitea needs to have an option for cookie free usage. Like instead sending the session id as a GET request, so adding that session key to all Links on the site and upon serving the request checking if the browser, ip, ... still match up. This would disallow the "Remember me"-Function ... > > > ## Screenshots > >  > —

GiteaMirror added the type/proposal label 2025-11-02 05:48:30 -06:00

GiteaMirror closed this issue

GiteaMirror commented

@guillep2k commented on GitHub (Nov 22, 2019):

Are session cookies also required to be announced? I think not. So, the quickest path to comply would be an option to disable the "Remember me" function.

You can disable the "Remember me" function by editing the login page template yourself if you are really pressed.

@guillep2k commented on GitHub (Nov 22, 2019): Are session cookies also required to be announced? I think not. So, the quickest path to comply would be an option to disable the "Remember me" function. You can disable the "Remember me" function by editing the login page template yourself if you are really pressed.

GiteaMirror commented

@Pingger commented on GitHub (Nov 22, 2019):

EDIT: GOT somewhat irrelevant, see top post for roundup

@Pingger commented on GitHub (Nov 22, 2019): EDIT: GOT somewhat irrelevant, see top post for roundup

GiteaMirror commented

@guillep2k commented on GitHub (Nov 22, 2019):

YES THEY ARE REQUIRED!

Hey, I live in Argentina. We don't even eat cookies here. No need to yell. 😁

However, from the link you provided:

Strictly necessary cookies — These cookies are essential for you to browse the website and use its features, such as accessing secure areas of the site. Cookies that allow web shops to hold your items in your cart while you are shopping online are an example of strictly necessary cookies. These cookies will generally be first-party session cookies. While it is not required to obtain consent for these cookies, what they do and why they are necessary should be explained to the user.

(Emphasis is mine).

Anyway, you can still update your template to warn and explain the users about any cookies.

@guillep2k commented on GitHub (Nov 22, 2019): > YES THEY ARE REQUIRED! Hey, I live in Argentina. We don't even _eat_ cookies here. No need to yell. 😁 However, from the link you provided: > Strictly necessary cookies — These cookies are essential for you to browse the website and use its features, such as accessing secure areas of the site. Cookies that allow web shops to hold your items in your cart while you are shopping online are an example of strictly necessary cookies. These cookies will generally be first-party session cookies. **While it is not required to obtain consent for these cookies, what they do and why they are necessary should be explained to the user**. (Emphasis is mine). Anyway, you can still update your template to warn and explain the users about any cookies.

GiteaMirror commented

@Pingger commented on GitHub (Nov 22, 2019):

OK ... sorry, It seems that I have multiple times now overread the not in that sentence ...
But then again, are those cookies strictly necessary?
By just opening the main page once, I get

_csrf (a session id, that is stored for 1 day?)
i_like_gitea (another session id, for the current session, I can see how that one is strictly necessary)
lang (why?! the Browser resubmits its language each time, and when I change it in my browser, why do I also have to delete a cookie, to apply it. lang is not strictly necessary, it is even counter intuitive ...)

EDIT: lang is set for ~75 years ...

EDIT 2: Yes I need to yell, because you are so far away, you otherwise couldn't hear what I say 🤐

@Pingger commented on GitHub (Nov 22, 2019): OK ... sorry, It seems that I have multiple times now overread the **not** in that sentence ... But then again, are those cookies strictly necessary? By just *opening* the main page once, I get - _csrf (a session id, that is stored for 1 day?) - i_like_gitea (another session id, for the current session, I can see how that one is strictly necessary) - lang (why?! the Browser resubmits its language each time, and when I change it in my browser, why do I also have to delete a cookie, to apply it. **lang** is not strictly necessary, it is even *counter intuitive* ...) EDIT: lang is set for ~75 years ... EDIT 2: Yes I need to yell, because you are so far away, you otherwise couldn't hear what I say 🤐

GiteaMirror commented

@guillep2k commented on GitHub (Nov 22, 2019):

@Pingger OK, I was only aware of the i_like_gitea cookie. Let's see what other maintainers have to say about this (as they may be well aware of the issue).

@guillep2k commented on GitHub (Nov 22, 2019): @Pingger OK, I was only aware of the `i_like_gitea` cookie. Let's see what other maintainers have to say about this (as they may be well aware of the issue).

GiteaMirror commented

2025-11-02 05:48:32 -06:00

@sapk commented on GitHub (Nov 22, 2019):

@guillep2k Your https://github.com/go-gitea/gitea/issues/9122#issuecomment-557526839 seems the good action to take.
What we should do:

Add a page describing all the cookies and what they do.
Allow a way to disable preference cookies like the remember me function, lang...
Maybe remove some that are not totally needed (like lang).

For details, the _csrf token would register as necessary cookie as it secure some actions by validating them.

@sapk commented on GitHub (Nov 22, 2019): @guillep2k Your https://github.com/go-gitea/gitea/issues/9122#issuecomment-557526839 seems the good action to take. What we should do: - Add a page describing all the cookies and what they do. - Allow a way to disable preference cookies like the remember me function, lang... - Maybe remove some that are not totally needed (like lang). For details, the _csrf token would register as necessary cookie as it secure some actions by validating them.

GiteaMirror commented

@silverwind commented on GitHub (Nov 22, 2019):

Yeah, I'd add something like "Privacy Information" to the footer which links to a page that explains what data is stored on a visitor's computer and for what purpose (the law is not only about cookies).

Just don't make any annoying dialogs please 😉.

@silverwind commented on GitHub (Nov 22, 2019): Yeah, I'd add something like "Privacy Information" to the footer which links to a page that explains what data is stored on a visitor's computer and for what purpose (the law is not only about cookies). Just don't make any annoying dialogs please 😉.

GiteaMirror commented

2025-11-02 05:48:32 -06:00

@sapk commented on GitHub (Nov 22, 2019):

On a side note for the bigger picture of GDPR, we should also add :

A explanation to gitea hoster of what they need to do like : https://about.gitlab.com/gdpr/
and a docs how to edit the page holding GDPR information
A way to export and erase user related data (I think this was discussed in an other issue and since it is far more complex with relation to data in git history and who upload it.)
I think we should maybe mention external service like gravatar if activated.

@sapk commented on GitHub (Nov 22, 2019): On a side note for the bigger picture of GDPR, we should also add : - A explanation to gitea hoster of what they need to do like : https://about.gitlab.com/gdpr/ and a docs how to edit the page holding GDPR information - A way to export and erase user related data (I think this was discussed in an other issue and since it is far more complex with relation to data in git history and who upload it.) - I think we should maybe mention external service like gravatar if activated.

GiteaMirror commented

@guillep2k commented on GitHub (Nov 22, 2019):

What about a pre-defined template in /contrib the users can add to custom/templates? It may default to empty, and be referenced from home.tmpl. Multi-language may be a problem, though, although not unsurmountable. I'm sure there's plenty of resources in internet with such legal notice already translated.

@guillep2k commented on GitHub (Nov 22, 2019): What about a pre-defined template in `/contrib` the users can add to `custom/templates`? It may default to empty, and be referenced from `home.tmpl`. Multi-language may be a problem, though, although not unsurmountable. I'm sure there's plenty of resources in internet with such legal notice already translated.

GiteaMirror commented

@bagasme commented on GitHub (Nov 23, 2019):

@Pingger I had similar feature issue in #8353.

@bagasme commented on GitHub (Nov 23, 2019): @Pingger I had similar feature issue in #8353.

GiteaMirror commented

@Pingger commented on GitHub (Nov 23, 2019):

@Pingger I had similar feature issue in #8353.

Yours was more for privacy information, mine was initially intended for removal of cookie requirement. But I agree, it has also changed strongly in the direction of your Feature Request.

@Pingger commented on GitHub (Nov 23, 2019): > > > @Pingger I had similar feature issue in #8353. Yours was more for privacy information, mine was initially intended for removal of cookie requirement. But I agree, it has also changed strongly in the direction of your Feature Request.

GiteaMirror commented

@guillep2k commented on GitHub (Nov 24, 2019):

* A way to export and erase user related data (I think this was discussed in an other issue and since it is far more complex with relation to data in git history and who upload it.)

@sapk Is this even possible with a git repository? Like commits, signatures, etc.

@guillep2k commented on GitHub (Nov 24, 2019): > > > * A way to export and erase user related data (I think this was discussed in an other issue and since it is far more complex with relation to data in git history and who upload it.) @sapk Is this even possible with a git repository? Like commits, signatures, etc.

GiteaMirror commented

@lafriks commented on GitHub (Nov 24, 2019):

@guillep2k it is not possible with git repository as that would require rewriting whole repository git history and it would lose all signed commits and would require retag all tags, so it is unrealistic

@lafriks commented on GitHub (Nov 24, 2019): @guillep2k it is not possible with git repository as that would require rewriting whole repository git history and it would lose all signed commits and would require retag all tags, so it is unrealistic

GiteaMirror commented

@guillep2k commented on GitHub (Nov 24, 2019):

@guillep2k it is not possible with git repository as that would require rewriting whole repository git history and it would lose all signed commits and would require retag all tags, so it is unrealistic

My point exactly. 😄

What I mean is that we can't bother to e.g. being responsible for removing user data, or force a repository owner to expose a private repo that has commits from public repos, etc. There's no way to comply with something like that. All we can do is:

Give the users the option of removing their account (already possible unless it's an enterprise environment with users taken from LDAP, etc., in which case who cares).
List all the issues/PRs where they have commented (already possible by API, I believe?)
Let the user remove?/anonymize all of their comments from issues/PRs.... I think the latter is already being done by the delete account procedure. As far as privacy goes, I think anonymizing the posts should be enough.

Am I missing something?

@guillep2k commented on GitHub (Nov 24, 2019): > > > @guillep2k it is not possible with git repository as that would require rewriting whole repository git history and it would lose all signed commits and would require retag all tags, so it is unrealistic My point exactly. 😄 What I mean is that we can't bother to e.g. being responsible for removing user data, or force a repository owner to expose a private repo that has commits from public repos, etc. There's no way to comply with something like that. All we _can_ do is: * Give the users the option of removing their account (already possible unless it's an enterprise environment with users taken from LDAP, etc., in which case who cares). * List all the issues/PRs where they have commented (already possible by API, I believe?) * Let the user remove?/anonymize all of their comments from issues/PRs.... I think the latter is already being done by the delete account procedure. As far as privacy goes, I think anonymizing the posts should be enough. Am I missing something?

GiteaMirror commented

@lafriks commented on GitHub (Nov 24, 2019):

imho when user is deleted all comments for that user becomes as commented by Ghost so that should be enough

@lafriks commented on GitHub (Nov 24, 2019): imho when user is deleted all comments for that user becomes as commented by `Ghost` so that should be enough

GiteaMirror commented

@bryanpedini commented on GitHub (May 13, 2020):

EDIT 1: added source about entire SHA1 history rebase for author info (email/name/commit_message)

From comment 69897:

A way to export and erase user related data (I think this was discussed in an other issue and since it is far more complex with relation to data in git history and who upload it.)

I don't see why you can't tell the user "hey, you joined a service that keeps track of who submitted what, we won't change how git works just because you want to get deleted; your email won't be in our systems anymore, wherever possible, but all your commits get either deleted if they're part of a repository owned by your account, or remain in the system if they're in a public or otherwise owned repo".

Regarding to the fact that the commits need to remain by how git works, from comment 15586:

imho when user is deleted all comments for that user becomes as commented by Ghost so that should be enough

imho effectively rewrting all the user's commit history (remember, you can hide the user from the web interface, but not effectively from all the single commits which base their SHA1 on the committer too), has to remain the same. An entire rebase of all the repos a particular user has committed to, just because a deletion request seems a little bit too far from being reasonable. (source: https://gist.github.com/masak/2415865, found in literally two minutes of googling).
Also, GDPR doesn't strictly require that you delete all the data, if you're forced to keep it for example by law, and in this case, by how the git system itself works. Gitea is imho a simple "web visualizer" (and manager and cloner and stuff, you get the point) of an underlying system not controlled by Gitea itself, which is git.
IMO letting the user know that anything he does regarding pushing commits and stuff that cannot be deleted even by entirely uninstalling the whole Gitea instance and trasfering all the repos to GitLab for example (in this case, the commits themselves), and telling him/her "look, you got this service, here are the terms and conditions, you accept them fine, you don't don't use the service", is GDPR-compliant "enough"...

Tho I'm not either a lawyer nor a GDPR expert, I only read here and there some articles and understood what I needed to understood for my personal life, so I might be both terribly wrong by means of how it should be implemented and terribly unlawful by means of effective GDPR compliance. Please don't quote me on this!

@bryanpedini commented on GitHub (May 13, 2020): EDIT 1: added source about entire SHA1 history rebase for author info (email/name/commit_message) From [comment 69897](https://github.com/go-gitea/gitea/issues/9122#issuecomment-557669897): > * A way to export and erase user related data (I think this was discussed in an other issue and since it is far more complex with relation to data in git history and who upload it.) I don't see why you can't tell the user "hey, you joined a service that keeps track of who submitted what, we won't change how `git` works just because you want to get deleted; your email won't be in our systems anymore, wherever possible, but all your commits get either deleted if they're part of a repository owned by your account, or remain in the system if they're in a public or otherwise owned repo". Regarding to the fact that the commits need to remain by how `git` works, from [comment 15586](https://github.com/go-gitea/gitea/issues/9122#issuecomment-557915586): > imho when user is deleted all comments for that user becomes as commented by `Ghost` so that should be enough imho effectively rewrting all the user's commit history (remember, you can hide the user from the web interface, but not effectively from all the single commits which base their SHA1 on the committer too), has to remain the same. An entire rebase of all the repos a particular user has committed to, just because a deletion request seems a little bit too far from being reasonable. (source: https://gist.github.com/masak/2415865, found in literally two minutes of googling). Also, GDPR doesn't strictly require that you delete **all** the data, if you're forced to keep it for example by law, and in this case, by how the `git` system itself works. Gitea is imho a simple "web visualizer" (and manager and cloner and stuff, you get the point) of an underlying system not controlled by Gitea itself, which is `git`. IMO letting the user know that anything he does regarding pushing commits and stuff that cannot be deleted even by entirely uninstalling the whole Gitea instance and trasfering all the repos to GitLab for example (in this case, the commits themselves), and telling him/her "look, you got this service, here are the terms and conditions, you accept them fine, you don't don't use the service", is GDPR-compliant "enough"... Tho I'm not either a lawyer nor a GDPR expert, I only read here and there some articles and understood what I needed to understood for my personal life, so I might be both terribly wrong by means of how it should be implemented and terribly unlawful by means of effective GDPR compliance. Please don't quote me on this!

GiteaMirror commented

@zeripath commented on GitHub (Sep 7, 2020):

See also #12298

@zeripath commented on GitHub (Sep 7, 2020): See also #12298

GiteaMirror commented

@Fl1tzi commented on GitHub (Apr 11, 2023):

https://github.com/go-gitea/gitea/issues/9122#issuecomment-557664851
For details, the _csrf token would register as necessary cookie as it secure some actions by validating them.

In my understanding, technically required cookies are allowed to be used without announcing them. However, the _csrf cookie is not technically required when the user is not logged in. Therefore, you would need to inform the user about it.

The most simple solution to it would be to just not use the _csrf cookie when the user is not logged in.

@Fl1tzi commented on GitHub (Apr 11, 2023): > https://github.com/go-gitea/gitea/issues/9122#issuecomment-557664851 > For details, the _csrf token would register as necessary cookie as it secure some actions by validating them. In my understanding, technically required cookies are allowed to be used without announcing them. **However**, the _csrf cookie is not technically required when the user is not logged in. Therefore, you would need to inform the user about it. The most simple solution to it would be to just not use the _csrf cookie when the user is not logged in.

GiteaMirror commented

@delvh commented on GitHub (Apr 11, 2023):

I am not a lawyer, but I don't think a technically required cookie depends on the context to be technically required.
I want to see the lawyer who sues a page on the basis that even anonymous users get a CSRF cookie that is not misused in any way.

@delvh commented on GitHub (Apr 11, 2023): I am not a lawyer, but I don't think a technically required cookie depends on the context to be technically required. I want to see the lawyer who sues a page on the basis that even anonymous users get a CSRF cookie that is not misused in any way.

GiteaMirror commented

@Fl1tzi commented on GitHub (Apr 11, 2023):

Cantao (they are saying they are GPDR compliant):

Providing CSRF protection for users that are not authenticated against the app does not make any sense.

You are maybe correct, but that doesn't change that the cookie is simply not required, and the cookies used should be minimized.

@Fl1tzi commented on GitHub (Apr 11, 2023): [Cantao](https://docs.contao.org/dev/framework/request-tokens/) (they are saying they are GPDR compliant): > Providing CSRF protection for users that are not authenticated against the app does not make any sense. You are maybe correct, but that doesn't change that the cookie is simply not required, and the cookies used should be minimized.

GiteaMirror commented