Steps we're taking as a site for GDPR compliance

This is the reason for a great deal of websites showing that little bar at the top/bottom of their page informing you that they use cookies and that you should leave if you do not agree with that (or something along those lines).

Those site are not compliant to the law because they have to let you access to the website even if you refuse their cookies, it is up to them to take all the step required for not storing cookies in your browser.

No, those sites are entirely compliant if they let you use the site without clicking on the banner. That particular (infuriating, useless) law is only focused on storing a cookie on your computer. Provided you don't click the banner, they won't (or at least shouldn't) store a cookie. You can continue to use the site and ignore the banner if you want.

Not all sites take that approach though, of course. If not storing a cookie breaks their site, they might not use a banner, but instead force you to accept the cookie before continuing. That's quite rare though I think.

So, how does GDPR apply to distributed data systems?

I don't think your git example is relevant. The names and emails are willingly attached to commits for copyright purposes (among other things), and git itself is software, not a web business. Services like gitlab will have to comply by making it explicit what data they collect and how they use it. And local git clones are not their responsibility any more than a saved screenshot from facebook is facebook's problem. I don't think the laws even apply to software in general, just the web.

Let's dig into this a little deeper. You must allow the user deny cookies in that prompt, and must needs to remember that choice. Seeing a contradiction, anyone?

Is there really a rule that says that choice needs to be remembered beyond the session? I don't think so.

The (cookie) technology is not the problem, third-party tracking is. But since the law-makers are clueless as ever, they are now wielding the proverbial hammer on the little guy. The big ones will find a different way, any way.

It does limit what the "little guy" can do with visitors' private data, but why is that a problem?


EDIT: I'm slow.


Last edited by tuubi on 21 Apr 2018 at 7:37 am UTC

Thanks, Liam, I really appreciate your attention to this. It is a chore, but something that is overdue for everyone in the industry. It is too bad the burden is a bit heavier for smaller sites.

Basically, the regulation says don't do creepy shit with people's personal data and if your "innovation" depends on doing just that, I'm perfectly happy for it to get out of the EU.

Well said.

Let's dig into this a little deeper. You must allow the user deny cookies in that prompt, and must needs to remember that choice. Seeing a contradiction, anyone?

Is there really a rule that says that choice needs to be remembered beyond the session? I don't think so.

The (cookie) technology is not the problem, third-party tracking is. But since the law-makers are clueless as ever, they are now wielding the proverbial hammer on the little guy. The big ones will find a different way, any way.

It does limit what the "little guy" can do with visitors' private data, but why is that a problem?

Well, I haven't read the legalese of this, but the public advisory materials I've seen indicate that it needs to be remembered. What is a session, anyway? HTTP is a state-less protocol. You get a session by saving a session identifier in a... session cookie.

My point is, cookies are not private data and their regulation should not have been included in GDPR.

Neither is IP address, imho.

GDPR is not only about limiting data usage either. You have to provide means to a) delete everything; b) export everything in a reusable format. This entails additional development costs that only the likes of GAFA should incur, imho.

What is a session, anyway? HTTP is a state-less protocol. You get a session by saving a session identifier in a... session cookie.

You're getting stuck on the terminology. The session doesn't need to include any identifiable private data. Just a randomly generated session id and a variable that tells the service not to store cookies on the user's system.

Personally, while testing our site using uBlock Origin in Chrome, I don't see a single notification about anything blocked, so that's good

I see that you're still pulling in stuff from Google, though. Namely a font CSS thing (which you could mirror yourself) and the reCAPTCHA script (probably not self-hostable).

There's also custom avatar URLs still live (Patola's, for example), and Ghostery also "complains" about Gravatar (it counts it as a tracker).


Last edited by DrMcCoy on 21 Apr 2018 at 9:17 am UTC

What is a session, anyway? HTTP is a state-less protocol. You get a session by saving a session identifier in a... session cookie.

You're getting stuck on the terminology. The session doesn't need to include any identifiable private data. Just a randomly generated session id and a variable that tells the service not to store cookies on the user's system.

Cookie is a cookie is a cookie, otherwise why would every random site bother you about it on your first visit ever?

Did you guys actually read the GDPR? It's actually clearly written and understandable: https://gdpr-info.eu/
Some people seem to write stuff that they read from some random clickbait article. (I'm not aiming at anyone in particular, please don't take offense).

