1878 films and counting...

What's in a Cookie? - Blog



You've probably heard about cookies. Little pieces of data on the Internet that are used to track you, or that tends to be what the public hears.

It isn't entirely true. It isn't entirely false either.

A cookie is somewhat like a car. In the hands of a drunk driver, it can be incredibly dangerous. In the hands of an attentive driver, it is incredibly useful.

To break it down more simply, a cookie is way for your computer to store data, that it then tells your web browser about.

Cookies on SIXTEENmm

We use cookies, extensively.

However, how they are used is with careful consideration.

"3rd Party Cookies" are used by a lot of websites today, and they're a way to transmit your data to people the website has a relationship with, but you don't. This insane practice of leaking data that belongs to you is why lawmakers have created things like the GDPR to try and remind the industry that the data belongs to the user, not the website. Especially when the user isn't in a position to negotiate with the website.

We absolutely, fundamentally, do not use "3rd Part Cookies".

In fact, the cookies we use are a special kind. They're classified as "Secure", "HttpOnly" and are authenticated.

Secure Cookies

"HttpOnly" cookies are cookies that are not available to JavaScript, the programming language of the web. So when you make a request to the website, such as to load a particular video or so on, the cookie is sent to us, and we render a page for you, and that is where it stops. We don't use the cookie-data to change anything dynamically. (In fact, we use very little JavaScript and you can disable it safely.)

"Secure" cookies are cookies that are only sent when you connect to our website using HTTPS, not HTTP. That is, when you get a green lock in your title bar, your browser makes an encrypted request for information, and the cookie can be sent inside that encrypted bundle, both ways, safely. However, if something goes wrong and you somehow force our website to work with HTTP (which I'm not sure is even possible), then those cookies will never be sent by your web browser.


Our cookie is authenticated. That is, if somehow something tampers with it between us sending it to you, and you sending it back, our server will reject it and replace it with a new one. (And nothing on the server ever remembers what's in a cookie, so once it's gone, it's gone. If you delete your cookie, that's the end of the story.)

What's in it!?

So we use a cookie. And when you look at it, all you see is an encrypted bundle of information.

You want to know what data we send to you, and what you send back.

Fair enough.

We can actually do this fairly easily.

def decode_flask_cookie(secret_key, cookie_str): import hashlib from itsdangerous import URLSafeTimedSerializer from flask.sessions import TaggedJSONSerializer salt = 'cookie-session' serializer = TaggedJSONSerializer() signer_kwargs = { 'key_derivation': 'hmac', 'digest_method': hashlib.sha3_256 } s = URLSafeTimedSerializer(secret_key, salt=salt, serializer=serializer, signer_kwargs=signer_kwargs) return s.loads(cookie_str)

We recently changed the digest method from the default SHA1, to the much more secure SHA3-256

The secret key is a securely and randomly generated string of 64 url-safe bytes. A computer can easily bruteforce that by iterating through the 64^64 options. On consumer hardware it'll probably take a couple days, but if you have access to something a bit faster then you could probably do it in under a day.

When I run the above function against a non-logged in session, I get this back:

{ '_permanent': True, 'csr': 'lVXplK4F9CDb9b9LWKlEtMNGntVyMo0TBid8zrgMLPE', 'film_count': 896, 'film_count_time': 1569981515.9447298 }

It's pretty simple to break down.

The _permanent key tells the server that if this cookie expires, as there are time constraints on the life of a cookie, then it should regenerate it and keep the contents. This is what stops you having to re-login every time you go to the website.

The csr value looks a bit strange. It is an identifier, of sorts. It doesn't unqiuely identifier you as a person, rather we check it when you submit a form to make sure that your connection wasn't interrupted. It's only a way of checking the integrity of the conversation between our server and your browser. It's a random string. You can safely lose it, and we'll just make you a new one.

In fact, here's the code from our server where we create the csr:

if 'csr' not in session: session['csr'] = secrets.token_urlsafe(32)

The film_count key might be surprising. But this is simple enough. Checking our exact film count can be somewhat expensive. There's a few films to count. So we get your web browser to remember it for a while, (with film_count_time checking when you last updated that number). This means that your page loads faster.

So, that's a logged-out person.

What about logged-in?

{ '_permanent': True, 'csr': '_zHel6FygBEGjOTEAPXB-SqwuFcjGdtYR3vVHvpwSNw', 'film_count': 896, 'film_count_time': 1569981815.9542258, 'username': 'oswald', }

Yep. We just store the username so that we can check it.

Hopefully that explains a bit about how cookies are used by SIXTEENmm, and can help relieve any fears you have that we might be tracking you. You should be able to use the provided decode function to check your own cookie contents.

Continue reading...