Session Replay, Chat Widgets and Pixels: The Website Wiretapping Wave

The tools at the centre of this are ones almost every agency installs by default and almost no client thinks about: an analytics pixel, a session replay script, a live chat widget. Standard equipment, added in an afternoon, usually years ago.

Over the past few years plaintiffs have recast them as interception devices, using state wiretapping statutes written long before the web. The theory sounded strained at first. It has since produced a large volume of filings, settlements in the millions, and a genuinely unsettled body of law.

This is a fast-moving area — one significant piece of California legislation was awaiting signature as this was written — so treat the position below as a snapshot, and check current status before acting on it.

How analytics became wiretapping

The core argument runs like this. When you embed a third party's script, your visitor's interactions with your site are transmitted to that third party in real time. The plaintiff says that is a communication between them and you, intercepted by a third party without consent — which is what an anti-wiretapping statute prohibits.

California's Invasion of Privacy Act is the statute of choice, for the same reason Unruh dominates accessibility litigation: statutory damages. CIPA provides for $5,000 per violation, without proof of actual harm. Multiply that by a site's visitors and the exposure arithmetic becomes obvious, which is why settlements have run from seven figures into the tens of millions.

Two theories are in play, and the distinction matters more than it used to.

Section 631 — wiretapping. The classic interception claim, aimed at the content of a communication. This is the theory behind most chat-widget and session-replay cases.

Section 638.51 — pen register and trap and trace. A newer and more aggressive theory arguing that pixels and SDKs capture addressing and routing information in the way a pen register does. Courts have split on it, with some allowing claims to proceed and others rejecting the analogy outright.

The millisecond problem

The pattern that defeats most good-faith compliance efforts deserves its own heading, because organizations that believe they have solved this usually have not.

Your consent banner loads. In the few hundred milliseconds before the visitor sees it, let alone clicks it, the analytics tag and the advertising pixel have already fired and already transmitted. Consent obtained afterwards does not retroactively authorise an interception that has already happened.

So a site can have a well-designed cookie banner, an accurate privacy policy and a documented consent process, and still be exposed — because the technical implementation lets tags fire before the choice is made. This is a tag-management problem, not a policy problem, and it is invisible from the legal side of the organization. It has to be checked in the browser.

Healthcare is the sharp end

The exposure is worst where the page itself reveals something sensitive. A visitor reading about a condition, searching a provider directory for a specialty, or starting an appointment request may transmit, through an advertising pixel, something that looks a great deal like health information — with the additional problem that it may also be a HIPAA matter.

Health systems have settled pixel cases covering millions of patients, with individual settlements in the eight figures.

The picture is not uniformly bad for defendants. A California federal court held in November that data reflecting a visit to a public webpage is not protected health information where it does not reveal anything about the person's conditions, care or interactions with a provider. That is a meaningful narrowing, and it draws the line roughly where instinct would put it: a marketing page is different from an authenticated portal or a symptom-specific journey.

If you run a healthcare site, this belongs alongside the HHS accessibility deadline on the same list. The two exposures sit on the same pages and are usually owned by the same person.

What California SB 690 does, and does not, fix

California has legislated in response. SB 690 restricts the pen-register and trap-and-trace theory, reserving those covered claims to the Attorney General rather than private plaintiffs.

Three qualifications, all of which matter.

First, as of early September 2026 the bill had passed the legislature but had not been signed. Check its current status before relying on it.

Second, it addresses Section 638.51. It does not remove the Section 631 wiretapping theory, which is the basis of a large share of chat and session-replay claims. Private CIPA litigation over website tracking does not end with this bill.

Third, CIPA is not the only statute. Other states have their own two-party consent and wiretapping laws, several with private rights of action, and plaintiffs have been filing under them. A California-specific fix does not resolve a nationwide theory.

Read SB 690 as narrowing one aggressive theory in one state, not as the end of the wave.

What actually reduces exposure

Five things, roughly in order of effect per hour spent.

Inventory what is actually running. Open your own site with the browser network tab and list every third-party request. Most organizations find tags nobody remembers adding, from campaigns that ended years ago. Every one of those is exposure with no corresponding benefit, and removing them is free.

Fix the firing order. Ensure no non-essential tag fires before consent is recorded. This is the highest-value technical fix available and the one most often assumed rather than verified. Test it in the browser; do not take the tag manager's configuration on trust.

Treat sensitive pages differently. On health, legal, financial and similar journeys, consider disabling third-party tracking entirely rather than relying on consent. The marginal analytics value is small; the marginal risk is not.

Check what your tools capture. Session replay tools can record form inputs. Confirm that fields are masked, and confirm it by watching a session rather than by reading the settings page.

Get the paperwork consistent. Your privacy policy should describe what you actually do, your consent mechanism should do what the policy says, and your vendor agreements should reflect the roles involved. A policy describing a configuration you no longer run is worse than no policy.

The uncomfortable summary

This area is genuinely unsettled. Courts disagree, legislatures are intervening, and the theories keep evolving — email tracking pixels are now drawing the same claims. Anyone offering you certainty here is overselling.

What is not unsettled is the practical advice, because it is the same advice regardless of how the law resolves: know what is running on your site, do not let it fire before consent, and be more careful on pages that reveal something about the person reading them. That reduces exposure under every theory simultaneously, and it is worth doing on its own terms.

For the wider picture of what applies to your site, see website legal requirements and website privacy and data protection. This article is general guidance and not legal advice; given how quickly this area is moving, anything you act on should be checked with counsel against the current position.