Topic: New European Cookie Laws

[青山 素子]

As 青山 素子 says, there are options but these will block the search engines as well and that is the problem, coming up with a solution that will work but not block robots, but I think that is too deep into the core code to be doable as a modification.

One other possible solution is to not start a PHP session until a user authenticates, but I'm not sure of the practicality or security implications of that. Of course, even if you're sending a hash so the password isn't in the clear, but doing so over a non-secure link isn't exactly the most secure practice either - unfortunately, it's often the best you can do with shared hosting.

[CircleDock]

• Move your forum to a sub-directory
• Put up an entrance page advising of the cookies that will be set.
• Make a small change on the main SMF index page redirecting anyone who doesn't have an "opt in" cookie set to the entrance page.
• Require a click-through to get to the new forum location, setting a cookie (which was disclosed on that page!) to prevent SMF from kicking them out.

If you put the check right at the start of the SMF execution path, that should avoid a PHP session from being started.

Oh, this solution also prevents search engines from indexing anything since SMF now requires an "opt in" cookie to even show.

I think that would legally work, although it would probably destroy your site since you wouldn't have any results in search so you'd only get new visitors via direct referral.

Are you serious?? Is this the "SMF solution"??! It seems to me you've just sent the message to European Forum site owners that they should look to other software providers because SMF isn't going to assist them in obeying the law.

You know very well that were this US Law, SMF would be bending over backwards to accommodate the new provisions and an updated version would have been beta'd and released by now. So why the discrimination against your European users who probably represent a significantly high percentage of your user base?

Why is it that no current representative of SMF is willing to engage in this discussion?

[CircleDock]

@CircleDock

I wish that were true, but I'm afraid it's simply isn't. You must obtain opt-in consent before setting any cookie. That advice is on the ICO web site and is exactly what a senior member of his staff advised my solicitor.

I agree you have no control over cookies already set and I am not sure how the law treats cookies that were set before the law became effective. But if you log out everyone they must log in again and in doing so will set a new cookie. If there is a notice about cookies at the log in point then I believe you have effectively met the requirements of the law, even though it may not be strictly correct. What I am saying is that the cookie for members is probably not the issue and that can be overcome, the problem is the session cookie.

In respect of cookies set before the law comes into effect you could do what I have done. I have a banner prominently displayed on my Portal Page that informs guests and members that my site sets one or more cookies that are essential for the site to work correctly. That banner contains a link to a FAQ page where I detail as best I can the names of the various cookies, where they originate and how they are used. That really is all that one can reasonably be expected to do.

As 青山 素子 says, there are options but these will block the search engines as well and that is the problem, coming up with a solution that will work but not block robots, but I think that is too deep into the core code to be doable as a modification.

Precisely! And it is for that very reason that SMF should be taking this issue seriously and provide us with an update so that we can be in compliance with the law. You can bet dollars for doughnuts that were this US law, the issue would already have been addressed. I would even go so far as to suggest that this issue affects a very sizable percentage of all SMF users and could even approach 50%. So why is this issue being ignored?

AS said this is going to be a major problem for many websites, especially for small businesses that may not be aware of what they are actually doing. In my view the new law actually makes using the internet illegal as your server can not legally read the packet headers which contain informationf from the users terminal without thier prior permission but how can you get that prior permission if you can't reas the headers.

That's an interesting observation and if one takes the regulations literally then one could certainly come to that conclusion. But I sure that's not the intent!

It is dangerous to read one section of the PECR in isolation, you have to take all the sections together, also to be aware that the UK law and the EU directive are not the same and other countries laws where they exist or are in preparation have taken a different viewpoint and modified things.

That's the point I made earlier: PECR is a framework for individual member nations' own legislation.

From the guidance:

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.

Which implies you do not have to get prior approval as long as you do it as soon as possible, but this is just guidance by the ICO and they could be challenged on thier interpretation by the courts or the EU. My impression is that the ICO will be looking for website owners to be doing as much as possible and to have a plan to eventually meet the regulations, it is not an option to be doing nothing.

Whilst that is certainly true, ICO will not accept that as an excuse for continued non-compliance and they will look to web site owners to be fully in compliance as quickly as possible. One could argue (and ICO might) that web sites should be fully in compliance as of 26th May as they will have had a full year to implement the necessary changes.

