Cookies allow a website to remember you, as you click from one page to another, as you browse through a website. This is particularly useful when implementing workflows. In technical terms: Cookies add state to the HTTP protocol, which would otherwise be stateless. Not only are HTTP cookies common in practice, they are also the official and standard way of implementing this in HTTP. There are other non-standard ways to keep state (for example by using HTTP GET parameters, or form fields in HTTP POST).
It is good to know that some the web browser features controlling cookies can be circumvented. For this the website developers needs to deviate from the standard HTTP cookie. See for example the ENISA paper on privacy and information security risks of cookies which discusses so-called ever-cookies. It has been compared to an arms race, but the good news is that the web is standardizing and converging to HTML5, so there is less and lss room for unexpected behaviour (i.e. state stored via plugins, local storage, etc). Browser vendors work to make sure that “clear cookies” means indeed that. And they work to ensure that “private browsing” indeed starts you with a clean sheet.
In 2009, driven partly by an EU directive, EU countries adopted a range of new rules on cookies. Some countries became very restrictive. For example, the Dutch legislation, apparently went too far for the Dutch EU commissioner of the Digital Agenda, Neelie Kroes. Some countries tried to leave websites the choice to implement cookies in a privacy-friendly way – not always with good results. Here is an interesting and critical article about the UK government’s rules on cookies, for instance. I have used some of their pictures in this article for amusement. Regardless of the good intentions, aimed at ending the practice of tracking users, the practical outcome (across the EU) of these policy initiatives was an epidemic of warning messages on websites, asking website visitors every time to click “Yes, accept?” or “No, I don’t”. The second choice usually meaning “Bye bye”.
The real problem is the hidden tracking of users. Asking users if they like cookies is really besides the point. There are plenty of ways to track users, for example via the IP address of the user (IPv6 is coming, so each users will have a unique IP address soon), via browser profiling, via variables in the URL, via hidden fields in the page, via third-party 1-pixel image, etc. The cookie is not the problem.
There can be little discussion about how this daily internet meme of clicking away cookie warnings is useless, uninspiring and time-consuming. I still need to meet the first person who reads the warning and then clicks “no”. It also a costly and inefficient approach to giving the user control, because control over cookies can be handled much better by the browser itself.
What is more important is that these cookie warnings are a security risk. We are training people to click “Yes, accept” every time a website is visited. This weakens an important and widely used security mechanism, which is to ask explicit authorization or consent for a security critical action. Cookie warnings increase the risk that users, when caught in a drive-by-download attack, mindlessly click “Yes, accept”, when prompted to run an applet, or install code, or give the page access to location-data. From an IT security perspective it is a very bad idea to train users to click mindlessly on warning messages. In other words, for the bulk of the users who are now handling cookie warnings, the cookie warnings do not improve privacy, but they just increase risks for their privacy.
The same argument could be made for other “click here to continue” consent and warning boxes, by the way. At first it seems a good idea to just ask the user – as explicitly as possible – but in the end it is just another mindless click. So where do we draw the line? Should check boxes such as “Check this box to agree with our terms and conditions” be replaced by just small print at the bottom, accessible via a link? Or should there be a ban on re-using the visual language of warning signs?
PS. As a footnote, about solving the issue of cookies without these cookie warnings; It should not be done by the individual websites. The browser is the best place to give this kind of control. So the focus should be on the W3C’s HTML specs and how browsers implement it. See for example ENISA’s work commenting and flagging security issues in the HTML 5 specs, when open opened for comments by W3C in 2011. By improving the HTML5 standard, we can give better control to the user over a host of issues around offline storage, cookies, third-party content, cross-domain access, and so on.