Tag: surveillance-economy-the-internet-watching-you-back

Posted on by

Form-field collection before a user submits the form

Most people treat the Submit button as a boundary.

Before the click, the form feels unfinished.

After the click, the information has been sent.

Technically, a webpage does not have to respect that mental model.

JavaScript running on the page can react while the user types.

That can be useful. A form may validate an email address, calculate shipping, save progress, or warn that a password is too short.

It also means data can potentially leave the page before the user submits the form.

Researchers measured this in the wild

A 2022 USENIX Security study called Leaky Forms examined the top 100,000 websites and looked for email and password data transmitted before form submission.

The researchers found email addresses being sent to tracking, marketing, and analytics domains before submission on 1,844 websites in their EU crawl and 2,950 websites in their U.S. crawl. They also reported incidental password collection on 52 sites associated with third-party session-replay scripts. See Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission.

Those numbers describe that study’s 2022 measurement and methodology.

They should not be casually converted into a claim about every website today.

The important finding is that the behavior is technically real and measurable.

The interface can imply a boundary the code does not use

Imagine entering an email address into a newsletter box.

You pause.

You decide not to subscribe.

You close the tab without pressing anything.

From your perspective, the transaction never happened.

If a script already transmitted the email address when the field lost focus, the site’s data history may disagree.

That is a sharp example of the difference between user intent and event-driven software.

The browser does not inherently reserve typed text until submission. Page scripts may be able to observe input events as they occur.

Not every pre-submit interaction is abusive

A site can process input early for legitimate reasons: fraud detection, validation, autosave, accessibility, or recovering an interrupted form.

So seeing JavaScript react to a field is not enough to prove covert tracking.

A stronger investigation asks whether the value actually leaves the browser, where it goes, whether it is transformed or hashed, which party receives it, and what the stated purpose is.

Network capture and script instrumentation can provide that evidence.

The Surveillance Economy becomes most revealing where interface assumptions and software behavior diverge.

The button says Submit.

The code may have started listening several keystrokes ago.

Posted on by

Session replay and the recording of user interactions

Some analytics dashboards do not just tell a site owner that you visited a page.

They can reconstruct how you moved through it.

That category is usually called session replay.

The name sounds like a screen recording, but many systems do not capture literal video. They record enough page structure and interaction events to rebuild an animation of the visit later.

Microsoft Clarity describes its own recordings this way: the service captures page information from the DOM along with user actions such as mouse movements, clicks, and scrolling, then reconstructs the session for playback. See Microsoft Clarity’s current FAQ.

The browser becomes a source of choreography

A replay can show where the visitor moved the pointer.

Where they clicked.

How far they scrolled.

Which page state appeared after a menu opened.

How long they hesitated before moving elsewhere.

For usability work, that can be genuinely useful. A developer can discover that visitors repeatedly click something that is not a button, fail to notice a form field, or abandon a page at the same confusing step.

The privacy issue is that interaction detail can reveal much more than an ordinary page-view counter.

Redaction determines what the recording actually contains

Modern session-replay products usually include masking controls.

Microsoft says Clarity masks sensitive content by default, always masks text entered in input boxes and drop-downs, and lets administrators choose stricter or looser masking for other page elements. It also says masked content is not uploaded to Clarity. See Clarity’s masking documentation.

That is an important distinction.

Saying this site uses session replay does not tell you exactly what sensitive information was captured.

You need to know the product, version, configuration, page structure, and masking rules.

A properly configured system may exclude fields that would be dangerous to record.

A poorly configured one can expose much more.

Visitors usually see the interface, not the recorder

The strange part is psychological.

A person experiences an ordinary webpage.

They do not necessarily experience it as a recording surface.

Nothing about scrolling halfway down an article feels like a deliberate disclosure of behavioral data.

Yet those movements can become analytics events.

That gap between interface and instrumentation is central to the Surveillance Economy.

A click can be both an action and a measurement.

A pause can be both indecision and a data point.

The replay does not need a camera.

The webpage already knows enough about its own behavior to reconstruct much of what happened.

Posted on by

Server-side tracking and the limits of browser-visible inspection

