Notice! We decided not to publish this library until we found a motivating use case that was not better addressed by using the Set-Cookie header on an HTTP response. Please open an issue describing your particular scenario if you think you found the motivating use case!

Cookies are an ancient mistake of web browsers. They make a bunch of security problems quite easy, so consider this an expert library.

If you are looking for a way to store information, you should take a look into local-storage or session-storage instead.

The crucial detail of cookies is that they all get collected and put into the Cookies header of every request you make. So you may have a header like this:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
…

This means that someone set theme and sessionToken cookies.

One way to set cookies is with headers on your response. For example, the server may have set the theme and sessionToken cookies by providing a response like this one:

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
…

This library provides ways to set cookies in Elm instead of with HTTP response headers.

The problems break down into three major categories: security, architecture, and encoding.

You may have heard of “tracking cookies” that let companies see which pages you have visited. The way it works is that a company convinces as many websites as possible to embed an “Like button” by adding a simple <script> tag to their page. This means they can now load arbitrary code and do whatever they want.

The goal is to uniquely identify a user, which is where cookies come in. When you visit their site, they create a cookie for their domain. It will uniquely identify you by your account or by your browser. Now when you are on some other site, their <script> can send a request to their servers about what page you are on, tagged with their cookies. That means they know exactly who you are as well as where you are. Pretty neat trick!

In the earlier examples, we saw a theme cookie. This implies you are making a few questionable choices:

1. You do not have theme in your URL. You could be requesting a URL like http://example.com/reader?theme=light or where the options are in the body of a POST request.

2. Your theme information is not associated with a particular user, it is associated with just this browser. Instead of storing theme information in your database such that you have a consistent experience from any device, you need to set it once for every platform.

3. You are sending this theme information in the headers on every request, even if it is not actually necessary for a given page.

In the end, storing information like this in cookies means it is not modeled on your server. It is not modeled in your client. There is now this third store of data that also kind of sucks.

Browsers all cap the amount of memory available for cookies. It does not appear to be consistent, but generally, it is not a very high cap.

On top of that, some browsers only permit you to store ASCII characters. So if you have a string with any Unicode characters outside that range, it will break in various ways depending on the browser.

As far as I can tell, the only usage that really makes sense is the following scenario:

A user comes to your website http://mail.example.com and you want to serve them their inbox immediately, no sign in necessary.

In that case, you do want to have some additional information added by the browser that can help reliably identify the user. You want to know that and nothing else though.

Based on that identifier, you could look up things like theme from your database and send back the appropriately styled HTML. Basically, any other information can be derived from knowing who the user is and that would mean your overall architecture was better anyway.

It seems like there is a lot of money in keeping the current API, so who knows if something like this will ever happen!