Persistent sessions and GDPR cookie consent

support
1

I’m setting up a discourse forum in a very privacy-aware environment. The current snag I’m running into is the persistent sessions setting, i.e. “remember me” for login. As far as I can tell the GDPR requires a user to give explicit consent for storing functionality/preference cookies, which includes persistent sessions (as the cookie used to handle a persistent session, or actually its lifetime beyond the browser session, is not strictly necessary).

The leads to two very unattractive choices:

  1. Disable persistent sessions, forcing every user either to log in every time they visit the forum, or to suggest/force them to use browser-based credential storage if they want to avoid logging in manually every time. However, since we will be using SSO for forum access, and there are many different services accessed through that SSO login having users store SSO credentials just for accessing the forum is not good policy. It might do more harm than good.

  2. Enable persistent sessions. But here I don’t see a feasible method for having a cookie banner integrated in Discourse that handles a per-user configuration value of the persistent sessions flag. The latter is crucial as consent needs to be given by the user, including being able to retract that consent, which requires some form of cookie banner/management solution.

I’m active on a number of Discourse forums that have persistent sessions enabled but don’t provide a cookie consent option (which includes this meta forum). And it seems to me they are operating in violation of the GDPR?

Am I wrong in the above reading (as I’m not a lawyer)? And are there really no good solutions available that integrate a cookie consent banner in Discourse that allows configuring a per-user persistent cookie setting?

Edit: I did read Cookie Consent, GDPR, and Discourse, and posts like Session Timeout - #56 by sam before posting, but they don’t really come to the crux on persistent sessions

2

Here is now two different things.

Legally by GDPR/data privacy you don’t need consent for persistent session. It is technical cookie for an user and not used collect personal data. Sure, you have to tell it is there, but it is user’s job to logout everytime if they want avoid remebering. You can still offer it.

And there is this:

That is totally different game and playfield. Here in Nordic every sites that are operating on banking, health care in any way, goverment/local bodies etc. will logout automatically after some time or after inactive period (hopefully that is true world wide) and then persistent ones are impossible. And same is true on sites that are, for their’s reasons, very privacy aware.

If that is true in your case I don’t know any out-of-the-box solutions, but here is a lot pros who may/will know.

But in generally you don’t need consent from an user for that. But there can be special cases when you can’t even offer it.

3

The point is not that it doesn’t collect personal data, the _t cookie identifies you as a person as it’s directly tied to your user account’s session on the Discourse server. So having the authentication cookie set in your browser means you’re identifiable for the server whenever you use your browser to visit the website that set it (and so you’re not anonymous). From the European Commision’s Data Protection Working Party WP 29 Opinion 04/2012 on Cookie Consent Exemption - 00879/12/EN WP 194:

Persistent login cookies which store an authentication token across browser sessions are not exempted under CRITERION B. This is an important distinction because the user may not be immediately aware of the fact that closing the browser will not clear their authentication settings. They may return to the website under the assumption that they are anonymous whilst in fact they are still logged in to the service. The commonly seen method of using a checkbox and a simple information note such as “remember me (uses cookies)” next to the submit form would be an appropriate means of gaining consent therefore negating the need to apply an exemption in this case.

Note that they suggest a simple solution websites can implement, a “Remember me” checkbox in the login form, which of course is available almost everywhere these days (but not in Discourse). This was a decision from 2012, so before the GDPR came into effect, but I don’t see any information that it has been superseded (e.g. Cookie Consent Exemptions: Strictly Necessary Cookies - CookieYes updated August 2023 still mentions persistent authentication cookies need consent). But there might be some legal followup or developments I’m not aware of.

4

Wrong. It is the only point.

That is not collecting and storing personal data that can or will be used to identify an user. A forum knows anyway who you are.

5

How will a forum know who you are if you visit it with a browser in which that cookie isn’t set? And you should be able to use a forum without being implicitly tracked, unless you have given explicit consent for that, in this case that you allow the _t cookie to persist after the browser session ends.

6

For the record, the above information is incorrect.