Browser developer tools are excellent at showing what the browser sends.

They are much worse at showing what a server does afterward.

That sounds obvious, but it becomes important when tracking moves server-side.

Traditional client-side analytics often has the browser contact several outside services directly. Open the network panel and you may see requests heading to analytics, advertising, testing, or personalization companies.

Server-side tracking can change that picture.

The browser can hand everything to one server

Google’s Server-side Tag Manager documentation describes the architecture plainly.

Instead of having a page send measurement data directly to multiple collection services, a website or app can send events to a server container. That server processes the event and can then route data onward according to configured tags. See Google’s introduction to server-side tagging.

Google notes that the server runs outside the user’s browser and that the operator controls how incoming event data is transformed and where it is routed.

From the browser’s perspective, the visible request may simply be:

analytics.example.com/collect

The browser can prove that it sent data there.

It cannot automatically see the later server-to-server request from that endpoint to another company.

Missing browser traffic is not proof of missing sharing

This creates a major inspection trap.

An investigator blocks every obvious third-party request, reloads the page, and sees only first-party network traffic.

That can establish something useful: the browser did not directly contact those third-party domains during the observed session.

It does not establish that the website’s server never forwarded related data elsewhere.

To answer that question, stronger evidence may be needed: server logs, tag-manager configuration, privacy disclosures, vendor contracts, API documentation, packet capture on the server side, or statements from the companies involved.

The absence of a browser-visible request is evidence about the browser.

It is not a subpoena for the backend.

Server-side collection is not automatically worse

This architecture can also improve privacy.

Google’s documentation emphasizes that server-side tagging can let the site operator remove, transform, or control data before sending it onward. Fewer third-party scripts in the page can improve performance and reduce direct exposure of browser data.

So the fact that tracking is server-side does not by itself prove secret misuse.

The important questions are what data enters the server, what is removed, what is retained, and which parties receive the output.

That is why Surveillance Economy research cannot stop at the network tab.

The browser shows the first handoff.

The rest of the conversation may continue after your machine is no longer in the room.

Posted on by

First-party tracking arrangements that conceal third-party involvement

The browser says the request went to track.example.com.

That does not necessarily mean Example Company operates the tracker.

Modern tracking systems increasingly try to look first-party from the browser’s point of view. The request uses the visited site’s own domain or subdomain, even though an outside analytics or advertising company may operate the infrastructure behind it or receive the resulting data.

This matters because browser privacy defenses often treat first-party and third-party resources differently.

A familiar hostname can hide an unfamiliar operator

One documented technique is CNAME cloaking.

A site can configure a subdomain such as:

metrics.news.example

to resolve through DNS to infrastructure belonging to an outside tracking provider.

To the browser’s ordinary web-layer view, the request appears to go to a subdomain of news.example.

Underneath, the DNS configuration points elsewhere.

WebKit documented this practice while explaining Safari’s CNAME-cloaking defenses. Its example shows a site-controlled subdomain resolving to a third-party tracker, giving the outside service first-party-looking access. See WebKit’s CNAME Cloaking and Bounce Tracking Defense.

WebKit cited research that found thousands of sites using this arrangement with dozens of trackers.

First-party appearance does not establish first-party control

This is the important investigative lesson.

A request hostname can tell you where the browser believes it is sending traffic.

It cannot by itself tell you:

  • who operates the server,
  • who contracted for the service,
  • who receives copies of the data,
  • what database the event enters,
  • whether the vendor can reuse the information elsewhere.

Those answers may require DNS records, privacy policies, vendor documentation, contracts, server configuration, or direct observation of downstream data flows.

Likewise, using a vendor does not automatically mean the site has surrendered control of the data. A third party can process information strictly on behalf of a first party under contractual limits.

The architecture has to be examined rather than assumed.

Browser defenses noticed the camouflage

Safari’s Intelligent Tracking Prevention added specific defenses against third-party CNAME cloaking. WebKit’s current tracking documentation also discusses third-party CNAME and IP-address cloaking as techniques its protections try to detect. See Tracking Prevention in WebKit.

