EU GDPR (General Data Protection Regulation) and Analytics cookies

How will this affect webmasters?

[bill]

The new General Data Protection Regulation or GDPR [en.wikipedia.org] is meant to protect the privacy, but it looks like it could be a nightmare for webmasters whose sites have dealings with citizens of the EU. Reading through some of these regulatory requirements and opinions is making my head spin.

Are there established guidelines of what a website would need to do to comply with this? For example, if my site uses Analytics it's serving a cookie (from Google). Does this mean I have to clutter my sites with those annoying "this site uses cookies" banners? They seem like a fairly useless addition, and I've read that they may not actually be sufficient for compliance with the new regulations.

What's a non-EU site to do? What about EU sites? Analytics arguably are not tracking personally identifiable data, but I'm sure we could find a lawyer who could argue otherwise. I am not seeing definitive information about this from Google.

We only have until May 2018 before the EU hammer comes down...

[engine]

Yes, it's another overly complex regulation with simplistic ambitions, yet has far reaching ramifications.

In May 2018 the new E.U. regulations, GDPR (General Data Protection Regulation) comes into full force. It's actually in force now, but full compliance is May 2018. The GDPR is aimed at strengthening and unifying data protection for all individuals within the E.U., and the export of personal data outside of the E.U.

This is a key component for businesses outside of the E.U. that deal with individual within the E.U as it also affects organisations outside the E.U. that collect or process personal data of E.U. residents.

According to the European Commission "personal data is any information relating to an individual, whether it relates to his or her private, professional or public life. It can be anything from a name, a home address, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer’s IP address."
This means that analytics, such as the recoding of personally identifiable information, such as IP addresses, should be covered.

Here's a quick summary of the preparation to be undertaken (source UK's ICO PDF file [ico.org.uk...] ).
Preparation for GDPR.
1.Awareness: All decision makers and key people in the business should be aware that the law is changing to GDPR.
2.What information is Held: Document what personal data is held, where it came from, and who you share it with. This may require an information audit.
3.Privacy notices: These should be reviewed, and a plan put in place to for making any necessary changes before May 2018.
4.The rights of individuals: Check the procedures to ensure they cover all the rights individuals have, including how to delete personal data or provide data electronically and in a commonly used format.
5.Subject access requests: Procedures should be planned and updated how requests are handled, within the new time scales, and provide any additional information.
6.Lawful basis for processing personal data: Identify the lawful basis for the processing activity in the GDPR, document it and update the privacy policy to explain it.
7.Consent: Review how you seek, record and manage consent and whether you need to make any changes. Refreshing existing consents now if they don’t meet the GDPR standard.
8.Children: Systems must be put in place to verify individuals’ ages and to obtain parental or guardian consent for any data processing activity.
9.Data breaches: Ensure the correct procedures are in place to detect, report and investigate personal data breach.
10.Data protection by Design and Data Protection Impact Assessments: Familiarise with the ICO’s code of practice on Privacy Impact Assessments as well as the latest guidance for Article 29 Working Party, and work out how and when to implement them in your organisation.
11.Data Protection Officers: Someone should be designated to take responsibility for data protection compliance within an organisation’s structure and governance arrangements. Consider whether required to formally designate a Data Protection Officer.
12.International: If an organisation operates in more than one E.U. member state (Cross border processing of data), determine the lead data protection supervisory authority. Article 29 Working Part Guidelines help achieve this.

This will also affect data that clubs and societies hold, so if you run a club that is in the E.U., or has E.U. members it'll affect them.

Clearly, this is more red tape for many businesses, and especially challenging for a small business. Larger businesses would probably already have a data protection officer, or someone allocated to be responsible, so it's more about compliance for them. For the smaller business, or a club or society with few resources, it's a real frustration. To be positive, it is good practice to look after the data.

Some aspects are good, so if you're in the E.U., and it's your personal data being held, you will have better rights and protection. For businesses and clubs, etc., far greater care and attention is required, along with procedures to protect, and to declare should a breach occur.

I've spoken to many small businesses and it's just hitting home that this really is quite a challenge adding to already busy days.

HTH to start the conversation.

[bill]

Today I came across this in Wikipedia:

https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive

In June 2012, European data protection authorities adopted an opinion which clarifies that some cookie users might be exempt from the requirement to gain consent:

