Cookie compliance under GDPR

Community
1

I would like to start a conversation on how to become GDPR compliant with regards to the use of cookies.

There was an old topic on EU cookie compliance here,

https://meta.discourse.org/t/compliance-with-eu-cookie-law/17727

…but GDPR is a completely different requirement. While EU cookie compliance only required a statement placed at the bottom or at the top of the website, that lets the user know cookies are being used, GDPR requires giving the user a real and informed choice.

Cookies can be used to uniquely identify a person, therefore they should be treated as personal data. The legal basis for storing cookies will typically be consent. The requirements are:

  • The users must have a choice. The fact that they use a website does not mean they agree to all cookies.
  • Like all other consent under the GDPR, consenting to cookies needs to be a clear affirmative action. An example is clicking through an opt-in box (no pre-ticked boxes).
  • The data subject should be able to withdraw consent as easily as they gave it.

The way I understand it, there currently is no standard solution for Discourse users to meet this requirement. If I am completely wrong about my interpretation of cookies and GDPR, or the use of cookies by Discourse, I will be glad to be told otherwise.

Searching around a little, I found some possible building blocks, for example this one:

Pros: OS / free

Cons: Mainly geared torwards old EU cookie law, doesn’t seem to support selective opt in/out. It seems to support withdrawing support, but it is not clear to me how this would integrate with Discourse. Maybe someone with good front-end skills can comment on that question.

Another choice I found was this one:

Pros: Appears to be fully GDPR compliant, with granular control, easy withdrawal/change of settings at any time.

Cons: Costs between EUR 39 for one (sub)domain, up to EUR 199 for multiple (sub)domains (per year). I don’t really feel like spending those sums for cookie control. If I am going to spend money, I would much rather donate towards a open source Discourse plugin.

How are other Discourse “data controllers” planning to deal with cookies under GDPR? I am surprised that there isn’t more discussion going on about this, which leads me to think that I may have fundamentally misunderstood something.

4 Likes
2

Also check List of cookies used by Discourse

6 Likes
3

Thanks, that’s really useful. If I understand GDPR correctly, session cookies are probably not relevant. However, I would guess that the theme_key cookie (and maybe the other non-session cookies as well), would classify as personal data, based on the following interpretation:

The GDPR explicitly states that online identifiers, even if they are pseudonymous, even if they do not directly identify an individual, will be personal data if there is potential for an individual to be identified or singled out. Any persistent cookie that is unique to the device by virtue of its attributes or stored values fits the criteria for personal data.
GDPR Compliance Means Cookie Notices Must Change | Cookie Law

If I see this correctly, the user should be give the choice to accept the cookie(s) or not. The same must apply for GA. The Civic example I posted above is a nice show case for solving the requirement in a compliant manner.

1 Like
4

No: if cookies are used to uniquely identify a person, then they should be treated as personal data.

No, (emphasis mine)

The theme_key cookie identifies a theme, not a person. I.e. multiple persons that use the same theme, will have the same theme_key cookie. There is no way to identify or single out an individual using the theme_key cookie. They are not personal data and they are not subject to the GDPR.

5 Likes
5

Theme_key cookie was an example from the list referenced by Falco. Since you seem to have a better understanding of the Discourse cookies than I do, what about the other Discourse non-session cookies, such as:

  • cn
  • _t (user authentication cookie)
  • cfduid
  • _utma
  • _utmz

Can you confirm that none of these cookies will be considered as Personal Data under the GDPR privacy law which will come into effect on May 25 of this year, and hence no functionality for consent and revokation of consent is required for a standard Discourse installation?

6

I think the article you referenced made things pretty clear, all you need to do is read it more carefully instead of generalizing examples and draw conclusions from that.

7

Just sayin’

:face_with_monocle:

image

8 Likes
8

@sam yes, the EU’s hypocrisy on this is quite amusing!

Given the punitive fines, I imagine many small forums will be nervous about the GDPR - not because those forums are doing anything unethical with personal data, but because there is a danger of their competitors using the poorly-defined law to raise spurious cases against them.

I, for one, have suffered multiple attempts at disrupting my (harmless local community) forum. Attempts which probably originated from my erstwhile competitors or people who personally disagree with my views. There are a lot of vindictive cowards out there - and when running a forum, you become a target to them.