One important point that SMF and all EU Forum owners should bear in mind is that although Cookie Laws have been implemented only in the UK, Denmark and Latvia so far, the ICO (and his Danish and Latvian counterparts) can enforce that law EU-wide. So if, for example, someone from the UK (or Denmark or Latvia) visits a web site hosted in (say) Germany and that site does not ask before setting cookies, that site is in violation and can be fined.

[青山 素子]

Are you serious?? Is this the "SMF solution"??! It seems to me you've just sent the message to European Forum site owners that they should look to other software providers because SMF isn't going to assist them in obeying the law.

I do not speak for the team, so it is certainly not an "SMF solution". It was an opinion on a way to ensure compliance if you had to make sure you were being very strict on the reading of the regulations. It's a totally crappy suggestion, but it would work.

Once again, I am not an active team member and the suggestion was my own.

You know very well that were this US Law, SMF would be bending over backwards to accommodate the new provisions and an updated version would have been beta'd and released by now.

Possibly. Maybe. SimpleMachines is a US organization, and the main board is in the US, so it would need to comply with US law. I don't see why a change would be made on this site for that and it not get put in the code when it was stable.

So why the discrimination against your European users who probably represent a significantly high percentage of your user base?

I don't think it's active discrimination at the very least. I haven't seen any team member say no or do anything discriminatory.


Okay, I'm going to sound kinda like an asshole here, but I think this should be said. Keep in mind this is my own opinon and not any kind of stance of the SMF project team, SimpleMachines, the larger community here, or whatever else I may be confused to represent. If you feel I've stepped over the line, there's a nice "report to moderator" link you can use to report my post to the folks running this site. It's down at the bottom right (at least in the default theme) of each post.

Now, the rant:

SMF 2.0 is under a totally free license, the BSD license. Anyone can go and change it and even provide their own "spin" of the software (provided they remove the SMF branding). They can even distribute patches to fix issues.

Instead of throwing tantrums over what you see as some kind of conspiracy by a very-understaffed project to ignore the law, fix it yourself and provide the fix. If you can't code and this is vitally important to you, get someone who can code to fix it.

SMF the software is provided free of charge and is maintained by some very passionate individuals who give up their spare time for this project. What makes things so awful is when people demand changes and generally present an entitled attitude when they have done nothing to contribute. While strong views are appreciated, acting like a spoiled brat demanding changes is the best way to get an issue ignored. Yes, this is probably an important issue and needs to be addressed, but being an asshole about it just makes it take that much longer.

As for me? I'm going to give things a try and see if I can avoid any cookies before login. I don't think it'll be all that easy to break the way dynamic software works to try and comply with a law that seems utterly clueless to that fact, especially for first-party cookies. Maybe I'll find a solution, maybe I'll give up. However, instead of ******ing about it, I'm going to actually try to contribute, unlike you.

[CircleDock]

Possibly. Maybe. SimpleMachines is a US organization, and the main board is in the US, so it would need to comply with US law. I don't see why a change would be made on this site for that and it not get put in the code when it was stable.

I would suggest to you that it would definitely be implemented because if it weren't, the outcry would be considerably more vociferous and indeed smf.org itself would be in violation.

Instead of throwing tantrums over what you see as some kind of conspiracy by a very-understaffed project to ignore the law, fix it yourself and provide the fix. If you can't code and this is vitally important to you, get someone who can code to fix it.

Firstly, whilst I hold very strong opinions about this issue - one of legal compliance - I have not intentionally demanded it be fixed but I and others have asked, sometimes passionately, that it be addressed. The fact this topic hasn't had a single contribution from any official SMF Project member speaks volumes in my view.

I am not a programmer but I have had someone who does do web site development work look at the code. He tells me that the way it is currently implemented, it was akin to a minefield that he didn't want to enter and urged me to refer the matter to the SMF development team - which is exactly what I'm trying to do here. So to accuse me of doing nothing about it is a wrongful accusation.

As for me? I'm going to give things a try and see if I can avoid any cookies before login. I don't think it'll be all that easy to break the way dynamic software works to try and comply with a law that seems utterly clueless to that fact, especially for first-party cookies. Maybe I'll find a solution, maybe I'll give up. However, instead of ******ing about it, I'm going to actually try to contribute, unlike you.

I completely agree with you that the EU Directive has been written from a political standpoint without much, if any, practical regard for how it is to be implemented in the real world. But it is now a law and one that has attracts massive penalty tariff ($750,000) if violated. We're unfortunately stuck with it and all EU member nations are legally obliged (by virtue of their EU accession treaties) to implement their own laws in compliance.

