What a review surface must never log
A human-in-the-loop gate shows a document and the fields pulled out of it, and the session-replay script the growth team added is recording both — default masking rules decide whether that is a feature or an incident.
The review gate is the best thing in the extraction product. A document crop on the left, the fields the model pulled out on the right, per-field confidence, the raw OCR text underneath, and an approve or correct control at the bottom. Nothing downstream fires until a person has looked. It exists to be looked at, which is the whole point.
Now somebody on growth installs a session-replay script through the tag manager, because activation on the review step is worse than expected and watching ten sessions is faster than guessing. That is a reasonable thing to want. The question this lesson makes answerable is what actually left the page when they did it.
What a replay tool actually captures
Session-replay tools do not record video off the screen. They serialise the rendered DOM and stream the mutations, then replay them into a blank page later. That mechanism is why the masking question is a per-element question rather than a per-screen one, and it is why the answer is different for each panel of the review gate.
- The extracted fields. Usually
<input>or contenteditable nodes. This is the one category every vendor in the list below treats as sensitive by default, because it is the one that historically held passwords. - The raw OCR text. Plain text nodes. Not an input, not a form field, and therefore outside the protection that covers the fields above at several of these vendors.
- The confidence chips and the field labels. Text nodes again. “Date of birth: 0.94” is a label that tells a reader what the masked thing next to it was.
- The document crop. An
<img>whosesrcpoints at your document store. Blocking media stops the pixels. It does not stop the URL, and the URL is a string in the serialised DOM. A signed storage URL carries a document identifier, often a customer slug, sometimes an original filename.
That last bullet is this course’s own reading rather than anything the vendor pages say. None of the six documents below discusses review gates, image crops or OCR panels; they describe elements. The mapping from “our review gate” to “these element types” is yours to do, and it is the part of the flag nobody else on the team is positioned to write.
Six vendors, six different defaults
The reason to hold these side by side is not that any of them is careless. It is that they differ on one axis — inputs versus page text — and almost nobody checks which one their company installed. Every page below is a vendor documenting the product it sells.
- Sentry is the conservative pole: “By default, the Session Replay SDK will mask all text content with
*”, plus masked inputs and blocked media. - LogRocket is the other pole. It will not record
inputelements wheretype="password", and “all other elements are captured by default.” The input and text sanitisers both default to off. On an unconfigured install, the raw OCR panel is recorded. - Microsoft Clarity defaults to a masking mode called Balanced, which masks numbers and email addresses. Not names. Not free text. The same page also warns that it does not mask content inside style sheets or style tags.
- Datadog is the interesting one, because its own two pages disagree. The privacy-options page says
maskis the default when the level is unspecified. The browser SDK upgrade guide saysdefaultPrivacyLevelismask-user-inputin v7, previouslymask. Both cannot describe one current install. - Fullstory documents the strongest posture in the group, where no text is captured unless it is explicitly allow-listed. The page describes this as something configured during account setup, so it is a property of an account rather than of the product.
- PostHog documents that inputs are masked, because any input element is “highly likely to contain sensitive text such as email or password.” Whether general page text is masked could not be determined from PostHog’s own documentation across two research passes for this course, and several plausible documentation URLs 404. That gap is a finding, not a gap in this lesson: “I could not determine the default from the vendor’s own docs” is a sentence you are allowed to say out loud.
Where people get burned
The Datadog contradiction is the most useful fact in this lesson, and not because Datadog did anything wrong. A masking posture can change during a routine dependency upgrade. Nobody reviews a minor bump for privacy behaviour, the replays keep arriving, and the only visible difference is that they got more useful. Never state a default without naming the major version you checked, and never state one you did not check yourself.
The prior art, and why it still lands
Englehardt, Acar and Narayanan studied seven session-replay firms in November 2017, finding scripts on 482 of the Alexa top 50,000 sites. The finding that transfers directly to a review gate is this one:
“text typed into forms is collected before the user submits the form” (Princeton CITP)
Leaked material in that study included passwords, card numbers and medical conditions. One caveat that keeps you accurate: this is a blog post from the Center for Information Technology Policy, not the similarly named peer-reviewed paper, which covers different findings. Do not cross-cite them.
A correction gate is worse than a form for this, not better. A form is filled in by the person the data is about. A review gate is filled in by an operations employee, about somebody who is not in the room and who has no idea that a third party is watching the field being typed.
Where the law sits, and why you stop there
There is live United States litigation treating session replay as wiretapping. In Javier v. Assurance IQ, the Ninth Circuit described a tool that “captured in real time every second of his interaction… and created a video recording”, and held that California’s CIPA § 631(a) requires prior consent, so a privacy policy shown afterwards did not cure it. That disposition is marked NOT FOR PUBLICATION. It is a memorandum disposition, not binding precedent, and saying so unprompted is what keeps you credible with the person who does own this.
That person is a lawyer or a privacy owner, and this is where you stop. Your job is to hand over an accurate description of what the page transmits. Their job is to decide what it means. A front-end architect who arrives with a legal conclusion has made the meeting harder and has given the actual owner something to correct before they can start.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
The team masks every text node on the review route. Name two things that still leave the page.
Check your answer
The image src for the document crop, unless it is blocked separately or the URL itself is opaque. And the structure: which fields exist, which ones were corrected, how long the operator hovered, the order they moved through the panel. Masked text still leaves a shaped hole, and a label reading “National insurance number” next to a masked value tells a reader what the masked value was.
There is a third, and it is the one that gets people: masking is applied by the SDK in the page. Anything that reaches the network by a route other than that SDK — an error reporter capturing a component’s props, an analytics event carrying a field name and value, a URL with an identifier in the path — is governed by a different configuration nobody looked at.
Hands on
Audit what leaves the review gate
Done when: A written finding naming every third-party script that loads on the review route, and for each one: the vendor, the SDK major version, the documented default for that version with the URL you read it on, and what you observed in the network panel with the panel open on real-shaped data. Any default you could not determine is recorded as “could not determine”, not guessed. Plus the matching FLAG-LOG row.
- Open the review gate in an environment that has the real tag set loaded, not local. List every third-party script on that route. The tag manager is the place to look, and the list is usually longer than the one the team would recite from memory.
- For each script, find the SDK major version actually loaded. Read it off the request or the loader, not off
package.json— a tag manager can be serving something else entirely. - For each vendor, open its own privacy documentation and record the default for that major version, with the URL. Where the vendor documents two conflicting defaults, record both and say so. Where you cannot find it, write “could not determine from vendor documentation” and move on. That sentence is a finding.
- Put realistic content in the gate — a document crop, a name, a date of birth, a long OCR block — and watch the network panel while you type a correction. You are looking for whether the field content, the OCR text, and the image URL appear in what goes out. Never do this with a real customer document; construct one.
- Write the finding as observations only. “The OCR panel <div> is transmitted unmasked to vendor on the review route, SDK vN” is a fact. “This is a GDPR breach” is not yours to write.
- Fill the What I saw and Why it matters here cells of the review-gate rows in
FLAG-LOG.md, then bring both in. I will push on any default that came from memory rather than from a URL you can paste, and on any observation that is actually a conclusion.
What this does not cover
This lesson is about telemetry somebody added to a surface. It says nothing about the surface built specifically to show everything: a trace view is not a leak, it is a product whose entire purpose is displaying every input and output of every step, and the redaction question there has to be answered before the view is useful rather than after. The trace-view lesson takes that up, and its primary source is the one that states the default in so many words.
It also stops short of where the recordings go. Every vendor above is a processor receiving personal data, and several of them are not in the same jurisdiction as the customer whose passport is on screen. Whose data and which border are the two facts in the residency lesson. And it says nothing about how long any of it is kept, which is the retention lesson, and the one where the answer is usually that nobody decided.
Read this next — primary source
Session Replay privacySentry — vendor documenting its own product, fetched 2026-09-05. Sentry sells the tool this page configures, which is worth naming: the page is still the most conservative default in the category, and it is the vendor telling you to check your own configuration.
This lesson takes one sentence from it — that the SDK masks all text content by default — and uses it as the fixed point against which the other five vendors are read. Read the whole page anyway, because the part this lesson cannot use is the part you will need: the list of ways to opt an element back in. That list is what a growth engineer will reach for when masking makes a replay useless, and knowing it exists is what lets you ask whether anyone has already reached for it on the surface you are worried about.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.