GNOME Bugzilla – Bug 722780
EU Law: Need Cookie Policy
Last modified: 2014-02-06 21:10:16 UTC
We do not have one. It is against the EU laws to store a cookie on someones browser in European states without getting their consent. As far as I understand things the consent does not have to be explicit. Implicit consent would rely on the presence of a clear privacy/cookie policy though and there is not one. The maximum fine for this is £500,000 if storing cookies on uk sites. The laws in Europe vary state by state. Check for some information on this on http://www.aboutcookies.org or via google.
I would be happy to file some patches for website but not sure what module to get the source from.
www.gnome.org uses Wordpress, https://git.gnome.org/browse/gnome-web-www/ contains the theme and translations. Maybe you could do some research on wordpress plugins that would be appropriate to use, from a quick search I found http://wordpress.org/plugins/cookie-law-info/, you could test it and propose CSS changes to match our website.
I am already familiar with this plugin http://wordpress.org/plugins/uk-cookie-consent/ which is good for explicit consent but misleading if it is not configured properly. If we want to use it we would need to hack it because we are using a few cookies (or this is what my browser says anyway) By default that plugin will only turn off google analytics (not universal). Other cookies are going to stay active unless the plugin is hacked to switch them off too. Explicit consent is a 'nice to have' but it is not a legal requirement (as far as I understand things - I am not a lawyer) Having a quick look at http://wordpress.org/plugins/cookie-law-info/ it is just a notification which then links to a site cookie policy and therefore does not turn off cookies (hence the 'implicit consent' description) What is vital is that the privacy policy exists in the first place. Any cookie consent plugin whether it asks for implicit or explicit consent cannot do anything without that cookie policy being present (i.e. n order to obtain the visitors explicit consent OR implicit consent, the user has to have been given an opportunity to read the cookie policy, which of course, must exist). The cookie policy must state, clearly, each cookie set and explain what the cookie does, how it is used and it is nice if the visitor is given an indication of the time scale the cookie will be active. I would suggest using a single cookie policy for all subdomains if there are not differences but if there are additional trackers on the subdomains perhaps lay this out differently. I can identify the cookies being used and how long they last but having not been involved in coding them into the site in the first place I am not sure how they are being used or what they are used for myself. If a few of the site developers want to collaborate in writing the policy out then I am happy to do this. Once this is done then the question is whether or not you want to obtain the users consent by providing a link to the policy on ever page of the site or whether or not you think a consent pop up or plugin instead. Does this make sense?
For the regular www.gnome.org wordpress do we actually store any cookies? If so, can we make sure to not do that somehow?
(In reply to comment #4) > For the regular www.gnome.org wordpress do we actually store any cookies? Yes, as follows: PHPSESSID (session) _pk_id.1.fc48 (2 years) _pk_ref.1.fc48 (6 months) _pk_ses.1.fc48 (30 mins) > If so, can we make sure to not do that somehow? There is a way yes, but I am not sure the extent of it all over the domains so it is hard to tell what the right approach would be for them yet. However, I imagine the four found on www.gnome.org are probably just coming from one call to https://webstats.gnome.org/piwik.js if so, the way to stop this storing a cookie would be to only call if if the user has clicked to agree (i.e. explicit consent). The api documents are http://developer.piwik.org/api-reference so it depends how you want to go about it really.
Quick check of the subdomains: Bugzilla uses 9 logged in (One of them is for git bz, I think) and 2 otherwise. Planet uses 2 (Same piwik ones it seems) Git (surprisingly) uses none The wiki uses none unless logged in, then it uses one. I'll double check bugzilla after logging out, clearing cookies. Apart from the bugzilla logged in ones, which I am not sure about without having poked about, they all seem to be using the piwik api so that means it could be worth using a single policy for the whole site.
Or as you suggested: One way to deal with it would get rid of tracking altogether and just use only login cookies on the domains which need it. The downside of doing this would be you would not have any way to tell how people are using the site and its subdomains - or where they are coming from.
Seems it's now possible to disable cookies in piwik, so I'll look into doing that. http://dev.piwik.org/trac/ticket/2772
according to them it's this one line before the trackPageView() call _paq.push(['disableCookies']); http://piwik.org/faq/general/#faq_146 However, if you are going for explicit consent rather than just getting rid of them altogether, the visitor will have to have been given a chance to read about the cookies somewhere I believe. From the looks of the thread it might also be worth looking into the 2 year old cookie to see if that can have a shorter lifetime as it seems this might be compliant, as well, though yet to check reliable sources to verify that one.
Browsing I just found this page with a cc template privacy policy for its users! This could be adapted to make a policy for gnome if you think that is a good idea? http://piwik.org/privacy-policy/ . One thing, having checked the list, I could not find PHPSESSID. Is there a way to verify this is a piwik cookie in case it's something else?
(In reply to comment #9) > http://piwik.org/faq/general/#faq_146 > > However, if you are going for explicit consent rather than just getting rid of > them altogether, the visitor will have to have been given a chance to read > about the cookies somewhere I believe. I'm not sure I'm following. I was aiming at getting rid of them altogether. (as I really want to avoid a banner if possible) Is this not technically possible?
Well. Piwik is spying technology. It relies on things like cookies to be present. Why not getting rid of Piwik altogether? Spying on our users is not a nice thing to do and from what I know, which is, admittedly, little, it only gave us an insight once (that many visitors use Internet Explorer). And it's not clear to me whether we made use of that insight. If there is a proper use of that technology, it'd be good if the case for it is made more often and more visibly.
(In reply to comment #11) > (In reply to comment #9) > > > http://piwik.org/faq/general/#faq_146 > > > > However, if you are going for explicit consent rather than just getting rid of > > them altogether, the visitor will have to have been given a chance to read > > about the cookies somewhere I believe. > > > I'm not sure I'm following. I was aiming at getting rid of them altogether. (as > I really want to avoid a banner if possible) > Is this not technically possible? This is the coding wise easiest option I think. All you need to do is remove the code which is currently calling it. As it is not being used to do anything but track. You should be free to get rid of it. I just figured if the service had been bought, then it had already been agreed hence my suggestions. Just remove the call to https://webstats.gnome.org/piwik.js and then we can double check there's no left overs I guess. I would check for myself but I have no way to look at the source code of the site so all I know is that the call is in the footer <script src="https://webstats.gnome.org/piwik.js" type="text/javascript"></script> if you poke abouut in the footer.php file but still cannot see anything obvious in there then maybe double check in case it is being called as php include to a separate php script where the tracker function is located. It is most likely to be found in the footer of the theme folder in wp-content/themes/footer.php with something like <?php include_once "piwik.php"; ?> in that case. I am not sure maybe someone has done something else, but that is a good place to start. If it is an include, then piwik.php is probably going to be located in the main directory so you could whip it out there as well as removing the call to it. (In reply to comment #12) > Well. Piwik is spying technology. It relies on things like cookies to be > present. > Why not getting rid of Piwik altogether? Spying on our users is not a nice > thing to do and from what I know, which is, admittedly, little, it only gave us > an insight once (that many visitors use Internet Explorer). And it's not clear > to me whether we made use of that insight. If there is a proper use of that > technology, it'd be good if the case for it is made more often and more > visibly. This is quite well said. It is reassuring to find that people care about this kind of stuff, actually. It makes sense to use tracking if you are trying to make money from the site via adverts or use the adverts to drive your google ranking up I think, but even then you could do this without setting cookies at all and or by removing 'personally identifiable information before sending it on, which I think is how startpage manages to use google search without sharing data with them or storing it themselves. It is hard to check this with start page's licencing as I do not think the code is accessible anywhere. Page view tracking could help the outreach efforts. I think it could be easy for the more experienced developers to take knowledge of the workings of GNOME for granted in newcomers unless there is a concious effort to check the behaviour of visitors of the site with particular regard for how newcomers search and use the site. If there are a lot of 'how to install bla,'how to bla' etc before people drop off then this might be an indication that there is a commonly sought bit of information which is currently lacking or incomplete. That said, if nobody is actively analysing the data the tracking is not being handled in a transparent (i.e. visible) way either, then this then there is not a lot to be gained, it seems. It is hard to judge from the outside though so Piwik and privacy policy chat aside, I am still a little confused about the cookies I am seeing on bugzilla. I know one is for git-bz but there seem to be a lot of custom, undocumented cookies on here just to allow the login and git bz to work. I was a bit taken aback to find 9. I will take a look when I have a chance but I am not confident these will be as straightforward as piwik to figure out.
(In reply to comment #13) > > It is most likely to be found in the footer of the theme folder in > wp-content/themes/footer.php with something like <?php include_once > "piwik.php"; ?> in that case. I am not sure maybe someone has done something > else, but that is a good place to start. FWIW you'll find the theme, with footer.php and its call to piwik in the https://git.gnome.org/browse/gnome-web-www/ repository.
Created attachment 267249 [details] [review] remove stat counter
(In reply to comment #12) > Well. Piwik is spying technology. It relies on things like cookies to be > present. > Why not getting rid of Piwik altogether? Spying on our users is not a nice > thing to do and from what I know, which is, admittedly, little, it only gave us > an insight once (that many visitors use Internet Explorer). And it's not clear > to me whether we made use of that insight. If there is a proper use of that > technology, it'd be good if the case for it is made more often and more > visibly. I don't agree that it's spying technology. We get very little knowledge of the individual visitors, especially if we turn the cookies off, and I would say the data is useful from time to time. I monitor the stats from time to time, but the reason I haven't posted about it on engagement-list is that the last time I did that I got no reactions whatsoever. It is however useful to see general visitor stats around the releases. For example, last release we got less traffic compared to the two releases before. It is also a useful tool whenever we need data to support a decision. One classic one was when some people argued that project news should go on planet gnome, because they had the feeling that nobody read news.gnome.org. I can certainly try and post to engagement-list again with some general stats over the last year.
(In reply to comment #12) > Well. Piwik is spying technology. It relies on things like cookies to be > present. > Why not getting rid of Piwik altogether? Oh seriously, "it uses things like cookies for some part of functionality" translates to "Kill it completely, it's evil to know what's popular"? I would like to know which pages of my user docs get how many hits so I can make those pages more visible. Please tell me how to find out without piwik.
(In reply to comment #17) > I would like to know which pages of my user docs get how many hits so I can > make those pages more visible. Please tell me how to find out without piwik. Actually it's possible to configure Piwik without its javascript tracker, feeding it access.log files (http://piwik.org/log-analytics/);I never tested that configuration, but it would obviously miss details like screen resolutions.
The point seems to have got lost in the politics a little. Personally, I can see either side but really it does not matter what anyone thinks here because the law says that either the cookies are removed or there is a way to gain consent of visitors of the site. If neither of these things are done all it takes is a single complaint and GNOME could have to pay out half a million pounds. This is a no brainer.
I doubt it as I can't imagine on what grounds we'd be bound to UK law. (In reply to comment #17) > (In reply to comment #12) > > Why not getting rid of Piwik altogether? > > Oh seriously, "it uses things like cookies for some part of functionality" > translates to "Kill it completely, it's evil to know what's popular"? You've cleverly skipped the parts in which I explained that our gains seem to be non existent at the cost of us having to deal with all this (and other) administrative stuff. To get the number of hits you can query the Apache log (or apparently make Piwik use that instead of executing code in the user's browser). That's much more robust and doesn't involve shipping code that is not marked as being free to our users.
(In reply to comment #20) > I doubt it as I can't imagine on what grounds we'd be bound to UK law. Why take the chance when it is simple to comply by simply explaining what cookies are on the site to visitors or by removing them? The UK penalty is up to half a million. I do not know what france, germany etc are doing but but the cookie law comes out of Europe. If site visitors are European then setting cookies on their browsers without their consent seems like a very bad idea.
I'll try and come up with a patch to disable the cookie part of piwik this weekend.
Andreas, fwiw the relevant organisation in France has published a guide explaining how to configure piwik to get compliant with the French interpretation of that "EU law"; this is in French but I'm sure you'll work it out, and it has screenshots. http://www.cnil.fr/fileadmin/documents/approfondir/dossier/internet/Configuration_piwik.pdf
Disabled Piwik cookies on the following websites: 1. www.gnome.org 2. help.gnome.org 3. developer.gnome.org 4. planet.gnome.org Relevant commits: www.gnome.org: https://git.gnome.org/browse/gnome-web-www/commit/?id=cd2626d planet.gnome.org: https://git.gnome.org/browse/planet-web/commit/?id=e7f68bb54828a279e6d3685394a8b0969c6aea2e {help,developer}.gnome.org: https://git.gnome.org/browse/library-web/commit/?id=d50fa2294d8f7f9e707cd867f975a4ad16fd5f9d Magdalen, can you please confirm? (help,developer.gnome.org might take a bit to rebuild completely, better to run the tests tomorrow on those websites)
(In reply to comment #24) > Disabled Piwik cookies on the following websites: > > 1. www.gnome.org > 2. help.gnome.org > 3. developer.gnome.org > 4. planet.gnome.org Are there any more thoughts on Bugzilla? > Relevant commits: > > www.gnome.org: https://git.gnome.org/browse/gnome-web-www/commit/?id=cd2626d > > planet.gnome.org: > https://git.gnome.org/browse/planet-web/commit/?id=e7f68bb54828a279e6d3685394a8b0969c6aea2e > > {help,developer}.gnome.org: > https://git.gnome.org/browse/library-web/commit/?id=d50fa2294d8f7f9e707cd867f975a4ad16fd5f9d > > Magdalen, can you please confirm? (help,developer.gnome.org might take a bit to > rebuild completely, better to run the tests tomorrow on those websites) Seems like you did a good job. Though there is one more cookie to remove on www.gnome.org. This is what I found: 1. www.gnome.org One Session Cookie Remains. PHPSESSID I believe this does not originate from Piwik, I am not sure where it is being added yet but fwiw I doubt anything needs to be changed in the modified piwik code you submitted in order to fix that. help.gnome.org No Cookies. Piwik Tracking Present. wiki.gnome.org No Cookies. No Piwik Tracking Present (Is this intentional?) planet.gnome.org No Cookies. Piwik Tracking Present Wordpress Tracking Present. Note: I am fairly sure I have stated things correctly here but I will probably need to double check on a new day as I have not had a chance to be thorough enough to be 100% certain yet!
(In reply to comment #25) > Seems like you did a good job. Though there is one more cookie to remove on > www.gnome.org. This is what I found: > > > 1. www.gnome.org > > One Session Cookie Remains. > > PHPSESSID > > I believe this does not originate from Piwik, I am not sure where it is being > added yet but fwiw I doubt anything needs to be changed in the modified piwik > code you submitted in order to fix that. Might be a php thing and possible to turn off in that case. http://wordpress.org/support/topic/questions-about-phpsessid
(In reply to comment #26) > (In reply to comment #25) > > > Seems like you did a good job. Though there is one more cookie to remove on > > www.gnome.org. This is what I found: > > > > > > 1. www.gnome.org > > > > One Session Cookie Remains. > > > > PHPSESSID > > > > I believe this does not originate from Piwik, I am not sure where it is being > > added yet but fwiw I doubt anything needs to be changed in the modified piwik > > code you submitted in order to fix that. > > Might be a php thing and possible to turn off in that case. > http://wordpress.org/support/topic/questions-about-phpsessid Do not think I can access what is needed to fix this myself... Anyone else care to take a look?
That was related to a php.session_cookies being enabled. I've disabled that now on php.ini and www.gnome.org should be cookies clean now. As usual please confirm.
Ok I think we can close this bug as it seems to be sorted out. The only cookies left are the bugzilla login cookies which seems to be acceptable under the rules anyway from what I can tell. If someone thinks otherwise maybe that is a bugzilla specific bug anyway. Well done everyone!