The bottom line is usually: protect you user's data as if it was your most invaluable business assets, don't collect anything you don't need, and don't store it for longer than it is needed for processing. There are multiple interesting discussions of it on [Hacker News](https://news.ycombinator.com/item?id=16472774).
An interesting point is that you can't refuse a service to a user because they didn't consent something actually unneeded for the service.

Database backups come to mind with the right to remove all data from all time.

I actually disagree with this. Backups are as important as live databases. If you have a breach in your backup system, you don't want to leak information you didn't even need anymore in the first place.

On the other hand, I am not sure stuff like public postings actually need to be deleted, even if the user decides to delete his account. The choice is probably up to him, though.

Far worse than backups (I just thought about this) is the Right to Erasure in something like Git.

Git being a distributed system used by many FOSS projects and Companies to version source code, simply cannot easily adhere to the right to erasure, if at all.

That doesn't seem necessary as per https://gdpr-info.eu/art-17-gdpr/ unless I am misunderstanding something there.

I find the GDPR really well written, forward-thinking, and it is obvious that a lot of thought by technical people has been put into it.

@liam: about Twitter, isn't any way to include a mastodon feed widget instead? (Plus, this sounds like something that could be "easily" written: fetch the atom feed, then parse the content from the resulting links; display).
a quick search gave me https://github.com/AzetJP/mastodon-timeline-widget/blob/master/README_en.md Thank you for taking the time to perform those changes :)


Last edited by MayeulC on 24 Apr 2018 at 1:16 pm UTC

What is a session, anyway? HTTP is a state-less protocol. You get a session by saving a session identifier in a... session cookie.

You're getting stuck on the terminology. The session doesn't need to include any identifiable private data. Just a randomly generated session id and a variable that tells the service not to store cookies on the user's system.

Cookie is a cookie is a cookie, otherwise why would every random site bother you about it on your first visit ever?

No, some cookies are delicious with coffee. And I have no idea what you're asking here. Surely those sites bother you because they're required to if they're going to store and access data on your system.

I don't think GDPR applies to services like Github. If it did, it would also apply to things like scientific journals, which operate on the same basic underlying principles (i.e. the content is deliberately publicized along with the (pseudo-)identity of the authors).

How about Wikis just to broaden the discussion a bit?

I don't think GDPR applies to services like Github. If it did, it would also apply to things like scientific journals, which operate on the same basic underlying principles (i.e. the content is deliberately publicized along with the (pseudo-)identity of the authors).

How about Wikis just to broaden the discussion a bit?

I guess GDPR applies to any personal information the wiki stores about users. Wiki page content itself is regulated by other laws I'd think, like any public content, articles and such.

ublock's ability to pre-configure itself for each site is nice, but if you disagree with it (for instance, a site loading Facebook when there's almost always no reason for it to) it doesn't let you start blocking it, or at least not easily, while 3P does, but 3P also starts off unconfigured so it's more of a hassle.

You just need to enable advanced features in uBlock Origin's configuration to get a nice, clickable list that allows you to block or allow stuff. If that's what you mean. You could also enable one of the stricter third party social block lists.

What is a session, anyway? HTTP is a state-less protocol. You get a session by saving a session identifier in a... session cookie.

You're getting stuck on the terminology. The session doesn't need to include any identifiable private data. Just a randomly generated session id and a variable that tells the service not to store cookies on the user's system.

Cookie is a cookie is a cookie, otherwise why would every random site bother you about it on your first visit ever?

There are different types of cookies and the EU rules e.g exempt the following types of cookies from the "consent requirement":

user‑input cookies (session-id) such as first‑party cookies to keep track of the user's input when filling online forms, shopping carts, etc., for the duration of a session or persistent cookies limited to a few hours in some cases
authentication cookies, to identify the user once he has logged in, for the duration of a session
user‑centric security cookies, used to detect authentication abuses, for a limited persistent duration
multimedia content player cookies, used to store technical data to play back video or audio content, for the duration of a session
load‑balancing cookies, for the duration of session
user‑interface customisation cookies such as language or font preferences, for the duration of a session (or slightly longer)
third‑party social plug‑in content‑sharing cookies, for logged‑in members of a social network.

More info can be found here (as well as EU supplied Javascript to add tacookie acceptance banner): [http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm](http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm)

