EU Cookie Law changes in 2018

[3L1AS]

In March 2018 a new EU cookie law is rolled out that a website visitor/user need to opt-in for the use of cookies and not just getting informed that cookies are used on a website. In case a user is not allowing (for whatever reasons) cookies than all scripts which use cookies on the site should be disabled.

I was wondering if the script could be adjusted to this new regulations. A website which has this functionality already is https://cookieconsent.insites.com/download/ (Point 5. ) but I really love this script here and would us it in the future as well.

How could this be achieved and how difficult would this be to be implemented?

[zytzagoo]

Interesting. Can you provide some more details / links on that new cookie law "spec"?

Providing hooks/callbacks and letting the implementer handle it (along with specifying the type of consent etc., as is done in the example you linked above) is certainly an option, and it shouldn't be too difficult to implement.

How/when/whether really depends on the details of the new regulations, which are unknown to me at the moment, and I'm not sure I'll have the time to look into it in detail this week (or even next)...

It'd be great if others would chime in with thoughts/details in the meantime.

[3L1AS]

There are not many websites about this topic in English but lot's of it in German. If you search for https://www.google.com/search?q=dsgvo it might show you some results in your language or in English.

At least Wikipedia has already an article about it: https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

I am not a developer (programmer) but could do testing or help on other things needed. (in German too ;)

A German lawyer site is writing about it as well with good informations (maybe use google translate)
https://www.swd-rechtsanwaelte.de/blog/e-privacy-verordnung-cookies-nur-mit-einwilligung/
https://www.swd-rechtsanwaelte.de/blog/eprivacy-verordnung/

[zytzagoo]

I had a feeling it might be about GDPR. As far as I understood it (back when I first heard about it), that was about storing/processing PII and SPI (https://en.wikipedia.org/wiki/Personally_identifiable_information) -- IANAL, but I figured a simple cookie that only stores a boolean representing acknowledgment of how cookies were used did not fall under that.

I'll look into it some more when I get a chance, but ideally we'll hopefully get someone with more legal experience in these matters to clarify things.

[zytzagoo]

This and the linked resources within should probably be required reading: https://www.cookielaw.org/blog/2016/5/13/the-gdpr,-cookie-consent-and-customer-centric-privacy/

[webaddicto]

Personally I would still wait before implementing that, looks like it is not yet definitive.

More information can be found on these recent articles:

The winners and losers of the EU’s new ePrivacy law
EU law bods closer to baking new 'cookie law' after battle
Digital D Day and the crumbling Cookie?
GDPR Makes Publishers Vulnerable If They Fail To Prepare
A Marketer’s Guide To GDPR

I really don't get why now they require all this crap, and especially:

even if a user rejects cookies, they must be allowed access to the site.

From a business point of view, we could use the popup banner to promote a product instead of that "Do you want to allow cookie?" banner. Moreover, what about bloggers, small companies and free web services that live with advertising? A possible related example: when I watch TV I get advertisement, that is fine with me because I get free TV in exchange of viewing advertising. What would happen if I have the choice to disallow advertising on TV? Would it still be free?

[senko]

A lawyer friend of mine also pointed to The Future of EU Cookie Compliance: GDPR and the ePrivacy Directive Revision whitepaper as a good (if somewhat dated) resource for this.

(For the record, it gave me headache.)

[zytzagoo]

Had a read through a few of the linked articles above... Wow. Messy, headache inducing stuff, and still so much vagueness.

But it looks like a clear win for privacy, so, thumbs up from me!

As to the question of using the existing cookie-banner script to simply satisfy the new requirements -- that's probably not gonna fly. Especially if used with some of the various accept-on-* options.

Providing callbacks along the lines of https://cookieconsent.insites.com/documentation/disabling-cookies/ might be an option. However, it will not be enough (as the consent can be withdrawn at any time, we should also provide an API to query/set/prompt for consent at any time, and re-trigger the corresponding callbacks etc.). Also, some of the existing options/functionalities might have to be removed (various accept-on-* options that we have currently)?

I still have no idea whether consent is needed in order to store the actual cookie which tracks whether consent was given etc.? And providing granular levels of consent based on different categories of cookies used is way out of scope here.

Doing a bunch of these changes in a fully backwards-compatible way feels like a lot of work currently (if not downright impossible, as some breakage will have to happen, since some functionality is being removed?)...

So, a major version number bump would be required, along with a clear migration path provided (meaning documentation, code examples, tests...).

At that point, I'm wondering if it might be easier to just create a new project/script?
And, aren't we then just replicating what https://github.com/insites/cookieconsent is already doing, but under a different name? Why would we want to do that?

Don't have time currently to dig any deeper... But, who knows, maybe browser vendors come up with something to ease all the pain away? (they're in a much better position to handle this, IMO)