• Some cookies can be exempted from informed consent under certain conditions if they are not used for additional purposes. These cookies include cookies used to keep track of a user's input when filling online forms or as a shopping cart.
  
• First party analytics cookies are not likely to create a privacy risk if websites provide clear information about the cookies to users and privacy safeguards.

I guess that means that Analytics cookies fall under a category where no special adjustments would be required? If that's the case then it's business as usual, but I won't base a policy on a Wikipedia snippet. We have lawyers for that, but they are just as confused as I am at this stage.

[bhukkel]

According to the official Dutch data protection authority you can setup Google Analytics without asking for permission.

Note: translated with Google

If you use Google Analytics, you use the analytical cookies to process personal data of your website visitors. In principle, you must comply with both the Telecommunications Act (informing your visitors and asking for permission) and the Personal Data Protection Act (Wbp).

But do you ensure that the cookies have no or minor consequences for the privacy of your website visitors? Then you do not need to request permission for the cookies. To do so, you can use the Privacy-Friendly Manual to use Google Analytics of the Dutch Data Protection Authority (Dutch-language Authority for Personal Data) (AP). In 6 steps you will learn how to set up Google Analytics privacy-friendly.

Link to manual (in Dutch)
[autoriteitpersoonsgegevens.nl...]

[Mark_A]

It is a serious EU regulation, that despite Brexit is being enacted in full in the UK. It will be interesting to see how companies interpret it - there are some guides for SMEs on the UK ICO (Information Commissioner Office) website which are worth a read, especially if you can't stretch to reading the full legislation.

That it will apply to IP addresses and cookies (as privately identifiable information) is probably true, but to what extent still debatable.

[bill]

I think bhukkel just pointed to the key for Analytics users.

According to Google's IP Anonymization in Analytics [support.google.com] it looks like you can set Anonymize IP [developers.google.com] in Google Analytics

ga('set', 'anonymizeIp', true)

and that would make sure you are not collecting any identifiable IPs.

So I am assuming that this means that we wouldn't need to ask user's permissions simply to run Analytics on our sites, and thus no need for those ridiculous "This site uses cookies" notifications pop-ups and modal dialogs. I hope that the EU will be satisfied if we notify about the use of cookies in a privacy policy area without the need to disrupt a visitor's experience on the site.

Am I understanding this correctly?

[engine]

Am I understanding this correctly?

Yes, I believe you are.
If you're not collecting and storing the user data you don't need to be concerned.

BTW, the "cookie law" is being updated to relax the annoying and over burdensome aspect of a user having to click on a cookie acceptance on every single site (yawn), and from the website administrators from ensuring the message is delivered. In very simple terms, the shift is to place the permissions on the users' terminal as part of the general acceptance of cookies. Cookies, of course, form part of the GDPR regulations for user protection. Of course, the key aspect is that those really annoying cookie acceptance notices will soon be a thing of the past. See the section on Simpler Rules on Cookies [ec.europa.eu]

However, having switched the burden away from the website to the user, there will now be a requirement for the cookie acceptance reminder to be renewed every six months. Of course, this is a general user, browser-based acceptance on the users' computer.

[keyplyr]

Yet another reason to keep the analytics off-site and not burden your visitors with the question of privacy violation.

[Shaddows]

I appreciate this was posted in the Analytics forum, but GDPR is a bigger topic than analytics. However, I will try and constrain myself.

I would be quite interested in the in-house analytics view. @iamlost had a thread recently on data-mined personalisation.

Under GDPR, what if someone requests you delete them from your server logs (under Right to be Forgotten)?

How do you go about revealing data held on a person, if they access your site from a shared IP such as a company?

[Mark_A]

How do you go about revealing data held on a person, if they access your site from a shared IP such as a company?

Surely Shaddows, if you can't identify a person's file requests in your logs for that reason, then it ceases to be personal identifiable information and is no longer covered under GDPR.

[Shaddows]

if you can't identify a person's file requests in your... then it ceases to be personal identifiable information and is no longer covered under GDPR.

Possibly. Hopefully, even.

Alternatively, it could be grounds for not complying with the law.

"I request all the data you have on me, per my rights"
"Actually, there is no data on you"
"Well, I visited your site, so you do have data, you are just not auditing it properly. Where's my lawyer?"