If you are able to devise a solution to this issue, then you'll most certainly receive my grateful thanks along with many others' I am sure.

I concur that it would probably be practically impossible to prevent the PHPSESSID cookie being set. I actually suspect that the ICO would understand that difficulty and not pursue a site provided it obtains an opt-in for all other cookies AND, should the visitor decline to accept cookies at all, that the PHPSESSID cookie be removed.

Thank you for taking an interest!

As a footnote I would add that I have logged-in and out of several SMF-powered Forums and the PHPSESSID cookies remain even after the browser is closed. That's with Firefox 11 and also SW Iron (Chromium-based).

[青山 素子]

Since I talked about doing something, I decided to try my hand at a quick fix. My patch is attached. It's a unified diff. You can apply it by hand or use the "patch" tool on Linux. I believe winmerge also works for this on Windows.

The patch prevents the default PHP session cookie from being created unless an SMF login cookie has been set. Additionally, it displays a noticeable yellow bar at the top of the page linking to information on the two default cookies used when logged in.

If you use this, you need to make sure PHP is not configured to auto-start sessions. That setting will make PHP always generate a session and cookie, and there is no way to fix that in code.

This is not ready for any kind of package install. It has hardcoded language strings and probably has some weird side-effects. I have not fully tested it. It's 2am and I want to sleep...

I am not a programmer but I have had someone who does do web site development work look at the code. He tells me that the way it is currently implemented, it was akin to a minefield that he didn't want to enter and urged me to refer the matter to the SMF development team - which is exactly what I'm trying to do here.

Preventing the default PHP session ID cookie wasn't too hard. A little snip in the loadSession function was all that took. A change to the index template and the addition of a new page for cookie info provided the announcement portion. I think I spent more time messing with git than coding...

As a footnote I would add that I have logged-in and out of several SMF-powered Forums and the PHPSESSID cookies remain even after the browser is closed. That's with Firefox 11 and also SW Iron (Chromium-based).

Make sure to check your cookies before going to the site again. Even if the one session cookie is removed on exit, a new one will be created when you visit the page again. If the expiration is set as "session" or similar wording, the browser is supposed to remove it when you fully close it.

[Norv]

Just to be clear here. There is no such thing as 'it's US not EU' at play on this matter, that SMF itself may not be "required" to comply is completely besides the point, and not the issue here.

