Posted on

Redirect chains used to synchronize advertising identities

A redirect can last less than a second.

That is still enough time to introduce two databases to each other.

Advertising systems often assign their own identifiers to the same browser.

Company A may know the browser as A-1842.

Company B may know it as B-9917.

Those IDs are useless for direct data sharing until somebody learns that they refer to the same browser.

One historical solution is cookie synchronization.

A redirect can carry the introduction

Imagine a browser visiting an advertising endpoint at Company A.

Company A redirects it to Company B using a URL like:

b.example/sync?partner_id=A-1842

When the browser reaches Company B, B can read its own cookie—perhaps B-9917—while also seeing A’s identifier in the URL.

Now a mapping can be built:

A-1842 = B-9917

The browser acted as the courier.

Academic researchers have documented cookie synchronization as an important mechanism for exchanging identifiers between advertising parties. A 2018 study described synchronization as a way for trackers with different local IDs to align those IDs and merge information about users. See Cookie Synchronization: Everything You Always Wanted to Know But Were Afraid to Ask.

MDN’s privacy documentation likewise identifies redirect tracking as a technique in which users are briefly and often imperceptibly sent through a tracker so it can use first-party storage or otherwise participate in recognition. See MDN’s Privacy on the web.

The redirect itself may be visible

Browser developer tools, network logs, or a carefully captured navigation can expose the chain.

You may see:

Site → Ad company A → Ad company B → destination.

You may also see identifiers moving in query parameters.

That is strong evidence that the browser contacted the intermediaries.

It may even reveal an apparent ID exchange.

What it does not automatically reveal is the entire server-side database created from those requests.

Identifiers can be encoded, hashed, short-lived, or translated later. Companies can also synchronize information through server-to-server channels the browser never sees.

Browser defenses changed the technique

Modern tracking prevention has made traditional cross-site cookie access more difficult. Safari, Firefox, and other browsers restrict or partition third-party storage, and advertising systems have responded with other approaches: link identifiers, first-party collection, login-based identity, server-side matching, and newer extended identifiers.

The old redirect chain remains useful because it demonstrates the architecture plainly.

One company does not need to know everything about you.

It only needs a reliable way to say:

The person I call A-1842 is the same browser you call B-9917.

Once that translation exists, separate surveillance systems can start speaking the same language.

Posted on

Shortened URLs as a preservation dependency

A shortened URL is not a pointer to a page. It is a key to somebody else’s lookup table. The address carries no destination at all, only a code that tells the browser whom to ask. Whether an answer ever arrives depends on an intermediary you never chose: the shortening service must still exist, still resolve, and still hold the entry.

A second dependency you never see

goo.gl launched in December 2009 and spread wherever a link had to fit in a sentence: tweets, footnotes, printed books. In 2019 Google stopped accepting new URLs but kept resolving old ones, saying existing links would keep working. That promise had a shelf life. On July 18, 2024, Google announced that goo.gl URLs would stop redirecting after August 25, 2025. It later changed the plan. In an August 2025 update, Google said links that had shown activity in late 2024 would continue to work; links already marked for deactivation would stop redirecting.

Which goo.gl links still work today therefore depends on whether they were popular during one specific recent window. The losers return 404s. The address did not rot; the operator’s decision to keep answering did.

What the archives kept

Recovery depended on capturing the mappings while they still worked. By 2025 the Wayback Machine already held large numbers of goo.gl redirects, and Archive Team ran a dedicated goo.gl preservation project before the August shutdown date. An archived redirect can preserve the original destination even after Google’s live lookup stops answering.

The conditions are strict. A link nobody captured leaves no trace, and a 404 says little about what it once pointed to. After the shutdown goo.gl even returns two flavors of 404: a Google-branded page for codes that used to resolve, a Firebase-branded page for codes that never existed. That is a tombstone, not a map.

Recovery returns an address, not a page

Finding the original URL rebuilds only half of the link. Michael Nelson documented exactly that failure with goo.gl/0R8XX6, one of 26 shortened URLs in a 2017 survey of self-driving-car datasets. The short URL stopped redirecting in 2025, and its Carnegie Mellon destination no longer resolved either. Recovering the citation required archives of both the redirect and the destination page.

A shortened URL is a preservation dependency: part of the address lives on infrastructure you do not own. TinyURL has outlived many of its targets, and bit.ly may outlive more. The point is not that any one service will fail, but that several already have, and that each failure moves the cost of rescue onto archives and readers. When a link matters, shorten the convenience, not the citation: keep the full URL and the content itself, and treat the short code as a fetch address rather than a record of what exists.