That's correct. Using cookies for the user session is fine and does not require consent as long as you really are just using them for the user session. The moment you use them for analytics, you have to request consent for analytics, even if they are primarily for maintaining the user session.

> The moment you use them for analytics

Not even then - there are plenty of analytics you can do without a cookie banner, as long as they don't identify the user.

Conversely, anything you do other than your obvious business requirements (e.g. if you buy something physical I need some address or identity to verify at pickup) requires consent whether or not it's analytics.

(Not a lawyer, not legal advice, jesus just don't track people...)

There needs to be the same kind if active consent whether it’s “required” or not.

The difference is if you can deny access for those opting out or not.

But wouldn't that consent be in the EULA? So long as they only track logged-in people, they'd have agreed to that.

No, it wouldn't be in the EULA. There are two parts of GDPR that would specifically go against putting consent to tracking in the EULA:

1. GDPR requires the consent check to be somewhere obvious and in plain language. That was specifically to deal with EULA's given to you in tiny legally compliant text boxes.

2. GDPR requires that you cannot make consent for non-essential usages of data mandatory as a condition for providing your services. Tracking only logged-in people for analytics falls into the category of non-essential purposes. That requires explicit consent, even if consent is not required to use the exact same data for authentication checks.

But wouldn't that be asked for at the same time as signing the EULA, i.e. at account creation? If you're avoiding banners, I can't think where else you'd put it.

If a cookie is not necessary (or you are using a necessary cookie for secondary purposes), then you need GDPR-valid consent. This means:

1. Consent must be separate from other terms being agreed to. So consent in the EULA would not be valid.

2. Consent must be an affirmative, unambiguous action. Pre-ticked boxes or bundled consent are not valid.

3. Consent can be revoked at any time. Revoking consent must be as easy as giving it.

So yes, you can ask for it from a user when you're having them agree to the EULA. However you can't have it as part of the EULA, it has to be an optional add-on. And you still need to let people turn it off afterwards.

No, GDPR does not say you have to consent to be tracked anywhere.

So, this is a case of “tech company thinks they found a clever GDPR hack, but didn’t and is still breaking the law”?

If we're talking about Github, no, I don't think it's a clever hack. I think they've actually ripped out the offending usages.

The reason I find that believable is that their core business is selling a git server with bells and whistles. From Microsoft's perspective, Github doesn't need to be doing any marketing because they kind of are the marketing.

Whether they complied in other ways is irrelevant to whether this case is non-compliant, and the point was about reuse of cookies for analytics, not marketing.

I don’t understand your point. You’re asking whether they’re trying to work a loophole or a clever hack, and I said that I don’t think they are and that I think it’s credible because they don’t have profit motives that would drive them to take that legal risk.

You don't think they do analytics on users based on these cookies session? Because doing that without the consent pop-up is (I claim above) illegal, and so the clever workaround fails.

I would be really, really surprised if Github were the only Bay Area unicorn that lacked a product manager nagging them for more analytics. The fact that they don't need to sell the analytics is irrelevant.

I can't speak for Github, but I can speak for my team in [tech giant]: if I wanted to do analytics on end users I'd have to go through a review to confirm that I would not be violating privacy laws. I literally couldn't query them if I wanted to without jumping through technical hoops with audit processes and paper trails.

I do believe Github is legitimately trying not to use that data for analytics. But whether some PM in there is querying that data for analytics purposes: at that point we're just speculating based on how cynical you or I want to be. I don't think that's a meaningful point.

Also: I'm not saying I don't think they do analytics. I'm saying I don't think they are using users' personal data for analytics. That's an important difference with respect to GDPR.

> then you still can’t use those cookies for other purposes, like analytics, right?

Yes. It’s not the cookies, it’s what you make the use of them.

The wording even predates GDPR. You could even dispense of the banner if you had DNT set to 1 or 0, since that would count as consent/not consent resp.

Pure analytics is exempt of consent from the gdpr point of view from my understanding and from explanations of our local french regulator.

Define "pure" ?

First Party maybe

Yes.

I just checked my cookies on the Github website and had several tracking cookies (including Google Analytics).

Then I realized I should probably clear all the cookies for Github, and start over with a fresh session. So I deleted all cookies that Github had given me (which was 12) and refreshed the page. As expected, I was now logged out and Github immediately issued you me 4 new cookies.

  • _gh_sess (a fresh session cookie)

  • _octo (not sure what this is, might have something to do with cache-busting? Looks like it contains something resembling a version id/string)

  • logged_in (my logged in status, now false)

  • tz (my timezone)

All of these are valid cookies (assuming that _octo is for cache busting) that would not require a cookie banner.

So then I logged in. I now have 10 cookies. None of them appear to be tracking cookies.

  • __Host-user_session_same_site (14 day session token)

  • device_id (this contains a random string to differentiate this device. Initially I was concerned with this, thinking it might be a fingerprint. But it is far too short for that, and it appears to be a flash cookie. It expires as soon as it is issued, so it only lasts one request. This is likely used to improve your experience in the case that you are logged in across multiple devices to differentiate which device is making a request within the current session)

  • gh_sess (same as before, session)

  • _octo (same as before, presumably cache-busting)

  • dotcom_user (contains a string with my github username)

  • has_recent_activity (boolean value, likely used to display "unseen notifications" on the front-end)

  • logged_in (same as before, except now true)

  • tz (same as before, timezone for frontend time displays)

  • tz (now have 2 timezone cookies. Both are currently the same timezone, although I assume the first one is a timezone gathered from my system clock and the new one is a timezone gathered from my github settings which they now have since I logged in. This is probably a bug where they expect to overwrite the first one, but since one is set to the github.com domain and the other is set to all github subdomains then it didn't overwrite)

  • user_session (yet another session token with 14 day expiration. However the session token in this cookie and the __Host-user_session_same_site cookie are the same. Not sure reason for the duplication)

So those are all the cookies that Github now gives you. 2 of these seem to have duplicates. Meaning the same could be done with 8 cookies instead of 10. But regardless, all cookies seem to check out. None of these are tracking your usage and are there to improve your logged in experience. Tracking things like your username and recent activity boolean are most likely being used to save making the same database queries for every request. The others are just tracking sessions, which is something that users definitely do want. The 14 day expiration is a good middle ground between convenience and security.

At the beginning I mentioned that I had two tracking cookies before I cleared my cookies. These are gone after the refresh. So it looks like github has in fact stopped issuing tracking cookies altogether. They also seem to have removed Google Analytics entirely as I don't see the script on their website at all.

So all-in-all this definitely checks out. I don't see any GDPR violations here or reason to display a cookie banner anymore.

I assume they still have analytics, but the analytics are all happening server-side which provides them basics like pageviews and visitors. And since you have to be logged in to do almost anything in github they don't need cookies to track what you do while logged in, thats all going through their servers and databases anyway.

I know plenty of people here have problems with Github, but I think it is exciting to see a large company like Github (Microsoft) take this step.

> I assume they still have analytics, but the analytics are all happening server-side which provides them basics like pageviews and visitors. And since you have to be logged in to do almost anything in github they don't need cookies to track what you do while logged in, thats all going through their servers and databases anyway.

Considering Microsoft's size, wouldn't this still be a concern, and might even still violate GDPR if they were to use identifiers like IP or Microsoft accounts between their various services ?

For an even more extreme version: see Google or Amazon (AWS).

Are we claiming that if GitHub has a dashboard like “number of concurrent sessions” and “average length of session” and “unique users who touched this feature” it would be a GDPR violation?

Because I can’t imagine that they don’t.

It looks like you can still be tracked as long as you are logged into your Github account? (Or even if you are not logged in as long as only Github/Microsoft is tracking you?)

Another question is how exactly can Github be trusted to not send this tracking to Microsoft? It's not like this is something that we can check... I don't think that the EU is going to send inspectors to Microsoft?

I don’t think this is a problem for GDPR. As long as there’s no personal data involved you can count active sessions, aggregate data etc

How would you count unique users without processing any records corresponding to particular users?

seasion ids are unique? are they personal data if you cannot link them to an individual? count those. let’s say you are paranoid and someone, somewhere can link those random ids to people. So hash those random ids with a key that this someone has no access to. Now you have anonymized ids you can count uniquely and that cannot be linked to individuals.

You can anonymize data if you really want to and use it for understanding trends, usage etc in a privacy respectful way. Few companies bother these days though. And yes if you want a 100% watertight way, it’s hard.