Regarding steps to take to protect Discourse forum operators from fines and harassment under this new law, I think the following might be worthwhile:

  • No cookies stored at all for non-signed in visitors
  • Google analytics disabled for non-signed in users
  • A consent checkbox (default unchecked) on the sign up screen, with a brief summary of which personally identifying information will be stored and which will be transmitted to Google Analytics (if enabled for the forum)
  • Consent form shown to all existing members, with consent required to continue using the forum - in fact we may have to go further here - removing any personally identifying data on members who have not logged in, seen and given this consent before May 25th.
  • Send partial IPs to Google Analytics to avoid unnecessary transmission of personally identifying data
  • No IP addresses stored in the Discourse DB - all should be hashed in an irreversible way and this data stored only temporarily, for the purposes of sock puppet detection.
4 Likes
9

I may be wrong, but I think cookies are outside of GDPR scope. GDPR is about storing personal data by the data processor (on their infrastructure). Cookies, on the other hand, physically are not stored by data processor. Cookies are stored by the browser on CLIENT (customer) machine. Customer is free to a) not allow cookies and b) delete/disable cookies at any time without any action required from data processor side. So consent to use cookies is given by customer by appropriate browser settings and such consent can be withdrawn at any time by the customer by changing browser settings.

On a side note: could we have some kind of “Consent to GDPR given” field added to the database with date when this consent was given (as GDPR requires data processor to be able to demonstrate when it was given)

10

Those aren’t tracking cookies. Cookies policy - European Commission says (emphasis theirs):

The cookie-related information is not used to identify you personally

3 Likes
11

One of the (many) problems of GDPR is that it doesn’t go into much detail regarding cookies. Recital 30 only mentions:

Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers … This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

When combining this with recital 26, which states

Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person

I think most readers will agree, that the combination of recital 30 and 26 leads to a pretty far flung net, in which many cookies will become caught.

Here is what I found to be a nicely written article on the subject of cookies and
GDPR: https://www.thesslstore.com/blog/amp/cookies-gdpr-compliance-involves-consent/

Based on what I believe to have understood so far, Discourse standard cookies (mainly _t and the session cookie _forum_session) are nothing to worry about, as they fall into the “essential” category, and contain no relevant identifiers (or are only session cookies). Where things become more problematic, is with GA cookies. I don’t think anyone will disagree with me, if I stated that Google is probably pretty good at combining “identifiers and other information received by the servers, [to] create profiles of the natural persons and identify them.”

The legal basis for sending data of EU users to Google will most likely be consent. As Chris nicely stated, this requires a (unchecked) consent checkbox (switch or similar), which can be updated at any time by the user. This functionality could probably be selectively applied only to EU located users, determined by their source IP’s (which may be problematic if the EU user is terminated in a non-EU IP range, i.e. through vpn, etc).

8 Likes
12

@Allen you are spot on with your analysis. And yes I meant only Discourse own cookies not Google Analytics. I don’t have GA enabled on my forum so I was not even considering them. Personally I block all Google tracking wherever I can.

2 Likes
13

Yours seems like the reasonable and safe route to take for now, at least until the proposed e-Privacy regulation will come into effect (it appears that it will not be ready by May 25). I understand that it may bring some more clarity to things like web analytics. In any case, I am also considering dumping GA, in favor of something like Matomo (ex PIWIK). As discussed earlier, it appears that one needs to have GA turned off by default for EU users, leaving it up to them to turn on tracking. Probably not many users are going to do that, rendering GA web analytics pretty useless.

As stated at the beginning of the topic, I also was considering consent support for my site because of GA. The solution I liked most was Civic Cookie Control, though the community edition lacks geolocation. Geolocation would be important to at least enable GA for non-EU users by default.

Even though I will probably rather self-host my analytics (and thereby not have to worry about consent), I would still like to share some details about my test setup with Cookie Control. If someone wants to use the paid version with geolocation, I think it’s not a bad solution, though it sends the IP of your visitors to a third party.

This is what it could look like on Discourse:

image
image773×755 28.7 KB

The user can change his preferences at any time by clicking on gear (opens up the panel again):

image
image777×751 34 KB

This is my config (put this in under Customize > Themes):

