What Session Replay Actually Records — and Why Courts Disagree About 'Interception'

Session replay is often described, loosely, as "recording your screen." That description is wrong in a way that matters legally. The replay you watch in a vendor dashboard is not a video that was captured off the visitor's display. It is a reconstruction, rebuilt after the fact from a stream of structured events. How that stream is produced and when it travels is exactly the technical question several wiretapping cases now turn on.

What the script actually does

When a replay library — Microsoft Clarity, FullStory, Hotjar, LogRocket, Contentsquare, and others work similarly — loads on a page, it does roughly four things.

First, it takes a serialized snapshot of the initial DOM: the full HTML structure of the page as rendered, captured as data rather than as an image. Second, it attaches a MutationObserver to watch for every subsequent change to that DOM — a price updating, a menu opening, an error message appearing. Third, it registers listeners for user-input events: clicks, scrolls, mouse movement, key presses, and form-field changes. Fourth, it batches these events and transmits them to the vendor's servers, usually as compressed payloads sent by background fetch or beacon requests to an endpoint like the vendor's ingestion domain.

On the vendor side, a player (the open-source rrweb is the common reference implementation) replays the snapshot and then applies the mutation and event stream in sequence, reproducing what the page looked like and what the visitor did. The "movie" exists only after reassembly.

The sensitive part is the input stream. By default, some configurations capture the values typed into fields. Vendors provide masking — CSS classes or settings that redact text, and automatic suppression of password fields — but masking is a configuration choice, not a default guarantee for every field. A site that has not deliberately masked may be transmitting what visitors type into search bars, forms, and, in the worst cases, fields containing personal or payment information.

Why the legal question is genuinely hard

Most replay wiretapping claims are pled under CIPA Section 631 and analogous two-party-consent statutes, which reach the interception of a communication "in transit." Two distinct sub-questions decide these cases, and courts have answered both inconsistently.

The first is the timing question. A defense that has succeeded in at least one California federal summary-judgment ruling argues that replay software does not intercept a communication in transit at all, because the individual events are only assembled into anything readable after they have been transmitted and stored by the vendor. On that reasoning, what travels is fragmentary data, and the "communication" comes into being later, defeating the contemporaneous-interception element. Other courts have been less receptive, treating the live streaming of keystrokes and clicks as interception as it happens.

The second is the third-party question, often framed through the statute's party exception. If the replay vendor is acting purely as a tool — a tape recorder held by the website, with no independent right to use the data — many courts hold the website cannot wiretap its own conversation, and the claim fails. If, instead, the vendor has the independent capability to use, analyze, or monetize what it captures, courts have been more willing to treat it as a third-party eavesdropper outside the exception. The Ninth Circuit's Javier v. Assurance IQ line, addressing consent timing, sits in the background of much of this, and the factual question of what the vendor is contractually permitted to do with the data often proves decisive.

The result is a body of law where outcomes turn on implementation details and vendor contracts, not on whether replay was used at all. That is unusual, and it rewards knowing precisely how a given deployment behaves.

What is observable from outside

A scan cannot read a vendor's data-use contract or confirm whether a specific field was masked server-side. But several of the facts that drive these cases are visible on the wire:

• Whether a replay library is present at all, and which vendor it reports to.
• When it initializes — in particular, whether it begins capturing before any consent interaction.
• The ingestion endpoints receiving the event stream, and whether transmission begins on first paint.
• Whether capture appears on pages that collect sensitive input (login, account, checkout, intake forms), where the masking question carries the most weight.

The legal exposure of session replay is not a yes/no property of the tool. It lives in the specifics — what is captured, when it leaves the browser, and what the vendor may do with it. The first two of those are measurable, and they are the right place to start.