Tor Browser window.name Isolation Spec

Isolation Mechanism

Historically, the DOM property window.name retained its string value across every cross-origin navigation inside the same browser tab, creating a covert tracking and data-exfiltration channel during link clicks. Tor Browser pioneered clearing window.name on cross-origin navigation, a safeguard later adopted by the HTML Living Standard whenever a navigation triggers a browsing context group switch.

Sources: Tor Browser Spec (msg01829), HTML Living Standard, COOP RFC Model.

1. The `window.name` Persistent Tab Vector

In the classic pre-2020 DOM specification, window.name existed to let target="..." hyperlinks and window.open() calls address a named browsing context. Because the specification tied window.name to the top-level browsing context rather than the active document's origin, any JavaScript running on https://origin-a.example could write up to several megabytes of JSON identifiers into window.name. When the user clicked a link or followed a redirect to https://origin-b.example, script on the destination origin could immediately read window.name in clear text.

In April 2014, the Tor Browser Specification commit archived at archives.seul.org/tor/cvs/Apr-2014/msg01829.html explicitly flagged window.name under cross-origin link-click tracking channels alongside the HTML5 <a ping> attribute and JavaScript link rewriting. Immediately beneath those warnings, the same Tor specification document listed Web-Send Introducers as a Promising Standard capable of delivering federated login and link sharing without exploiting link-click side channels.

Three physically separated brushed aluminum RF shielding compartments with emerald anodized lock pins on a slate laboratory bench — **Plate 03:** Physical analogy for isolated browsing context groups where state containers remain severed across origin boundaries.

2. Legacy Persistence vs. Browsing Context Group Reset

3. Cross-Origin Click & Navigation Side-Channel Matrix

Tor Browser's design document grouped window.name with several adjacent cross-origin leakage paths. The table below maps each historical vector from the Tor specification against its modern browser defense.

Table 1. Cross-Origin Navigation Side Channels Tracked in Tor Browser Spec & Modern Defenses
Side-Channel Vector	Historical Mechanism	Tor Browser Defense	Modern Standard Mitigation
`window.name`	Tab-scoped string persists across cross-origin clicks	Cleared to empty string on cross-origin load	HTML Living Standard clears on BrowsingContextGroup switch
`<a ping="...">`	Asynchronous POST beacon on link click	Disabled (`browser.send_pings = false`)	Blocked by privacy browsers; visible in Fetch DevTools
`document.referrer`	Full URL path & query string sent cross-origin	Trimmed / stripped on cross-origin transitions	Default `strict-origin-when-cross-origin`
`window.opener`	Cross-origin popup retains handle to opener tab	Isolated per first-party domain	Implicit `noopener` on `target="_blank"` + COOP
HTTP Cache Timing	Probing whether third-party asset is cached	First-Party Isolation keyed HTTP cache	Network State Partitioning across top-level sites

4. Application-Level Isolation Hardening

Even on modern Chromium and WebKit engines, relying solely on default browser heuristics leaves an opening when a popup retains a window.opener reference across origins. Applications handling sensitive tokens or capability URLs should enforce three deterministic protections:

Emit Cross-Origin-Opener-Policy: same-origin on sensitive origins so cross-origin navigations unconditionally sever window.opener and reset window.name.
Emit Referrer-Policy: no-referrer or strict-origin-when-cross-origin so query strings are never leaked cross-site.
Store transient client tokens in origin-bound sessionStorage or in-memory closures rather than window.name, and validate event.origin on every postMessage listener.

Tor Browser Design Evolution: TBB 3.6 to Mullvad & Chromium Storage Partitioning

When Mike Perry and the Tor Browser engineering team documented the April 2014 specification update archived at archives.seul.org, mainstream browsers still treated top-level browsing context properties as globally shared convenience slots. In Firefox and Chromium builds prior to 2020, navigating an ordinary anchor tag from an e-commerce store to an unrelated news publisher preserved the exact string assigned to window.name in the source document. Cross-site analytics scripts routinely read window.name alongside document.referrer to stitch user sessions whenever third-party cookies were disabled or blocked by tracker lists.

Tor Browser countered this class of side-channel leak through two complementary mechanisms: First-Party Isolation (FPI) keyed persistent state (cookies, HTTP cache, HSTS, OCSP, TLS session tickets, and TLS channel IDs) by the top-level URL bar domain, while explicit navigation hooks cleared window.name whenever the document exited the same-origin trust boundary unless a deliberate script-opened window maintained a non-null opener relationship. By scoping every storage jar to the first-party site tuple rather than the embedded script origin alone, FPI eliminated silent linkability between two unrelated publishers embedding the same social share widget or analytics tag.

Between 2020 and 2026, those same isolation invariants entered the baseline web platform. Safari's Intelligent Tracking Prevention (ITP), Firefox's Total Cookie Protection (dynamic state partitioning), and Chromium's Storage Partitioning converged on a dual-keyed or triple-keyed model matching the original Tor threat taxonomy. At the DOM layer, Section 7 of the WHATWG HTML Living Standard codified explicit rules for clearing window.name whenever a browsing context performs a cross-origin navigation across browsing context groups. Combined with implicit rel="noopener" on target="_blank" links, an outbound click from one publisher to another now swaps into a fresh browsing context group with a reset window.name string.

Operational Verification for Modern Applications

Security auditors checking legacy single-page applications or OAuth/OIDC redirect flows should still inspect codebase references to window.name. Older JavaScript transport polyfills, such as pre-CORS cross-domain iframe hacks and some legacy enterprise federation adapters, explicitly serialized serialized JSON payloads inside window.name across origins. On hardened modern user agents, those flows silently fail with an empty string unless upgraded to structured window.postMessage handshakes guarded by strict origin allowlists.

Equally important is protecting outbound links against reverse tabnabbing and opener-mediated state retention. When a publisher must open an untrusted external service in a new tab while preserving same-origin tab performance and strict isolation, attaching both Cross-Origin-Opener-Policy: same-origin on response headers and explicit rel="noopener noreferrer" on external anchors guarantees that neither window.opener nor window.name can carry cross-site identifiers across the navigation boundary. Security teams auditing third-party embeds should test cross-origin link transitions inside Chromium DevTools and Tor Browser to verify that every browsing context group boundary drops both opener handles and tab-scoped string state cleanly.

Proceed to the Interactive Isolation Sandbox to generate and test exact COOP, COEP, and Partitioned cookie policies for your origin boundary, or inspect how Web Introducer and Bookmark Introducer eliminated link-click tracking altogether in 2010.