Worth noting is that my legal obligations trump your GDPR rights. So, my obligation to keep sales records for tax reasons trumps your ability to request I delete my record of selling to you.

However, I might (unclear until tested in court) need to pseudonymise your sales record and lock away my own access to it until legally required to unlock it.

[engine]

As you've proven in this discussion, this GDPR is still a work in progress.

If you don't store data, you're fine.
If you do store data, you have to adequately protect it.

Note, under the UK's Data Protection Act companies have had to reveal this data to the users in the past, and have been able to charge a flat, low, fee to present the data. Now, there's no charge to be levied. This is also storing up problems, imho.

[henry0]

How one could be fairly aware of data collected by WP, not sure I know about all of them?

[blend27]

@Shaddows, ditto there!

I roll my own Analytics script that I wrote more than a decade ago. I would never knowingly share any data with any outside company, ever, never did. Click-path data is stored in DB and is encrypted on DB level. Yes IP is recorded in DB, Yes IP is also present in IIS Logs(not that I have any use for them), Nothing that I could or would do to prevent it from being recorded. Yes, personal info is also recorded to be able to ship products to the correct Address.

And there is nothing I or all those Big Box stores will change unless off-course user's Browser could say with a distinct certainty: Hi, My Name is Bob, from the get go...

P.S. I also take mine and my family own privacy very seriously.

[bill]

If you're not collecting and storing the user data you don't need to be concerned.

If someone were using Google Analytics, in the default configuration where this IP anonymization is not toggled, would that change anything in terms of what and how the site user's from EU need to be notified? I am now wondering whether this needs to be toggled at all.

[Shaddows]

@bill

It's not specifically the collection and storage that is the issue, it's the auditing and handling. If GA keeps an IP, then that data is subject to GDPR.

Data subject to GDPR needs to be presented to the Data Subject on request, must be deleted on request, and must be amendable on petition. GA does not (currently) offer these features, so it best not to collect the data in the first place.

[nonstop]

According to Google's IP Anonymization in Analytics [support.google.com] it looks like you can set Anonymize IP [developers.google.com] in Google Analytics

ga('set', 'anonymizeIp', true)

and that would make sure you are not collecting any identifiable IPs.

So I am assuming that this means that we wouldn't need to ask user's permissions simply to run Analytics on our sites, and thus no need for those ridiculous "This site uses cookies" notifications pop-ups and modal dialogs. I hope that the EU will be satisfied if we notify about the use of cookies in a privacy policy area without the need to disrupt a visitor's experience on the site.

according to the Uk's ICO site:

Do the rules still apply if the data is anonymous?
Yes.

[ico.org.uk...]

this is the current rules tho.

Also this is interesting...

under new rules...

"A site that sets cookies for different purposes will also need to obtain consent for each separate purpose"

"The data subject shall have the right to withdraw his or her consent at any time. …. It shall be as easy to withdraw as to give consent."

"under the GDPR, any cookie or other identifier, uniquely attributed to a device and therefore capable of identifying an individual, or treating them as unique even without identifying them, is personal data."

[Mark_A]

I haven't started to look at website analytics and GDPR yet, so far I am learning the actions I have to do to get my CRM compliant and where needed "consented". There will be increasing levels of work as the deadline looms.

[rubyrailsninja]

Is it a bad law ? or a good law ?

I believe this law would not change anything for people who were collecting email properly :)

[engine]

Is it a bad law ? or a good law ?

It's a good law for consumers, but it's a bigger challenge for smaller business. I certainly wouldn't call it a bad law.

[JonathanEdmonton]

Oh fun. I like this solution

ga('set', 'anonymizeIp', true)

[engine]

For those of you following the topic, there's a news discussion on GDPR over here. [webmasterworld.com...]

[surfgatinho]

I'll wait for the first prosecution before I start taking this seriously...

[ken_b]

Just checking in, trying to get less confused.

[Shaddows]

I'll wait for the first prosecution before I start taking this seriously...

Why? It's pretty easy to comply.

1) Have a Privacy page.
2) Declare what you collect, state grounds as "legitimate interests"
3) Give an Opt-Out on privacy page that deactivates analytics. Also, comply with browser-level privacy settings.

If you do not want to have to present data back to a user, pseudonymise everything and delete logs periodically. Then you can state you do not store any personal data.

