No cookies

This website does not use Cookies.

I'm sure you've noticted a wave of popups around the web warning you about websites using cookies to track your behavior.

If you're viewing this document as a web page, I feel very happy to inform you that this website does not use cookies!

The origin

Technically, a cookie is just a piece of meta-information, that the server and the browser use to establish unique user sessions. Server will tell the browser, "hey, please keep this little badge, and hand it over to me each time you speak to me again". This simple mechanism was meant to enable "user sessions", back in mid-1990's things like shopping carts.

The problems

Soon people have started to exploit this mechanism to track and profile other people's behaviors around the web and serve them personalised advertisements.

What few people acknowledge is that the problem lies with the web browsers, not with the services or the people. Non-malicious web services simply use a convenient mechanism to overcome HTTP's shortcomings and enable features. Users simply want to surf the web, look at cat pictures, check the train schedule, or talk to other people... A lot of people don't know, some don't care, and some are well-scared of how the cookies are used.

Cookies enable evil web services to track people, but it is the browsers that blindly accept and send them.

Solutions?

For web users: don't accept third-party cookies

Most web browsers allow you to choose whether you'd like to accept "third party" cookies. These "third parties" provide little actual benefit for you as a web user - you should go to your browser's preferences and turn them off right now.

For web developers and browser vendors: Basic Access Authentication

Web services that require authenticated user sessions can still provide their full functionality without using the cookies mechanism. There is a standard for user authentication over HTTP, but browsers usually implement it as an ugly modal dialog, provide no indication whether the user is logged in or not, and no obvious way to end the session (although there is a workaround, using some simple JavaScript).

Browser vendors could improve the user experience of Basic Auth. Then we could trade Set-Cookie for WWW-Authenticate, and Cookie for Authorization.

For web developers and browser vendors: put the user in control

Some uses for cookies include simply storing the user's preferences, without having them to create accounts or log in.

Some web services are already doing that! For example, to change the theme of a website, a simple key-value pair is stored in a cookie, e.g. theme=dark. That's too little information to uniquely identify (and therefore track) users.

Browser vendors could add a simple and accessible user interface, where users can review and tweak these parameters. It could take the form of a "website-specific" preferences dialog and use elements like checkboxes or drop-down lists, with the help of some meta-data.

It's difficult to hide tracking information in plain sight.

Other options?

I don't know. Whatever would that be, it should allow authenticated user sessions while always letting the user choose when to become anonymous again.

If you have thoughts or suggestions, shoot me an email.


See this as plaintext. Get the permalink. Check out related. Go home.