[Jimmi08]

Hi,
if you are interested how it should looks on website, you can look here:
https://www.optanon.com/cookie-consent-manager/
Just click on Cookie settings and you will see it in action.
Nightmare.

[binoculars88]

I'm not educated at all on this subject, but I found some website telling something different. For example, this website claims the cookie stuff will be a responsibility of the browser, not the website, which would make live easier for web devs.

Article is more than a year old though, so I'm not sure which source to follow... Any thoughts?

[Jimmi08]

@binoculars88 that article is old (or better will be old soon) It's how it is now and each country could have a bit different rules - f.e. in my country browser cookie setting is enough, but other European countries have this different way. But it will change in May 2018 with GDPR. I saw solutions by optanon.com and https://www.cookiebot.com too.

I use this now: https://cookieconsent.insites.com/download/
At point 5 Compliance type - try to change it and you will see how cookie banner is changing. First option is what is now. Option 2 or 3 - nobody knows, I will change it according they say what way is needed at least. The worst thing is the option 2 and 3 needs other customization in your code.

[Ezyweb-uk]

I found this article concisely describes GDPR compliance requirements for cookie handling for EU websites:
https://www.itgovernance.eu/blog/en/how-the-gdpr-affects-cookie-policies/

[schlos]

EU Cookie Requirements (incl. GDPR):

• Disable all cookies by default (only allowed are mandatory cookies),
• Show info transparently (for example: display a banner on the first page view and a small one on other pages),
• Display a panel to allow or deny each cookies one by one,
• Activate cookies on the second page view if not denied,
• Store the consent in a cookie for up to 365 days (after which user needs to give consent again).

[dmgroom]

By far the best implementation of a new GDPR compliant cookie consent seems to be www.cookiebot.com . I'd love to see an open source version which was similiar, but without the automatic scanning.

[amrutadotorg]

Nice, but beyond asking ppl to approve them, we should be able to remove the cookies if not wanted, right?

[3L1AS]

But even cookiebot.com is doing it the wrong way. As far as I know and have read the user should opt-in which info/cookie(s) he/she would like to approve or accept. With cookiebot.com all the boxes are already marked but maybe one can change that in the settings!? Nevertheless a free solution or upgrade to the cookie-banner script would be awesome!

[dmgroom]

@amrutadotorg . yes there does need to be a way or removing consent, with cookiebot this is done by including a javascript file which provided much of the content seen on this page https://www.cookiebot.com/en/cookie-declaration/ which includes the ability to change / remove consent

[dmgroom]

@3L1AS yes, you can change which boxes are already checked by default. I was not suggesting cookie bot was perfect, just better than other implementations I have seen. one problem with it is that it requires you to change the standard javascript tags to <script type="text/plain" .... . this is ok as long as you have control over the javascript which sets the cookies, but if you are using js files hosted on a third party server you cant change these.

[Ezyweb-uk]

I called the ICO helpline (the authoritative body in the UK) earlier this week to clarify the situation on cookies. They say that this area is under consultation and will be part of the ePrivacy Regultions in 2019, and until that time the existing PECR applies. I was informed therefore that granular cookie control and saving consent with id and date is not required at this time. Also that blocking of cookies before consent is received is not absolutely necessary under PECR, they refered me to their 'Guidance on the
rules on use of cookies and similar technologies' pdf https://ico.org.uk/media/for-organisations/documents/1545/cookies_guidance.pdf page 7 ‘Prior’ consent. It seems to be a grey area, here's an extract from their guidance:

