ExpressionEngine’s cookie habit goes unchecked

“The Cookie Law is a new piece of privacy legislation that requires websites to obtain consent from visitors to store or retrieve any information on a computer or any other web connected device, like a smartphone or tablet.” - The Cookie Collective

28 comments | Got something to add?

Is it the case though that EL are actively looking at a solution but just haven’t started working on the code?

By Steven Grant on 05 Mar '12 | Tweet | #91
No idea… its been on the forums a little while now and not seen any official response to it myself.
I hope so!

By Andy on 05 Mar '12 | Tweet | #92
Have a gander here - @steveabraham raised it with tech support http://expressionengine.com/forums/viewthread/208478/

By Steven Grant on 05 Mar '12 | Tweet | #93
Ah excellent.

Thinking about it, an addon (over modifying the core EE files) would have the added advantage that we won’t have to go back over all our previous EE2 (and EE1) sites and update each and everyone - an addon uploaded and some template code to integrate it will be far less work than upgrading EE2.1.3 sites to EE2.6+

Glad it’s on EE’s radar tho.

By Andy on 05 Mar '12 | Tweet | #94
Well, you already know much of my thoughts on this but one thing I haven’t gone into on this is the technical difficulty of compliance and why I suggested your best bet would be to talk to EllisLab about it.

This is enough of a problem that it might even be a usable defence to state that it cannot be reasonably expected for a person of competence in this field to have the ability to comply, and you’re showing a lot of ‘best effort’.

The core of the problem is that, as you’ve found, this is a problem which will require changes beneath the API layer and, unlike a compiled program, the API layer is not there to expose otherwise hidden features, but as a safety layer you can be confident will not change without warning. Go past the API and any changes made may be undone by an update which, if it’s a security update, may be required by your commitments under the Data Protection Act.

This is basically a problem which can never be comprehensively solved by a plugin and subsequently must be solved by EllisLab. A complete solution would have a section in the back-end management tool which would handle cookies in the same manner settings and setting groups could be handled. Newly installed plugins could include a new file describing all cookies or for older ones, evaluation of the code and inline rewriting could be done. Again this is deep enough into the core that it would need to be done as an official update.

On the upside, I see above that something is being done about this. From what I’ve seen, the only way this is going to be solved with WordPress is if the entire project is forked.

By Paul Duffy on 05 Mar '12 | Tweet | #95
Glad I’m not using Wordpress then!

I think something that involves both EllisLab changing the core EE files and gives specific control to 3rd party addons would be the best solution going forwards, but to deal with all the thousands of EE sites out there in the EU that are now non-compliant, some kind of retroactive cookie control solution has to be found, and a third party addon is far easier a solution to implement than forcing an update of all sites to 2.6+

By Andy on 06 Mar '12 | Tweet | #96
As much as EL may be looking to resolve this, I can’t see it happening for EE1.

I know personally I’d much rather install an add-on to an EE1 site than have to upgrade a client site to EE2. As much as I’d love to move all those clients, if EE1 is working for them then there’s not much point in moving them and that’s before you even get into budget constraints.

For the talk of a third-party solution - I’d prefer some sort of unlimited licence model where I can cover all of my sites. I guess the question is, what is the value of having all your EE sites meeting the requirement…

By Steven Grant on 06 Mar '12 | Tweet | #97
Yep - am with you on all your points Steven.

I have clients who have no desire, and likely no budget to move from EE1 to EE2.

I was also thinking an unlimited license (as has started to become a popular option among certain types of addon that devs would use on all sites whether for general usefulness or improved development flow), but yes I do also see that as it’s fixing a compliance issue with EE at it’s core it’s something that EllisLab really should be dealing with themselves…

In that sense it’s hard to argue that all EU EE users need to start paying for additional licenses as out of the box EE isn’t enough.
Even tho almost all of us use 3rd party addons, there’s no requirement to do so, and so the cookie issue should be no different - 3rd party addons, esp paid ones should only extend / improve core EE, not fix it.