That evolution shows why the simple phrase block third-party trackers became technically slippery.

If the tracker can borrow the site’s own hostname, the third party no longer looks third-party at first glance.

The Surveillance Economy does not only collect data.

It also changes where collection appears to happen.

The address bar and network panel are useful evidence.

They are not always the corporate org chart.

Posted on by

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 by

Link decoration that carries identifiers between websites

Sometimes the tracking identifier is not hiding in a cookie.

It is sitting in the address bar.

A URL can carry extra information after a question mark or fragment:

shop.example/?campaign=summer&id=847219

Some of that information is harmless campaign attribution.

Some of it can identify or help recognize a particular user.

This technique is often called link decoration.

The link becomes the courier

Suppose a social site knows a user as account 847219.

When that user clicks a link to a store, the social site can append a click identifier to the destination URL. The store, or a script running there, can read that identifier and potentially connect the visit back to the source.

WebKit documented this pattern while describing Safari’s tracking defenses. Its example shows a social network adding a click ID to outgoing links; once the user lands on another site, embedded scripts can read the identifier and store or report it. See WebKit’s explanation of cross-site tracking via link decoration.

MDN’s current privacy guide makes the same broader point: URL parameters can carry campaign information, email addresses, or other identifiers from one context into another. See MDN’s Privacy on the web.

Not every decorated link is surveillance

A parameter such as:

utm_campaign=spring_sale

may simply tell a merchant which advertisement or newsletter produced the visit.

That is different from attaching a stable user-specific ID that can be associated with activity across destinations.

The important question is what the parameter represents and what happens after it arrives.

A campaign label describes the traffic source.

A persistent user identifier can describe the visitor.

Those uses should not be collapsed into one accusation merely because both live in a query string.

Removing one obvious parameter may not end tracking

Browsers and privacy tools increasingly strip, limit, or defend against known forms of link decoration. Safari, for example, has long restricted storage behavior associated with cross-site tracking through decorated links.

But the URL is only one possible connection.

The destination may also recognize a logged-in account, receive server-side data, use a first-party identifier, derive a fingerprint, or connect the visit through another advertising system.

Deleting ?id=847219 removes that particular visible signal.

It does not prove that all other links between the two services disappeared.

That is why decorated URLs are so useful for studying the Surveillance Economy.

They expose the plumbing.

For a moment, the identifier is not buried in a database or browser storage.

It is literally traveling inside the link.

Posted on by

Browser fingerprinting without a conventional tracking cookie

Deleting a cookie removes a stored identifier.

It does not necessarily make the browser indistinguishable from every other browser on Earth.

That is where fingerprinting enters the story.

A website can observe characteristics exposed during an ordinary visit: browser version, operating system, language, time zone, screen dimensions, graphics capabilities, supported features, font behavior, and other details.

Any one property may be common.

The combination can be much less common.

The identifier can be calculated instead of stored

A cookie works by writing a value and reading it later.

Fingerprinting can work differently.

The site asks the browser a collection of questions, combines the answers, and computes a signature. On a later visit, it asks similar questions again and compares the new signature with previous ones.

Nothing requires a file named tracker_id=12345 to sit in the cookie jar.

Mozilla describes fingerprinting as an attempt to identify users through a set of characteristics of their browser or device. Firefox now includes Fingerprinting Protection, while its stricter Resist Fingerprinting feature deliberately reduces or standardizes exposed differences. See Mozilla’s current fingerprinting guidance.

The reason those defenses exist is straightforward: uniqueness itself can become an identifier.

A fingerprint is not a magic serial number

This is where explanations often become too dramatic.

Browser fingerprints are generally probabilistic and context-dependent.

Devices update. Fonts change. Window sizes change. Browsers reduce exposed information. Privacy tools deliberately make many users look alike. Two machines can share enough characteristics to collide, while one machine can change enough to look new.

So a fingerprint can be a strong recognition signal without being equivalent to a hardware serial number.

A tracking company may also combine fingerprinting with other evidence such as account logins, IP-derived information, cookies, advertising IDs, or link identifiers.

The confidence comes from the bundle.

Cookie blocking changes the economics, not the desire to recognize

