Gitea: [GDPR] Cookie free usage

[Pingger]

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

—

[guillep2k]

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.

[Pingger]

EDIT: GOT somewhat irrelevant, see top post for roundup

[guillep2k]

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.

[Pingger]

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 🤐

[guillep2k]

@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).

[sapk]

@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.

[silverwind]

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 😉.

[sapk]

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.

[guillep2k]

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.

[bagasme]

@Pingger I had similar feature issue in #8353.

[Pingger]

@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.

[guillep2k]

* 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.

[lafriks]

@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

[guillep2k]

@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?

[lafriks]

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

[bryanpedini]

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!

[zeripath]

See also #12298