<script src="https://cc.cdn.civiccomputing.com/8.0/cookieControl-8.0.min.js"></script>
<script>
    var config = {
        apiKey: 'put-in-your-api-key-here',
        product: 'COMMUNITY',
        optionalCookies: [
          {
            name : 'analytics',
            label: 'Analytical Cookies',
            description: 'Analytical cookies help us to improve our website by collecting and reporting information on its usage. Even if set to On, your IP address is anonymized.',
            cookies: ['_ga', '_gid', '_gat', '__utma', '__utmt', '__utmb', '__utmc', '__utmz', '__utmv'],
            onAccept : function(){
              // Add Google Analytics
              (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
                (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
                m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
                                      })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
        
              ga('create', 'UA-123456789-1', 'auto');
	      	  ga('set', 'anonymizeIP', true);  // very important
              ga('send', 'pageview');
              // End Google Analytics
            },
            onRevoke: function(){
              // Disable Google Analytics
              window['ga-disable-UA-123456789-1'] = true;
              // End Google Analytics
            },
			initialConsentState : 'off'  // this pretty much kills analytics, better would be to differentiate between EU and non-EU 
          }
        ],
        position: 'LEFT',
        theme: 'LIGHT'
    };
    CookieControl.load( config );
</script>

The api key you need to get here (community edition is free for one domain)

2 Likes
14

There is no point in hashing IP(v4) addresses – there’s not enough of them to prevent reversing the hashes through brute-force. The only way to anonymise IPv4 data is to not store it. Which makes a real mess of pretty much every anti-abuse measure in existence (not just in Discourse – when the only non-spoofable information is L3/L4, to decide whether or not something is abuse, what else are you going to key off, other than source IP address?)

How so? Do EU residents not travel outside the EU? Or does the GDPR not apply to EU residents when they’re not accessing the Internet via an IP address which is identified as being within the EU? That seems… unlikely.

5 Likes
15

Given that we’re dealing with Eurocrats here, a box-ticking measure will probably suffice :wink:

16

Let’s please refrain from pejorative names here. Intentionally using a negative name for something leads to corrosion of the discussion.

17 Likes
17

This is another major point of confusion with regards to GDPR. It doesn’t mention EU citizens or residents. Instead, GDPR uses the term “Data Subject”. Article 3 (2) defines the territorial scope as follows: “This Regulation applies to the processing of personal data of data subjects who are in the Union “. By this definition, the data subject could even only be on transit through the EU. Residency, or indeed citizenship, are not a criteria. In other words, Article 3 (2) says that the data processing has to take place in the territory of the EU for GDPR to be applicable. By this definition alone, if the data subject travels outside of the EU, then GDPR will not apply, even if the data subject is an EU resident (or even citizen).

However, under certain circumstances, you’re right when you state that it doesn’t matter if the data subject is located in the EU or not. Article 3 (1) expands the definition of the Data Subject even wider to include almost anyone in the world: “This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not .” In other words, if the controller or processor are (established) in the EU, GDPR will apply, no matter where the processing (or data subject) is located.

Back to the original point: If both processor + controller are located/established outside the EU, then geolocation of where the processing is going on may work as criteria for determining the need for consent in the case of GA. If not, it’s probably best to work with consent, no matter where the user is located. What I am not sure about though, is if it is possible to use GA with IP anonymization turned on, without the need for consent, even if GDPR applies. Maybe someone has some solid info on that one.

Further reading: https://cybercounsel.co.uk/data-subjects/
GDPR Article 3: Article 3 EU General Data Protection Regulation (EU-GDPR). Privacy/Privazy according to plan.

19

How to turn it on/off ?

//
And basically, what does it depend on whether a website is directed to eu? if I make it clear that the website is only for Taiwanese users, what then? do I also have to have a cookie policy ?

1 Like
21

Grave digging an old topic, but this is starting to get very relevant for EU instances:

Non-essential cookies must be deployed only after getting the users’ consent. A notification banner does not make a site GDPR compliant.

This is an issue if the site uses the official advertising plugin to serve AdSense or similar ads - their script is executed whether or not the user gives the consent. Same goes for GAnalytics.

Anyone got any ideas how to tackle this? I can live without GAnalytics, but without AdSense we will most likely need to close the shop.

4 Likes
25

I am also interested

2 Likes