If you want to keep personal data, you are probably going to need to do something involving databases- but then you probably do anyway (otherwise why keep it).

This only covers small businesses with centralised systems. But if you're a Corporate and thinking "I'll wait" - well, you're going to be in trouble.

[iamlost]

What Shaddows suggests above may well be sufficient for many most webdevs, however, if one uses any third party applications, frameworks, platforms, be aware that you are responsible for knowing their PII behaviour and addressing it appropriately.

For a longer more indepth, yet still just skimming the surface...

Government verbiage is sure fun to decipher, isn't it? When law and tech usage mate the result is not pretty not least because so many third parties are often involved.

However, if there is a silver lining in this tangled web it is that businesses be they individual or enterprise are actually going to have to determine what all they are collecting, what all they are doing with it, and why. Too often the answer is 'because it is there', or 'because we can'.

DISCLAIMER: the following is my current understanding of a complex issue; please use with care.
DISCLAIMER: I am a not a lawyer and the following is not to be construed as legal advice. Please consult a competent qualified attorney.

There are really four basic requirements:
Note: the requirements have two main premises that must be met:
* data privacy by default.
* data protection by design.
Note: and two corollary premises:
* the principle of data minimisation.
* an easily portable removable format.

1. explain clearly what data, particularly PII (Personally Identifiable Information), is being collected, how it is stored, how it is used, how long it is retained, with whom it is shared under what conditions; give reasons why; and request OPT-IN authorisation of the visitor aka their express consent.

2. store it securely. Plus incorporate security data access level and role controls, data breach mechanisms, and notification protocols. Data breaches MUST be reported within 72 hours to relevant authorities.
Note: you remain responsible for data stored on third parties, i.e. AWS, G-Cloud, Azure.

3. be audit able. Basically know and be able to provide:
* what data is discovered/held?
Note: include itemising that within each separate application/system, i.e. logfiles, Google Analytics.

* where is each datum/data set stored?
Note: it may be that some are held in more than one place.

* what is each datum/data set used for? eg. analytics, budgeting, forecasting, personalisation...
Note: some may be used in more than one process.

* who has access?
For most of us here at WebmasterWorld this is likely a very short list. However, it includes listing the SEO (company!?) with access to analytics, etc.

4. be removable. In whole or in part upon substantiated required request.

In summary:
* you MUST be able to prove how you store and manipulate PII.
* you MUST identify who has root access and who can login, create, change, copy, share, each application.
* you MUST be able to prove receiving express consent and responding appropriately to PII action requests.

TaylorWessing, and international law firm, has a nice, if basic, GDPR Audit Checklist [taylorwessing.com] that might be helpful.

Penultimate (for moment!) point that may rear it's nasty pointed head is the possible obligation to hire a DPO (Data Protection Officer). This - vaguely - is required if your organisation:
* is a public authority.
* does large-scale systematic monitoring of PII.
* processes large volumes of PII.
Yup: 'large', 'large-scale'. Very clear. Not.
According to (legal reasoning behind act) Recital 91:

The processing of personal data should not be considered to be on a large scale if the processing concerns personal data from patients or clients by an individual physician, other health care professional or lawyer.

Yup: much better. Not.
Context will be the killer here but in my non-legal advice opinion an individual webdev run site is off the DPO hook. Always obtain competent qualified legal advice!

My last point (for now!) regards Article 22, which provides EU visitors/users the right to question and appeal how their PII is presented by algorithms, such as search results, and in automated user profiling, such as personalisation. This article is contentious and may be revised. Just a 'beware' heads up should it apply.

Ah, the joy of it all!

[iamlost]

On a more personal GDPR note...

As Shaddows mentioned earlier in this thread I have been, am still concerned how the GDPR will affect the identification of new or repeat visitors, of personalisation and contextual delivery of content. For the last eight months or so I've been suffering (the only applicable sfw word I can think of) through R&D into how best to keep collecting data while not transgressing.

Given that most proposed solutions I've been reading about use anonymisation or the usage of anonymity sets as a basis of compliance I took a second and a third look at a similar approach. However concluded they are more accurately an Anonymity Probability Distribution and as such may or may not actually be anonymous, i.e. indirect re-identification, side channel attack, prior knowledge. Further, the very creation of many/most Anonymity Sets deliberately lose information to aid the data anonymisation process, i.e. loosing the last octet in an IP address as 209.59.188.36 becomes 209.59.188.xxx.