If this directive/regulation is affecting indeed EU admins and/or users (and it's workable and at least a bit reasonable to implement a solution), then we will find a way. That document attached several replies above, as shocking as it is, appears to be relatively explicit as to some expectations, though I will try hard not to qualify them and their potential consequences on the web today. Thank you all who are looking into it, be it legal side or technical side.

Be it said. (sorry to be on the run). Personally I appreciate generally, that there are attempts in the current worldwide landscape today, to address third party applications tracking users activities and behavior on the web, and informing people of what websites do. This one however, for all I can see so far, it's a terribly misguided attempt at that. And that's an understatement.

When politicians/lawyers make regulations on technical aspects they don't fully understand, we get ourselves something like this. (which I won't qualify, because I'm trying to remain polite. )

On the constructive side, for one, we are also taking a look at the ToS at registration time, to add more information about the operation of the forum and what are cookies used for. I'm NOT convinced that any kind of "prior" consent could or should be reasonably required for session cookies, considering the normal operation of the forum, non-existent "intrusiveness", and non-existent harm to personal information of any kind. Same goes for 99% of the web applications packages these days.


ETA: Thank you very much, Motoko, for the patch! Will look ASAP into this too.

[JohnS]

N.N. I fully agree that the law which perhaps had a valid reason in the beginning, has gone through the political machine that is the EU and has emerged mangled and useless much like everything else that goes through that machine. But neverthess it is now a law here in the UK which is being enforced by the ICO and has huge penalties. The fact that the UK just adopted the EU directive without any thought for the impact of the law makes things even worse, at least some of the other EU countries are making laws which meet the intent of the directive without being so restrictive. The sites I operate with SMF are charity sites and we just can not afford to fall foul of this law in any way.

The persistant user cookie I have solved, prior to the 26th May last year I removed access all users and made them re-validate thier membership under the new terms and conditions which seek permission for the placement of cookies, I did this by changing thier is-activated setting to its current value +50 and developed a script they could go through to set it back again by agreeing to the new terms and conditions . It did result in about 50% of the registered members not doing this, but as they never visit the site anyway that was in fact a plus as it cleaned out my database (something the DPA requires). I considered this showed an attempt to comply pending more permanent changes.

Over the past few weeks I have modified my template so that there is a notice about cookies on the log in page and above the log in area at the top left of the page, warning members that if they log in they are setting cookies, that has links to my cookie explanation page.The registration terms and conditions have been modified with links to my cookie information page. On the 26th May I will log everyone out and so when they next revisit they will have to log in again, so not only did they last year accept the new terms and conditions, they will have to log in again after a warning that logging in will generate cookies. I believe that covers the persistent user cookie.

I now have to look at what Motoko has provided (many thanks for the work Motoko it is appreciated as it gives me some more clues as to where I should be looking.) And see if I can resolve my session cookie issue.

[emanuele]

That law is BS because users already have such power in any browser they just need to use it (and it has been like that from...I don't even know when, since as far as I remember any browser has the option to ask to accept cookies or not).

BTW, try the attached package (not really tested, not really sure I take in consideration everything).

https://github.com/emanuele45/EU-cookie-law

ETA: the privacy notice is completely unwritten, it's just a placeholder, I'm not good at writing this kind of legal-related things...

ETA2: this will (hopefully) prevent any kind of cookie to be set up, so even ban-related cookies are not put in place (bans will relay rely on a complete ban check every time unless the user accept the cookie.
Additionally, since these actions would setup a a cookie, I disabled at "action-time" any post, vote, moderate, etc. action that could create a cookie (I added more than necessary just because I was too lazy to check if the actions actually create a cookie).
The "accept cookie" is obtained through a cookie itself (i.e. once you click on "accept" a cookie is created) that will last for the session (i.e. every time you or your users will close the browser you will be asked again to accept the cookies, this could be changed to a more persistent cookie...let's say a week?).
There is an hidden setting (ecl_strict_interpretation) that enables a possible stricter interpretation of the law: in other terms you or your users will not be allowed to login or register unless the accept the cookies. As far as I can tell this is *not* required by the law (UK instructions on implementation), because as soon as the user registers or logs in he is accepting the communication (or something like that, I read it yesterday and I don't remember the exact terms), but still can be enabled if you want.

[oOo--STAR--oOo]

That law is BS because users already have such power in any browser they just need to use it (and it has been like that from...I don't even know when, since as far as I remember any browser has the option to ask to accept cookies or not).

BTW, try the attached package (not really tested, not really sure I take in consideration everything).

https://github.com/emanuele45/EU-cookie-law

ETA: the privacy notice is completely unwritten, it's just a placeholder, I'm not good at writing this kind of legal-related things...

AWESOME I am glad to see someone is taking this serious.
Even though the law seems like a whole lot of gibberish, its still have to be adhered to and we all have to take measures.
Simple fact is, alot of people who use the SMF software have no coding knowledge, so expecting them to do it them selves is like asking a dog to make you breakfast lol.

I'll try this out now
Thanks again sir.!

Edit: I will help you with the wording also if need be. I have no problem with that
I been reading the dam law for about 2 hours lol.

[oOo--STAR--oOo]

Just like to confirm that it has broken my forum lol.
I will fix it and report the error few mins,

[emanuele]

Just like to confirm that it has broken my forum lol.
I will fix it and report the error few mins,

Working fine here, I installed without errors.
BTW I removed it.

[oOo--STAR--oOo]

I fixed the forum and un installed the package for now.

These are the errors I got.

Code: [Select]

PHP Fatal error:  Call to undefined function ecl_authorized_cookies() in Load.php on line 2751and

Code: [Select]

PHP Fatal error:  Call to undefined function ecl_authorized_cookies() in Subs-Auth.php on line 166
Thanks,
Star.

[emanuele]

That's a problem with the hooks not installed...try to run the install.php manually (load it into your forum directory and run it from the browser).

I uploaded it at github download section.

[oOo--STAR--oOo]

Just like to confirm that it has broken my forum lol.
I will fix it and report the error few mins,

Working fine here, I installed without errors.
BTW I removed it.

Yeah there was no errors on the install. But as soon as I installed it I got error.
If you can point me in the right direction I would love to get this problem solved on my own forum as quick as possible

Awesome.. I still have your package, will try it now XD

[oOo--STAR--oOo]

That's a problem with the hooks not installed...try to run the install.php manually (load it into your forum directory and run it from the browser).

I uploaded it at github download section.

Awesome it works.. Now just needs to privacy notice to display all the cookies and what they do
I need to delete my cookies now and see what cookies it placed on the website before this notice.
I see how this is done using ECL cookie 2 lol nice...

[oOo--STAR--oOo]

Sorry to be a pain
But what are these cookies?
Just that when I re-visited I had these cookies set automatically.

__utma
__utmb
__utmc
__utmz

Scrap that.. They are analytic cookies GRRRR.

[CircleDock]

Since I talked about doing something, I decided to try my hand at a quick fix. My patch is attached. It's a unified diff. You can apply it by hand or use the "patch" tool on Linux. I believe winmerge also works for this on Windows.

The patch prevents the default PHP session cookie from being created unless an SMF login cookie has been set. Additionally, it displays a noticeable yellow bar at the top of the page linking to information on the two default cookies used when logged in.

If you use this, you need to make sure PHP is not configured to auto-start sessions. That setting will make PHP always generate a session and cookie, and there is no way to fix that in code.

This is not ready for any kind of package install. It has hardcoded language strings and probably has some weird side-effects. I have not fully tested it. It's 2am and I want to sleep...

I am not a programmer but I have had someone who does do web site development work look at the code. He tells me that the way it is currently implemented, it was akin to a minefield that he didn't want to enter and urged me to refer the matter to the SMF development team - which is exactly what I'm trying to do here.

Preventing the default PHP session ID cookie wasn't too hard. A little snip in the loadSession function was all that took. A change to the index template and the addition of a new page for cookie info provided the announcement portion. I think I spent more time messing with git than coding...

As a footnote I would add that I have logged-in and out of several SMF-powered Forums and the PHPSESSID cookies remain even after the browser is closed. That's with Firefox 11 and also SW Iron (Chromium-based).

Make sure to check your cookies before going to the site again. Even if the one session cookie is removed on exit, a new one will be created when you visit the page again. If the expiration is set as "session" or similar wording, the browser is supposed to remove it when you fully close it.

I've tried your patches and, unfortunately, they don't work. The Cookie message isn't ever displayed and cookies are set. But many thanks for trying to provide a solution!

[CircleDock]

That law is BS because users already have such power in any browser they just need to use it (and it has been like that from...I don't even know when, since as far as I remember any browser has the option to ask to accept cookies or not).

BTW, try the attached package (not really tested, not really sure I take in consideration everything).

https://github.com/emanuele45/EU-cookie-law

ETA: the privacy notice is completely unwritten, it's just a placeholder, I'm not good at writing this kind of legal-related things...

ETA2: this will (hopefully) prevent any kind of cookie to be set up, so even ban-related cookies are not put in place (bans will relay on a complete ban check every time unless the user accept the cookie.
Additionally, since these actions would setup a a cookie, I disabled at "action-time" any post, vote, moderate, etc. action that could create a cookie (I added more than necessary just because I was too lazy to check if the actions actually create a cookie).
The "accept cookie" is obtained through a cookie itself (i.e. once you click on "accept" a cookie is created) that will last for the session (i.e. every time you or your users will close the browser you will be asked again to accept the cookies.
There is an hidden setting (ecl_strict_interpretation) that enables a possible stricter interpretation of the law: in other terms you or your users will not be allowed to login or register unless the accept the cookies. As far as I can tell this is *not* required by the law (UK instructions on implementation), because as soon as the user registers or logs in he is accepting the communication (or something like that, I read it yesterday and I don't remember the exact terms), but still can be enabled if you want.

Thank you very much Emanuele, your implementation is almost exactly what's required! In point of fact, ecl_strict_interpretation will be required because, under UK law at least, the user must take a positive action to show he is prepared to allow cookies to be set and all actions including Login and Register should be ignored until he does so.

Unfortunately, setting that option means that visitors can not accept cookies (the "accept" link is missing in this case).

[emanuele]

Thank you very much Emanuele, your implementation is almost exactly what's required! In point of fact, ecl_strict_interpretation will be required because, under UK law at least, the user must take a positive action to show he is prepared to allow cookies to be set and all actions including Login and Register should be ignored until he does so.

The ICO guide says:

There is an exception to the requirement to provide information about cookies and obtain consent where to use the cookie is:
(a) for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or

(b) where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user

As far as I can understand the acts of register and/or log-in are requests made by the user to access an information (society) service, so they belong to the exception. So I would consider theme as implicit approval (also because registering and/or logging-in the users already gives you explicit permission to send them informations: it's the user that is requesting the log-in and/or the registration to access your service (i.e. the forum), it's not you that subscribe them without notice).