Pimp My IDE / garage dispatchBack to dispatches
October 12, 2026 / browser privacy / interface craft

Your browser keeps introducing itself.

Delete a cookie and its stored label is gone. A site can still combine browser, display, language, graphics, and audio traits into a new identifier.

Test fingerprints as repeated observations. Change the site, session, and browser posture. Record which traits stay stable and which defense changes them.

Storage is one input

MDN defines browser fingerprinting as the collection and combination of browser and operating-system traits. Examples include browser version, timezone, language, codecs, fonts, settings, and display size. JavaScript and CSS can expose enough traits for a site to distinguish one browser from others.[2]

Cookies work differently. They store an identifier in the browser. A fingerprint derives an identifier from observations. Clearing storage can break the first route while leaving the second route available.

A privacy test needs several visits. One screenshot cannot tell you whether an identifier survives a new site or session.

Consistency is the payload

Roy Fish's live essay combines audio, graphics, canvas, timezone, and hardware readings into a nickname and hash. The page invites readers to refresh, clear cookies, change network routes, and compare another device.[1]

The demonstration is useful because it treats identity as a comparison. A single hash proves only that a script produced a value. Repeated matching values show stability inside the tested conditions. They do not prove global uniqueness, one person per value, or tracking by a named company.

Two defenses make different promises

Brave describes a randomization approach called farbling. It derives values per site and session so one site receives a stable value during that session while another site, or a later session, receives a different value. Brave also states that its default defense uses real traits and may not stop a motivated targeted attack.[3]

Tor Browser takes a crowd strategy. Its documentation describes standardized values, window letterboxing, and other changes intended to make users less distinguishable from one another. Tor warns that user-selectable identity options can make a browser more unusual.[4]

Randomization tries to break correlation. Standardization tries to enlarge the group that shares the same observable values. These are different test plans. Neither is captured by a green privacy badge.

Run the test without collecting people

  1. Use a disposable browser profile and a page you control.
  2. List every trait the fixture reads before the run.
  3. Save no raw fingerprint beyond the test window.
  4. Visit twice in one session. Record stable and changed traits.
  5. Start a new session and repeat on the same site.
  6. Repeat on a second site you control.
  7. Change one browser defense, then rerun the same matrix.
  8. Delete the fixture records and confirm deletion.

Do not turn a privacy test into another tracking database. The smallest useful record is a matrix of match or change results, the browser posture, and the deletion receipt.

Interactive teaching fixture

Fingerprint drift booth

Traditional purpose: compare fingerprints across visits. This booth joins the defense strategy, collected surfaces, three visit plates, and a copyable test brief. It uses invented signatures and reads no device traits.

CollectCombineCompareDecide

Test posture

Choose one browser posture. Then select the surface groups that the controlled fixture will be allowed to read.

Defense strategy
Surface groups selected
TEST MATRIX INCOMPLETE2 of 4 surface groups selected

Three visit plates

The same invented signature appears on both sites and the new session. This models correlation, not a real browser result.

Site ASession 1
FP-81C4
Site ASession 2
FP-81C4
Site BSession 1
FP-81C4
CROSS-VISIT MATCHAll three plates match. The fixture would need retention and correlation controls before any real test.
Sources read / October 12, 2026 UTC

Source log

Open the evidence boundary
  1. Roy Fish, "Fingerprints are the new cookies", read October 12, 2026. This was the discovery route. The page demonstrates a browser-side fingerprint assembled from several traits and explains entropy, correlation, and two broad defense strategies. Its live result applies only to the browser and session that loads it.
  2. MDN, "Fingerprinting", read October 12, 2026. MDN defines fingerprinting and lists browser, operating-system, language, codec, font, settings, and display traits that sites can combine.
  3. Brave, "Fingerprinting defenses 2.0", published May 18, 2020 and read October 12, 2026. Brave describes per-session and per-site randomization, its compatibility goal, and its limits against targeted attacks. This is Brave's account of its own design.
  4. Tor Project, "How Tor Browser protects you against browser fingerprinting", read October 12, 2026. Tor documents standardized values, letterboxing, and the reason it avoids user-selectable operating-system identities. This is Tor's account of its own browser.
  5. Hacker News item 50048642, resolved through the official API and read October 12, 2026. It was a discussion route. It supports none of the technical claims.

Evidence boundary: this dispatch reads public documentation and one live demonstration. It does not compare browser builds, audit implementation code, measure anonymity sets, identify a tracker, or prove that any defense stops targeted fingerprinting. The booth uses fixed invented values and does not read, hash, transmit, or store device traits.