Unpacking Cookies: From Basics to Future Front‑End Management

Preface

As front‑end developers, we frequently deal with cookie for authentication, tracking, and giving state to the stateless HTTP protocol. This article focuses on cookies, breaking them down and explaining how we use them.

All code examples target Chrome 96.0.4664.55. The article covers four points:

Cookie existing attributes

How cookies are used for tracking

Front‑end management practices

The future of cookies

1. Cookie attributes

Before detailed attributes, recall the official definition:

An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to a user's web browser. The browser may store the cookie and send it back to the same server with later requests. Typically, an HTTP cookie is used to tell if two requests come from the same browser—keeping a user logged in, for example. It remembers stateful information for the stateless HTTP protocol.

Thus a cookie is a small data block stored on the client, created by the Set‑Cookie response header. It can also be created manually via document.cookie.

1.1 Why cookies exist

Cookies originated because servers did not want to store state, so the client had to carry it. They enable stateful interactions over HTTP.

Server does not want to store state

We need to store state

Other storage mechanisms (sessionStorage, localStorage) can replace cookies, but cookies still have unique features such as same‑domain sharing and server‑set capabilities.

1.2 Detailed attributes

Open the browser devtools to view all cookie attributes.

Cookie attribute table

Attribute name

Explanation

name

Cookie name

domain

Domain that can access the cookie

path

URL path that can receive the cookie

Max‑Age

Lifetime in seconds; expires after this many seconds

Expires

Expiration date; if omitted the cookie lives only for the current session

HttpOnly

Prevents JavaScript from accessing the cookie, mitigating XSS

secure

Sent only over HTTPS when true

SameSite

Controls whether third‑party requests can send the cookie (Strict/Lax/None)

SameParty

Chrome‑only attribute for First‑Party Sets cooperation

Priority

Chrome‑only priority (Low/Medium/High) used when storage limits are reached

Key points for each attribute:

name : Same name can be reused on different domains or paths; same domain and path cause overwriting.

value : Must be a string; other types are converted via toString().

domain : Determines which sub‑domains can use the cookie; JavaScript can only set first‑party domains.

path : Must be a prefix of the request URL; affects when the cookie is sent.

Max‑Age : Setting ≤0 deletes the cookie; non‑integer values default to session lifetime.

Expires : Takes a Date object in UTC; Chrome prefers Max‑Age over Expires.

HttpOnly : Server‑only flag, not settable via JavaScript.

secure : Allows JavaScript to set, but only sent over HTTPS.

SameSite : Strict blocks all third‑party requests, Lax allows top‑level navigation GETs, None requires Secure.

SameParty : Works with First‑Party Sets; Chrome‑only and requires Secure and non‑Strict SameSite.

Priority : Chrome‑only, influences eviction order when storage limits are hit.

2. How cookies are used for tracking

Beyond authentication, cookies are the primary tool for advertising tracking. Third‑party cookies (e.g., from .mmstat.com on Taobao) mark users across sites, enabling ad networks to build profiles and serve targeted ads.

Typical flow:

First visit to a site triggers a tiny GIF request that sets a third‑party cookie.

Subsequent page loads send the same cookie together with parameters that reveal the user’s actions (search query, clicked product, etc.).

Other sites that include the same third‑party domain read the cookie and recognize the same user, allowing cross‑site ad targeting.

Example request parameters include search source, product ID, and other behavioral signals that let the ad platform infer interests such as “interested in backpacks”.

3. Front‑end cookie management practice

Common issues include inconsistent behavior across sub‑projects, uncertainty about modifying authentication cookies, name collisions, and domain changes.

Solution: define a schema of all cookies used in the project and manage them centrally.

// cookie-schema.js
{
  cookie1: {
    name: 'cookie1',
    domain: 'root', // root, sub, or current
    path: '/',
    expires: 30 * 24 * 3600 * 1000, // 30 days
    secure: false
  },
  cookie2: {
    name: 'cookie2',
    domain: 'sub',
    expires: 30 * 24 * 3600 * 1000,
    path: '/cookie-test',
    secure: false
  }
}

All cookie operations reference this schema, reducing duplication and errors. A small utility library (e.g., Cookie‑Util ) can enforce the schema.

4. The future of cookies

Privacy concerns are driving browsers to restrict third‑party cookies. Safari already blocks them; Chrome plans to phase them out over the next few years.

4.1 Google’s approach

Chrome introduced SameSite, First‑Party Sets, and Trust Tokens to limit third‑party cookies while preserving legitimate first‑party use cases.

First‑Party Sets allow a group of related domains (owned by the same organization) to share cookies via the SameParty attribute. The group is declared in a JSON file under .well-known/first-party-set.

4.2 Cookie Store API

The new asynchronous Cookie Store API lets service workers read and write cookies more conveniently, but requires HTTPS and has limited browser support.

4.3 What replaces third‑party cookies?

When third‑party cookies disappear, single sign‑on, analytics, and tracking tools will need alternatives such as browser fingerprinting or server‑side identifiers.

End of article