By Andy on 06 Mar '12 | Tweet | #98
There are huge grey areas with this law, and one point I’d like to make is that my current feeling is the cookies dropped by EE as standard are critical to the operation of the system.

As such, I *think* you could argue the case that they are excluded from the legislation.

There’s not a lot that gets my annoyed, but this law really does rub me up the wrong way for so many reasons.

By Steve on 06 Mar '12 | Tweet | #99
That was my first thought too when I ran through the legislation and the definition of what cookies were set but I guess better to err on the side of caution and be prepared.

I agree with the annoyance, it’s adding another level of UI not to mention is seriously going to skew data gathering. I can almost guarantee, nobody is going to allow cookies.

If a user sees something saying “allow” I can’t see them hitting that option.

By Steven Grant on 06 Mar '12 | Tweet | #100
Absolutely. The key though at the moment is that so long as you have given it some thought and have an argument when they come knocking you’ll be OK - they have *way* bigger fish to fry.

The one thing is does affect is Google Analytics (or similar), that is basically as of 6 months ago not a viable product to use (though at this point in time we are still using it). How do you tell a client that they can’t have GA… that’s a tricky thing to explain. However, again, they’ve more or less admitted that if all you’re using is GA, then you’ll be at the bottom of such a long list you’re unlikely to ever have any legal issues.

By Steve on 06 Mar '12 | Tweet | #101
I can agree with the spirit of what the EU is trying to do, but think they miss the mark by such a large degree it really does annoy me too.
As usual a half-baked (pun fully intended) law ends up causing more problems that it tries to solve and ultimately isn’t going to stop the big players (Facebook, Google etc) from messing with our privacy anyway.

Just because 90% of sites use GA and the EU will never likely bring them all to task over it’s use however, doesn’t help us as web professionals who have a duty to at least inform our clients of the situation.

Mark Steven’s .net article did talk about a 3 point approach:
1. Audit your cookies and update our privacy policy
2. Ask for consent to allow non-essential cookies
3. Adapt scripts to check for consent before dropping

Of these:
1. Is easy to do.
2. Is easy for some (GA), currently impossible for others (EE)
3. See point 2.

He goes on to say “the ICO has said that it’s looking for some positive steps ... choose a level of compliance that you can manage to get your head round now, with a view to doing more when you can”.

At the moment, all we EE users can do is step 1. There’s no point implementing Cookie Control (or similar) that gives the impression of asking consent if EE’s gonna drop them regardless.

By Andy on 06 Mar '12 | Tweet | #102
I think I’m fortunate in that other than EE and GA I don’t really deal with anything that drops cookies (other than membership systems where they basically don’t get access without signing their life away first).

The whole asking consent (as mentioned above) is where I have a problem - there’s simply no point. If you’re going to ask for consent to drop GA cookies, you might as well bin GA and save the hassle and design issues of adding a banner. GA with consent just isn’t going to give you any information that’s in any way useable (worse, it is likely going to give you very skewed results).

The ICO reported an almost a total drop in their GA stats after adding their banner.

I still stand at the moment by my option in that in the case of EE cookies they are required for the software to work (which ticks the ICO’s criteria), and as such are permittable by law. That’s the tact I’m planning to take if I ever get picked up on any of my EE sites.

I guess everyone is different though and we all have to assess our own situations.

I’ve been asked a couple of times to talk at business events about this subject and so far I’ve not taken up the invitation, but I think I’m going to have to start saying yes as I think there’s a lot of false information out there and the public generally don’t have a clue about the truth surrounding cookies.

By Steve on 06 Mar '12 | Tweet | #103
OK - I see what you’re saying with regards to the effort required and likely non-take up of consent.

I guess the main sticking point for me then is what actually does constitute an essential cookie?
Is there any guidance / documentation from the ICO on this?