Incase your interested. Privacy Badger is still reporting up to 8 potential trackers per page and is blocking cookies from them. These places might not be tracking with cookies but PB is ensuring to block them anyway. I think PB just blocks cookies from any external source other than the site your looking at.

I visited various pages on this site, Here is a list of "potential" trackers according to PB.

www.gravatar.com
www.gstatic.com
fonts.googleapis.com
www.google.com
fonts.gstatic.com
www.youtube-nocookie.com
i.ytimg.com
s.ytimg.com
i0.wp.com
yt3.ggpht.com

I don't think GDPR applies to services like Github. If it did, it would also apply to things like scientific journals, which operate on the same basic underlying principles (i.e. the content is deliberately publicized along with the (pseudo-)identity of the authors).

How about Wikis just to broaden the discussion a bit?

I guess GDPR applies to any personal information the wiki stores about users. Wiki page content itself is regulated by other laws I'd think, like any public content, articles and such.

From MayeulC's link ([https://gdpr-info.eu/art-17-gdpr/](https://gdpr-info.eu/art-17-gdpr/)), paragraph (3):

[Right to erasure] shall not apply to the extent that processing is necessary:

a) for exercising the right of freedom of expression and information;

d) for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing;

To my interpretation those exemptions would cover Wikis.

Simply put, I welcome the GDPR and what it's doing to the Internet on behalf of the common person's right to freedom of expression and freedom of privacy.

For those interested, you can track more ramblings on gitlab: https://gitlab.com/liamdawe/gamingonlinux/issues/307

Made lots of progress on this, for those who care. Here's the just of it:

• All 9K+ articles have all their YouTube videos switched over to the YouTube no cookie URL. I'm waiting to see how Google handle the GDPR deadline, before I force site visitors to click something before they can see them. I'm hoping google add some form of notice, that once you click a video you get cookies - it's their damn job to do so.


• I've also improved our user deletion tool, so it will remove article likes a user made if a user removes their account. It wouldn't show anyway since their account would be gone, but it cleans it all up and adjusts the total likes for an article properly.


• We also now remove unactivated users 10 days after they register if not activated.


• Remove the IP of someone who hasn't logged in for 3 months, after that long we really have no need for it. They can't login if banned anyway. Also set their profile to private, they may forget about it.


• We now only pull in google recaptcha JS in the files that need it (register, contact us, submit article) nowhere else.


• Users PC Info they submit for our monthly survey is auto-wiped after 2 years, both preventing stale data and personal data anyone forgets about.


• I also fixed up the full-article RSS feed for YouTube videos, iframes don't seem to work, so we're pulling in the high quality thumbnail with a link to the video - better than seeing a blank space.

Working on having the user deletion tool fuzzy usernames in quotes if a user deletes their account so:

test

Becomes

test

For YouTube, additionally I'm waiting to see what Google do by the GDPR deadline. I really don't want to force 100% of our users through some JS script that forces you to accept something on our end, before you can even click the video. It's Google's job to ensure you're properly informed, I hope they add a proper notice. It's good they offer the no cookie version, but it's not enough. Same for reCAPTCHA.

I'm not sitting on my hands though, I have code waiting and W.I.P to not show a video unless people accept cookies in a banner on our site just in case.


Last edited by Liam Dawe on 23 Apr 2018 at 5:49 am UTC

After watching a few hours of videos on youtube and having a 2 hour meeting at work where some of it was explained I still don't have a clue as to how to produce the needed documentation for what we have. I work in a municipality though so we can't just focus on the GDPR, and even though I personally don't handle more than a fraction of the data we have (system admin kinda role, it's complicated:P), I still love the whole thing.
Not because it is a lot of work but because a lot of my colleagues are acting like a bunch of ignorant FB users who now have to think about what personal information actually is. It's the need to know/nice to know and consent part of it that makes ppl actually have to care about other peoples data, not only as an employee but also as a private citizen.

I understand why this is a lot of work for small business and sites and I don't envy them :P

After watching a few hours of videos on youtube and having a 2 hour meeting at work where some of it was explained I still don't have a clue as to how to produce the needed documentation for what we have.

No offence, but the final approval of the GDPR was in April 2016, so you had two years of time to inform yourself about this. The text was final in April 2016 and, like everything EU, public. Especially if you work in a muncipality, as part of the government, the information should have been passed down long ago.

And it's not just you. All this rushing, from multiple (most?) orgs in the month before it goes live, after two years of forewarning, feels...not good.