@paulmelis I think you are correct and this is a good catch.

A persistent cookie does need explicit permission even if it provides specific functionality to the user: the user must have explicitly requested the functionality.

To make things worse, the various existing “cookie consent banner” solutions that are currently available for Discourse, including the official theme component, are not GDPR compliant. They will only inform the user about these cookies being set, but if the user does not click the “I understand” button then Discourse will happily set those cookies anyway. In other words, these solutions are not asking for permission for something to happen, they are informing the user that something is happening (or worse: happened already).

So even if you would have a cookie consent banner on your forum, if you have persistent sessions enabled, you’re still in violation of the GDPR.

This all said, I doubt that this will be a huge problem in practice, but for those of us that are looking for 100% compliance this is an issue indeed.

For now your only option will be to disable the persistent sessions setting.

On a first glance, this does look very doable in a plugin, although it would be much better if this was in core Discourse.

1 Like
8

No it is not. This has been rolled via EU-lawyers at big enterprises so many times and it has never changes.

Still have to remember what is the target and purposes of GDPR and its followers. And why we can have technical cookies without need to get consent.

9

@paulmelis has provided citations from official EU documents that explicitly state they’re not permitted by GDPR.

If you have different information, I’m all ears, but please cite your sources and provide links to the original documents.

10

It doesn’t say that.

No offence, but this is as difficult, and kind of pointless offer public legislation as a source like it is pointless guide me to secrets of swap offering man swapon. There is demand to some knowledge and I can read those man pages, but I don’t understand what I’m reading.

I’m working with these daily basis and any of these questions aren’t new for me. That’s why I give two recommendations:

  • buy needed software and ask what consent wanted for everything (it doesn’t help because after all how that data is used is important, not consent per se)
  • if an enterprise is big enough (like CDCK for example) that there is actual risk to get fines then must use legal division of company or pro level 3rd party
11

Right, that’s (unfortunately) what I’m doing now.

I’m really curious how you read that document then. I mean, 3.2 Authentication Cookies lays it out pretty clearly:

Authentication cookies are used to identify the user once he has logged in (example: on an
online banking website). These cookies are needed to allow users to authenticate themselves
on successive visits to the website and gain access to authorized content, such as viewing their
account balance, transactions, etc. Authentication cookies are usually session cookies. The
use of persistent cookies is also possible but they must not be regarded as identical, as
discussed below.

Recognizes the need for authentication cookies (note, not named technical cookies). Explicitly states that lifetime of these cookies, i.e. session vs persistent, implies them to be treated differently.

When a user logs in, he explicitly requests access to the content or functionality to which he is
authorized. Without the use of an authentication token stored in a cookie the user would have
to provide a username/password on each page request. Therefore this authentication
functionality is an essential part of the information society service he is explicitly requesting.
As such these cookies are exempted under CRITERION B.

However it is important to note that the user has only requested access to the site and specific
functionality to perform the task he requires. The act of authentication must not be taken as an
opportunity to use the cookie for other secondary purposes such as behavioural monitoring or
advertising without consent.

Logging in means the user provided consent to being logged in, not for other types of data usage through any authentication cookies set.

Persistent login cookies which store an authentication token across browser sessions are not exempted under CRITERION B. This is an important distinction because the user may not be
immediately aware of the fact that closing the browser will not clear their authentication
settings. They may return to the website under the assumption that they are anonymous whilst
in fact they are still logged in to the service. The commonly seen method of using a checkbox
and a simple information note such as “remember me (uses cookies)” next to the submit form
would be an appropriate means of gaining consent therefore negating the need to apply an
exemption in this case.

CRITERION B being:

the cookie is “strictly necessary in order for the provider of an information
society service explicitly requested by the subscriber or user to provide the service”.

So the user needs to provide consent before persistent authentication cookies may be set. Reason: you cannot expect a user to know the implications of persistent authentication by default.

Yes, the legislation is diffuse and complex, with many different updates over two decades almost. And even the official EU sites I looked into seem to be very messy when it comes to how they handle cookies and their stated policies.

2 Likes