I believe originally (back in the early drafts of the spec) the concept of a "site" was significantly stricter (based on the origins matching), but it got watered down which was a real shame. I'm not sure why.

c.f. https://tools.ietf.org/html/draft-west-first-party-cookies-0... and https://tools.ietf.org/html/draft-west-first-party-cookies-0...

Excerpts (draft 2):

> If "document" is a first-party context, and "request"'s URI's origin is the same as the origin of the URI of the active document in the top-level browsing context of "document", then return "First-Party".

vs. (draft 3)

> A document is considered a "first-party context" if and only if the registerable domain of the origin of its URI is the same as the registerable domain of the first-party origin, and if each of the active documents in its ancestors' browsing contexts' is a first-party context.

> but it got watered down which was a real shame. I'm not sure why.

I think (and this might just be an old wive's tale) it was related to the browser connection limits being per domain, and so subdomains + looser cookie origins was a band aid for it.

Any good references on the definition? I’ve always found it awkward.

The concept of a Site is defined here https://html.spec.whatwg.org/multipage/origin.html#sites

It's basically an origin, but disregarding subdomains.

What reason is there even to use Cookies anymore? Use LocalStorage instead and get better protection as it's not by default being sent around.

Cookies work when JavaScript is disabled or has failed to load (your basic functionality should work without it), localStorage doesn't. So unless we are talking about SPAs cookies are generally the better choice.

The sole reason really is that the contents of a HttpOnly cookie cannot be exfiltrated by an XSS-exploit, while a JWT stored in localStorage could be. This would probably only make a difference if the JWT either has a long lifetime, or is usable outside of the site's origin.

Other than the security implications of HttpOnly (and what it means for XSS), it's also convenience, and works well for small values you want to send with every request anyway, such as user session ids of logged in users and other forms of access tokens[0]. Your frontend code does not have to keep track of such values itself in localStorage (and maintain things like expiration) and it does not have to manually stuff it into each request itself, and so on.

localStorage and IndexedDB on the other hand are most useful for frontend only stuff that the server doesn't need to ever see, and for large chunks of data that you do not want to send with every request, and app-domain specific caches that would be awkward to implement using regular browser caches or ServiceWorkers.

[0] For example, cloudflare implements their "browser checks" anti-DDOS-protections by setting some token in a cookie so your browser isn't hit with that check page on every navigation (at least in theory, TOR users and a lot of VPN users have different experiences). Since the browser will automatically manage and maintain such a cookie, the actual websites behind cloudflare do not need any changes whatsoever to their code.

Cookies are sent with the first request, so the site can customize the response based on user ID. If the site uses local storage to identify the user , it will first have to send some bootstrap page which loads the id and sends it back. Much more cumbersome.

Doesn't local storage imply JS? How would you serve client with JS disabled?

As far as I know...

1. cookies can prevent js access (httpOnly flag)

2. cookies can enforce https only (Secure flag)

I think 1 is the only real argument.. 2 seems less and less relevant with HSTS.

I suppose the other thing you can do with cookies is use cookie prefixes. __Host probably makes no sense in the context of localStorage/sessionStorage anyway though, since they're all tied to the exact domain.

Having HttpOnly set only buys you so much, too. Sure, you can't steal the session from an XSS vector but your code can still do AJAX queries as the victim, potentially set up a JavaScript shell that works whilst the tab is open...

Local storage is per-origin, so anything set on an https page for a certain domain will not be readable on an http page and vice-versa.