"Wherever possible the setting of cookies should be delayed until users have had the opportunity to understand what cookies are being used and make their choice. Where this is not possible at present websites should be able to demonstrate that they are doing as much as possible to reduce the amount of time before the user receives information about cookies and is provided with options. A key point here is ensuring that the information you provide is not just clear and comprehensive but also readily available."

The ICO's website cookie notice appears to be provided by civicuk.com but currently it has no granular control, even though CIVIC offer a so called GDPR compliant version. Similarly the solution offered by Iubenda which they confirmed to me is GDPR compliant.

Although granular consent (and the documenting of consent) may not be a requirement of PECR, public perception may mean that websites that offer granular control might get more kudos from users/customers. I've looked at the Cookiebot, CIVIC, and OneTrust solutions which all offer cookie blocking with granular control; and the Iubenda solution that doesn't; I think the OneTrust cookie notice with control popup is neatest.

This is NOT advice, these are only my opinions. It would be interesting to know how the guidance from the UK's ICO compares to that from Germany's BfDI.

[flatcapco]

The new Civic version allows disabling of 3rd party cookies (not granular control) but this is probably for the best to keep it simple for users and developers? You don't have to list every exact cookie on this accept/decline page as it'll just be too confusing for users. The cookie or privacy policy could list those 3rd party cookies in more detail. However the person that wants to opt out of one 3rd party cookie - in my mind can be opt'd out from them all.

It's so frustrating how grey this all is at the moment - I'd imagine most sites still wont be compliant come May 25th.

[Ezyweb-uk]

The Civic GDPR cookie notice doesn't allow control over cookies individually but does appear to offer control by purpose or category/class. Would you not call that a form of granular control?

There's obviously different views about what's necessary, Iubenda state here that (quote): "cookie usage and it’s related consent acquisition are not governed by the GDPR, they are instead governed by the ePrivacy Directive.". I'm sure there will be much debate about, I'm still waiting to hear an answer on this from the ICO in the UK.

[zytzagoo]

Implementation wise, if the vistor, for example, disables "Social Sharing Cookies" in the screenshot above, does that mean the site doesn't load social sharing plugins at all? (after reloading the page that showed the cookie prompt, in case it's not a SPA/PWA etc.)

I mean, even going to https://www.civicuk.com/cookie-control/v8/download and opening the prompt shows analytics cookies being off by default, and yet piwik is loading on that first initial page load anyway? What gives?

A potential alternative might be to instruct each social sharing plugin to initiate itself in "cookieless" mode (if visitor turned off those cookies), but you're shit out of luck if you need that info server-side before even rendering anything? And, "cookieless" mode for social sharing plugins doesn't exist yet if I'm not mistaken? (and it's a long shot thinking that such a thing will exist at all?)