Firefox’s privacy documentation says the browser protects against known third-party trackers and fingerprinting technologies. Safari’s Tracking Prevention Policy likewise defines tracking broadly enough to include methods beyond cookies. See Firefox’s privacy notice and WebKit’s Tracking Prevention Policy.

That broader framing matters.

If privacy protection focused only on cookies, the incentive would be obvious: replace the blocked identifier with something computed from the browser itself.

Modern defenses increasingly treat recognition across contexts as the underlying problem rather than one specific storage mechanism.

That is the Surveillance Economy’s recurring lesson.

The cookie was never the goal.

The goal was remembering which browser came back.

Posted on by

Email open tracking and the uncertainty of its measurements

An email service can report that you opened a message without ever seeing your eyes.

Usually it saw an image request.

Email-open tracking commonly works by placing a tiny remotely hosted image inside an HTML message. Mailchimp describes its own implementation this way: when open tracking is enabled, it embeds a tiny invisible graphic in the email. When the graphic is requested, the service records an open. See Mailchimp’s explanation of open tracking.

That is a useful measurement.

It is not a perfect description of human behavior.

A loaded image is not the same thing as a read message

Consider the chain:

  1. The message arrives.
  2. The mail client loads remote content.
  3. The tracking image is requested.
  4. The sender records an open.

The fourth step is real.

The assumption is that step two happened because a person opened and read the message.

Sometimes it did.

Sometimes software loaded the image for privacy, caching, security scanning, previewing, or other automated reasons.

Apple’s Mail Privacy Protection is a major example. Apple says the feature hides a user’s IP address when remote email content is fetched, preventing senders from using that IP to determine location or connect it to other online activity. See Apple’s Mail Privacy Protection support documentation.

Mailchimp explicitly warns that bot or proxy activity such as Apple’s Mail Privacy Protection can falsely inflate open metrics. See Mailchimp’s open and click rate documentation.

False negatives happen too

The uncertainty runs in both directions.

A person can genuinely read an email while their client blocks remote images.

A plain-text reader may never request the tracking image. A privacy tool may strip it. A proxy may cache one copy and reuse it. Network failures can interrupt loading.

So a missing pixel request does not prove that nobody read the message either.

That leaves marketers with a measurement that is useful in aggregate but fuzzier at the individual level than the word open suggests.

Better language produces better conclusions

A tracking system may know:

The remote resource associated with this message was requested.

From that, it may infer:

The email was opened.

What it usually cannot prove is:

A specific human carefully read and understood the message at 9:14 AM.

That distinction matters because open data can drive automation. A recipient may be segmented, retargeted, scored as engaged, or sent a follow-up based on the signal.

The Surveillance Economy does not only collect data.

It builds decisions on top of measurements whose confidence is easy to forget.

Sometimes the machine knows that an image loaded.

Then the dashboard upgrades that fact into a human action.

Posted on by

Tracking pixels embedded in ordinary web pages

A tracking pixel can be one pixel tall.

It can also be completely invisible.

The important part is not the picture.

The important part is the request.

When a browser loads an ordinary web page, that page can instruct it to fetch additional resources from other servers: images, scripts, fonts, analytics endpoints, advertisements, social widgets, or a tiny transparent image whose visual contribution is essentially zero.

Fetching that resource tells the receiving server that a browser loaded it.

That sounds trivial until the request is connected to an identifier.

A page can quietly contact companies you never visited

Suppose you visit:

localnews.example/story

The page includes an image from:

tracker.example/pixel.gif?id=847219

Your browser may then contact tracker.example even though you never typed that domain into the address bar.

Depending on the request and browser configuration, the server can receive information such as the requesting IP address, browser headers, the requested URL, timing, referrer information, and cookies previously associated with that tracker.

Mozilla’s privacy documentation describes third-party tracking as the collection of browsing activity through resources embedded across multiple sites. Its broader web-privacy guide also notes that tracking can occur through cookies, referrer information, decorated links, redirects, and other mechanisms. See MDN’s Privacy on the web.

The pixel is therefore less like a microscopic camera and more like a doorbell.