As I have been using the BLAKE2 cryptographic hash function as a check that uploaded website files have not been compromised it seemed that immediate hashing of all PII (Personally Identifiable Information) and indeed all of a visitor's 'fingerprint' data within a hash tree structure just might allow it's continued collection while simultaneously incorporating pseudonymisation.
Note: the GDPR differentiates anonymisation and pseudonymisation and requirements differ accordingly.
---anonymisation means, basically, that identifiable data is destroyed and can not be directly recovered.
---pseudonymisation means, basically, to substitute identifiable data with a directly reversible, consistent other value.

The only 'fly in the ointment' is that I also have a methodology for calculating when a return visitor arrives via a different IP, device, etc. that does not easily play nice with a hash as prior identifying fingerprint input. So far I've been testing various ideas of how best to compare individual hash tree leaves to accomplish the same goal. Live, on the fly, without noticeably slowing or interrupting visitors' experience. Where fun and headache meet!

I have two quite different PII data collection behaviours:
1. the real thing aka name, address(es), phone/email, credit card, etc, that is collected via affiliate presell to pre-fill forms on a merchant's and/or payment gateway's site. I do this because there is an associated significant conversion rate increase. I could:
* stop doing this and simply refer the visitor to the often poorly designed customer shedding merchant/gateway forms. A serious privacy Damocles' sword issue vanishes. Conversions drop by low double digits.

* continue as I have been doing, easing the visitor experience, while simply passing through collected data that is wiped on return receipt of checksum or n-minutes. The main consequences would be, as now, securing the PII data while in transit and, a new requirement, appropriate advisory to the visitor prior to their sharing such data. And, as a marketing, not regulatory, necessity notify them when the data has been successfully transferred and subsequently wiped.

I'm currently running both to iron out kinks and nail down consequences. What is behind door number three?

2. I have come to rely on a rather extensive visitor/device fingerprinting methodology to (1) recognise return visitors and (2) provide contextual content delivery. Nothing as overt as name or address or email (except for double opted in newsletter) and certainly not credit card or similar information. However, IP is potentially an identifier (and is so considered by the GDPR) and so are other collected data.

I use the information collected as (1) offline analytics data mining and various R&D methodology enhancements and (2) live on public facing servers as mentioned earlier. Losing some to all of it would pull out the very foundation of my systema. So the choice discussed earlier.

On the public facing servers hashes should provide sufficient PII data protection; the R&D servers are not connected to the internet, and I'm the sole mucker about. Which leaves again, appropriate disclosure and audit methodologies. Good gracious but the law-type-people have been having a fine old time. However, the end result should be seamless and compliant.

Most webdevs don't have the need nor the interest in all the stuff I enjoy so here's hoping one or more of the in development software is a golden ticket to ride, it most certainly will be less expensive than my MightyMorphenFrankenMonster!

[TravisDGarrett]

As I said, in another topic, I also have a hard time making my mind about IP address. When someone posts a message at my site, I record the IP address, but "I" do not need his information at all. So according to the EU documentation, if I don't need it, I shouldn't record it. I am fine with the idea. I paying attention to what people are posting at my site, but what if one day, a legal investigation is conducted against a poster. What if the justice asks me for the IP address? If I don't store it, will I get problems? And if I store it , the EU might be on my back saying I am storing PI which is not mandatory.

[MayankParmar]

Well I've a contact form, and it shows the IP, location, email address of the submitter. This is also a data collection, isn't it? I've a long privacy page... though I hate the idea of "This website uses cookies notification". I guess it would be fine if I this notification to visitors in EU.

[TravisDGarrett]

This is also a data collection, isn't it?

It depends if you save / store these information. If you save/store the email address, ip , etc... that is personal information , and if the person concerned is European, then it falls under the GDPR rules.

I've a long privacy page...

From what I understand the European Union says you need a simple , easy to understand privacy policy, to fight against the Internet giants which have endless text stuffed with things the mere mortal can't understand.

It makes me think, the GDPR concerns European citizens, so in theory, it doesn't matter the geo localization of the IP address. An European Citizen accessing / using a site, from the USA (for example), is still an European citizen...

ps: if the owner WebmasterWorld reads this, I think it would be interesting to know what he is doing to conform to the GDPR. This could help "us".