To complicate things further, if you classify your social-sharing-plugins-usage as required functionality, and those need to set their own 3rd party cookies (as they themselves classify those as required), hello to 3rd party cookies being set by default and no way for users to opt-out (except by turning them off via browser, which means the whole thing is redundant, might as well just instruct users to disable third party cookies if they don't want to participate in social sharing crap?)

Murky waters ahead for sure...

[zytzagoo]

Companies have been issuing privacy policy updates left and right in the last couple of days, I haven't had time yet to go through the details and see what they're changing actually, perhaps someone here has?

But I think/hope those changes should be indicative/representative of how they plan on handling cookies/ePrivacy directive hopefully...

Otherwise, they'll have to update the policies again real soon, no?

[flatcapco]

Well I've got about 50 tabs open with various privacy policies and I dont see barely any use of cookie consent and certainly not optin.. they are all assumed optin.

I think a blanket "any 3rd party cookie disabled" is the way to go and sensible.. if they are off then yes social sharing code doesnt load.. fine just make that clear to the users in the cookie policy. or do a "are you sure.. this will stop social sharing buttons working"

Social sharing isn't mandatory.. only cookies that handle ecommerce carts or search features ect are.

The privacy policies do usually cover what cookies are used but so far as to say their name and why they are used rather than showing a cookie code name or anything tech. Then as they are mainly 3rd party the documents point to google analytics docs on it ect...

So no responsibility of it really.. and still not what I think will be "compliant" unless ePrivacy cookie laws are really slow at getting their act together inline with GDPR.

[flatcapco]

Ok so the short answer on cookies from the ICO is .... do whats going to be most GDPR compliant now and in the future... IE they are not saying you need to make a user opt in but they are recommending it as a better practise.... Not ideal but I guess the grey area of that is.. you're ok to run the risk with auto opting in.. until they explicitly say otherwise..

Depends if you want to run over all your coding again in a couple of months I guess.

I got that from a live chat on the ICO.

[Ezyweb-uk]

I've noticed a trend to have a separate Cookie Policy page, that lists individual cookies with code name and purpose, that's in addition to the normal Privacy Policy page.

[flatcapco]

I actually think they are more confusing and not sure its a legal requirement. Present a user with a list of cookie codes it gets baffling. There will be a lot of personal preferences on all of this but I'm pretty sure I'll be going with 1 privacy policy that states it all.

[zytzagoo]

This smells of road-block-style popups/modals (similar to what google was doing recently when you landed on a search results page in an incognito/privacy-enhanced mode). And even they seem to have decided on a slightly different approach now: first they show you a block below results, and only then trigger the consent modal/popup.

Previously they showed the modal instantly (and if I remember correctly, you couldn't easily close it apart from nuking the entire DOM via devtools). I'm guessing they stopped doing that because it caused a noticeable drop-off in engagements + betterads.org dislikes popups anywhere.

When you have to know/decide on the server-side whether to include analytics tags, social sharing tags and whatnot, is there any other viable option really?

And to be fully GDPR-compliant (as far as I understand it currently), you're supposed to not even trigger those analytics/social tags/trackers until opt-in/consent is given? Which means a giant drop in analytics numbers is guaranteed, since all your first page views are no longer counted... It will eventually hopefully slowly get back to where it was, but it sure will be entertaining to explain the drops to non-tech audiences.

Or, you'd maybe have to have a centralized consent/opt-in service and UI somewhere and do a 302/307 redirect there, prompt for consent, and then redirect back to where the visitor initially wanted to go...

Which sounds equally terrible to me, and is yet another service to have to maintain and secure and just doesn't scale easily... And people just love being interrupted like that (being redirected to somewhere that isn't where they expected to land).

Consent revocation is another interesting thing that has to be handled somewhere too and it has (somewhat) similar implications/problems: consider surfing on the same site in two separate tabs, you give consent in the first one, open a second one, revoke consent there, and switch back to the first one and then follow a link to somewhere on the same site -- to be fully compliant, this leads to having to check for consent on every request server-side, which is not cacheable/scalable at all. Maybe having caches vary on consent-related properties of a request would solve that, but not without an explosion in cache storage requirements (if nothing else) and nightmares when it comes to cache invalidation(s).

This needs to be taken care of at the browser level. It really, really does.

Was DNT considered at any point, does anyone know? (quick google for "gdpr dnt" gives crap results)

It's a simple header which pretty clearly states the user's intent on not agreeing to being tracked, and the only thing missing is a control in browsers of setting DNT per domain/origin or similar (and globally, as is already possible) -- and the UI can be borrowed from password managers or other existing UI elements/parts that have domain/origin-level granulation/choices.

And then GDPR/ePrivacy could say that obeying DNT is a must (if it's present) in order to be GDPR/ePrivacy compliant. And if someone is not obeying it, it's easily noticeable/provable and will be reported wherever non-compliance is to be reported anyway.

I'm pretty sure people much smarter and better paid than me have had discussions/rants about all the technical implications already... maybe not in public, but still? This has to have been discussed/debated in much more detail somewhere, right? And actual reasons why DNT was not the solution exist? Who do we ask those questions? My tiny country's EU representatives are useless in that regard, but maybe some of you have someone to ask? If so, please do.

[Ezyweb-uk]

I found this article the other day about the DRAFT ePrivacy Regulation and cookies, and Section 4 paragraph 2 says:

"Thus although the draft Regulation will mean that website operators can rely on browser technical settings to express users’ consent to the storing and accessing of cookies, the Article 29 Working Party’s suggestion that the same consent could extend to subsequent processing of information derived from those cookies no longer appears tenable. Website operators will therefore need to take their own measures to ensure that their processing of cookie data complies with the law. And, where cookies constitute personal data, it should now be clear that the relevant law has never been the special cookie provisions of ePrivacy law but, from 25 May 2018, the GDPR. Using cookies will therefore resemble other examples, presented in the Working Party’s 2011 Opinion on Consent, of compound processing where different aspects may be covered by different legal provisions.27 Website operators must therefore identify and apply the relevant aspects of the GDPR when processing any personal data derived from cookies."

[webaddicto]

I believe that it is not a requirement to allow the user to block cookies singularly via the cookie banner, but instead from what I have understood we should block the scripts/iframes related to analytics, advertising, etc by default when the user first visits the website, then we show the cookie banner and if the user clicks on "Accept" button OR scrolls the page OR clicks somewhere on the page we can load the scripts/iframes code immediately.

This behavior is what iubenda.com is doing:

Here is the text of their cookie banner:

This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the cookie policy. If you want to know more or withdraw your consent to all or some of the cookies, please refer to the cookie policy. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies.

And one interesting thing to note is that they write in their cookie policy all information needed for the user to allow or block cookies via the web browser settings:

I am quoting the entire text taken from their cookie policy page below:

How to provide or withdraw consent to the installation of Cookies

In addition to what is specified in this document, the User can manage preferences for Cookies directly from within their own browser and prevent – for example – third parties from installing Cookies.
Through browser preferences, it is also possible to delete Cookies installed in the past, including the Cookies that may have saved the initial consent for the installation of Cookies by this website.
Users can, for example, find information about how to manage Cookies in the most commonly used browsers at the following addresses: Google Chrome, Mozilla Firefox, Apple Safari and Microsoft Internet Explorer.

With regard to Cookies installed by third parties, Users can manage their preferences and withdrawal of their consent by clicking the related opt-out link (if provided), by using the means provided in the third party's privacy policy, or by contacting the third party.

Notwithstanding the above, the Owner informs that Users may follow the instructions provided on the subsequently linked initiatives by the EDAA (EU), the Network Advertising Initiative (US) and the Digital Advertising Alliance (US), DAAC (Canada), DDAI (Japan) or other similar services. Such initiatives allow Users to select their tracking preferences for most of the advertising tools. The Owner thus recommends that Users make use of these resources in addition to the information provided in this document.

This behavior is much better and less intrusive compared to:

Cookie Control by CIVIC

An interesting jQuery plugin I found a few days ago is this:

https://github.com/fabioquarantini/cookie-banner

It allows us to very easily block element execution until cookie is accepted, example:

Original code:

<script type="text/javascript" src="scripts.js"></script>

Modified code:

<script type="text/plain" src="scripts.js" class="block-cookie"></script>

And it has two options to auto-consent the cookie on scroll and on navigation:

consentOnNavigation:
boolean: Implicit consent on site navigation
Default: true

consentOnScroll:
boolean: Implicit consent on page scroll
Default: true

So that after the user scrolls the page, clicks on a link or clicks the "Accept" button, the blocked elements are immediately and automatically activated with the function:

activateBlockedElements( defaults.blockCookieClass );

Would be awesome to have this functionality on cookie-banner too.

[zytzagoo]

There's an apparently free CMP solution from Quantcast available: https://www.quantcast.com/gdpr/quantcast-choice-self-serve/

Noticed some of the sites in the region using it already.

Found some docs here: https://quantcast.zendesk.com/hc/en-us/articles/360003814853-Technical-Implementation-Guide

[zytzagoo]

This also looks interesting: https://github.com/as-ideas/oil

[simogeo]

I'm also interested by having a library supporting individual / thematic consent. Any news regarding this ?

[simogeo]

see a nice alternative here : https://github.com/ketanmistry/ihavecookies