Marcello Oliveira

In Production · Frontend · Backend

Running code on other people’s sites

I once built a script that lived inside our customers’ websites. The mechanism that tracks you across the web is the same one; the responsibility is what changes.

By Published 7 min read1 interactive figure

At Social Miner I built and maintained URSA: a script our customers embedded through a pixel, the way you embed Google Tag Manager. It ran in a hostile environment, inside the browser sandbox of sites we did not control and could not test against in advance. Its onsite and offsite parts talked through postMessage, with a small pub/sub on top. Behavior events were batched in IndexedDB and shipped by a service worker, so nothing was lost when someone closed the tab. URSA also captured push-notification permission, which is what made our Push Notification product possible. I led a team of four on it and on the Channel Builder, built with .NET and React.

Code in someone else’s page sees a lot. To understand how much, imagine a large company, call it MOZART, that wants to recognize the same person anywhere on the web without ever knowing who they are. It defines a person as a set of actions: visited the Palmeiras page on globoesporte at 6:30 pm, then the São Paulo state government site at 6:35 pm. From that it guesses: supports Palmeiras, lives in São Paulo, has free time around 6:30. To stitch the visits together it needs only two HTTP headers. The referer says where a request came from. A cookie, mozart.id, identifies the browser. Any site that loads mozart.com/external.png hands over both.

Fig. 1 — One pixel, three sitessimulation · no real requests

Loading interactive figure…

Static version: with a third-party cookie and a full referer, three visits become “supports Palmeiras, lives in São Paulo, has free time around 6:30 pm”.

A pixel is enough

Visit the three sites with everything allowed and watch the profile assemble. Then block third-party cookies: each request arrives anonymous and the visits stop linking. Trim the referer to the origin and “Palmeiras” disappears, because the page path no longer travels. Browsers have moved to that side, limiting third-party cookies and trimming cross-site referers by default.

For code embedded in good faith that is not an obstacle. It is the contract. Every widget, SDK and embedded chat is a guest in someone else’s house, and a good guest:

  • stays isolated, in an iframe or Shadow DOM, with no globals and no leaking CSS;
  • relies only on what was offered, assumes no third-party cookies and a trimmed referer, and asks for anything else explicitly;
  • has a budget for weight and for failure, so that when it breaks the host page stays up.

A one-by-one image used to be enough to learn a team, a city and a time of day. What you do with what arrives is the whole difference.