How opening a webpage could expose who you are

Imagine if I told you that you may have exposed your name, your email address, and potentially who you are, merely by opening this webpage?

How would you feel?

To understand how this could even happen, we first need to understand cookies.

For the uninitiated, cookies are key-value strings that a server can store in your browser, such that subsequent requests to the website automatically include them.

But in order to understand why cookies exist, we first need to talk about the “statelessness” of HTTP.

The way I like to imagine HTTP servers is like the main character of Memento or Ghajini.

Every HTTP request is like a conversation with Leonard from Memento.

Imagine you are sitting at a restaurant, and your “server” is Leonard. Every HTTP request is like a conversation with him. He has no idea who you are or whether you have spoken with him previously. Every conversation starts afresh.

That doesn’t mean your history or state does not matter. It just means Leonard cannot independently remember those details, and instead has to check his external notes to figure out the context.

Web servers work in a very similar way.

When your browser makes a request to a server, the server does not inherently remember:

• who you are
• whether you are logged in
• what is in your cart
• whether you prefer dark or light mode

This data is usually stored in session stores like Postgres or Redis.

So now the problem is better defined:

How do you associate incoming requests with their correct context and users?

Back in the late 90s, this was handled using:

• query parameters
• hidden form fields
• URL rewriting

These approaches barely worked and came with a whole host of issues.

Then Netscape introduced cookies.

Cookies allowed servers to ask browsers to store small strings locally and automatically attach them on subsequent requests.

This is kind of like Leonard sticking a sticky note on your forehead, so that the next time you speak to him, he knows exactly where to find the relevant context.

This “sticky note” (cookie) could contain things like:

• a session identifier
• your cart ID
• your theme preference
• login state

Problem solved… right?

Not exactly.

The problem was not the cookies themselves. They solved the exact problem they were designed to solve.

The new problem was that browsers would also attach cookies to requests made in third-party contexts.

Now imagine you are at a restaurant called:

watermelons4sale.com

Leonard is your waiter.

At some point during the conversation, Leonard says:

“Hang on, ask my friend from Facebook for that photo / Like button / widget.”

So your browser walks over to another waiter sitting in a completely different restaurant:

facebook.com

To the browser, an embedded Facebook Like button was still just a normal request to facebook.com.

Browsers didn’t really distinguish between:

you intentionally visiting Facebook a website embedding Facebook resources

So cookies were attached in both cases.

So before talking to him, your browser also carries all the sticky notes Facebook had previously attached to your forehead.

Those sticky notes might identify:

• who you are
• your Facebook account
• your session identifier
• whether you are logged in

So the second Leonard from Facebook instantly recognizes you.

Not only that, your browser may also tell Facebook where you came from using something called the Referer header.

So now Facebook potentially knows:

• you visited watermelons4sale.com
• when you visited
• what browser/device you used
• and potentially who you are in real life

And all of this could happen even if you never clicked the Facebook button at all.

The mere act of loading the webpage was enough.

You didn’t have to log in.

You weren’t asked whether you wanted Facebook to know about your offsite browsing behavior.

At first glance, this sounds harmless.

“Oh no, they’ll show me watermelon ads.”

But now scale this behavior to millions of websites.

All of a sudden, companies could build incredibly detailed profiles about people:

• what they are interested in
• how long they spent on certain sites
• what products they were thinking of buying
• what political content they consumed

A tiny feature that was meant to maintain state and remember your theme preference had accidentally evolved into one of the largest tracking systems the world had ever seen.

And it wasn’t just Facebook.

It was nearly the entire advertising industry throughout the 2000s and 2010s.

Then came the backlash.

People slowly started realizing the system that harmless cookies had inadvertently created. A handful of companies could now monitor a huge portion of human behavior online.

Unlike malware, this tracking happened through perfectly normal browser behavior.

Your browser was simply doing what it had been designed to do.

Over time:

• lawsuits piled up
• regulators stepped in
• browsers started changing cookie behavior

Modern browsers now impose restrictions like:

SameSite=Lax

SameSite=Strict

SameSite=None

Browsers like Safari and Brave outright block most third-party cookies by default.

Chrome has also been moving toward phasing them out.

Cookies themselves were never “evil”. They solved a very real problem, enabling stateful applications to exist on top of a stateless protocol.

The problem was that the advertising industry realized what else this feature could be used for.

Now for the fun part.

Let’s see if I can deliver on the promise I made in the first paragraph.

For this demo to work, you need to open this page using the same browser/profile you use for notesbhej.mshiv.net.

If you are not logged in there, try logging into notesbhej.mshiv.net first and then refresh this page.