Reference: http://www.simplemachines.org/community/index.php?topic=425349.0
Repo: https://github.com/emanuele45/EU-cookie-law
Package: attached
This package is a work in progress, I don't know if all the cookies are blocked.
Please also remember that this mod is intended to work with SMF only, I will not support any mod.
If you find cookies once installed try to provide as much informations as possible to find out why it is created (i.e. action you were doing, mods installed, themes installed, used SSI, particular configurations (permissions, options enabled, etc.).
The attached package
should:
- prevent any kind of cookie to be set up (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);
- 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.
Important: the privacy notice is completely unwritten, it's just a placeholder, I'm not good at writing this kind of legal-related things...
This is an excellent starting point, Emanuele! But I'm still seeing visitor cookies being set :(
Anyone who has the Google Analytics mod installed should perform the following edit on subs.php
Search for:
function ob_google_analytics($buffer)
{
global $modSettings, $boardurl;
Replace with:
function ob_google_analytics($buffer)
{
global $modSettings, $boardurl;
if (!ecl_authorized_cookies()) return;
This will stop the four cookies set by Google Analytics.
Quote from: CircleDock on April 21, 2012, 11:58:38 PM
This is an excellent starting point, Emanuele! But I'm still seeing visitor cookies being set :(
I visited your forum and this applies:
Quote from: emanuele on April 21, 2012, 04:30:56 PM
Please also remember that this mod is intended to work with SMF only, I will not support any mod.
I cannot know what other mods you have installed and how all these uses cookies, remove that is responsibility of mods' authors, I can't do (almost) anything about it.
Of course other mods can rely on the functions provided by this mod for their functionalities.
Quote from: emanuele on April 22, 2012, 04:02:00 AM
Quote from: CircleDock on April 21, 2012, 11:58:38 PM
This is an excellent starting point, Emanuele! But I'm still seeing visitor cookies being set :(
I visited your forum and this applies:
Quote from: emanuele on April 21, 2012, 04:30:56 PM
Please also remember that this mod is intended to work with SMF only, I will not support any mod.
I cannot know what other mods you have installed and how all these uses cookies, remove that is responsibility of mods' authors, I can't do (almost) anything about it.
Of course other mods can rely on the functions provided by this mod for their functionalities.
I also have another site in the process of construction where I tested your mod. It doesn't have the Portal which I suspect is your concern here. That site also sets the PHPSESSID cookie even when I take no action to permit any cookies.
I have also had a look at the Portal's code and it appears to do nothing which would directly cause a cookie to be set. Using your convenient function, I have blocked Google Analytics as noted above.
Is it possible that SSI has an unplugged path which can cause a cookie to be set? That's about the only thing I can think of.
My point is not that the portal is setting the session, my point is that I cannot see the cookie on your site...unless I enable javascript, so it means it's a script.
Here it is the script that is setting the session:
http://liveinthephilippinesforum.com/forum/sachat/index.php?action=head&theme=default
Quote from: emanuele on April 22, 2012, 04:53:31 AM
My point is not that the portal is setting the session, my point is that I cannot see the cookie on your site...unless I enable javascript, so it means it's a script.
Here it is the script that is setting the session:
http://liveinthephilippinesforum.com/forum/sachat/index.php?action=head&theme=default
Ah! Thank you!!
I'm attaching that particular file and assume that the cookie is being set in line 20:
define('SMF', 1);
// Experimental Optimizer
define('loadOpt', 1);
session_start(); // <--- line 20
session_cache_limiter('nocache');
// Lets go head and load the settings here.
require_once(str_replace('//','/',dirname(__FILE__).'/').'../Settings.php');
// Load SMF's compatibility file for unsupported functions.
if (@version_compare(PHP_VERSION, '5') == -1) {
require_once($sourcedir . '/Subs-Compat.php');
}
As the chat facility isn't available for guests anyway, in your opinion would the following work?
define('SMF', 1);
// Experimental Optimizer
define('loadOpt', 1);
// Lets go head and load the settings here.
require_once(str_replace('//','/',dirname(__FILE__).'/').'../Settings.php');
// Load SMF's compatibility file for unsupported functions.
if (@version_compare(PHP_VERSION, '5') == -1) {
require_once($sourcedir . '/Subs-Compat.php');
require_once($sourcedir . '/Subs-EclWarning.php');
if (!ecl_authorized_cookies())
return;
session_start();
session_cache_limiter('nocache');
Or, perhaps it would be better to put:
define('SMF', 1);
// Experimental Optimizer
define('loadOpt', 1);
// Lets go head and load the settings here.
require_once(str_replace('//','/',dirname(__FILE__).'/').'../Settings.php');
// Load SMF's compatibility file for unsupported functions.
if (@version_compare(PHP_VERSION, '5') == -1) {
require_once($sourcedir . '/Subs-Compat.php');
require_once($sourcedir . '/Subs-EclWarning.php');
if (ecl_authorized_cookies())
session_start();
allow most of the rest of the code to execute and just before it tests to see if the Mod is disabled, put:
$modSettings['2sichat_disable'] = !ecl_authorized_cookies();
if ($modSettings['2sichat_disable']) {
die();
}
if ($modSettings['2sichat_load_chk']) {
doLoadCHK();
}
I'm a "dabbler" rather than a coder, so would welcome any help you can provide :)
Mark
I would go a bit further (but that depends on how the chat is working) and not even echo the <script> tag if the user is not allowed to use the chat...
It should be in index.template.php...the exact implementation depends.
This is what's necessary in the case of SA-Chat. SA-Chat's index.php file will require the following edit:
Search for:
define('SMF', 1);
// Experimental Optimizer
define('loadOpt', 1);
session_start();
session_cache_limiter('nocache');
// Lets go head and load the settings here.
require_once(str_replace('//','/',dirname(__FILE__).'/').'../Settings.php');
// Load SMF's compatibility file for unsupported functions.
if (@version_compare(PHP_VERSION, '5') == -1) {
require_once($sourcedir . '/Subs-Compat.php');
}
Replace with:
//
// SA-Chat - index.php - Modified to prevent cookies being set when they haven't been
// expressly permitted by the user. Based on Emanuele's EU Cookie Law modification.
//
define('SMF', 1);
// Experimental Optimizer
define('loadOpt', 1);
// Lets go head and load the settings here.
require_once(str_replace('//','/',dirname(__FILE__).'/').'../Settings.php');
// Load SMF's compatibility file for unsupported functions.
if (@version_compare(PHP_VERSION, '5') == -1) {
require_once($sourcedir . '/Subs-Compat.php');
}
//
// Load Emanuele's 'EU Cookie-checker Modification.
require_once($sourcedir . '/Subs-EclWarning.php');
// If the user hasn't accepted cookies, get out! We can not go ahead and load SA-Chat
// because set_session() sets cookies and so potentially does SA-Chat's javascript.
if (!ecl_authorized_cookies())
die();
// Okay, cookies can be set so continue.
session_start();
session_cache_limiter('nocache');
It should be noted that the above will prevent SA-Chat from loading and invoking session_start() which causes a cookie to be set. It is necessary to stop SA-Chat from loading because its Javascript also has the potential of setting cookies.
For the sake of completeness, here's the modification necessary to prevent Google Analytics from setting all its cookies:
In subs.php
Search for:
function ob_google_analytics($buffer)
{
global $modSettings, $boardurl;
Replace with:
function ob_google_analytics($buffer)
{
global $modSettings, $boardurl;
if (!ecl_authorized_cookies())
return;
As far as I am concerned, Emanuele's Mod coupled with the above change means that no cookies whatsoever are set until the visitor clicks on the "Accept" link. This means my sites now comply fully with the EU Directive and with UK law.
Thank you very much indeed Emanuele for providing this modification!
Mark
There is one change that needs to be made to the ecl_authorized_cookies() function in Subs-EclWarning.php:
Search for:
elseif (isset($_COOKIE['ecl_auth']) || isset($_COOKIE[$cookiename]))
$storeCookies = true;
elseif (isset($_GET['cookieaccept']))
{
setcookie('ecl_auth', 1, 0, '/');
$storeCookies = true;
} else
$storeCookies = false;
Replace with:
// Temporary code until May 26. On that date, remove this code and re-enable the commented-out section
// below.
//------------------------------------------>
elseif (isset($_COOKIE['ecl_auth']))
$storeCookies = true;
elseif (isset($_GET['cookieaccept']))
{
setcookie('ecl_auth', 1, time()+60*60*24*30, '/'); // Set cookie to expire in 30 days
$storeCookies = true;
} else
$storeCookies = false;
//<------------------------------------------
// Code to be re-enabled on May 26
//
//elseif (isset($_COOKIE['ecl_auth']) || isset($_COOKIE[$cookiename]))
// $storeCookies = true;
// elseif (isset($_GET['cookieaccept']))
// {
// setcookie('ecl_auth', 1, 0, '/');
// $storeCookies = true;
// } else
// $storeCookies = false;
//<-------------------------------------------
The reason for that is that someone who is already a member of your site won't necessarily know that you're setting cookies - or indeed their purpose. The law requires everyone to "opt-in" as of May 26 regardless of whether or not they have visited the site previously.
Fortunately Emanuele sets a cookie when assent is given but as written the cookie lasts for the current session only and will (or should) be removed when the browser is closed.
With this change, a visitor need only accept once and regardless or not if they become a member, they shouldn't be asked to accept cookies again.
However this change is only necessary until May 26 after which it should be changed back to the original code.
Hey emanuele,
Could you modify the code so that the cookie agreement only has to be accepted once. As there is no requirement for them to have to keep accepting on every visit.
I know you set the cookie to say its accepted, but would it not be best to store this value in the database?
Quote from: aljo1985 on April 22, 2012, 08:15:38 PM
Hey emanuele,
Could you modify the code so that the cookie agreement only has to be accepted once. As there is no requirement for them to have to keep accepting on every visit.
I know you set the cookie to say its accepted, but would it not be best to store this value in the database?
That is precisely the way it is working at the moment! Emanuele's code tests for the presence of EITHER the "CookieAcceptance Cookie" (ecl_auth) OR a "regular members" cookie and if either is found, then there is no requirement to get another acceptance from the user.
There is a problem with his code, however, which has just occurred to me. If, having accepted cookies, the visitor then logs-on but does NOT set his session time to be 'forever', then his "regular members" cookie will be removed as indeed so will his "CookieAcceptanceCookie" when he closes his browser. The fix for that is very simple:
Search for:
setcookie('ecl_auth', 1, 0, '/');Replace with:
setcookie('ecl_auth', 1, time() + 189345600, '/'); // 60*60*24*365.25*6That will set a 6 year cookie (the same length of time as SMF's 'forever' cookie.
You can, if you wish, replace the numerical value 1 with a descriptive string so that the visitor will know the purpose of that cookie - eg:
setcookie('ecl_auth', 'EU_Cookie_Acceptance', time() + 189345600, '/');You can not store the cookie acceptance value in the database because guests must also be prompted to accept cookies and, unless they register, they have no details to store in the database.
The first issue (https://github.com/emanuele45/EU-cookie-law/issues/1) I opened is exactly about that. Make it 6 years is in my opinion a bit too much. I'd set it to no more that a month or a year.
P.S.
I'm playing with a couple of ideas, I hope to have something ready in the next few days. I think it will be...nice. :P
Take a look at the attached package which is a combination of Javascript and PHP. It has the advantage of scalability as some EU nations may require separate "opt-ins" for first and third-party cookies (the UK currently does not require this).
You can see it in action here:
http://www.allaboutcookies.org/
but the only missing item is a link to a Privacy Policy page. That may be a configuration setting within the package.
I rather like this implementation as the acceptance window is modal and it also overcomes the problem of "shared PCs" - where the owner may not be aware of what cookies have been set by others using the computer.
Quote from: emanuele on April 26, 2012, 01:01:37 PM
The first issue (https://github.com/emanuele45/EU-cookie-law/issues/1) I opened is exactly about that. Make it 6 years is in my opinion a bit too much. I'd set it to no more that a month or a year.
I mean, that the max lifetime for cookies is limited to one year.. ::)
Quote from: feline on April 27, 2012, 07:32:18 PM
Quote from: emanuele on April 26, 2012, 01:01:37 PM
The first issue (https://github.com/emanuele45/EU-cookie-law/issues/1) I opened is exactly about that. Make it 6 years is in my opinion a bit too much. I'd set it to no more that a month or a year.
I mean, that the max lifetime for cookies is limited to one year.. ::)
Yeah but as the cookie would expire and would/should be,removed by the browser, the member would have to re-accept cookies. The longer that is delayed, the better. in my view.
How to make Emanuele's Modification only affect visitors from within the EUAs it stands, Emanuele's modification will prompt all visitors to accept cookies, regardless of where they are located in the world. This may not be desirable and could be irritable for non-EU members. There is a way around this but you will need to have Spuds' geoIP (IP to Location) (http://custom.simplemachines.org/mods/index.php?mod=3206) modification installed as the method presented here makes use of that modification's database tables.
We will be editing just one file - Subs-EclWarning.php - which should be in your Sources directory.
Search for:
global $cookiename, $modSettings;
static $storeCookies;
if (isset($storeCookies))
return $storeCookies;
Replace with:
global $cookiename, $modSettings;
static $storeCookies;
static $inEU; // True if visitor's Point of Presence is within a EU member state
// Have we checked this visitor's Point of Presence?
if (!isset($inEU))
$inEU = ecl_IsInEU();
// If he's not within the EU, he can have cookies without giving permission
if (!$inEU)
$storeCookies = true;
if (isset($storeCookies))
return $storeCookies;
Immediately above the function ecl_authorized_cookies(), add the following code:
//
// Convert an IPv4 Address to a long integer. Adapted from a similarly-named
// geoIP function and included to save loading the whole of geoIP.
//
// Parameter: $ip_Addr An IPv4 Address in dotted notation
//
// Returns: >0 IT Address as long integer
// 0 No IP Address or badly-formed IP Address
//
function ecl_geo_dot2long($ip_addr)
{
if (empty($ip_addr))
return 0;
elseif (preg_match('~\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3}~', $ip_addr, $dummy))
{
$ips = explode('.', $ip_addr);
return ($ips[3] + $ips[2] * 256 + $ips[1] * 256 * 256 + $ips[0] * 256 * 256 * 256);
}
else
return 0;
}
//
// Master Function to determine whether an IP Address points to a location within the European Union.
// If the geoIP modification is available and the visitor's IP Address is IPv4, then we use the geoIP
// tables. IPv6 Addresses currently not catered for.
//
// Returns true If the ECL modification should prompt for permission to store cookies.
//
function ecl_IsInEU()
{
global $sourcedir;
if (!isset($_SERVER['REMOTE_ADDR']))
{
return true;
}
if ((file_exists($sourcedir . 'geoIP.php')) && (strpos($_SERVER['REMOTE_ADDR'],':') === false))
{
return ecl_geoIP($_SERVER['REMOTE_ADDR']);
}
// Add code here if you want to check IPv6 Addresses (not currently catered for).
return true;
}
//
// This function checks the geoIP database tables to determine whether a given
// IPv4 Address is located within the EU. Uses code from geoIP modification.
//
// Parameter: $ipAddress A properly-formed IPv4 Address
//
// Returns: true IP Address is within the EU
// false IP Address not within the EU
//
function ecl_geoIP($ipAddress)
{
global $smcFunc;
$euNations = array('AD', 'AT', 'BE', 'BG', 'CY', 'CZ', // Andorra (Sain), Austria, Belgium, Bulgaria, Cyprus, Czech Rep,
'DE', 'DK', 'EE', 'ES', 'EU', 'FI', // Germany, Denmark, Estonia, Spain, (Europe), Finland,
'FR', 'FX', 'GB', 'GG', 'GR', 'HU', // France, France (Metropolitain), United Kingdom, Guernsey, Greece, Hungary,
'IE', 'IM', 'IT', 'JE', 'LI', 'LT', // Ireland, Isle of Man, Italy, Jersey, Lithuania, Lichtenstein,
'LU', 'LV', 'MC', 'MT', 'PL', 'PT', // Luxemburg, Latvia, Monaco, Malta, Poland, Portugal,
'RO', 'SE', 'SI', 'SK', 'SM', 'VA', // Romania, Sweden, Slovenia, Slovakia, San Marino, Vatican City
);
$ip = $ipAddress;
// We have an IPv4 address, convert to a long integer
if (strpos($ip,'.'))
$ipl = ecl_geo_dot2long($ip);
// No declared IP Address, must be a dodgy user. Assume he's in Europe!
if ($ipl === 0)
return true;
// Localhost is assumed not to be within the EU, though.
if ($ipl == 2130706433)
return false;
// Query the geoIP database
$request = $smcFunc['db_query']('', '
SELECT ip.start, ip.end,
gc.cc, gc.cn as country
FROM {db_prefix}geoip_ip as ip
LEFT JOIN {db_prefix}geoip_countries AS gc ON (ip.locid = gc.ci)
WHERE ip.end >= {int:ip}
ORDER BY ip.end ASC
LIMIT 1',
array(
'ip' => (int) $ipl
)
);
// Sanitise the result. Assume the visitor is within the EU.
$row = $smcFunc['db_fetch_assoc']($request);
$cc = 'EU';
// If the IP Address is not contained within a range, the next higher value will be returned.
if ($row['start'] <= $ipl && $row['end'] >= $ipl)
$cc = $row['cc'];
$smcFunc['db_free_result']($request);
// We have the two-letter country code, does it match?
$res = array_search($cc, $euNations);
if ($res === false)
return false;
return true;
}
That's it folks!
A caveat and other considerations:
- This addition does not currently cater for checking the location of IPv6 Addresses and assumes any IPv6 address is within the EU.
- As other countries (eg the US, Australia, New Zealand etc) enact similar cookie laws, their two-letter country codes can be added to the array $euNations
- You can replace the database query with a cURL request to an external IP-to-location server.
- Note that some EU member states have more than one identifiable country code (eg the UK includes 'GB', 'GG', 'IM' and "JE').
- Note that I'm only testing for the presence of the geoIP modification (and hence its database), its code is not loaded and executed by this modification. If you have installed geoIP but have not updated its database, then you will need to do this.
Enjoy!
Honestly geo location is not at all accurate, so I would strictly avoid it.
Quote from: emanuele on May 03, 2012, 01:07:08 PM
Honestly geo location is not at all accurate, so I would strictly avoid it.
Your point is well taken but MaxMind, whose database this uses, claims it to be well over 98% accurate at the country level, which is all we're interested in. The changes I've suggested do err on the side of caution and assume the visitor is within the EU unless their IP Address shows otherwise.
There's enough hostility towards this law as it is and some EU-based Admins might well be hesitant to implement any solution that might antagonize their non-EU members and visitors.
Given that many UK Government sites employ Geo-Location, as does all the UK's television broadcasters, Amazon etc., I can not see any reason why the ICO should object or come down heavily against a Forum where its use of Geo-Location has produced an erroneous result.
The ICO does not itself use country based geo-location for the purposes of cookie detection and I can't see them taking it well if there is a complaint because it seems to be 'how can we avoid having to do this' which is a sign of bad faith compliance.
Geo-location where it can be used to benefit the user's experience is encouraged, or where it is required for legal compliance (e.g. content that is only licensed in certain places) but to avoid compliance with a law, is not something I'd want to argue.
Quote from: CircleDock on May 04, 2012, 12:48:44 PM
Your point is well taken but MaxMind, whose database this uses, claims it to be well over 98% accurate at the country level, which is all we're interested in.
That would leave you a 1% (well, probably less) of probability that an EU-based user will not be recognized as such.
If you are lucky enough within this 1% you will not get anyone that will sue you (or report to the competent authority).
Feel free to post it, no problem, I (personally) would not include it in a package. ;)
I downloaded the package and uploaded to package manager - I get the following message when I try to "Apply mod":
The package you are trying to download or install is either corrupt or not compatible with this version of SMF.
What version of SMF?
The package works only with 2.0, and at the moment I don't have any plan to backport it to 1.x.
If anyone is interested feel free to fork the repo and ask questions! ;D
Ah, I am using 1.1.16 :(
I guess I ought to get round to upgrading - I just don't have the time at the moment.
What are the chances of a backport? Does bribery work? :)
BTW, yesterday I realized that in the vast majority of the cases the registration doesn't work unless the cookies are accepted (otherwise smf cannot set the verification code cookie).
Quote from: emanuele on May 07, 2012, 06:44:56 AM
BTW, yesterday I realized that in the vast majority of the cases the registration doesn't work unless the cookies are accepted (otherwise smf cannot set the verification code cookie).
Yes and that's one of the reasons I have modified several templates to omit the display of the main menu bar, Search and the Registration/Log-On boxes unless cookies are accepted.
Quote from: emanuele on May 07, 2012, 06:44:56 AM
BTW, yesterday I realized that in the vast majority of the cases the registration doesn't work unless the cookies are accepted (otherwise smf cannot set the verification code cookie).
it's more that not works properly with your code emanuele ;)
1. Take a look at Maintenance mode handling
2. If you are logged in (always), leave the site without logout, come back and then logout will gives a session verification error.
3. Wap/Wap2/Imode is not handled
We have implemented (based on you code) a worked ECL support for our Portal & SMF and Mobile devices.
Test it on our site .. ;)
I am interested in this plugin but what state is it currently in after reading feline's comments ?
I have looked at felines site and seen the code in action but this is modifed from standard - are there any other sites I can look at?
What you have see is mostly the final release that we will develop in association with our Portal software ...
Just looking at feline's site and looking at the code it looks to be a nightmare to anyone that wants to accomplish SEO. Even if you do allow the bots in you may receive a penalty for different content for user and different content for bot.
Here I just thought of this one, Here is a can of worms.
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fwww.sicomm.us%2Fjunkbin%2Fnends_sig%2Fsignature.php&hash=3f8514d59378fcb8e7b7caba2cca22a022216dab) (http://www.sicomm.us/junkbin/nends_sig/signature.php?link=true)
There we go, just set a cookie in your browser from a different domain through a script claiming to be a image. Now who is reliable for that?
Quote from: nend on May 12, 2012, 02:20:28 PM
Here I just thought of this one, Here is a can of worms.
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fwww.sicomm.us%2Fjunkbin%2Fnends_sig%2Fsignature.php&hash=3f8514d59378fcb8e7b7caba2cca22a022216dab) (http://www.sicomm.us/junkbin/nends_sig/signature.php?link=true)
There we go, just set a cookie in your browser from a different domain through a script claiming to be a image. Now who is reliable for that?
In the UK, the Information Commissioner (who enforces the new law) will very likely hold the site owner liable for any third-party cookies delivered to visitors to that site.
Points I am trying to make, is that search engines like Google are going to penalize you for this. Even if you allow them in they will still penalize you for showing different content to a search engine vs a user. Second point is how are you going to prevent all third party cookies, there is no way a webmaster can be sure of all cookies, like the image above a cookie can be set by a generated image which can be hosted elsewhere.
Should the site owner be liable for third party cookies they may be unaware of?
Say I put this image on your site, I am not bound by the same laws so it is legal for me but not for you. How would the law handle this, embedded content.
Maybe getting off topic here though, but SEO is a real problem with this method. Only option for SEO sake is to allow anybody in and make sure the site doesn't set a cookie, but then you got your third parties. Maybe safe to turn of generated images in the BBC, to only allow non generated images.
Fact though, IMHO a simple mod is not going to achieve this, a more complex modification is needed. Even though, you will have to be extremely careful not to allow third party ads if law makes you reliable for them. There are allot of stuff that can set a cookie, this doesn't look like such a easy task if your reliable for third parties.
Really though, the law makes you reliable for third party cookies?
I think it is a mess and nobody knows how to implement the law properly and most web users do not know what it means. Another law that has not been thought through properly and probaly creates "jobs for the boys" ( work that is given by someone who is in an important position to their friends or members of their family ).
One problem feline and that is I can not browse your website without accepting a cookie and perhaps I do not want to do that. How do you sell your product in that case? Does this mean that all websites should have a version of their website without any cookies what so ever?
My attitude nend is to do the best you can and if something sneeks in at least you can prove you have tried.
Interesting modification.
I agree with @bonzo that it's a mess. It's well-intentioned (stop the invasion of privacy by the use of tracking cookies), but stupidly implemented. My advice is
- Be careful not to add mods which use tracking cookies. Someone please start a list of mods which use potentially illegal tracking cookies?
- If you want to add tracking cookie mods (e.g., for revenue generation), find a way to shut them off in the EU.
- Add highlighted text to the agreement.txt file notifying users that you have some cookies on your site, but they are used only to maintain the session and not to track them.
If the EU wants to prosecute you for normal SMF session cookies, just point out all the government sites illegally using cookies (e.g., the British ICO) and publicly demand that
they be the first prosecuted. Who knows, you may be the straw that breaks the camel's back and brings down the whole EU! :)
1. Most mods actually don't use tracking cookies. In fact, there's only a handful of mods that use their own cookies - other than Nibogo's multi quote mod, you're pretty much looking at the analytics and ad mods, and that's more because of the tracking aspect of the analytics and ads code (i.e. Google)
3. Should really be covered as part of the default wording for members, but there's no requirement to guests to do so.
Re British ICO, they acknowledge that they are using session cookies however they are working with the software developers to remove them. If you're not compliant currently, making a good faith effort towards compliance will discourage penalties.
I've opined elsewhere that it may actually be beneficial not to start a session at all for guests. Sure, you lose tracking of what guests are doing 'right now' and lose any ability to judge how many guests are on the site but search engines screw those over anyway, and you'd save a buttload of effort and DB stuff by not doing it.
Quote from: MrPhil on May 20, 2012, 11:15:14 AM
I agree with @bonzo that it's a mess. It's well-intentioned (stop the invasion of privacy by the use of tracking cookies), but stupidly implemented. My advice is
- Be careful not to add mods which use tracking cookies. Someone please start a list of mods which use potentially illegal tracking cookies?
- If you want to add tracking cookie mods (e.g., for revenue generation), find a way to shut them off in the EU.
- Add highlighted text to the agreement.txt file notifying users that you have some cookies on your site, but they are used only to maintain the session and not to track them.
If the EU wants to prosecute you for normal SMF session cookies, just point out all the government sites illegally using cookies (e.g., the British ICO) and publicly demand that they be the first prosecuted. Who knows, you may be the straw that breaks the camel's back and brings down the whole EU! :)
I agreed with what you said right up to the highlighted part. The ICO is not acting illegally as it has identified all the cookies it and third-party sites are likely to set and enumerates them on its privacy page. As Arantor has said, they say they're working with their software providers to remove the session cookies. The fact that many UK Government web sites won't be compliant in time doesn't mean that the ICO will give a free pass to those in the private sector.
It's not the EU who would prosecute offenders but the national regulator in the relevant member nation that would act. However with only three countries that have enacted PECR so far - the UK, Denmark and Latvia - the whole thing is a bit of a mess and pretty typical of the EU in general.
Quote1. Most mods actually don't use tracking cookies. In fact, there's only a handful of mods that use their own cookies - other than Nibogo's multi quote mod, you're pretty much looking at the analytics and ad mods, and that's more because of the tracking aspect of the analytics and ads code (i.e. Google)
Also, many large ADK mods use cookies.
We have decided to allow no access to the contents before the cookie storage is not accepted.
This switchable option we have implemented in our portal, but no one MUST use it.
That is at least more than SMF and other mod authors make ..
Quote from: live627 on May 20, 2012, 01:22:33 PM
Quote1. Most mods actually don't use tracking cookies. In fact, there's only a handful of mods that use their own cookies - other than Nibogo's multi quote mod, you're pretty much looking at the analytics and ad mods, and that's more because of the tracking aspect of the analytics and ads code (i.e. Google)
Also, many large ADK mods use cookies.
Adk Portal certainly does (see Subs-Adkfunction.php -> function rewrite_context_html_headers()) but Adk Blog and Adk Advertising do not appear to.
Quote from: feline on May 21, 2012, 02:35:24 AM
We have decided to allow no access to the contents before the cookie storage is not accepted.
This switchable option we have implemented in our portal, but no one MUST use it.
That is at least more than SMF and other mod authors make ..
Won't that screw up search engine access entirely?
Quote from: Arantor on May 21, 2012, 09:09:31 AM
Won't that screw up search engine access entirely?
No .. search engines (they detect by SMF as robot) can read all ;)
Oh, fantastic, you're going to fall foul of the cloaking rule then.
Basically Google penalises sites that show drastically different content to robots as to users. A certain technical site that expects people to pay for viewing answers, but showed everything to Google, was a notorious example, especially after Google dropped their site-wide PR by several points.
Whether that's automated or not is not entirely clear - but it's the reason why SMF doesn't allow you to show boards to search engines that guests cannot.
Well .. of course can google and co. not scan boards/topics they not visible for guests ..
a spider can see that what a guest can see .. if the ECL function enabled or not ..
But if you require people to accept cookies before any access to content, how can a search engine agree to accept cookies?
Well ... guest != spider ;D
if($user_info['is_guest'] && !$user_info['possibly_robot']) go to ECL accept page
works also for wap/wap2/imode
Yes, yes, yes I know that guest != spider but if you show content to spiders and not to guests, firstly a user can spoof their user agent, and secondly it can and does draw SEO penalties from Google.
if a user spoof their user agent, then it's not a site holder problem .. that have nothing to do with the ECL.
And what have google to do with this? Google see the same with and without ECL accept ???
-sigh-
You've provided the option for site owners to not allow content to be seen without ECL agreement. But you've allowed search engines to see it anyway.
Google can and has penalised sites for doing this.
Quote from: Arantor on May 21, 2012, 02:45:55 PM
You've provided the option for site owners to not allow content to be seen without ECL agreement. But you've allowed search engines to see it anyway.
True .. while google don't have a mouse button to click on "accept" :D
Quote from: Arantor
Google can and has penalised sites for doing this.
Google have to learn the we are have a Law in the EU ..
So what if there is this law in the UK? Makes no difference to them. My problem with this is your implementation, because I guarantee Google aren't going to change that policy of theirs to be able to 'accept' anything.
This is what happens when ill-informed politicians, egged-on by privacy activists, enact legislation that is frankly unworkable. Feline has implemented the safe option to stop all cookies until the (human) visitor makes a conscious decision to accept them, but she's allowing search engines to carry-on as normal. That's a fairly logical and sensible thing to do. But because Google will penalise sites that show different content to spiders than a visitor can see, that site will be penalised. And since Google is one of the main offenders with regard to third-party cookies, that's simply crazy.
So we have two choices: Prevent access to everyone including spiders to prevent first and third-party cookies being set and not have our pages indexed at all; or, prevent human visitors accessing pages but allow spiders and risk being penalised by Google. Great. Thank you Denmark for such a well thought-out piece of legislation.
Well .. we have implemented this as option for users in UK and other country's the have a concrete ECL.
No body MUST enable this .. it's a option they protect the users PC for cookies they he will not accept.
A non modal version is not cookie secure specially if you have google ads in your content. And SMF itself it's also not cookie secure (as example guest votes) and without a session cookie not all works correct.
I know what you're saying and I appreciate that you've put in the time and effort to do so but what I'm saying is that doing it screws other things up and people need to be aware of that fact (and taking the decision you have to treat search engines differently is not a wise one - but as long as you're aware of the consequences in penalties for sites that use it, that's up to you)
QuoteSo we have two choices: Prevent access to everyone including spiders to prevent first and third-party cookies being set and not have our pages indexed at all; or, prevent human visitors accessing pages but allow spiders and risk being penalised by Google. Great. Thank you Denmark for such a well thought-out piece of legislation.
Not really, no, we have other options.
We can avoid setting cookies and not issue anything to users pending agreement, or even not use cookies for guests whatsoever and not even start a session for them in the first place, which has other interesting aspects to it - but it does mean we have all sorts of choices ranging from strict to lax.
We have long time tested on this .. if you have a better solution for all the things, then let me known ...
My preferred solution is not one you want to implement, trust me on this.
What is funny is that while cookies might be the easiest way to track people it isn't the only way. Anyone remember browser fingerprinting?
Quote from: Arantor on May 21, 2012, 04:24:06 PM
QuoteSo we have two choices: Prevent access to everyone including spiders to prevent first and third-party cookies being set and not have our pages indexed at all; or, prevent human visitors accessing pages but allow spiders and risk being penalised by Google. Great. Thank you Denmark for such a well thought-out piece of legislation.
Not really, no, we have other options.
We can avoid setting cookies and not issue anything to users pending agreement, or even not use cookies for guests whatsoever and not even start a session for them in the first place, which has other interesting aspects to it - but it does mean we have all sorts of choices ranging from strict to lax.
As far as SMF right now is concerned, I don't believe we do have the luxury of other choices. What you're talking about are radical changes to the core and whilst that's undoubtedly do-able, it's not something that's going to happen in the next 2 days, 2 weeks or 2 months. I'm not sure if Emanuele's modification is SMF's official answer to the issue but if not then what is?
The issue
may be addressed in v2.1, whenever that will be released, but who knows? Meanwhile we have just over two days to become compliant - or as close to full compliance as is possible and there are two solutions on offer: Feline's and Emanuele's. Neither are ideal - Feline's is part of PortaMx whilst Emanuele's fails to take into account third-party cookies, although there are ways to overcome that.
Your remarks are from the standpoint of a completely unmodified installation where the only cookies are those set by SMF itself. However I'd suggest that very few SMF powered Forum sites are quite so barren. Many I'm sure will have Google Analytics, mods such as Nibongo's multi-quote and/or Adk Portal and let's not forget the social network sites and Adsense which all deliver cookies via SMF served pages but are not necessarily stored in the browser's cookie folder for that site. Therefore it is quite impracticable to allow visitors to access the site under these circumstances, given that SMF is not designed to work without cookies.
As I said earlier, given the current constraints, it is better to allow spiders to index the pages and risk PR penalties than to lock-out spiders completely.
The real answer - and the long-term solution - must come from SMF since it is their software that is serving the pages. Surely it must be possible for the "system" to strip-out cookies from the prepared pages prior to serving them?
QuoteAs far as SMF right now is concerned, I don't believe we do have the luxury of other choices. What you're talking about are radical changes to the core and whilst that's undoubtedly do-able, it's not something that's going to happen in the next 2 days, 2 weeks or 2 months. I'm not sure if Emanuele's modification is SMF's official answer to the issue but if not then what is?
All the evidence I've seen is that if you are making reasonable attempts to be compliant and are working towards compliance (i.e. by working with the software manufacturers) then that's the best you can do, note that the ICO's OWN WEBSITE is not even compliant though they are working towards it, by their own admission. This is the same deal.
QuoteYour remarks are from the standpoint of a completely unmodified installation where the only cookies are those set by SMF itself.
*shrug* That's the only meaningful position I can take, since I don't use Google Analytics, nor any of those other mods that set cookies. All of my sites would theoretically be compliant with Emanuele's mod installed, so in that respect I'm not seeing much of a problem.
That said, how, exactly, would you suggest I take a different position? I cannot deal with all the permutations of mods that work with mods, there are so many permutations of mods that may or may not use cookies.
I know how I could solve this, in a mod, in time for compliance-day, but I also know that no-one here would want that solution, even though of all the benefits I believe it brings, and it would improve SMF's SEO position, save a buttload of resources in the process and so on, by simply not setting any kind of session until such time as a user actually logs in (and lose all tracking of guests)
Quote from: Arantor on May 21, 2012, 07:03:19 PMI know how I could solve this, in a mod, in time for compliance-day, but I also know that no-one here would want that solution, even though of all the benefits I believe it brings, and it would improve SMF's SEO position, save a buttload of resources in the process and so on, by simply not setting any kind of session until such time as a user actually logs in (and lose all tracking of guests)...........
When you say "lose all tracking of guests", exactly how do you mean that? Would it still be able to show how many guests there were, and their IP's? If so, that would be fine IMO. I don't care what guests are actually doing, as long as I can check IP's.
NO tracking. AT ALL. No idea how many guests there are, no idea what they're doing. No ability to track or use any of that, nor their IP addresses.
Now you understand why I said I could solve this in a mod in time for compliance: no-one here, just like when I proposed it on Wedge, wants to do without the safety blanket that is the guest list, despite the fact that it's not particularly accurate, nor particularly useful (in 6 years of running forums, I spend most time in there debugging faults with logging)
What do you want to check with the IP addresses, exactly?
Handy for spammers/bots.
ETA: Although personally I could live without it.
Quote from: Arantor on May 21, 2012, 07:03:19 PM
QuoteAs far as SMF right now is concerned, I don't believe we do have the luxury of other choices. What you're talking about are radical changes to the core and whilst that's undoubtedly do-able, it's not something that's going to happen in the next 2 days, 2 weeks or 2 months. I'm not sure if Emanuele's modification is SMF's official answer to the issue but if not then what is?
All the evidence I've seen is that if you are making reasonable attempts to be compliant and are working towards compliance (i.e. by working with the software manufacturers) then that's the best you can do, note that the ICO's OWN WEBSITE is not even compliant though they are working towards it, by their own admission. This is the same deal.
I fully accept that the ICO site is not 100% compliant and that it is far closer to compliance than many other public sector sites in the UK. But I don't imagine for one minute that they will accept as an excuse that our software provider, SMF, is looking into the issue and that we will be compliant when the necessary changes are made by the developers - even though that, in a nutshell, is the excuse their offering.
QuoteQuoteYour remarks are from the standpoint of a completely unmodified installation where the only cookies are those set by SMF itself.
*shrug* That's the only meaningful position I can take, since I don't use Google Analytics, nor any of those other mods that set cookies. All of my sites would theoretically be compliant with Emanuele's mod installed, so in that respect I'm not seeing much of a problem.
That said, how, exactly, would you suggest I take a different position? I cannot deal with all the permutations of mods that work with mods, there are so many permutations of mods that may or may not use cookies.
I know how I could solve this, in a mod, in time for compliance-day, but I also know that no-one here would want that solution, even though of all the benefits I believe it brings, and it would improve SMF's SEO position, save a buttload of resources in the process and so on, by simply not setting any kind of session until such time as a user actually logs in (and lose all tracking of guests)
Yes, yes, I know! For what it's worth, I grudgingly agree with your position of removing PHPSESSID completely for performance reasons even though it will mean we lose all track of guests - and I'm not particularly enthusiastic about that. But the two SMF cookies are only part of the problem and any lasting solution must take account of those served by mods and the third-parties ones too. At the risk of repeating myself, surely the "system" can strip-out all cookies immediately prior to serving the page?
QuoteHandy for spammers/bots.
ETA: Although personally I could live without it.
How? How, exactly, does it make life easier for dealing with spammers/bots, who by definition need to register in the first place? All it gives you the ability to do is grab a snapshot of what's going on right now, which isn't particularly useful in the scheme of things.
Don't forget your usual hit logs are still produced so you still have access to awstats to track activity and potentially bar mass hits first.
QuoteI fully accept that the ICO site is not 100% compliant and that it is far closer to compliance than many other public sector sites in the UK. But I don't imagine for one minute that they will accept as an excuse that our software provider, SMF, is looking into the issue and that we will be compliant when the necessary changes are made by the developers - even though that, in a nutshell, is the excuse their offering.
Why not, since that's their excuse?
QuoteI grudgingly agree with your position of removing PHPSESSID completely for performance reasons even though it will mean we lose all track of guests - and I'm not particularly enthusiastic about that.
This is the sticking point of my frustration when explaining this issue on Wedge. What exactly do you think you're losing by not having that log?
QuoteAt the risk of repeating myself, surely the "system" can strip-out all cookies immediately prior to serving the page?
No, it can't. I spent some time researching that for Wedge.
Quote from: Arantor on May 21, 2012, 07:37:21 PM
QuoteHandy for spammers/bots.
ETA: Although personally I could live without it.
How? How, exactly, does it make life easier for dealing with spammers/bots, who by definition need to register in the first place? All it gives you the ability to do is grab a snapshot of what's going on right now, which isn't particularly useful in the scheme of things.
Don't forget your usual hit logs are still produced so you still have access to awstats to track activity and potentially bar mass hits first.
That's why I said I could live without it. Might be handy for noobz who want to wallop miscreants, but wouldn't bother me if it was dropped. Saving a buttload of resources is always nice too.
Quote from: Arantor on May 21, 2012, 07:26:47 PM
NO tracking. AT ALL. No idea how many guests there are, no idea what they're doing. No ability to track or use any of that, nor their IP addresses.
Surely guest activity could be logged keyed on IP Address without the need for a session cookie? Right enough the guest log table could grow to be quite big, but could be pruned with a scheduled task. This would have the added benefit of greater accuracy whilst eliminating the session cookie.
As I discussed, repeatedly, at Wedge, no. IP address is not remotely reliable for identification of a user, and considering how there are still ISPs that change IP address per request (not to mention the proxy nature behind all mobile phones), it really isn't worth the effort.
Also, note that when IPv6 is deployed you get all the fun attached to another privacy matter.
Honestly, session cookies are way way more accurate than using IP addresses, and would also cause more work than a session cookie does for the user. Heck, you'd be better off just pushing the session into the URL and be done with it for all the problems that will cause with SEO than you would trying to cope with IP based sessions.
So how hard is it to implement your idea about dumping guest tracking?
It's a fair amount of work since it has to deal with a lot of edge cases (especially around registration) but probably a day's work if I can nudge out my other work commitments.
That said, I'm really not sure I want to deal with the support comments from people that complain about the consequences (especially as it will require edits to any custom theme with its own board index, message index, display or who's online templates)
Fair enough. Was just wondering. Sounds like a good option though.
I think it is, but too many people are attached to chasing the phantom numbers of guests online.
Quote from: Arantor on May 21, 2012, 07:37:21 PM
QuoteI fully accept that the ICO site is not 100% compliant and that it is far closer to compliance than many other public sector sites in the UK. But I don't imagine for one minute that they will accept as an excuse that our software provider, SMF, is looking into the issue and that we will be compliant when the necessary changes are made by the developers - even though that, in a nutshell, is the excuse their offering.
Why not, since that's their excuse?
Oh I agree with you but that's not the point. I'm too cynical to believe that the ICO will take action against another agency of government - including themselves!
QuoteQuoteI grudgingly agree with your position of removing PHPSESSID completely for performance reasons even though it will mean we lose all track of guests - and I'm not particularly enthusiastic about that.
This is the sticking point of my frustration when explaining this issue on Wedge. What exactly do you think you're losing by not having that log?
Simply because it's a better estimate of site popularity. Awstats/Webstats are too blunt an instrument in that they record all hits to a site but if Bad Behavior is installed, not all hits will get through. My owners want to know the number of actual readers.
QuoteQuoteAt the risk of repeating myself, surely the "system" can strip-out all cookies immediately prior to serving the page?
No, it can't. I spent some time researching that for Wedge.
Ah, I wasn't aware of that.
QuoteOh I agree with you but that's not the point. I'm too cynical to believe that the ICO will take action against another agency of government - including themselves!
What, the old boy's club? Heh, no chance.
But there are many provisions in the law itself (and not the layman's advice) about working towards compliance and that action, if taken, will be lessened if the site is making an effort towards compliance as best they are able.
QuoteSimply because it's a better estimate of site popularity. Awstats/Webstats are too blunt an instrument in that they record all hits to a site but if Bad Behavior is installed, not all hits will get through. My owners want to know the number of actual readers.
So what? It's still a meaningless number. Assuming you also exclude search engines from that, and that you exclude every single possible search engine, every single possible bot and more from the stats, you're still dealing with a number that doesn't really work. (And believe me, the default listing in SMF plus BB is not even close to that)
All you're getting is a vague number based on the number of requests currently being fired at the server, which is not really substantially more accurate than using awstats. If you really cared about accuracy of stats, you'd be using Google Analytics or similar anyway, even with all the foibles THAT has, privacy aside.
Quote from: Arantor on May 21, 2012, 07:37:21 PM
QuoteAt the risk of repeating myself, surely the "system" can strip-out all cookies immediately prior to serving the page?
No, it can't. I spent some time researching that for Wedge.
I don't know whether this would be satisfactory in compliance terms, but how about this: just before serving the page, check $_COOKIE and for each cookie found:
setcookie("cookieName", "", mktime(12,0,0,1, 1, 1990));That should cause them to be destroyed immediately upon receipt by the browser (it says here (http://www.freewebmasterhelp.com/tutorials/cookies/2)).
That only solves a fraction of the problem, though, doubly so with logged in users (where both the main and session cookies get a 6 year life time) - some browsers actually treat that as end of session rather than 'from here on'.
Quote from: Arantor on May 21, 2012, 08:08:21 PM
QuoteOh I agree with you but that's not the point. I'm too cynical to believe that the ICO will take action against another agency of government - including themselves!
What, the old boy's club? Heh, no chance.
But there are many provisions in the law itself (and not the layman's advice) about working towards compliance and that action, if taken, will be lessened if the site is making an effort towards compliance as best they are able.
But this is my whole point. If we were to adopt the ICO stance and claim we're waiting on a solution from our software providers, we'd be using that excuse for .... well, rather a long time. Let's face it, there's been no attempt by SMF, officially at least, to provide a solution - not helped, it has to be said, by certain staff virtually encouraging others (ie us Europeans) to break the law. But I rather imagine that were it to be US Federal Law, an update would have been issued to specifically address the issue. (Another reason to be grateful that Wedge is Anglo-French!)
Quote from: Arantor on May 21, 2012, 08:20:21 PM
That only solves a fraction of the problem, though, doubly so with logged in users (where both the main and session cookies get a 6 year life time) - some browsers actually treat that as end of session rather than 'from here on'.
Oh I'm not talking about logged-on users since they would have to accept cookies. I'm talking about guests who could be served both first and third-party cookies.
But I do agree, many browsers are broken in that respect so I guess it's a non-starter.
Quote from: CircleDock on May 21, 2012, 08:17:21 PM
I don't know whether this would be satisfactory in compliance terms, but how about this: just before serving the page, check $_COOKIE and for each cookie found:
setcookie("cookieName", "", mktime(12,0,0,1, 1, 1990));
that should not work .. make a simple test with the default theme ..
click on the header upshrink icon .. look at the cookies and you find one "upshrink" ..
Because the site is not reloaded at this time you have a ECL violation ;)
Same problem if you have a non modal ECL accept ...
Quote from: CircleDock on May 21, 2012, 06:56:10 PM
I'm not sure if Emanuele's modification is SMF's official answer to the issue but if not then what is?
No, it's not.
[Cynical mode ON]
At the moment it's just a personal way to play with cookies (that I know very less about), so from my personal point of view it's not even a way to address the problem. :P
[Cynical mode OFF]
If at any time the others think they want to adopt it anyway they are free to do.
Quote from: CircleDock on May 21, 2012, 06:56:10 PM
The real answer - and the long-term solution - must come from SMF since it is their software that is serving the pages. Surely it must be possible for the "system" to strip-out cookies from the prepared pages prior to serving them?
Please note that even if SMF would provide a "long-term solution" it would be strictly related to the cookies set by SMF itself, SMF cannot in any way control 3rd-party cookies.
SMF cannot control GA or other tracking things added by the admin by means of a mod or direct code edit.
That said, what I'm (kind of) working on for this mod is a function that scans the files present in the SMF directories looking for setcookie and then gives an admin interface to deal with each cookie one by one (and hopefully to give users the possibility to accept single cookies too).
Unfortunately at the moment I'm already doing few other things and I don't have many time to dedicate to this idea (part of the code is already written, but a big part is not), if I can finish off the two IPB converters I'm working on (or if you find someone that wants to work on them instead of me :P) I'll come back to this.
With some installations of PHP you can rename the setcookie function. Then from there you can override it with a custom function that will check if the user has accepted cookies. From the overridden function you can call the renamed setcookie function.
The procedure above is only viable for those who have a optional Zend extension installed.
For the rest though why not set up a custom function for SMF that handles all cookies and sessions then start rewriting SMF to use that function throughout the entire source. This will be the first step and maybe you can encourage mod authors to use this function to set the cookie instead of PHP's function.
Quote from: nend on May 22, 2012, 10:19:00 AM
For the rest though why not set up a custom function for SMF that handles all cookies and sessions then start rewriting SMF to use that function throughout the entire source. This will be the first step and maybe you can encourage mod authors to use this function to set the cookie instead of PHP's function.
In 2.1 is there...it was born for another purpose, but it's there and is used, in the future it will be up to modders to use it. ;)
A lot of post on the subject all of a sudden!
I also think that the SMF developers should help out here and if it was easy to change forums I would as their seemingly head in the sand attitude is anoying me. Although I have had a quick look around and can not see any posts about other forums doing anything either.
I run a basic form with no mods and do not care about guests - why track guests they do not mean anything until they have regestered?
I can not see the point in most mods as the forum is to discuss the subject and I think a lot of forums are having a load of surpless content. Who wants or pays attention to "The quote of the day" add Twitter and Facebook links !!!
A lot of users on my forum have trouble even posting!
Anyway back to the problem I have the one PHPSESSID cookie when people first visit the site which is a problem and the SMF cookie when they have logged in which is not a problem if they want to be a member of the forum.
Will emanuele's code take care of the PHPSESSID cookie?
I would think there are quite a few installations of the forum around that are not overloaded with extra packages as people just want a basic easy to maintain forum. I had a couple of plugins when I was on verson 1. to try and stop spammers but they always turned out to be a problem when upgrading which I think is another reason to stay clear of them.
I think Arantor is spot on here - the only good solution IMO is to not track guests at all. Its only then you really abide the cookie law, and you also focus the software towards USERS instead of guests, which can be *anything* that request the page, human or not. AWstats or other server logging software will give you this traffic anyway. IMO, if you are on a shared host and isn't able to check server logs because of that, well, then its one of the things you just cannot access by being on that setup.
As for the "upshrink" cookie, why set it at all? IMHO upshrinks that remember state should be reserved to members only. It can still work, just not remember over the next page.
If you are on a shared hosting and can not access the stats you could always install bbclone - although every shared hosting I have been on has had cpanel.
I think you get a lot more as standard these days even on a shared hosting. I have set somebody up with a hosting package for about £20/year that has everything and is UK based. If you want something and its not on your hosting package you do not have any excuse not to move.
Off-topic
Is it just me or does everybody get redirected back to the section index when you have posted?
You forgot a lot of cookies they set by javascript .. all the collapse functions (smf_toggle) ...
There are only a couple of those and we mentioned them in passing when talking about upshrink - but the point stands: why bother setting those with cookies for guests, when they can join the site and get that functionality?
Quote from: Bloc on May 22, 2012, 02:46:25 PM
As for the "upshrink" cookie, why set it at all? IMHO upshrinks that remember state should be reserved to members only. It can still work, just not remember over the next page.
That is what we do on the Portal .. no problem .. but we can't change that on the themes
Well .. now we have done a modal and a none modal ECL acceept (can be selected).
For WAP/WAP2/IMODE and mobile devices we use always modal ECL accept.
On none modal the admin have the risk, that other mods or adsense content set cookies.
More we can't do ...
Don't forget images, images can set cookies too, people always forgetting about images.
@feline, I bet I can make your site break the law on a user stand point, by my point above. :D
There's two ways to solve that problem, neither ideal - either you proxy every image and blackhole the cookies in the process, or you manually look up every image on posting and see if cookies are posted in the response and if so warn the user.
I'd love the shoot the idiots who thought this law was a good idea. ::)
Quote from: Arantor on May 22, 2012, 05:26:52 PM
There's two ways to solve that problem, neither ideal - either you proxy every image and blackhole the cookies in the process, or you manually look up every image on posting and see if cookies are posted in the response and if so warn the user.
Actually you can do it with other file types too. All you need to do is call it dynamically. So if I load a file through a PHP script I can add a cookie then pass the contents.
I am guessing all that would have to be done is not allow dynamic images in post and signatures. Basically a file extension check. Currently SMF does not check the extensions in images in BBC, so adding a new rule should do the job, I think.
I am though against it and only hope if these things do make it to SMF only they do so as a optional feature. Why penalize the users who are not bound by this law. :D
@Ant: that would be the European Courts that decided this was a problem, and then the UK and a couple of other countries that actually implemented the rules. Wait until it goes postal with everyone getting in on the act.
@nend: Sure you can do it with other file types, but the only ones that SMF will allow dynamically included under most circumstances are images (though checking for cookies is something we might have to look at in the auto embed part of Aeva), so it's only really anything in the img tag that we have to look for.
And really, the extension means squat, I know full well that a simple rewrite rule on the destination will pretend .png or .gif is the filename instead of .php or similar.
QuoteWhy penalize the users who are not bound by this law.
It's only a matter of time before we all are, I fear.
This is a draft of a future EU regulation that involves cookies too:
http://ec.europa.eu/justice/data-protection/document/review2012/com_2012_11_en.pdf
something that will replace the current directive.
That's even more incomprehensible than the current wording of the UK law itself. :/
It seems simply to restate that mechanisms such as cookies that used to identify/track users, must have the users' permission before they are deployed. (The word "cookie" appears once in that rather turgid document.)
So no mention of localStorage or other mechanisms, then?
I would assume the law will affect all kinds of tracking - that is the idea: to not be allowed to store locally without consent. Whether its cookies, localStorage or future technologies.
Quote from: Arantor on May 23, 2012, 06:25:54 AM
So no mention of localStorage or other mechanisms, then?
I only had a quick scan through the proposed new EU legislation and it doesn't specify which mechanisms other than saying (words to the effect of) 'mechanisms such as cookies'. From that I deduce
any mechanism present or future.
I know that's the idea, but all the time it keeps mentioning cookies and not focusing on all the others, it's going to be exploited by slightly less scrupulous people.
'mechanisms such as cookies' can be argued as to not really cover the different types of localStorage or Flash cookies. (Yet again, law makers should not meddle in things they do not understand)
I have just had a thought that would make everything simple: All browsers have a warning about cookies.
Sure they do, but the law puts the onus on site *owners* to be compliant, not browser users.
I have installed the package and all looks OK so far. I have a privacy policy in place on the site but how do I link to that from this mod?
Quote from: bonzo on May 23, 2012, 02:53:57 PM
I have installed the package and all looks OK so far. I have a privacy policy in place on the site but how do I link to that from this mod?
You'll need to create a text file named "ecl_privacynotice.txt" and place that in the same directory as Settings.php. I'm attaching one we're using which you may use as a model, though you'll need to edit it to include the cookies your site sets - and remove those you're not setting.
Thank you very much for the information. Luckly we have a complete standard setup with no mods.
I could not view the agreement and thought I had a problem and then found it could not be viewed in maintanace mode.
A very good document.
Another quick question:
The cookie warning is not showing up for me when logged in and I assume the same for other people already logged in. Do I need to either log everyone out somehow first or change the cookie value so everyone needs to login again?
Well .. this mod don't work correct on all situations ...
We found follow problems:
1. you can login/register without accept ECL
2. register visual verification don't work if the accept ECL screen displayed (seems like a SMF bug?)
3. Maintenance mode is not handled
4. attach requests from guests they not have accepted ECL produce session errors
5. WAP/WAP2/IMODE not handled
6. cookies they set by collapse header or information center are not handled
7. For Mobile devices not applicable
and much more problems they ends in a session error
We have spend many time to solve all these things, but it's a fact that a "none modal" ECL accept not work without a lot of problem (many logged session errors).
So we have decided to add both modes (Modal / none Modal) in our Software so it's in the hand of the Site ower what he will use. For WAP/WAP2/IMODE and for Mobile devices the ECL accept is always Modal, because these devices are to small. Spider have always access to the site, also in Modal mode.
And thanks to CircleDock for the Pricacy police .. we will add this (as example) in our Portal ...
Quote from: feline on May 24, 2012, 04:13:43 AM
1. you can login/register without accept ECL
This is intended.
Quote from: feline on May 24, 2012, 04:13:43 AM
2. register visual verification don't work if the accept ECL screen displayed (seems like a SMF bug?)
This has been fixed in the version I just uploaded.
Quote from: feline on May 24, 2012, 04:13:43 AM
3. Maintenance mode is not handled
Don't know if I fixed this while doing something else, but I can't see any problem.
Quote from: feline on May 24, 2012, 04:13:43 AM
4. attach requests from guests they not have accepted ECL produce session errors
What do you mean by "attach requests"?
Quote from: feline on May 24, 2012, 04:13:43 AM
5. WAP/WAP2/IMODE not handled
Fixed.
Quote from: feline on May 24, 2012, 04:13:43 AM
6. cookies they set by collapse header or information center are not handled
Fixed.
Quote from: feline on May 24, 2012, 04:13:43 AM
7. For Mobile devices not applicable
Why?
Quote from: feline on May 24, 2012, 04:13:43 AM
and much more problems they ends in a session error
That was expected, if anyone would mind to report when and where I can fix it.
Quote from: feline on May 24, 2012, 04:13:43 AM
For WAP/WAP2/IMODE and for Mobile devices the ECL accept is always Modal, because these devices are to small. Spider have always access to the site, also in Modal mode.
Well...I don't even care to show this to wap/2/imode: the register button is absent and if they login the know they accessing a service that needs cookies, so there is no problem as far as I'm concerned. For everything else the cookies are disabled.
Oh I forgot to say a thing, but edit that post would be a nightmare... :P
Quote from: emanuele on May 24, 2012, 05:58:49 PM
Quote from: feline on May 24, 2012, 04:13:43 AM
1. you can login/register without accept ECL
This is intended.
This is partially changed with the version I just uploaded because the privacy notice is displayed (also) above the registration agreement (and the registration agreement is forced even if the admin has it disabled), so if someone is accessing the register page he will be exposed to the privacy notice and accepting the agreement he will accept the notice too, so for the register the problem is fixed.
Quote from: emanuele on May 24, 2012, 05:58:49 PM
Quote from: feline on May 24, 2012, 04:13:43 AM
4. attach requests from guests they not have accepted ECL produce session errors
What do you mean by "attach requests"?
Look at Subs.php - function writeLog
if (!empty($modSettings['who_enabled']))
{
$serialized = $_GET + array('USER_AGENT' => $_SERVER['HTTP_USER_AGENT']);
// In the case of a dlattach action, session_var may not be set.
if (!isset($context['session_var']))
Error->>> $context['session_var'] = $_SESSION['session_var'];
Quote from: emanuele
Quote from: feline on May 24, 2012, 04:13:43 AM
7. For Mobile devices not applicable
Why?
The screen is to big, to many text, so you see nothing of the content ;)
Quote from: emanuele
Quote from: feline on May 24, 2012, 04:13:43 AM
and much more problems they ends in a session error
That was expected, if anyone would mind to report when and where I can fix it.
I accumulate all the errors currently ...
Quote from: emanuele
Quote from: feline on May 24, 2012, 04:13:43 AM
For WAP/WAP2/IMODE and for Mobile devices the ECL accept is always Modal, because these devices are to small. Spider have always access to the site, also in Modal mode.
Well...I don't even care to show this to wap/2/imode: the register button is absent and if they login the know they accessing a service that needs cookies, so there is no problem as far as I'm concerned. For everything else the cookies are disabled.
This is not, what the ECL say .. you have to accept the cookies BEFORE you can take any action ...
So Login and Register must locked until the visutor have accept the ECL ..
Quote from: feline on May 24, 2012, 06:31:21 PMQuote from: emanuele
Quote from: feline on May 24, 2012, 04:13:43 AM
7. For Mobile devices not applicable
Why?
The screen is to big, to many text, so you see nothing of the content ;)
It's a lot of text, and they probably won't read it (since it will take them too much effort to do so),
but they still have the right to accept or decline cookies. IMO.
Quote from: ssullivan on May 24, 2012, 08:25:39 PM
It's a lot of text, and they probably won't read it (since it will take them too much effort to do so), but they still have the right to accept or decline cookies. IMO.
Yes .. but WE have a modal ECL accept on mobile devices .. can you see on our site ;)
I must accept it's a really neat solution. Maybe only trigger the message when the user clicks "register" or "login", so they aren't bothered by the same message in their screens on each page?
However I feel you'd have already done that if that was the case, there must be something I'm missing.
EDIT: Okay. The advertising and stats cookies. That's the reason :D
Quote from: feline on May 24, 2012, 06:31:21 PM
This is not, what the ECL say .. you have to accept the cookies BEFORE you can take any action ...
So Login and Register must locked until the visutor have accept the ECL ..
That's not actually true. I'm not sure what the wording of the laws is for either the Danish or Latvian implementations of PECR. In the case of the UK's Data Privacy Act - which is known as the "Cookie Law" - a web site must not serve
any cookie unless and until the visitor has specifically agreed to accept cookies from that web site. However the practical implications for SMF-powered sites is that visitors should be required to accept cookies in order to browse or register - particularly in view of the fact that the site may serve third-party cookies.
With that in mind, I would suggest that you remove the non-modal method and have only a modal dialog with a link to the privacy page that explains what cookies are served and their purpose. That, in my view, would ensure full compliance with UK Law - and probably PECR generally.
Incidentally, I have identified another cookie used by Google Analytics: "__utmv" which is a session cookie and appears to track which pages on the web site the visitor reads.
There is one aspect that has not been addressed at all. Many browsers are configured by their users to send a "Do Not Track" code in the request header. It should be noted that "Do Not Track" is an American initiative and may well form the basis of Cookie Laws there.
"Do Not Track" can be tested server-side by the following code:
$DoNotTrackHeader = "DNT";
$DoNotTrackValue = "1";
$phpHeader = "HTTP_" . strtoupper(str_replace("-", "_", $DoNotTrackHeader));
if((array_key_exists($phpHeader, $_SERVER)) and ($_SERVER[$phpHeader] == $DoNotTrackValue))
{
// Do Not Track is enabled
}
else
{
// Do Not Track is not enabled
}
As the default browser setting is "off" (ie DNT is not set), the user has made a conscious decision that he doesn't want to be tracked as he goes from web site to web site. Currently trackers such as Google do not honour this setting but should we do so? I ask this because a user may have a perfectly valid complaint if he has already enabled "Do Not Track", has accepted SMF Cookies and discovers that Google Analytics (or tracking cookies) have been set.
It might therefore be wise to test for DNT and not include the GA code in Subs.php when serving the page if DNT is set.
Quote from: CircleDock on May 24, 2012, 11:45:55 PM
With that in mind, I would suggest that you remove the non-modal method and have only a modal dialog with a link to the privacy page that explains what cookies are served and their purpose. That, in my view, would ensure full compliance with UK Law - and probably PECR generally.
Basically, that's correct, but .. with WAP / IMODE is "not Modal" ECL not practical, as well as for mobile devices.
The screen is simply too small to even see something from the page content.
And I stick to it .. Login and registration can not be performed when ECL is not confirmed. This is simply unique and clear ..
Quote from: CircleDock on May 25, 2012, 01:36:35 AM
It might therefore be wise to test for DNT and not include the GA code in Subs.php when serving the page if DNT is set.
This we must give in the Site Admin hand I think ..
Or is there a way to detect if the site owner use GA ?
(i don't use GA :D )
@emanuele ...
Quote from: emanuele on May 24, 2012, 05:58:49 PM
Quote from: feline on May 24, 2012, 04:13:43 AM
and much more problems they ends in a session error
That was expected, if anyone would mind to report when and where I can fix it.
Here two points I found:
1. Subs.php
// Don't mark them as online more than every so often.
if (!empty($_SESSION['log_time']) && $_SESSION['log_time'] >= (time() - 8) && !$force)
return;
add before:
if(the_ecl_cookie_not_found)
return;
2. Security.php
// Is it in as $_POST['sc']?
if ($type == 'post')
{
$check = isset($_POST[$_SESSION['session_var']]) ? $_POST[$_SESSION['session_var']] : (empty($modSettings['strictSessionCheck']) && isset($_POST['sc']) ? $_POST['sc'] : null);
if ($check !== $sc)
$error = 'session_timeout';
}
add before:
if(the_ecl_cookie_not_found)
$error = 'session_verify_fail';
That suppressed a lot of undefined index errors
Quote from: feline on May 24, 2012, 06:31:21 PM
QuoteWell...I don't even care to show this to wap/2/imode: the register button is absent and if they login the know they accessing a service that needs cookies, so there is no problem as far as I'm concerned. For everything else the cookies are disabled.
This is not, what the ECL say .. you have to accept the cookies BEFORE you can take any action ...
So Login and Register must locked until the visutor have accept the ECL ..
Quote from: http://www.legislation.gov.uk/uksi/2003/2426/regulation/6/made6.—(1) Subject to paragraph (4), a person shall not use an electronic communications network to store information, or to gain access to information stored, in the terminal equipment of a subscriber or user unless the requirements of paragraph (2) are met.
(2) The requirements are that the subscriber or user of that terminal equipment—
(a) is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information; and
(b) is given the opportunity to refuse the storage of or access to that information.
(3) Where an electronic communications network is used by the same person to store or access information in the terminal equipment of a subscriber or user on more than one occasion, it is sufficient for the purposes of this regulation that the requirements of paragraph (2) are met in respect of the initial use.
(4) Paragraph (1) shall not apply to the technical storage of, or access to, information—
(a) for the sole purpose of carrying out or facilitating 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.
The UK implementation of the ECL says so.
The EU directive itself at the moment is not particularly relevant since it's each country's implementation the relevant piece of code.
Anyway: in order to login a user has to register, the moment he click the register button the privacy notice is shown (first block of the page, even before the registration agreement).
For already registered users the above paragraph applies.
Quote from: feline on May 25, 2012, 02:54:59 AM
@emanuele ...
[...]
That suppressed a lot of undefined index errors
Thanks, will check. ;D
As I thought changing the cookie value made the message show and users had to accept and log in again.
There is a problem as when I uploaded the new package SMF said it was an older version than the one on the server.
Also I forgot to set the default cookie time and can not seem to find where to change it now!
Quote from: bonzo on May 25, 2012, 02:35:52 PM
There is a problem as when I uploaded the new package SMF said it was an older version than the one on the server.
Strange...I changed the version from 0.1.0 to 0.1.1...
Quote from: bonzo on May 25, 2012, 02:35:52 PM
Also I forgot to set the default cookie time and can not seem to find where to change it now!
Which cookie time?
I thought there was a discussion about how long the new cookie would last?
Quote from: bonzo on May 25, 2012, 03:27:41 PM
I thought there was a discussion about how long the new cookie would last?
How often do you want to make your members re-accept cookies?
I would rather not have to get them to re-accept so the cookie would not expire or would be quite a while in the future.
This all seems vastly overcomplicated.
If I'm reading the ICO stuff correctly they are not really concerned about session cookies, ie those that expire when you leave the site and only help you recognise what you are doing whilst you are on the site. They are concerned about cookies that recognise who you are perhaps by returning password, might track you for advertising patterns, use statistics and other behaviour patterns.
So if you don't have advertising or other web tracking, you don't have a major problem. If you do need such tracking then you need to develop measures in conjunction with the advertiser or web tracking processes. However, if by default SMF is tracking guest activity, in terms of what they are looking at and such like, other than the server simply recognising there has been a visitor from an IP (anonymised because it doesn't know anything of the user's computer, etc), then if that tracking relies on cookies we really need SMF to remove that cookie system by default.
Returning registered users are surely covered by the SMF registration process that as standard says there will be a cookie. I don't see why there is a need for further measures or warnings and no need to renew or time that out.
So to keep things extremely simple:
We need to ensure all cookies for guests do not exists even if that means that the browser can't remember what has recently been viewed. It's the guest's problem if the site doesn't browse easily without an account and the "please register" template message could surely easily be amended to show the site doesn't work properly without an account.
If a guest'[s sessions cookie is provided to show what is being viewed then is must expire at the end of that website visit. It can't have any function other than to show the browser the threads / posts where someone has already been.
That's the problem. The definition of 'session cookie' combined with 'tracking behaviour' is complicated. SMF's session management allows admins to not only see how many 'users' there are, but also what actions they're carrying out at that time, and it verges on being under the definition of analytics.
I actually wrote to the ICO weeks ago, still not received an answer even after chasing up, asking for some clarification on this matter - we have a session cookie, it has some analytical uses, and it's hard to argue it as being 'strictly necessary' for the site to function.
The problem is that SMF creates a cookie straight away for sessions, which also gives you an idea of how many users there are - if it were not used for any other purpose, it wouldn't even be a difficult decision, you'd just yank out sessions for guests that aren't going through the log-in or registration processes.
However, since people do *really* like having that number of guests, even if it's really inaccurate, because 'it makes the site look busy', it's actually hard to deal with.
Also, there is a problem with the PHPSESSID cookie, when you log in 'forever' both the SMF and PHPSESSID cookies get set.
(And there's a bunch of other stuff in SMF that is tracked with cookies for guests, actually.)
So basically until the ICO tells us what we really need to do, rather than their wishy washy definitions, and hopefully provides proper solutions to this mess, can we just stick our head in the sand? Certainly that is going to be my approach to this mess since I can't see how most of the web can function without cookies.
I'm not running a site to make any money from it. I actually don't need to know if I'm getting guests (it's nice, but not important). Indeed my own site is primarily for a group of friends to converse and perhaps to widen that group of friends also interested in certain online gaming styles. I've no interest in even worrying my limited number of users about privacy policies and such things. Most of my sites users know me personally. In fact the only problems I've had is with those who don't really know me and see me as fair game for internet abuse when I've had to chastise.
Perhaps I could hide my site behind a htaccess type password. But that would antagonise both my legitimate users and defeat the idea of the site being friendly.
Like most users, even of small sites, that allow others to register and post the biggest issue is spammers. Perhaps the government, EU and all should look to properly deal with that rather than meddling with ill thought out policies that cause headaches to most legitimate users.
If this piece of red tape is to be applied then the simplest solution will be for the majority of the internet to be turned off. Certainly if there is no simple workable solution, and I receive any complaint I'll simply shut down as It isn't going to be worth the hassle.
For those that rely on advertising type income to provide useful sources of information the anti cookie laws are an even greater problem for the long term funding of the internet.
Sadly no, we can't. They're expecting us to make a judgement call as to whether we're compliant and wait for them to receive a complaint.
The government have no understanding of the consequences of their laws, and even with the best of intentions (which I can't argue with on this one, privacy protection is a worthwhile goal), the road is fraught with peril, and here's one of them.
Regarding funding of the internet, I actually don't think that's such a big deal. All it means is we avoid the behavioural tracking that there is currently, and frankly that sucks anyway. Right now, for example, most of the behavioural ads I see are for a thing called BuildMaster. But I only started getting those ads about two weeks after I actually went to the BuildMaster site to see what it was about. Meaning that instead of showing me things I actually might want to click on, it shows me things I already know about and have no intention of clicking on anyway.
The real money isn't even in AdSense, it's finding people who want to advertise on your site specifically, and that isn't likely to be particularly behaviourally orientated. (It's advertising to people who might actually want to buy, rather than advertising to people based on some creepy flawed magic.)
Quote from: movedgoalposts on May 25, 2012, 07:06:45 PM
This all seems vastly overcomplicated.
It is (unnecessarily so).
Quote
If I'm reading the ICO stuff correctly they are not really concerned about session cookies, ie those that expire when you leave the site and only help you recognise what you are doing whilst you are on the site. They are concerned about cookies that recognise who you are perhaps by returning password, might track you for advertising patterns, use statistics and other behaviour patterns.
Bingo! Unfortunately, the way the law is worded (i.e., what a judge and jury would have to follow),
all cookies have to be specifically approved -- no exemptions. Disclaimer: I have not read the law(s) myself, and am only passing on what others who claim to have read the law(s) have said. They seem consistent, but for all I know they could be full of aromatic fecal matter...
Quote from: movedgoalposts on May 25, 2012, 08:23:27 PM
So basically until the ICO tells us what we really need to do, rather than their wishy washy definitions, and hopefully provides proper solutions to this mess, can we just stick our head in the sand?
At your own risk (if you're subject to EU national laws). I'm not sure that the first case won't be laughed out of court, but you do run the risk of considerable expense and annoyance/irritation defending yourself.
Someone was annoyed enough by tracking cookies to push for this law, and they evidently have friends in low places (legislatures), so it might not be a pushover. Hey, maybe it's a secret cabal of typewriter manufacturers, the Post Offices, and brick-and-mortar stores. You think?
Quote
Perhaps I could hide my site behind a htaccess type password. But that would antagonise both my legitimate users and defeat the idea of the site being friendly.
You'd still have cookies, and thus still be technically illegal. It would be interesting if they could force you to grant Big Brother an ID so they can get in and see if you have any of those horrific cookies!
Quote
Like most users, even of small sites, that allow others to register and post the biggest issue is spammers. Perhaps the government, EU and all should look to properly deal with that rather than meddling with ill thought out policies that cause headaches to most legitimate users.
Fat chance. I'm sure spammers are quite wealthy and therefore can buy any legislation they need.
QuoteThey seem consistent, but for all I know they could be full of aromatic fecal matter...
This is the problem. The layman's advice provided by the ICO seems to imply that it is OK but the wording of the law seems to imply that it isn't unless it can be shown to be 'strictly necessary'. Given the wording of the rest of the law and the UK's Data Protection Act, I believe it would be defendable as 'strictly necessary' if there weren't the analytical capability attached to it.
QuoteAt your own risk (if you're subject to EU national laws). I'm not sure that the first case won't be laughed out of court, but you do run the risk of considerable expense and annoyance/irritation defending yourself.
Therein lies one of the problems, actually. While enshrined in law, it's not the police or the direct judicial system that's charged with dealing with it, it is a regulator who would take it through private courts, primarily.
A lot of the advertising mechanisms have evolved and unfortunately do seem to have a level of tracking. Equally the informed user, and that's the problem that they need to be informed, can reduce their exposure with their anti-malware software, and other opt out systems (http://www.networkadvertising.org/managing/opt_out.asp for example deals with many providers, but no doubt places it's own cookie on your browser). Unfortunately this regulation seems to have gone beyond just adverts and related tracking behaviour. Whilst I respect privacy, if someone does choose to visit a website why shouldn't the owner of that site be able to understand what the visitor is looking at as hopefully such information might improve the site and information provided as well as the basic justification for the site.
But this should still come down to reasonableness in the extent of the solution. Most websites that allow any interaction between user and the site are going to need some form of tracking. Did the EU really envisage that the evolved interactive internet was going to have to be reprogrammed?
We'll never know the full implications of this without some test case and decisions from a court of law. Some sense of proportionality and reasonableness must surely prevail especially as the ICO's views are themselves only their interpretation of the regulation. I maintain that if I am just running SMF based cookies that allow my site to function and if I really wanted to, to know some basic data on what and where my visitors went, that is not a problem. After all those people, even if they don't register, chose to visit my site. But if I'm, trying to pass that gleaned information on to others, that is a problem and should be stopped.
I'm using standard software, i.e. SMF not cutting edge stuff. I'm a basic user who is struggling to even get the website to have a theme that seems individual. Essentially I rely on stuff that other cleverer people have donated for use by numpties like me, as I haven't got the funds to line the pockets of people like Bill Gates pension fund. As a simple internet user I don't want or need complex barriers in my way before I can get at the useful stuff, hell If I encounter a flash type preview thing before entry to the main web site I've probably moved on to somewhere else.
Unless the standard, unmodded SMF is doing something to track users, or even the webmaster, by installation and use of the package, which allows the webmaster or SMF to sell on individual user data or activity, I really can't see a problem and why SMF should be modded. If we really must do this then it shouldn't be an add on mod, it needs a fundamental rewrite of the SMF code so that cookies never exist. In turn that needs a fundamental rewrite of most of the code that powers most of the internet's website.
It is suggested that the current SMF guest cookies go beyond the essential use of short term session this is what you have looked at use, and could provide analytical data giving too much activity information to the webmaster in the process. Surely the easiest solution is to prevent the cookie from collating such analytical information, that many of us have no idea how to access simply keeping things to the basic session cookie that tells the user where they have been, rather than the website.
If it is the concern over tracking that is the problem, then deal with the tracking and the consequences of the cookie, rather than causing problems by even placing cookie warnings in front of the user.
QuoteBut this should still come down to reasonableness in the extent of the solution. Most websites that allow any interaction between user and the site are going to need some form of tracking. Did the EU really envisage that the evolved interactive internet was going to have to be reprogrammed?
No, they didn't. Partly this is because they're lawmakers and not technical people. But they actually allowed for this with the 'strictly necessary' exception. If you can justify what you're doing as 'strictly necessary' it's allowed.
But the justification criteria for that is vague. Cookies that are used for analytics strictly for load balancing are considered 'probably acceptable' but for general analytics such as SMF's... not so much.
Thing is, I actually wrote to them, detailing all of this and waiting for some kind of guidance but none is forthcoming.
The standard, unmodded SMF does have facilities to track users over and above what would be necessary for logins to work, you can see how many 'users' there are and what they are doing (and by default that's visible to anyone on the site), and an IP address is tied to it.
The argument, then, is that it is over and above what is strictly necessary.
I outlined that it would be possible to remove even that cookie behaviour and session handling for guests and leave it strictly for registered users, but even that is problematic because the 'number of users' and 'what they're doing' is seen as 'required information' by some admins, meaning that no-one wants to actually remove it from the core, even though you'd get several benefits and very little practical down-sides.
(I'd do it but I really don't want the hassle attached to dealing with supporting the changes required.)
Of interest: XenForo, which is entirely operated out of the UK, appears to be doing nothing special regarding cookies at all.
After the mention of XenForo ( no idea what or who they are ) I thought I would visit Amazon.co.uk and I have deleted all my browser cookies. Amazon are setting 15 cookies when you land on their site and you can not tell me these are all essential to the running of the site!
Well, XenForo is particularly relevant, it's a paid forum software based primarily (entirely?) in the UK and they've not made any active moves towards it at all.
Ok that is interesting - I had looked around at other forum software and most of those were American based and they had made no mention of EU cookies either.
Even vBulletin seems to be doing nothing which would annoy me as I would be paying for it!
Well, XenForo is paid and there's been little more than a two page discussion on it which has amounted to 'it doesn't matter'. Maybe the law will turn out to be a farce but I don't see how it is anything other than irresponsible for software makers not to be concerned by it at this time.
The UK's ICO has issued an eleventh hour update to their guidance. There seems to be a new concept of implied consent to cookies from having visited a website.
For registered users of a forum, that implied consent would seem to exist simply using the standard SMF registration agreement that says there are cookies, especially if one were to add in a privacy policy page. That assumes of course that the registration agreement phrase
QuoteAlso note that the software places a cookie, a text file containing bits of information (such as your username and password), in your browser's cache. This is ONLY used to keep you logged in/out. The software does not collect or send any other form of information to your computer.
is correct, as discussions in this thread seems to suggest the cookie does a lot more?
I'm not so sure if implied consent is fully sufficient for guest visits but assuming a site is only adding it's own first party cookies, not third party cookies from other advertisement or analytic type sites, my reading is that again a simple amendment to the standard "welcome guest please login or register" phrase to say the site uses cookies might suffice, especially if the SMF cookie has only a limited life. That simple phrase amendment is probably a very easy template change. That just leaves the cookie session setting, and again (I dunno as a lot of this stuff is way over my head of the programming) is one simple file, at least according to the standard SMF agreement that's saying one cookie only is used.
QuoteThe UK's ICO has issued an eleventh hour update to their guidance. There seems to be a new concept of implied consent to cookies from having visited a website.
You mean, just as they realise this mess has just come into force? :P
QuoteFor registered users of a forum, that implied consent would seem to exist simply using the standard SMF registration agreement that says there are cookies, especially if one were to add in a privacy policy page. That assumes of course that the registration agreement phrase
The consent should actually list all the cookies by name and explain what they're doing.
Yes, changing the phrase is as simple as a template change, however it doesn't change the fact that the cookie is only supposed to be sent *if* and only *if* the user opts into it.
And it doesn't alter the fact that SMF has a bug wherein two cookies get used anyway for login even if one of them doesn't have any meaning or use.
Quote from: Arantor on May 26, 2012, 07:52:46 AM
Well, XenForo is particularly relevant, it's a paid forum software based primarily (entirely?) in the UK and they've not made any active moves towards it at all.
mybb is free but has plugin http://mattrogowski.co.uk/mybb/plugins/plugin/cookie-law
With all due respect, that's not the point.
The point is XenForo is a UK-based forum software, whereas MyBB isn't. And XenForo is not making any moves that I can see towards changing their situation.
Quote from: martec on May 26, 2012, 10:11:22 PM
Quote from: Arantor on May 26, 2012, 07:52:46 AM
Well, XenForo is particularly relevant, it's a paid forum software based primarily (entirely?) in the UK and they've not made any active moves towards it at all.
mybb is free but has plugin http://mattrogowski.co.uk/mybb/plugins/plugin/cookie-law
Well that plug-in doesn't work, I received 3 cookies just to read the cookie warning message. It also sets a cookie if you decline to accept them!
Given the 11th hour update allowing implied consent I have now just gone for the Google solution, a simple javascript and one line in the template which requires all first time visitors to agree to cookies or get diverted back to another site of your choice, with of course a link to the privacy page which defines what cookies are used.
Whilst it may not fully fill the letter of the law, I feel it is enough to fill the meaning of the directive.
http://code.google.com/p/cookie-warning/
Funnily enough that won't prevent search engines like Google getting to your site, and anyone who has JS disabled won't even see it anyway, but it's probably acceptable in the eyes of the law because you're making reasonable attempts to do so (though the cookie still gets *set* anyway)
That script helps nothing .. if it's shown, SMF have created cookies :D
Yes, as I said it does not fulfil the letter of the law, at least the UK law. But it does give the visitor an informed choice as to whether to continue on the site or not, which should meet the implied permission ruling.
Although it does not delete the cookies and allows the session ID to be set, the session ID will go when the browser is closed and the log in cookie is only for logged in members who have signed up knowing that cookies are set, that is something I did last year so I was never worried about setting cookies for logged in members.
I agree that if you have javascript turned off you will not see the note, but you can put a noscript tag in with information that you have disallowed javascript and if they proceed you are implying agreement to the setting of cookies. I have not done that yet and am still considering whether it is essential.
Hopefully at some point in the future SMF will become EU friendly and build the requirement into the core code.
Glad I am in the USA and do not have to worry about EU laws!
For now. The odds are that the US will implement something similar before long.
I doubt they will do anything until after the Presidential election. Then there will be such a debate it will be twisted into something that benefits Corporate interests. :o
Quote from: butchs on May 28, 2012, 10:29:14 AM
Then there will be such a debate it will be twisted into something that benefits Corporate interests.
No, the debate will be for public consumption. Behind the scenes, the corporate lobbyists will make sure to write it so that it benefits the Corporacracy. My prediction is that it will be sprinkled with onerous conditions (unrelated to tracking cookies and privacy) that make it impossible for the Little Guy to run a website, particular online retailing (in the name of preventing piracy, counterfeit goods, sales tax evasion, and the decline of brick and mortar stores). Forums/blogs will also be restricted to prevent hate speech and material unsuitable for children.
Sign me up for the Revolution. It's time to display the heads of the 1% on pikes.
Quote from: Arantor on May 28, 2012, 10:25:11 AM
For now. The odds are that the US will implement something similar before long.
I would expect that to codify the "Do Not Track" proposals into law. And that's probably a far more sensible way to tackle the issue since it would allow for essential cookies to be set but the site would be required to honour DNT with regard to tracking cookies.
Have they actually agreed on a single consistent DNT format yet? Last I saw, each of the browsers that implemented it did so differently...
Quote from: Arantor on May 28, 2012, 11:32:32 AM
Have they actually agreed on a single consistent DNT format yet? Last I saw, each of the browsers that implemented it did so differently...
Apparently yes. This is the recommended method to test if DNT is set (or not):
$DoNotTrackHeader = "DNT";
$DoNotTrackValue = "1";
$phpHeader = "HTTP_" . strtoupper(str_replace("-", "_", $DoNotTrackHeader));
if((array_key_exists($phpHeader, $_SERVER)) and ($_SERVER[$phpHeader] == $DoNotTrackValue))
{
// Do Not Track is enabled
}
else
{
// Do Not Track is not enabled
}
If you're referring to the DNT measures indicated by http://donottrack.us/ please note the information as per http://ie.microsoft.com/testdrive/Browser/DoNotTrack/Default.html though I note that Firefox 5 is mentioned rather than current versions nor is it clear what Chrome or Safari versions are relevant.
But IE8 and lower doesn't support it, Chrome current beta does not support it either, I can't find much on Opera, though IE9 and Firefox do.
Agreed - although Chrome does have related settings - "Do not allow sites to track me" but that doesn't conform to "DNT". Also you can set an option not to allow third-party cookies to be accepted which does appear to work.
And since Chrome is the second most popular browser (and has been known to be the most popular browser for days at a time), I would see this as a fairly major oversight...
There possibly a good reason for that: Google doesn't want its browser users to reject tracking ... ;)
Quote from: CircleDock on May 28, 2012, 09:45:22 PM
There possibly a good reason for that: Google doesn't want its browser users to reject tracking ... ;)
Speaking of DNT, how do you track clicks on adverts?
Thank you emanuele for the mod. :)
Hi,
I upgraded my forum to 2.0.2 and installed this mod which works fine for the most part - thanks for that!
My issue is as follows:
Click "privacy notice" link in banner at the top - this works fine.
At the bottom of this page you get the same options, to accept, or login / register.
When I click on the accept link at the bottom of the privacy notice I get the following:
QuoteNot Found
The requested URL /{ACCEPTCOOKIES} was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Any clue as to what might cause this?
If you accept the cookie via the link in the banner across the top, it works.
Cheers,
James
I think that I have possibly stumbled upon a slight issue.
Since installing this MOD, I am no longer able to login to my forum via the Tapatalk app from my iPhone.
My other users are experiencing the same issue also.
I have been in touch with Tapatalk support as I am able to view my forum in their app, just not able to participate in any way.
I noticed a small detail which I have told them and that I will share here.
If instead of logging in to the forum via in the Tapatalk app, I hit the 'View in Safari' button, Safari pops up with the page loaded and the header for accepting cookies is visible and functional, this should not be happening as I have already looked at my forum via Safari and already accepted the cookie, which has a 1 year expiry.
I am able to load my forum over and over using the iPhone's Safari app and it works fine because I have already accepted the cookie, the cookie shows in the Safari settings page.
It is only when I use the 'View in Safari' button inside the Tapatalk app that the cookie acceptance header keeps being displayed.
This leads me to believe that Tapatalk is not recognizing the set cookie and that this is causing the problem with me being able to login via Tapatalk.
Just wondered if anyone had any ideas about this?
Kind regards..,
MT
Sorry, I know that this is work in progress but I think I have found another small bug.
If I type my forums address in my browsers address bar, (currently using FF 12.0), my forum loads perfectly as I have already accepted the cookie and I have chosen to login forever, (6 years max I think).
Now if I click on a link to my forum from another webpage, it opens the forum as a guest, i.e. I am not logged in, and displays the cookie acceptance header.
I am able to open another tab in my browser, again manually typing in my forums address and it loads without showing the cookie acceptance header and I am logged in as normal.
Not knowing too much about this but I can see that it should be irrelevent as to where you come from to get to the forum, the cookie acceptance should not reappear after the cookie has been accepted until it expires, which in my personal case is 1 year.
It would seem that only when the forum address is typed into the address bar that the code searches for the ecl_auth cookie, if you navigated to the forum via a link on an external webpage, it does not seem to recognize that the ecl_auth is present.
Regards..,
MT
QuoteIt would seem that only when the forum address is typed into the address bar that the code searches for the ecl_auth cookie, if you navigated to the forum via a link on an external webpage, it does not seem to recognize that the ecl_auth is present.
If that were truly the case exactly as presented, I'd tell you that your browser is malfunctioning. But I suspect that's not the case.
What I'd guess is that if you arrive at your forum through a link, you're getting there via www.domain.com but when you're typing, you're getting there via domain.com. The two are subtly and importantly different - the cookies will not travel from www. to non-www. without changing the default configuration.
Quote from: Arantor on June 01, 2012, 07:29:06 AM
QuoteIt would seem that only when the forum address is typed into the address bar that the code searches for the ecl_auth cookie, if you navigated to the forum via a link on an external webpage, it does not seem to recognize that the ecl_auth is present.
If that were truly the case exactly as presented, I'd tell you that your browser is malfunctioning. But I suspect that's not the case.
What I'd guess is that if you arrive at your forum through a link, you're getting there via www.domain.com but when you're typing, you're getting there via domain.com. The two are subtly and importantly different - the cookies will not travel from www. to non-www. without changing the default configuration.
Thanks Arantor for replying.
I did think of that and had in fact place the link on this external page as www. and yes, when typing I exclude this prefix.
I went and changed the external link to minus the prefix and again clicked it only to be presented with my forum in guest 'mode' with the acceptance header in place.
However, since reading your reply, I have gone back and looked at this more closely and yes, even though I have placed this external link on another forum minus the www. prefix, when the link is moused over the status bar shows the link as the full url i.e. including the www.
So firstly I apologize for not spotting this sooner and secondly, I know it is just a minute issue in the whole scheme of things, is there a way that the cookie could be set to recognize +/- the www. prefix?
Regards..,
MT
OK, I think I have figured the www vs non-www issue.
I quick and dirty work around using .htaccess.
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.domain.co.uk
RewriteRule ^(.*)$ http://domain.co.uk/$1 [R=301,L]
I think that I am correct in understanding that this method will not hamper search engines that look for both iterations of the domain.
Regards..,
MT
Your SE listings for "www" will gradually disappear, to be replaced by non-www. That should actually help with search results if both www and non-www were being listed as separate sites.
To improve efficiency, make sure your applications are configured to generate only the non-www form. This avoids an extra round-trip between the browser and server to ask for service a second time, with the non-www form.
Quote from: MrPhil on June 01, 2012, 11:14:33 AM
... To improve efficiency, make sure your applications are configured to generate only the non-www form. This avoids an extra round-trip between the browser and server to ask for service a second time, with the non-www form.
Thanks for the tip, I will do. ;)
Quote from: MadTogger on June 01, 2012, 06:20:44 AM
I think that I have possibly stumbled upon a slight issue.
Since installing this MOD, I am no longer able to login to my forum via the Tapatalk app from my iPhone.
My other users are experiencing the same issue also.
I have been in touch with Tapatalk support as I am able to view my forum in their app, just not able to participate in any way.
I noticed a small detail which I have told them and that I will share here.
If instead of logging in to the forum via in the Tapatalk app, I hit the 'View in Safari' button, Safari pops up with the page loaded and the header for accepting cookies is visible and functional, this should not be happening as I have already looked at my forum via Safari and already accepted the cookie, which has a 1 year expiry.
I am able to load my forum over and over using the iPhone's Safari app and it works fine because I have already accepted the cookie, the cookie shows in the Safari settings page.
It is only when I use the 'View in Safari' button inside the Tapatalk app that the cookie acceptance header keeps being displayed.
This leads me to believe that Tapatalk is not recognizing the set cookie and that this is causing the problem with me being able to login via Tapatalk.
Just wondered if anyone had any ideas about this?
Kind regards..,
MT
OK, thanks to the wonderful support of Jayeley (http://support.tapatalk.com/members/jayeley.169/) on the Tapatalk Support Forum (http://support.tapatalk.com/), my issue with not being able to login via the Tapatalk iPhone app after installing this MOD has been cured.
Apparently there was a conflict function 'ecl_authorized_cookies' and it has now been added to the conflict list (mobiquo/config/config.txt) as:
mod_function = AnnoyUser, shd_init, shd_allowed_to, shd_load_language, TP_loadTheme, TPortal_init, shd_load_plugin_langfiles, ecl_authorized_cookiesand I can now you can login from the app.
Quote from: Insight on May 31, 2012, 04:22:28 PM
When I click on the accept link at the bottom of the privacy notice I get the following:
QuoteNot Found
The requested URL /{ACCEPTCOOKIES} was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Any clue as to what might cause this?
That's a bug.
Will take note and fix as soon as possible. ;)
In the meantime you can lok into Subs-EclWarning.php, find this code:
if (!$register)
$context['ecl_privacynotice'] .= '<br /><br />' . $txt['ecl_accept_how_to'];
and replace it with:
if (!$register)
$context['ecl_privacynotice'] .= '<br /><br />' . str_replace('{ACCEPTCOOKIES}', $scripturl . '?cookieaccept', $txt['ecl_accept_how_to']);
Quote from: JohnS on May 28, 2012, 08:53:37 AM
Given the 11th hour update allowing implied consent I have now just gone for the Google solution, a simple javascript and one line in the template which requires all first time visitors to agree to cookies or get diverted back to another site of your choice, with of course a link to the privacy page which defines what cookies are used.
Whilst it may not fully fill the letter of the law, I feel it is enough to fill the meaning of the directive.
http://code.google.com/p/cookie-warning/
Hi, which page did you add this text on as I am trying to do the same thing but cannot work out where to upload the file too and which template/php page to change. I'm using 1.3.9 so cannot use Emanuele's version as it's for 2.0 only :(
Thanks
Updated the package.
commit ba8bc1043a09e43a5c12d9b2f56bbd7bfb1012cd
Author: emanuele
Date: Fri Jun 8 2012
Few more checks to avoid errors in the log (Thanks feline for the reports)
Now if in wap/wap2/imode the accept/decline is used only when the cookie is actually needed (post or other similar actions)
Fixed a cache problem with parsing of the privacy notice
ETA: updated again with a couple of missing str_replace
Nice mod.
Install wend flawlessly.
When clicking on privacy notice nothing happens and the index page is getting reloaded.
In my errorlog i keep seeing this error:
8: Undefined index: ecl_privacy_notice_url
Pas filter toe: Toon alleen fouten van dit bestand
Bestand: xxxxxxxxxxxxx/forum/Sources/Subs-EclWarning.php
Regel: 111
TheVoiided.
mmm...okay...
Add this line:
$context['ecl_accept_cookies'] = $scripturl . '?' . http_build_query(array_merge($_GET, array('cookieaccept' => '1')));
after this block:
function ecl_warning_add_theme_elements ()
{
global $context, $txt, $modSettings, $scripturl;
that should fix it...SMF is right, action comes after theme...but not always...I'll put a kind of init function.
Added the line, thnx!
Now i'm able to click on accept cookie. Still i can't view the privacy notice. (only index.php refreshes)
And in my errorlog i still keep getting the same error (only now line 113, but its the same line as stated before).
Any idea what is going wrong?
Thevoiided.
Yep, of course...if one is not initialized it isn't the other too...
Add this line too, same location.
$context['ecl_privacy_notice_url'] = $scripturl . '?action=privacynotice' . (WIRELESS ? ';' . WIRELESS_PROTOCOL : '');
That did the trick! Great, thnx for your help.
Thevoiided.
Thank you for the report! ;D
Fixed the package in the first post.
it would seem the privacy notice link is incorrect it goes to action;=privacynotice instead of action=privacynotice or this could just be me. either way i believe its a easy fix.
edit: OR NOT some thing else seems to be causing all action= to be changed to action;= any ideas?
Unless you give us some hints on what you have installed I have no ideas. :P
Quote from: emanuele on June 17, 2012, 11:33:59 AM
Unless you give us some hints on what you have installed I have no ideas. :P
oh yeah :D
1. Tapatalk SMF 2.0 RC4/RC5/Final Plugin 3.0.2
3. SA Twitter 0.6 REV 30
4. EU cookie law 0.1.2
5. SimplePortal 2.3.5
6. SA GPlus 0.3 REV 9
7. SA Facebook 2.0 RC4 Rev58
8. Menu Editor Lite 1.0.5
9. Pretty URLs 1.0
Thats all :) it did however seem to start when i installed EU cookie law.
also
htaccess file
# PRETTYURLS MOD BEGINS
# Pretty URLs mod
# http://code.google.com/p/prettyurls/
# .htaccess file generated automatically on: June 16, 2012, 12:34
RewriteEngine on
RewriteBase /
# Rules for: actions
RewriteRule ^(activate|admin|ads|announce|attachapprove|buddy|calendar|clock)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(collapse|coppa|credits|deletemsg|display|dlattach|editpoll|editpoll2)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(emailuser|findmember|forum|portal|groups|help|helpadmin|httpBL)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(im|jseditor|jsmodify|jsoption|lock|lockvoting|login|login2)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(logout|markasread|mergetopics|mlist|moderate|modifycat|modifykarma|movetopic)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(movetopic2|notify|notifyboard|openidreturn|pm|post|post2|printpage)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(profile|quotefast|quickmod|quickmod2|recent|register|register2|reminder)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(removepoll|removetopic2|reporttm|requestmembers|restoretopic|search|search2|sendtopic)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(smstats|suggest|spellcheck|splittopics|stats|sticky|theme|trackip)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(about:mozilla|about:unknown|unread|unreadreplies|verificationcode|viewprofile|vote|viewquery)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(viewsmfile|who|\.xml|xmlhttp)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(projects|p2map|fcbrowser|youtube)/?$ ./index.php?pretty;page=$1 [L,QSA]
# Rules for: boards
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/?$ ./index.php?pretty;board=$1.0 [L,QSA]
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/([0-9]*)/?$ ./index.php?pretty;board=$1.$2 [L,QSA]
# Rules for: topics
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/([-_!~*'()$a-zA-Z0-9]+)/?$ ./index.php?pretty;board=$1;topic=$2.0 [L,QSA]
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/([-_!~*'()$a-zA-Z0-9]+)/([0-9]*|msg[0-9]*|new)/?$ ./index.php?pretty;board=$1;topic=$2.$3 [L,QSA]
# PRETTYURLS MOD ENDS
and url
http://forgottencoders.co.uk
and of course the version is 2.0.2
thanks
EDIT: how do i change the z-index on the ecl notice? i cant find it in style.css or the index template.
Honestly no idea...
Try switch off pretty urls and see if it is fixed.
Quote from: emanuele on June 17, 2012, 12:18:32 PM
Honestly no idea...
Try switch off pretty urls and see if it is fixed.
ok will try that then. thanks.
what about changing the z-index?
ok yep so its defo prettyurls. any ideas how to fix it though? also once i accept cookies (need to manually remove the ; from the url) it then works fine so i guess its conflicting with this mod for some reason. any ideas on a fix?
ok so apparently just disablind prettyurls and re-enabling it seems to have fixed it. just my final issue now.
Where is the css for this saved?
EDIT: Found it (sources\Subs-EclWarning.php)
<style>
#ecl_notification
{
color: #f96f00;
background-color: white;
border-bottom: solid 3px #f96f00;
text-align: center;
font-size: 12pt;
padding: 8px;
width: 100%;
line-height: 25px;
position: fixed;
top: 0;
left: 0;
padding-left: 0;
padding-right: 0;
}
</style>
In the middle of Subs-EclWarning.php :)
Quote from: emanuele on June 17, 2012, 01:34:16 PM
In the middle of Subs-EclWarning.php :)
yep as stated above found it :D.
heres what i have done
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fi.fcss.in%2F002.jpg&hash=f631932146e69d61d81daa00f7aba03faabb8876)
EDIT: ok now i am more confused. the action; bug thing has just came back :( no idea why. still think it is prettyurls though
It is however only doing it when cookies have not been accepted. once they are accepted it all works fine. except for having to manually type the cookie acceptance url in the address bar.
Okay, try this:
$context['ecl_accept_cookies'] = $scripturl . '?' . http_build_query(array_merge($_GET, array('cookieaccept' => '1')));
$context['ecl_accept_cookies'] = $scripturl . '?' . http_build_query(array_merge($_GET, array('cookieaccept' => '1')),null, ';');
The line is at the end of the file.
Quote from: emanuele on June 17, 2012, 02:58:41 PM
Okay, try this:
$context['ecl_accept_cookies'] = $scripturl . '?' . http_build_query(array_merge($_GET, array('cookieaccept' => '1')));
$context['ecl_accept_cookies'] = $scripturl . '?' . http_build_query(array_merge($_GET, array('cookieaccept' => '1')),null, ';');
The line is at the end of the file.
i so hope this works :D i have tried everything i can think of from code edits, settings, htaccess and nothing worked. just came on here to say i give up :( but then read your latest post :)
-------------------------------------------------------
DAM it didnt work :( this is the url i am getting http://forgottencoders.co.uk/index.php?cookieaccept;=1 and when clicked it goes to a blank page (im guessing a 404 page?) just to confirm shouldn't the url be http://forgottencoders.co.uk/index.php?cookieaccept=1 (without the ;)? oh and also the same happens for index.php?action;=login and index.php?action;=login2 and more.
Since it is happening with all the URLs I'd suggest you to ask in the pretty URL topic support...the author should know better what the problem could be. ;)
Quote from: emanuele on June 17, 2012, 04:24:43 PM
Since it is happening with all the URLs I'd suggest you to ask in the pretty URL topic support...the author should know better what the problem could be. ;)
um ok thanks. that thread has 335 pages :o
I was thinking of a easier solution, well here is my idea hope you like it.
<?php
ob_start('callback');
setcookie('test', '123', time()+3600);
echo '123';
ob_end_flush();
function callback($buffer) {
header_remove('Set-Cookie');
return $buffer;
}
?>
Just a simple test script which removes the cookie from the header before sending. Instead of invading all mods and locations in SMF where a cookie is set it might just be simpler just removing all the headers that were set. What do you think?
I think I already tried doing that before and finding that it didn't always work to remove the PHPSESSID cookie.
It looks like you have to call it the number of cookies that are set. So if two cookies are set I must call the function twice. Figured it would be recursive. Well updated with compatibility for older PHP.
<?php
ob_start('callback');
setcookie('test', '123', time()+3600);
echo '123';
ob_end_flush();
function callback($buffer) {
if (function_exists('header_remove')) {
header_remove('Set-Cookie');
} else {
header('Set-Cookie:');
}
return $buffer;
}
?>
Did you try using it to remove the PHPSESSID cookie, though?
That's the only cookie set until logging in and it doesn't behave the same way!
Quote from: Arantor on June 20, 2012, 01:49:00 PM
Did you try using it to remove the PHPSESSID cookie, though?
That's the only cookie set until logging in and it doesn't behave the same way!
Just tried and both methods remove the PHPSESSID cookie, header and header_remove.
Odd, I couldn't get either to remove the PHPSESSID when I tried it ages ago.
You know they are always changing how things work in PHP, I have version 5.3.6.
In any matter the functions are not recursive meaning they will only remove one cookie per call. So we must make it recursive to remove all the cookies. What do you think about headers_list function to do this?
*shrug* Whatever works, I guess.
Here this one should be recursive. Tested and works on my machine, hopefully works on more.
<?php
ob_start('callback');
session_start();
$_SESSION['test'] = '123';
setcookie('test', '123', time()+3600);
echo '123';
ob_end_flush();
function callback($buffer) {
if (function_exists('header_remove')) {
foreach(headers_list() as $header) {if(strstr($header, 'Set-Cookie:')) {header_remove('Set-Cookie');}}
} else {
foreach(headers_list() as $header) {if(strstr($header, 'Set-Cookie:')) {header('Set-Cookie:');}}
}
return $buffer;
}
?>
That's cool! :D
Anyway edits are necessary anyway because SMF (and most likely mods) assumes that session data are present in several places and so unless we want to live with an error log full of errors we need to check where the session is checked without taking care of assessing if present or not...I'm wondering if all these errors should be considered bugs...
Hi,
just a quick question.
If my current members have accepted the cookie policy and I then install a MOD which creates a new cookie, how do I allow them to re-opt in if you know what I mean.
At the moment I have added the new cookie to the 'ecl_privacynotice.txt' file, which will display on new registrations and I send out a newsletter explaining the new cookie addition to my current members.
I suppose what I am wondering is if there is a way to re-initialise the acceptance header when new cookies are added.
Kind regards..,
MT
That's becoming complicated.
The only way (for the current implementation) I can think of to workaround this is to change the name of the "acceptance" cookie:
elseif (isset($_COOKIE['ecl_auth']) || isset($_COOKIE[$cookiename]))
$storeCookies = true;
elseif (isset($_GET['cookieaccept']) || $override_accept)
{
setcookie('ecl_auth', 1, 0, '/');
'ecl_auth' in the 1st and last line here.
That said, of course if a user is already logged in the bar will not be presented. Again you could workaround this limitation change also SMF's cookie name, that should "logout" all your users and force them to accept again everything.
Alternatively you could serialise the names of all the cookies being accepted and store that data in the authorisation cookie. You'd also need to alter the "ecl_authorized_cookies" function to additionally read that data and compare the cookie names with those found in the $_COOKIE array; if an extra cookie is found (ie the one you just added) then the function should delete the authorisation cookie (by expiring it) and ecl_authorized_cookies() should return false.
This replacement function and the two additional ones that follow should do the trick:
function ecl_authorized_cookies($override_accept = false)
{
global $cookiename, $modSettings;
static $storeCookies;
if (isset($storeCookies) && !$override_accept)
return $storeCookies;
// Have any additional cookies been added?
if (!ecl_check_cookies())
return false;
if (isset($_SERVER['HTTP_X_MOZ']) && $_SERVER['HTTP_X_MOZ'] == 'prefetch' &&
isset($_GET['cookieaccept']))
$storeCookies = false;
elseif (isset($_COOKIE['ecl_auth'])) // || isset($_COOKIE[$cookiename]))
$storeCookies = true;
elseif (isset($_GET['cookieaccept']))
{
ecl_setcookie(); // Set a 6 year cookie, the same as a "Forever" cookie in SMF
$storeCookies = true;
} else
$storeCookies = false;
if ((isset($_COOKIE[$cookiename])) && (!isset($_COOKIE['ecl_auth'])) && $storeCookies)
[color=red]ecl_setcookie(); // Set a 6 year cookie, the same as a "Forever" cookie in SMF[/color]
if (!$storeCookies && !empty($modSettings['ecl_strict_interpretation']))
$modSettings['registration_method'] = 4;
return $storeCookies;
}
// Checks if any additional cookies were set by the site since the last
// time the visitor was asked to accept cookies. If any were added, expire
// our cookie and return false (to signal that re-acceptance should be sought).
function ecl_check_cookies()
{
$parts = explode('=', $_COOKIE['ecl_auth']);
$accepted_cookies = explode('|', $parts[1]);
// If our cookie has already been expired ...
if (isempty($accepted_cookies))
return false;
//
$noExtraFound = true;
foreach($_COOKIES as $cookie) {
$_parts = explode('=', $cookie);
if (!in_array($_parts[0], $accepted_cookies)) {
$noExtraFound = false;
break;
}
}
if ($noExtraFound == false)
setcookie('ecl_auth','', time()-3600, '/');
return $extraFound;
}
// Set our authorisation cookie to include all the names of the cookies
// currently set for this domain.
function ecl_setcookie()
{
$cookies = 'ecl_auth|'; // Must include this!
foreach($_COOKIES as $cookie) {
$part = explode('=', $cookie);
$cookies .= $part[0] . '|';
}
setcookie('ecl_auth', $cookies, time()+189345600, '/');
}
Caveat: this code should work but it is untested!
well my issue with prettyURLs and this still stands. no response from the prettyURL thread.
I'm ignoring this "law". If/when I ever get something in the mail from a lawyer, I'll worry about it. Until then, they all can pound sand for all I care.
While I fully understand the sentiments behind those who 'don't care' about this law, there is one thing that does annoy the *** out of me about people who seem to share that line: and that's that they're not willing to take some responsibility for the privacy of their users.
Whether you have to do this or not, is it not a good idea to say up front that you have cookies and what the cookies do? Im particular, if you use Analytics, do you not think it prudent to tell your users that you are using a system known for tracking users *across sites* that might risk their privacy?
I am not yet compliant on any of my sites, however I am taking steps towards compliance, and I'm actively looking at taking out the cookies I have where not actually required, because that doesn't just make my life easier, I'm taking responsibility about what my sites do to/for my users.
/me is not saying anyone in particular is or is not following this attitude, but the two have shown to go hand in hand.
I wonder how many people would be so 'rebellious' if they weren't using Analytics or Adsense, the two biggest reasons why this came into effect.
Oh, and you won't get anything from a lawyer on it. If your site is the victim of a complaint, it will not be from a lawyer but the governing body in your region, in the UK that is the Information Commissioner's Office.
Quote from: Arantor on June 25, 2012, 04:47:58 PM
Whether you have to do this or not, is it not a good idea to say up front that you have cookies and what the cookies do? Im particular, if you use Analytics, do you not think it prudent to tell your users that you are using a system known for tracking users *across sites* that might risk their privacy?
I think it's good, right and IMPORTANT to tell our users which cookies we use and for what they are used.
Not only because it is a law, but also because it is fairly easy ...
My site is a private invite only site... 8)
;)
QuoteMy site is a private invite only site...
In which case the registration agreement covers you.
QuoteI think it's good, right and IMPORTANT to tell our users which cookies we use and for what they are used.
Not only because it is a law, but also because it is fairly easy ...
You have no idea how few people actually agree with that sentiment, however :/
I am trying this mod on a test forum to see if it blocks all cookies.
It does block most cookies, but not all!
Embedded pictures from imageshack, photobucket and probably other sites try to set a cookie.
Embedded video's from youtube or vimeo also try to set cookies.
Is there any way to fix this?
Quote from: Johanvd on August 09, 2012, 04:46:33 PM
I am trying this mod on a test forum to see if it blocks all cookies.
It does block most cookies, but not all!
Embedded pictures from imageshack, photobucket and probably other sites try to set a cookie.
Embedded video's from youtube or vimeo also try to set cookies.
Is there any way to fix this?
The modification is designed to prevent any of your SMF Forum's cookies being set. It is not possible to prevent third-party cookies being set since these arise out of transactions between your browser and the third-party sites concerned.
The modification is not designed to prevent third-party cookies being set, it's not possible to do that anyway.
Quote from: CircleDock on August 10, 2012, 12:07:57 AM
The modification is not designed to prevent third-party cookies being set, it's not possible to do that anyway.
It is possible by not showing those 3rd party elements to the guests (i.e. hide imageshack images to guests).
The function provided by the mod can be used to decide what can be presented to guests and what cannot, though it's a "problem" of the admin search where these things are presented.
Maybe a future release of the Mod could include the auto-stripping of all external URLs from pages prior to serving, if cookies haven't been accepted ;)
Thanks for your answers :)
So, is it possible to hide all images that are placed with the [img]...[/img] tags?
The problem is that the Dutch cookie law does not allow sites to place any cookies without a visitor's permission. It is required that the visitor gives his/her permission by clicking on a button or a link. Simply informing a visitor that you will place cookies without giving the option to decline is not allowed.
The only exceptions are cookies that are essential for the site to function (session cookies, log in cookies, etc.)
Quote from: CircleDock on August 10, 2012, 04:06:58 AM
Maybe a future release of the Mod could include the auto-stripping of all external URLs from pages prior to serving, if cookies haven't been accepted ;)
and images. Even legit images can serve cookies.
This is how you comply with the EU laws: Interactive guide to 25th May and what it means for you (http://www.davidnaylor.co.uk/eu-cookies-directive-interactive-guide-to-25th-may-and-what-it-means-for-you.html)
PITA...
I clicked cancel. And I clicked cancel again. And again. Yet again. Once more. And... does it ever end? :P
You should read the dialogues. Most of them are hilarious. ;)
Too long to be read... :P
Do, we need this mod/cookie law, if it for a clan site?
I've just been scared into installing this mod :P When I click on Privacy Notice in the warning nothing happens. I mean, the page refreshes but it all looks the same and I don't see any text.
Secondly, does somebody have a privacy notice I can use as I've probably less idea about writing one than Emanuele had in the OP :)
You can get some free legal outline documents at http://www.seqlegal.com/free-legal-documents though you do have to leave a credit to them and a linkback. Though it will give you some idea of what these polices should contain. If you are in Europe you need more than just the Privacy notice.
Thank you, I was hoping for one that somebody has already tailored to SMF. I just have a simple SMF forum, no advertising, no analytics or anything complex, but while I could copy and paste from the internet about "We use cookies and as part of the directive,.... cookies are pieces of code, blah, blah, blah, I would then need to customise the specifics for my forum. I don't know how to go about describing the cookies we are using as part of the standard SMF install so I was hoping somebody had already written one :)
I have one at http://cumbriafhs.com/cgi-bin/site/main.pl?action=privacypolicy which applies to my site , not just the forum, though I only use cookies in the forum. This is taken from one of those free legal ones and defines the cookies used.
I run a private invite only site with members in the United States only. Is there any cause of concern over this ridiculous EU law?
Hey. It will be updated mod?
Quote from: MadTogger on June 03, 2012, 04:35:35 AM
OK, thanks to the wonderful support of Jayeley (http://support.tapatalk.com/members/jayeley.169/) on the Tapatalk Support Forum (http://support.tapatalk.com/), my issue with not being able to login via the Tapatalk iPhone app after installing this MOD has been cured.
Apparently there was a conflict function 'ecl_authorized_cookies' and it has now been added to the conflict list (mobiquo/config/config.txt) as:
mod_function = AnnoyUser, shd_init, shd_allowed_to, shd_load_language, TP_loadTheme, TPortal_init, shd_load_plugin_langfiles, ecl_authorized_cookies
and I can now you can login from the app.
I just realised I'm having the Tapatalk issue too and I've checked the mobiquo config file and the function ecl_authorized_cookies is indeed there on the conflict list.
The full error I'm getting on my mobile is:
QuoteServer error occurred: 'Cannot redeclare ecl_authorized_cookies() (previously declared in home/chalkcat/public_html/mobiquo/env_setting.php(12) : eval()'d code:1) (Subs-EclWarning.php:141)'
Any ideas on this? One of my members only accesses the forum through Tapatalk.
disable template eval in server settings and post the real error after that ;)
It's exactly the same with eval disabled. The error I posted is the one my mobile shows me within the iPhone Tapatalk app.
Apparently Tapatalk adds some functions to a sort of "compatibility list" in order to...dunno exactly.
Though, what happens is that this list is evaluated *before* the pre_include hook and that means the functions are not yet loaded when the "compatibility list" is evaluated...that of course means a dummy function is created and an error is raised the moment the *real* function is included...meh.
In Load.php you should have:
if(defined('IN_MOBIQUO'))
{
// tapatalk add
global $mobiquo_config;
if(isset($mobiquo_config['conflict_mod']) && !empty($mobiquo_config['conflict_mod'])) {
foreach($mobiquo_config['conflict_mod'] as $conflict_mod) {
if (isset($modSettings[$conflict_mod])) {
$modSettings[$conflict_mod] = 0;
}
}
}
// end
}
// Call pre load integration functions.
call_integration_hook('integrate_pre_load');
Change it to:
// Call pre load integration functions.
call_integration_hook('integrate_pre_load');
if(defined('IN_MOBIQUO'))
{
// tapatalk add
global $mobiquo_config;
if(isset($mobiquo_config['conflict_mod']) && !empty($mobiquo_config['conflict_mod'])) {
foreach($mobiquo_config['conflict_mod'] as $conflict_mod) {
if (isset($modSettings[$conflict_mod])) {
$modSettings[$conflict_mod] = 0;
}
}
}
// end
}
Thanks Emanuele. Oddly, I didn't have any of that Tapatalk stuff in my Load.php, so I just added the "replace" part of your code over:
// Call pre load integration functions.
call_integration_hook('integrate_pre_load');
I still get the same error on my phone though, with the difference that the 141 has now changed to 140 :-\
I downloaded the 3.2.3 version from the mod site, don't know what version you have installed...
Mmmm ok, mine is older than that. However, Illori suggested changing the name of the ecl_authorized_cookies function in all instances and it worked. I can now use Tapatalk without problem :)
I will have a look at the newer version of Tapatalk mod though and see what I'm missing ;) Thanks for your help :)
Anyway you should report that issue to the tapatalk mod author.
Will do, thanks Ema :)
I'm giving this mod a try on my site http://guitaristguild.com
Looking at my users online though, it seems to have stopped my traffic completely. Usually if I tweeted a post, or link to my site I would get about 30 or more guests, bots, whatever showing in my users online. Now I get nothing. Have I missed a post about this problem somewhere?
Obviously.
Tracking of users relies on cookies, if you can't use cookies tracking is in fact disabled.
Quote from: emanuele on June 11, 2013, 04:33:17 AM
Obviously.
Tracking of users relies on cookies, if you can't use cookies tracking is in fact disabled.
Thanks. It's strange not seeing anyone in the users online list lol.. I've removed the mod for now, as it stopped my members using tapatalk. This EU cookie law is a right PITA, isn't it.
Quote from: lurkalot on June 11, 2013, 01:02:56 PM
Thanks. It's strange not seeing anyone in the users online list lol.. I've removed the mod for now, as it stopped my members using tapatalk. This EU cookie law is a right PITA, isn't it.
I had the same problem with Tapatalk, fixed now ;)
Quote from: ChalkCat on May 19, 2013, 09:22:06 AM
Mmmm ok, mine is older than that. However, Illori suggested changing the name of the ecl_authorized_cookies function in all instances and it worked. I can now use Tapatalk without problem :)
Quote from: ChalkCat on June 11, 2013, 01:07:05 PM
I had the same problem with Tapatalk, fixed now ;)
Quote from: ChalkCat on May 19, 2013, 09:22:06 AM
Mmmm ok, mine is older than that. However, Illori suggested changing the name of the ecl_authorized_cookies function in all instances and it worked. I can now use Tapatalk without problem :)
Thanks, I did see that post, but I haven't a clue where to look for those edits. I'm still using tapatalk 2_3.4.0 (because it works) Care to talk me through it? A step by step idiots guide.
/me is using Tapatalk 3.6.0
I just did a simple find/replace on all the files installed by this mod to replace every instance of ecl_authorized_cookies with ec_authorized_cookies. It may not be the best solution but it worked for me. Though first you could try removing the entry from the mobiquo conflicts file referred to a few posts back, just in case.
Quote from: ChalkCat on June 11, 2013, 04:59:36 PM
I just did a simple find/replace on all the files installed by this mod to replace every instance of ecl_authorized_cookies with ec_authorized_cookies. It may not be the best solution but it worked for me. Though first you could try removing the entry from the mobiquo conflicts file referred to a few posts back, just in case.
Thanks for the help, I'll have a go at that later.
I can not find out in which file(s) I should rename this "ecl_authorized_cookies"?
I don't remember exactly, one of the configuration files in mobiquo I think.
But, TBH, I don't understand why you are asking here to fix an issue with the tapatalk mod and not asking the tapatalk authors to fix their broken code...
Does this work with 2.0.7?
yes and 2.0.8 :)