Loading the page rings it.

The visible request is evidence, not the whole data map

Browser developer tools can often reveal that the request occurred.

That is useful evidence.

It does not automatically tell you everything the receiving company later does with the event.

A network request may contain an identifier but not reveal the database record attached to it. The server might discard the request, count it anonymously, associate it with an advertising profile, combine it with account information, or forward it elsewhere.

The browser-visible packet does not answer all of those questions.

Likewise, seeing a third-party request does not automatically prove that the company is following the person across multiple sites. Cross-site tracking requires some way to recognize or link activity between contexts.

Modern browsers block some of this machinery

Firefox’s Enhanced Tracking Protection blocks known cross-site trackers and isolates other third-party cookies using Total Cookie Protection. Safari’s tracking-prevention system also restricts multiple forms of cross-site tracking. See Firefox’s tracking-protection documentation and WebKit’s Tracking Prevention Policy.

Those defenses make old tracking techniques less reliable.

They do not make embedded requests disappear as a concept.

Ordinary pages still load resources from other places constantly.

That is the first lesson of the Surveillance Economy.

The page in front of you may belong to one website.

The network conversation behind it may involve several more.

Posted on by

Third-party cookies and the construction of cross-site browsing histories

You visit a shoe store.

Then a newspaper.

Then a recipe site.

Three unrelated websites.

One advertising company may have been present on all three.

That is the basic trick that made third-party cookies one of the classic technologies of cross-site tracking.

The cookie is ordinary; the context makes it third-party

There is no magical file format called a third-party cookie.

WebKit’s tracking documentation explains the distinction clearly: if news.example is in the address bar while the page loads a resource from adtech.example, the news site is the first party and the ad-tech domain is a third party. If the browser allows that third party to read and write its cookies in this context, those cookies can carry an identifier across sites. See WebKit’s Tracking Prevention documentation.

Imagine the browser receives this identifier from the tracker:

user=847219

Later, another unrelated site loads the same tracker.

If the browser sends user=847219 again, the tracker can recognize the same browser.

Now the tracker can associate both visits with one identifier.

Repeat that across hundreds of participating sites and the result can become a browsing history.

A browsing history reveals patterns, not just pages

One visit says little.

A sequence can say much more.

Travel research followed by mortgage calculators, moving companies, and school-district pages may suggest a relocation.

Repeated visits to automotive sites can reveal purchase interest. Visits to hobby stores, political publications, technical forums, financial pages, or health-related sites can contribute additional categories and inferences.

Mozilla’s current Firefox documentation describes cross-site cookies in similar terms: when the same tracker appears on multiple sites, it can use cookies to build a more complete profile of browsing activity over time. See Mozilla’s explanation of third-party trackers.

That profile does not require the person to intentionally visit the tracking company’s own website.

The tracker rides inside other pages.

Browsers have sharply restricted this technique

The old third-party-cookie model no longer works uniformly across browsers.

Safari blocks third-party cookies by default as part of Intelligent Tracking Prevention. Firefox enables Total Cookie Protection by default, isolating third-party cookies into separate per-site cookie jars so the same cookie cannot simply follow the browser across unrelated sites.

Chrome took a different path. Google announced in April 2025 that it would maintain user choice for third-party cookies rather than roll out a new standalone prompt or complete a universal deprecation. Chrome blocks third-party cookies by default in Incognito mode, while regular browsing exposes controls that let users allow or block them. See Google’s April 2025 Privacy Sandbox update and Chrome’s cookie controls.

So in 2026, saying browsers killed third-party cookies is too broad.

The reality depends on the browser and settings.

Blocking cookies does not end tracking

Trackers can also use link decoration, browser fingerprinting, first-party storage, account logins, server-side data sharing, IP-derived signals, and other techniques.

WebKit’s own tracking-prevention work discusses defenses against several of those methods because restricting one identifier creates incentives to find another.

That is why third-party cookies belong at the beginning of Surveillance Economy — The Internet Watching You Back, not the end.

They are the easiest version of the idea to see.

You thought you were visiting three websites.

The interesting question is whether a fourth company quietly recognized you at all three.