If we’re to say that the 3 dropped by EE are essential, then presumably so is the one dropped by DevDemon’s hits (they both just track a browser session so as to not count that user again in terms of repeat activity / site visits.

If we then allow Hits cookie, then should we allow the GA cookies as also essential?

I’d imagine no to the GA ones, but I struggle to see where the line can be drawn. Ultimately, the 3 that are dropped by EE are NOT essential to the running of 90% of sites that use EE. They are only essential if you wish to use EE as your CMS of choice (as they can’t be turned off), but not to actually run EE - if EllisLab removed those 3 cookies there would be very little drop in user experience as a result.

In what way do you see those 3 as essential to the running of an EE site Steve?

By Andy on 06 Mar '12 | Tweet | #104
Just to clear something up, a lot of the lack of understanding around this law is the ICO’s fault. Despite a huge revision of their guidance surrounding this law in the last few months they continue to provide bad information including this ongoing focus on cookies when the EU directive and therefore the UK law apply to all client/server programs which store/retrieve locally stored data using any method. So, if I’m correct in remembering that Spotify is headquartered in the EU then that’s a program that’s also covered.

The difference with Spotify is that they can just make you update and have you agree to a new privacy policy during the process. Not only is it easy for them, but they can err on the side of caution 100% and just include everything in a one-time notice.

When you get back to the source EU directive there’s actually a distinct lack of ambiguity or grey area. If you can load enough of the page to ask whether a cookie is allowed, that cookie is not exempt unless it fits the exceedingly narrow ‘technical data’ criterion.

Confusion like this is, of course, weakening this law. If the average web developer can’t reasonably be expected to be able to comply with this law (or even fully understand it) then the law may well be written off, at least for some sectors, as unenforceable.

The way I find most useful for thinking about this is to look at this as an extension of the definition of what constitutes your collection, storing and processing data under data protection legislation. This new directive is excellent in principle but excessively difficult to apply in practice with the ad-hoc nature of websites where every visit to the site has now to be handled with the exact same rules which apply to a market surveyor in the street.

It’s also really not helpful that out of the five main CMS’s in use (Drupal, Joomla, MODX, WordPress, EE) not one of them is based in the EU.

By Paul Duffy on 06 Mar '12 | Tweet | #105
Andy: On the basis that you simply cannot disable those cookies from being dropped by EE, I see them as essential. By the time a visitor has seen a banner asking them if they want to allow cookies, it’s already too late, they’ve been dropped. It’s not to say that this can’t be changed in the future by Ellislab, but for the time being there isn’t any way round it. As such, I’m happy to argue that they are required. The client isn’t going to rebuild their site in another CMS (which CMS doesn’t use cookies anyway?) to solve this issue, so what’s the alternative, take the website offline?

As for DevDemon’s addon cookies, I’d suggest that add-on can be removed and as such isn’t essential. Would removing any cookie-dropping add-on prevent the web site from functioning?

Paul: It sounds like you’re a lot more clued up on this than I am. I read the various guidelines some time ago and haven’t picked them back up again since recent revisions have been in place. At the time my understanding was that any website/system that could be accessed from an EU computer fell under the law (though how enforceable that is I don’t know). Otherwise, we’re talking about just EU products and services, which surely puts the EU at a significant disadvantage.

I think the problem is, without a legal degree the legislation and guidance is somewhat open to interpretation.

I’m firmly in the “unenforceable” camp. Sure, some of the smaller players (like us) could be pulled up on it and lose, but the ICO and similar are going to go after the big fish first and I suspect they’ll lose by the time the big wig legal firms get involved.

By Steve on 06 Mar '12 | Tweet | #106
As far as I understand it the EU law applies to websites owned by EU business’, not anyone access a site from the EU… so Facebook, Google etc have no obligation to change anything.
Conversely, an American accessing our site should be asked their permission to allow cookies - that’s gonna go down well for EU / UK businesses, a whacking great roadblock to business and/or analytics!

When you say that the 3 EE cookies are essential, you’re only referring to the fact they are shipped with EE by default and can’t be turned off, not that their purpose / use is essential to EE working (as, as far as I can tell they’re no more essential to the site’s correct functioning than DevDemons Hits or Google Analytics).

Not that I’m saying this at all, but is there not an argument then for the use of a different CMS that doesn’t require cookies if the CMS you’d like to choose will drop them regardless?

I’m really not saying we should do that, and I have no intention of doing so, nor do I know of a CMS that would be inherently compliant with this law, but can you see my point?

If a CMS is inherently non-compliant and breaking EU and UK legislation, do we have an obligation to advise our clients of this and find an alternative solution?

By Andy on 06 Mar '12 | Tweet | #107
I think from my point of view (which I’m happy to argue about to the ICO) the EE cookies that get dropped can’t be disabled, so in order to deliver the website (which the user has requested) these have to be dropped. There’s no way round it, they are fundamental to the existence of the CMS. As such, I would deem them ‘strictly necessary’ (the ICO term).

With add-ons, you can remove them and the website (which is what the user has requested) will still work. Likewise with GA. You can’t remove EE and still have the website functional.

You make a very valid point though that given we know EE drops cookies that can’t be removed, can be continue to offer it as a service to clients; and again, I’d say that’s open to interpretation.

In my opinion if EE is the right tool for the job, and those cookies are necessary for EE to function (which they are since they cannot be removed), then I would happily put the argument forward to the ICO. I might well lose that argument, but I’d at least be happy to make the stand.

The rule of thumb here is that if it’s at all possible to remove the cookies (or delay them until after user consent), then they aren’t ‘strictly necessary’.

This is my opinion only, and certainly not something that I’d push on anyone else - everyone will have to make up their own minds about what they’re willing to argue to the ICO when/if they come knocking.

We’re coming up with a privacy policy that will be generic enough to explain the use of the EE cookies.

It will be interesting to see how Google handle the whole GA thing though - if they can find a way to make it work sans-cookie it would be in their own interests; otherwise they’re going to lose the EU in the not too distant future.

By Steve on 06 Mar '12 | Tweet | #108
Those guidelines were a mess, I had to do a lot of digging and reading around to get a clear picture but at the time it came up I was working at a company where we wrote our own CMS so the potential legal liability and responsibility was that much greater.

The problem I’m trying to get at with the ICO missives is that the legislation without guidance is difficult to interpret while the guidance is still poorly written enough that someone can easily believe themselves to be compliant when they’re not. The legislation itself is completely unambiguous.

The reason the ICO is making reassuring noises about minor infractions is that there are no requirements in the EU directive regarding penalties and they’re more than aware of the risk of invalidating the law in all cases should they prosecute someone who can demonstrate that the law is at all unenforceable. All-in-all it’s a lot less problematic to ask nicely than to risk invalidating a law which would would then require the UK government to explain at the EU level why UK law is now in breach of a legally binding EU directive.

...and yes, as an amendment to the EU Electronic Privacy directive (with direct reference to the Data Protection directive) this law covers you if you’re covered by EU law and/or the Data Protection Act so any company headquartered in an EU state is covered by this while not a single extra-EU company, including Facebook, Google, etc. are not (although some of their subsidiary operations may be covered, I’m not 100% on this). I’m loathe to describe this as a ‘disadvantage’ against US companies, partly because it sounds like giving up and partly because child-labour laws can be seen as a ‘disadvantage’ against some countries. I always prefer to describe these things in terms of whether the burden can be justified against necessity or benefit.

The necessity is there, but the burden is onerous and the benefit of the way this law is implemented has yet to be demonstrated. When you look at the large amount of time between the 1995 Data Protection directive and the 1998 Data Protection Act then fast-forward to 2011 and the three months given… it’s not about the length of the legal text but the work required to comply. This along with the bumbling cack-handedness of the ICO has made for a legal maze reminiscent of Terry Gilliam’s Brazil.

By Paul Duffy on 06 Mar '12 | Tweet | #109
Oops, typo.. I mean, “not a single extra-EU company, including Facebook, Google, etc. are covered”.

By Paul Duffy on 06 Mar '12 | Tweet | #110
EllisLab really need to come up with a solution for this. I posted a feature request (http://expressionengine.com/forums/viewthread/209790/), but there’s been no response from them.

Anonymous users browsing an EE site get at least three EE cookies, none of which can be considered “essential” under the EU directive. Also, the directive makes no distinction between session cookies and persistent cookies: both need to be consented to before being placed on a user’s computer. There is very little wiggle room available, and you cannot simply say that because the EE cookies are part of the core, then that suddenly makes them “essential”. They’re not.

WordPress is actually one of the better CMS when it comes to cookies. In an out-of-the-box install I did, no cookies were set for anonymous users browsing the site. However, if you add plugins, that can change. Cookies are set when a user comments on a post, but you can either warn users on the comment form, or simply squash the cookies using a few lines of code.

By Simon Jones on 21 Mar '12 | Tweet | #121
It’s a non-issue now; the next version of EE is expected to have this covered.

By Steve on 23 Mar '12 | Tweet | #122
Only a non issue going forwards tho… it doesn’t solve the thousands of websites out there that are running EE2.4 or below that are still non-compliant… upgrading all our client sites to 2.5 will be too much for many clients, and those on EE1.x even more so.

By Andy on 26 Mar '12 | Tweet | #124
Fair point, though in our case we keep all our clients sites up to date anyway as part of our relationship with them.

In your case though, if you don’t have active support/maintenance contracts then really sites that are older aren’t really your concern; they were legal when you built them.

If the clients need to become legal then they’ll just have to accept there’s a fee to do so, which would involve the update to 2.5.

We’re in a fairly fortunate position; all our clients are on annual hosting/support/maintenance fees, so I do appreciate that we’re the exception here, not the rule.

By Steve on 26 Mar '12 | Tweet | #125
I see, yeh.
I was thinking this would be a service we could contact out past clients about and offer a solution that would ideally take no more than a couple hours to solve, and so be pretty affordable.
Updating EE versions will be significantly more complicated than that, and I’m not sure so viable. I think this is why I was hoping for a solution based around an addon, as this would allow us to easily install something that solved the problem, then it’s just a case of skinning the interface to suit the site.

By Andy on 26 Mar '12 | Tweet | #126
Yeah, a 1st party plugin/module would have been a nice solution.

I think what they’ve had to do is add a new hook, so that won’t be viable on anything prior to 2.5.

You can core hack the cookies not to be dropped I believe, though I’ve never tried it. I’m not a fan of core hacks, but then again, if you’re not responsible for the updates to the CMS then that might be worth looking into.

By Steve on 26 Mar '12 | Tweet | #127
Core hacks aren’t good, no, but mostly just cause you then lose them if you did an EE version update whereby they get copied over, but in this case, that would be a good thing.
That might have to be the solution should it come to it, at least for the more “budget conscious” client!!

By Andy on 26 Mar '12 | Tweet | #128
No guarantee that a security update won’t nobble the change either. A patch, which replaces by line number, may mangle an altered file and file replacement will undo any changes in that file only which, due to the structure of CodeIgniter/EE, may cause the site to break.

Doing anything past the API line will require you to manually check and possibly merge in any security updates just to make sure this doesn’t happen. It’s a bane of a thing, taking on maintenance for someone else’s product, which is why I’m not real happy with Wordpress’ position.

By Paul Duffy on 26 Mar '12 | Tweet | #129

To reduce comment spam, we've closed commenting on this article.
If you'd still like to talk to us about it, contact us on Twitter or through our contact form.

Moogaloo

digital design boutique

The Blog