Ladies and Gents,
Just seen this http://www.netmagazine.com/news/anti-eu-cookie-law-protest-site-launched-121930 - and it appears that if you use a cookie, then you have to get the user's permission before they can proceed. I use a session cookie in my course format that is just for user state.
Thoughts on how this will / could affect Moodle?
Cheers,
Gareth
Dear Petr,
Interesting list of reasons .
My cookie only stores a compressed toggle state (base 36 representation of a 53 bit binary number) on a per browser per course basis so that on a page refresh the toggles reopen as the user had set them. This is a non-persistent cookie that does not exist beyond the session unless the administrator changes the code - thereby giving control to the admin in their country regarding privacy. I could equally now convert the code to a PHP session variable as at the time of original creation I did not know how to do this. I don't want to go near the DB as that would be a large amount of data to store / manage on a per user per course basis for the sake of toggle state + I would need a way for my custom course format to operate code when a user is deleted. I do agree with cookies getting mixed up, but hey again, this is only toggle state.
Cheers,
Gareth
Look at the get_/set_user_preference functions in moodlelib.php, and M.util.set_user_preference and user_preference_allow_ajax_update in javascript-static.js and lib/ajax/ajaxlib.php, if you want to change how you implement this.
Dear Tim,
I'm using the latest 2.2 - 2.2.2+ (Build: 20120419) and I change the 'AJAX and JavaScript' in the user's profile to 'basic features' and yet the code still appends:
script type="text/javascript" // [CDATA[ document.body.className += ' jsenabled'; // ]]
Type (with the proper tags) to the generated HTML, should this be the case?
Cheers,
Gareth
Yes, that is intentional. It lets you write CSS rules like
body.jsenable .non-js-fallback-thing { display: none; }
That means that bits of your code that should be hidden when JavaScript is enabled are hidden right from the very start, and you don't get nasty transient flickering as the page loads.
Cool! But what is happening is that 'jsenabled' is happening all of the time regardless of that user setting?
Correct. That user setting only controls a few specific things. Really it is a legacy thing, and we could probably get rid of it these days.
The jsenabled thing lets you know easily (from CSS) if JavaScript is running in the user's web browser.
Oh absolutely brilliant!!! I did not know that, will really help with something I'm solving. Thanks Tim
And Tim, thanks, in the long term I will, but ATM in a real rush and not enough time to learn AJAX over PHP. And pragmatically if Paged Course formats adds a 'toggle' next year then my code will be redundant.
It does however look good. I was observing how the block minimise / dock code operated with FireBug to see the XHTTPRequest etc. operate - really neat and beautiful.
Cheers,
Gareth
Users can set the browser to deny cookies. If they don't do that they effectively give permission to the site they are browsing to proceed.
Hi Gareth.
IANAL, but that site probably makes things sound a bit more alarming than they really are. The new regulations are very vague, and nobody really seems to know exactly what they'll end up meaning; You'll need "consent" to set certain kinds of cookie, but it might turn out that your browser settings already allow the user to give their consent. And there are some big exemptions that will probably cover Moodle's session cookies and things you might use to maintain state as part of the functionality of your course format.
The sensible thing to do here is probably to ignore the directive and wait until it goes away.
That said, what I could imagine becoming an issue here is that in an excess of caution some schools may adopt stricter policies than the minimum they could get away with. If you're setting your own cookies, this might be a good time to fix your thing along the lines Petr describes, which is probably better coding practice anyway. That way if some schools do end up wanting to tweak Moodle to be extra compliant with something, there will be fewer places they will need to mess with.
Dear Edmund,
Thanks, I will consider the PHP session route. But loathe ATM to change what works unless I have to. I think I need to watch this space and have a backup plan.
Cheers,
Gareth
Hi Gareth,
I take web privacy very seriously. I use a browser plugin that denies tracking cookies and deletes all other cookies after every session. It's also possible to set Flash Player's security settings to deny all local SharedObjects (LSOs) which Google are particularly bad with: If you have Flash debug Player installed, you can see the error they throw every time they try to save one to your cache.
I use Piwik analytics which allows users to opt out of being tracked. I think this is a requirement in Germany now. It's also a good idea to inform users of what data you collect (Moodle logs almost everything), how long you store it for and what you do with it. To see what the important differences are and to get an idea of why the EU is introducing this law (i.e. to limit the power of corporations since they're now collecting more surveillance data than any governments, even China), I suggest comparing EFF's clear, informative, succinct site policy with Google's or Facebook's.
Most of the time all you need is a prominent notice with a link that displays your site policy and any opt outs you might have. The target of these laws isn't your average educational site, they're after Facebook, Google+, Amazon, "non-approved" private security consultants and agencies, etc., who are competing with government surveillance, although there is the danger of getting squashed between the sides.
The US NSA are doing something similar. This recent news programme (online video) should make your hairs stand on end: http://www.democracynow.org/shows/2012/4/20
Dear Matt,
Thank you for such a pragmatic response . A lot to think about. What is the name of the browser plugin that denies tracking cookies please?
I think given the nature of my cookie that I will put a notice in my Readme file instructing administrators to choose to place a notice about the cookie and with full disclosure of what it is.
In this digital age, the 'cold war' ethos is just evolving and perpetuating its fear and paranoia into a new technological form. As Frank Herbert wrote in 'Dune' - 'Fear is the mind killer', therefore 'fear' of cookies needs to be removed though careful clear precice disclosed benificial use as you say with 'clear, informative, succinct site policy'.
Cheers,
Gareth
Hi Matt,
the German perspective here is to forbid cookies that send data to third parties without asking users for acceptance. This happens with Google analytics.
They don't have problems with cookies that identify user to identify him that he gets page access.
User data tracking is discussed controversary in all areas of education. Mostly its ok to delete server logs after two or three days. In some cases full anonymous access is discussed until they start to think about communication and cooperation.
We had discussion with state data protection offices that accept tracking if it is required for learning process. They say: 'Learning first. If there are educational argument why they need the data to support the learning process it will be accepted.'
This idea is based on German data protection laws (17 laws! One on federal and 16 on state level.) that says data collection is allowed if there is a predefined purpose to use them, its limited to the neccessary data and users get an information before data are collected.
I've had to look at this issue for my college, and how it relates to our Moodle VLE.
As far as I can see, the EU set the directive, and it's up to each country how they implement the directive. So each country could have slightly different rules about what's OK.
As far as the UK goes, I've read the Information Commissioner's 27-page report, and this is the gist of it. I'm not a lawyer.
I'm currently conducting an audit of cookies used by our Moodle and Piwik installations, as well as our WordPress blogs. This isn't fun.
Hi Alex,
Thanks for sharing that. It's really useful to know
Cookie blocker plugins for Firefox include Abine and TACO but there are others. Clearing cookies at the end of every session is the most effective measure. Firefox has a setting to do this for you automatically.
This doesn't stop sites from using invisible images to track you. Another trick is to use social networking site "Like" buttons which contain surveillance software. In other words, if you're logged into Facebook, Google+, etc., every time you land on a page with their "Like" buttons, they know where you've been and may even know what you looked at, clicked on, etc.
If you use a Javascript blocker like NoScript, Google converts links, for example in web searches, into tracking buttons. You can see it by copying the link location (right click) and then pasting the link into a text editor so you can see it. It doesn't look like the link you copied on the web page, does it?
Again, one of the worst offenders is Google who also use LSOs. It's well worth taking the time to change your Flash Player security settings to disallow LSOs altogether. LSOs are more persistent than regular cookies and more difficult to get rid of. They aren't cleared from the browser cache in the normal way.
To clear LSOs and prevent new ones, go to any web page with a Flash app or movie on it. Right click on the Flash window and select: Global settings... > Storage > Block all sites from storing information on this computer > OK. No more LSOs! If you find that you absolutely must have LSOs for some sites (unlikely), you can permit them on a site by site basis instead. You always have the option to delete all LSOs at any time.
Another thing to secure your privacy is to insist on using encrypted connections (HTTPS Everywhere) so that your ISP can't monitor your communications. Additionally, it'll reduce the efficacy of the NSA's surveillance programmes which re-route a lot of web traffic through their own servers. It doesn't stop them but it makes it less convenient for them.
The only secure way to hide you're identity is to use TOR browser and no Flash, Java or Javascript at all: https://www.torproject.org/ (Originally a US Navy project). This is why governments need to step in and legally prohibit this kind of blanket surveillance. Of course, this isn't 100% effective either.
Dear Alex,
Thank you . Indeed it is not fun at all!
I found a good guide linked by the ICO - http://www.international-chamber.co.uk/components/com_wordpress/wp/wp-content/uploads/2012/04/icc_uk_cookie_guide.pdf from http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/cookies.aspx which leads me to think that my cookie is a 'Category 3' cookie - sounds like a Muppet Show farce. So I now have a design to implement a permissions functionality in my format to solve this issue.
As for Wordpress, I use it for my own website and came across this plugin - http://wordpress.org/extend/plugins/cookie-control/ - which I think is rather need and fairly easy to install. I also found - http://codex.wordpress.org/WordPress_Cookies - useful.
I've also found this Firefox and Chrome plugin - http://chrispederick.com/work/web-developer/ - useful in displaying cookie information for audit purposes.
Cheers,
Gareth
@Alex "The ICO is very clear on this because Joe Public doesn't know what cookies do. You must have explicit, informed consent."
This seems rather contradictory. How can you have "explicit informed consent" from "Joe Public" who does not understand anything about cookies (apart from the edible ones). Would we expect "Joe public" to read the ICO's 27-page report in order to get "informed" before clicking on the "I thereby give consent" button?
Joseph
From the ICO report, it just recommends you use clear language to say what the cookies are used for (e.g. 'remembering who you are once you log in', 'tracking how many people visit the site') and the implications of rejecting them.
It's all in that 27-page report and it's worth a read. It's not as boring as you think it'll be.
One more point: it doesn't matter where the site's hosted. If it's hosted outside the EU but targeted mainly at people inside the EU, it's apparently still a target. I don't know what exactly they can do, but the report says sites hosted outside the EU that target people inside the EU aren't exempt.
It's highly unlikely that anyone will sue a college or university for Moodle. These laws are primarily targeted at data miners like Amazon, Facebook etc. But that doesn't mean we should do nothing.
Basically, if you are thinking 'the law is totally ludicrous, this can't possibly be what it means' then that is what it means.
I think the take-home message for developers is probably, make sure you don't add any cookies beyond the Moodle standard PHP session cookie. Which was most likely good practice anyway.
If there are legal issues, so long as you run a site which is not open to the public (for students of a particular university or school) then it should probably be possible to fix this without doing anything technically - just add a point to whatever document they have to sign when they sign up for courses, so they can agree there that cookies will be used to track their login. That way they will have to give permission before getting their account or even seeing a link to the website, and therefore before a cookie would ever be set.
--sam
Here's some information from JISC Legal.
Based on that information, here's what we're doing with regards to Moodle:
To be on the side of caution I have now started work on CONTRIB-3624 - which will place in plain English (or other languages when translated) an option to the user to switch on / off the cookie and the implications of such - i.e. the toggles will remember / not remember their state respectively. The system administrator can choose to turn off / on the functionality as desired.
On the plus side, I've eliminated an issue in my format that has been bugging me for ages and learnt something new about creating Moodle forms .
I have found the - http://www.international-chamber.co.uk/components/com_wordpress/wp/wp-content/uploads/2012/04/icc_uk_cookie_guide.pdf - document the easiest to understand.
Cheers,
Gareth
I've been participating a lot of these cookie audits at Blackboard around this regulation. In the interest of sharing, I've posted some basic info on my process on my personal blog. Some more thoughts below. Standard internet disclaimers that I'm not a lawyer and this is just one man's opinion apply. Before I go much further I really think the law is poorly written and should be reworked. I respect the goals of disclosing the cookies and how they are used. I also know that given the recent issues at Facebook and Google tricking browsers into accepting questionable cookies there is probably a good reason that site operators should be responsble for the use of adsense, analytics, Facebook "Like" buttons, etc. The user experience prescribed by the regulations sucks.
I beleive that a challenge products like Moodle/Blackboard is the law appears to make the site operator responsble for all the cookies set on the users browser when they visit a the site. So for example if you have a "twitter" plugin in a course to show hashtag info, that gadget will set a cookie. YouTube videos may contain flash cookies which also get set on the browser. Then there are many people using Google Analytics or services like Omniture to get analytics and performance data on their site. Then there are the cookie like things such as javascript local storage and other ajax tricks used to improve the site. Some of these will qualify as "cookies" under the law. The law exempts cookies that are strictly necessary, which might apply to the cookie used for login, but odds are your users will hit other cookies as they use the site. Unless all of these cookies are strictly necesary, you'll need to get prior consent. If you read the Data Protection Directive closely it seems that you must still provide "notice" to the user about the use of "strictly necessary" cookies, you just don't need their prior consent. So it isn't clear what this buys you other than the techincal ability to call "set cookie" before getting the user to agree.
Thus is is my view is that applications like Moodle / Blackboard /etc will need to put some kind of notice/consent dialog either on the "login" page (if that's the first thing users see). Or on whatever the "guest" user sees when they access the site. It will be very difficult given all the possible cookies the user may encounter to argue that they all meet the "strictly necessary" test. The big challenge for the LMS/VLE is the law appears to make the site operator responsble for all the cookies set on the users browser when they visit a page. So for example if you have a "twitter" plugin in a course to show hashtag info, that gadget will set a cookie. YouTube videos may contain flash cookies which also get set on the browser. Then there are many people using Google Analytics or services like Omniture to get analytics and performance data on their site. Then there are the cookie like things such as javascript local storage and other ajax tricks used to improve the site. Some of these will qualify as "cookies" under the law. Even if we strip these things away and just focus on the session cookie used in Moodle or Blackboard for login, it isn't clear if the fact that session is also used for tracking usage moves it beyond the exempted "strictly necesasry" to some other catagory. And of course if you read the Data Protection Directive closely it seems that you must still provide "notice" to the user about the use of cookies, you just don't need their prior consent.
Keep in mind that this notice / consent process may also applies to mobile applications used on smart phones even if they don't actually use the web since the law talks about Internet services and "terminal devices" It even defines a cookie well beyond what we would normally think of as a cookie.
The more difficult challenge in complying with these regulations will be to keep up with all the different things being thrown up inside Moodle that might also set cookies. Under the regulations you are supposed to provide detailed informaiton about the cookies, third party cookies, third party privacy policies, and informaiton on how to remove the cookies or personal info from the site.
I hope that providing a generic disclaimer at the end that the list of cookies may not be exhaustive and can report rogue cookies to an appropriate on campus contact.
Anyway, I hope this information is helpful.
Agreed, Howard, and also, no legal sysytem supports the concept of a "system of perfection" yet that is what John seems to be suggesting above. Making these laws is considerably easier than enforcing it. This would, I suspect, mean that unless someone complains about a particular cookie, then nothing is going to happen. A lot of complaints would then imply that cookies will either be cut out altogether, or made so stealthy that people will not realize they are there, or cause a repeal of the law.
I think we also need to remember why cookies were developed in the first place and ask if that need no longer exists. I am not sure if that is arguable at all, I do not have the technical qualifications to be able to draw any serious conclusions here. I would suggest that the need still exists, even with the huge technical improvements to network operating systems, to computer operating systems, Windows notwithstanding, to network hardware and even to public knowledge. In short, I am not sure that we can have a completely cookie free Internet.
I would also suggest that the law is aimed more specifcally at tracking cookies to try and improve privacy standards for users. If this is the case, then unless someone writes a cookie for Moodle that tracks a User's movements while in Moodle, then there should not be a problem. Whether session cookies do that, or not is problematic. I know some discussion here has been around usage tracking, and student progress, which may cause an issue, but if it is entirely internal for legitimate purposes, i.e. assessment, I don't think it will be any concern.
DISCLAIMER: I am not a lawyer, I am not a European citizen, I am not a whale, I am not indigenous, I am not female. The opinions expressed above do not represent the opinions of Warner Brothers or Fox Media. I refuse to accept any liability for any opinion raised above if used in a court of law in any nation on Earth or in the universe, that fails to satisfy that court as being legitimate or useful. These opinions cannot be traded, bartered, sold or otherwise used as legal tender. I think that covers everything..whew!
As I understand it, ICO would only investigate someone if they get a complaint about them - so if your organisation is high profile enough to be a target for people with a grudge it could be at risk.
I don't think it's a very big risk however, as:
I'm hoping that it will be possible to defer setting MoodleSession until a user logs in, but my non-Moodle sites have more issues so I'm currently working on getting them to the same level that Moodle is as standard.
IANAL.
Ah, not having looked at it yet, I hadn't realised that it is part of all those things - in which case it seems reasonable to say that MoodleSession is strictly neccessary for the operation of the site, and therefore exempt from opt-in even for non-logged in users.
That should make things a bit simpler
On the cookie front.
Ignore the MoodleSession cookie for a moment and remember that as the website operator you are responsible for more than just the default cookies set by Moodle. You are also responsible for the cookies that might come from various third party content and add-ons.
As I read the law, if you have any cookies which are not strictly necessary then you need prior consent. The most straightforward means of obtaining this consent would be to do it when the user arrives at the site.
To find these other cookies look for the following:
1- Do you embed flash games, video or images from third party sites. These games probably have flash cookies in them. You Tube and other video sites have this as well.
2- Do you use Google Analytics, Omniture or another service to gather usage and performance stats? These tracking cookies are not strictly necesary.
3- Do you use Facebook Like buttons, Tweet buttons or other items for your pages. The twitter feed javascript gadget is very popular for instructors who want to post info about specific hash tags. Be aware that these use cookies.
If you find any of these things you should probably implement a consent dialogue for users when they first visit the site. You should try to document these on a seperate page.
Pragmatically, I consider that as long as Moodle core can satisfy the category 1 cookie category as defined in http://www.international-chamber.co.uk/components/com_wordpress/wp/wp-content/uploads/2012/04/icc_uk_cookie_guide.pdf as I linked in a previous post, then it is up to the plugin provider to state explain their use of cookies.
I have placed in my Collapsed Topics course format the abilty for a user to control its cookie as it is a category 3, if you wish to borrow / modify the code to be global, then please do. Or you could modify the code from http://www.civicuk.com/cookie-law/index (which also has a Wordpress plugin) so Wordpress could be a front end, and indeed given that principle I'm sure there are talented plugin developers willing to give this a bash as a Moodle plugin.
However, in discussions mainly with Petr and Tim I now consider cookies an obsolite technology, like the floppy disk, therefore intend to eliminate them in my code - probably in the Moodle 2.3 version which will be a rewrite. I'm sure this actual problem of privacy will not go away, it is just that technology can be developed and implemented faster than the law. And a law that targets specific technology will not last long as its intent is lost as soon as something identical but not legally the same replaces it.
Disclaimer: These thoughts are my own. They provided as is for the purpose of discussion without any warrenty, guarantee or the ability to spell and instigate correct grammar. They may not be used as an igniter of a forum flame war or reproduced out of context. MoodleNews please feel free to reproduce in an article on the matter.
Cheers,
Gareth
Samuel Johnson said that "the law is an ass", I suspect what he meant was that the lawmakers made laws that were unworkable or unenforceable, and some things do not change. However, I cannot see where third party cookies are an issue here though. In Sweden, the storage of torrents, for example, is not illegal. In Australia, an ISP cannot be held responsible for the flow-through traffic a customer may download. These are two examples of court decisions that really have major implications elsewhere. Obviously the judges who made these decisions were technically literate in ways that gave them insight onto how the internet and services actually work. In the end, the law itself may be flawed, from a networking, technically, User, Internet perspective, so judges make decisions to balance what a law says and how it can be made to work. If any judge making a decision on these laws is technically literate, and I would suggest they actually need to be now, then any reasonable interpretation of how cookies work would not hold a party responsible for what a third-party may or may not do. To do otherwise would, I suggest, undermine the very concept of Open Source. Moodle cannot be held responsible for what Google does, and I would think Google would be seriously miffed, if they paid any attention at all, if Martin was to tell them that their product was going to be barred because of their cookie policies. I would expect that it is Google that has to respond to the European laws on cookies as more organizations include Analytics code into their sites and products than just Moodle.
John, I do see your point, that is the 11th Commandment, "Thou shalt protect thine own backside first.", but I am not sure that it is relevant here.
The regs already anticipate you trying to code your way out of this. They define a cookie to pretty much cover all the alternatives.
In other news the ICO is doubling its staff and preparing to send out inquiry to a number of web application provides starting on the 26th.
It seems that the UK government is having trouble complying with its own law. This would seem to buy time to figure out how to comply. In related news the Netherlands has just passed a similiar law, though the timeline for enforcement is unknown.
Personally I'm sticking with the approach of detailed documentation on as many known cookies and cookie like things as possible along with a one time notice for users with an "acknolweldgement" dialog.
The latest update is that the UK ICO released updated guidance 48 hours before the law went live. It seems that in many circumstances implied consent is now possible. Thus provided you have a prominent notice that your site uses cookies, you don't need to get opt-in consent. Many commentators have noted that this is inconsitent with the actual EU data protection directive. I anticipate guideance will change again in about 6 months after the ICO finishes reviewing whta web operators actually did. For now my recommedation remains that people modify the text in their terms of service module to inform users that cookies are in use and collect their consent where possible.
Let's consider for a second only standard Moodle 2.2 or newer. It creates only one cookie "MoodleSession" which I would consider "strictly necessary cookie", in line with the "ICC UK Cookie guide" from April 2012:
Generally these cookies will be essential first-party session
cookies, and if persistent or third party, there should be a good
justification for this.
Not all first-party session cookies will fall into the ‘strictly
necessary’ category for the purposes of the legislation. Strictly
necessary cookies will generally be used to store a unique
identifier to manage and identify the user as unique to other
users currently viewing the website, in order to provide a
consistent and accurate service to the user.
Examples include:
• Remembering previous actions (e.g. entered text) when
navigating back to a page in the same session.
• Managing and passing security tokens to different services
within a website to identify the visitor’s status (e.g. logged in
or not)
• To maintain tokens for the implementation of secure areas of
the website
• To route customers to specific versions/applications of a
service, such as might be used during a technical migration
These cookies will not be used
• To gather information that could be used for marketing to
the user.
• To remember customer preferences or user ID’s outside a
single session (unless the user has requested this function).
For this kind of cookies:
User consent is not required for the delivery of those cookies
which are strictly necessary to provide services requested by
the user. However, it is important to give users the opportunity
to understand these cookies and the reasons they are used.
So it seems to me, that standard Moodle is now (after MDL-28158) compliant but provided that some message is given to the user about using "MoodleSesssion" cookie, in a visible way and with simple to understand explanation (I think that current explanation in inline help is good enough).
cheers,
Tomasz Muras
Enovation Solutions
