A farewell to cookies

Graeme Johnston / 23 December 2021

Some questions asked to me the other day:

Q: Why doesn’t your site have a cookie banner?

A: Because we don’t use cookies.

Q: Why not?

My answer to that second question seemed to interest the questioner. This post summarises the points, in case anyone else finds it interesting or useful.

Some background

Cookies are packets of data which many websites download on to the machine being used to view the site.

In some cases, they are technically necessary – for example, if you’re logged into a site to buy something or do your banking or some other sensitive transaction, they may be used as part of a system for identifying securely that it’s still you.

In other contexts, they are not strictly necessary, but can offer various benefits to some or all of

  • the website owner
  • the provider of code or services used for the site
  • people using the site
There’s plenty about it online. Suffice it to say that opinions vary as to the benefits derived by those three categories of people, and about the appropriateness of some practices utilising cookies. It can also be quite hard to find out what a particular cookie does.

The early history is explained by Lou Montulli (who was there at the creation) in this 2013 post. It’s worth reading in its entirety, but here are some extracts:

One of the problems faced in the early years of the web was how to create websites that had “memory” for individual users. The uses of “memory” on a website are many: shopping carts for shopping, personalized content, logging in, and many other interactive features require memory. The problem in 1994 was a lack of mechanisms to identify a user individually…

There were some interesting proposals, but one of the popular ones that kept coming up was to add a unique identifier to every web browser so that a web site could individually identify each user use that to build a session. I was very much against this concept because the unique identifier could be used to track a user at every website…

[Eventually,] the general concept of Web Cookies formed in my head. The idea of allowing a single web site to send a session identifier to the browser that would get sent back only to the server appealed to me and prevented cross site tracking. I wanted to create something that had more utility so that we could do a lot more than just shopping carts, so I extended the concept of the session identifier into a general payload that would get sent back to the server…

We released the Netscape browser in the fall of 1994 and within a year it was the most popular browser in the world. We also released the Cookie specification so that other browsers could implement it and so that web sites would know how to use it. With most of the world using a browser that supported Web Cookies, web sites started using cookies for many different things and in ways that we could not have predicted. Most of those uses were fantastic, some of them were concerning…

Around 1996 ad tracking via Cookies became a hot topic. Users were upset with the practice and asking for change. Tracking across websites was certainly not what cookies were designed to do, they were designed with the opposite intention, but what could be done at that point to fix the problem?…

In the end the decision to disable 3rd party cookies or keep them on was left to me. I agonized about the decision for weeks and in the end I chose to keep them…

Web Cookies find themselves in the midst of a very controversial area, and have gained a level of notoriety because of it. Even though they were designed to protect privacy they have been used in ways that are sometimes infringing upon it… The nature of the advertising business is to collect as much information as it possibly can, so the public needs to push back when it goes too far.

Another factor is that laws impose various constraints on the use of cookies, including requirements (which vary from place to place) to seek consent or offer an opt-out. You can read about the UK rules on the topic here.

Why we don’t use cookies

In the case of our website, cookies aren’t necessary to make it work as intended. We chose to build it with tools which don’t require this. James Friel’s recent piece explains how.

One thing I take from that experience is that you can’t assume that a “no cookies” option will be available. If you’re building a website and want to go cookie-free, figure out in advance what level of control over this the tools and services you use will give you. The default expectation from major services is that cookies will be used: we had to do something quite specialist to turn off a cookie on our site (see James’s article for details). Had we gone with certain options, it would have been impossible for us to turn them off completely.

As to the possible benefits of using non-essential cookies, we looked at these and concluded that most of them are not relevant to us, and those which might be useful are outweighed by

1. the potential privacy impact

2. the nuisance factor for people visiting to our site of having to deal with a cookie consent process.

That was enough for us to make the decision to say no to cookies.

The future

I don’t want to come across as some sort of iconoclast (cookieclast?) or moralist.

There can be legitimate uses for cookies. We use them in our software product to deliver real benefits to customers and users. But, as Lou Montulli noted back in 2013, the use of cookies and associated practices feels a little out of control. The regulatory changes of recent years have been met with counter-moves such as complicated dialogs which appear likely to confuse, overwhelm or otherwise manipulate people into giving “consent” or failing to object or opt out. If we use cookies in future, we won’t be doing it that way, but for the time being we’re OK with opting out of that whole world by not using cookies on our website.

In short, our position can be summed up as “If in doubt, don’t use cookies.” If, in future, we think that there may be a genuine case for using them on this website, we intend to:

1. consider very carefully whether it’s a real need or substantial benefit;

2. if so, whether it can be achieved in some other acceptable way;

3. if not, understand properly how the suggested cookie works, and any side-effects;

4. weigh it all up taking into account not merely legal compliance but also the broader implications of ideas like data minimisation, privacy-by-design and, quite simply, respect for people.

I appreciate we’re a bit of an outlier on this topic, but this approach feels right to us. We’re always open to feedback, though: feel free to let us know!

Photo: Caroline Attwood on Unsplash