CIPA Compliance Framework: Live chat text is not captured unless submitted

Overview

This check confirms that a live-chat tool only transmits a visitor's message to its backend (and any third-party vendor) once the visitor has actually clicked send, not continuously as the visitor types, which would let the vendor reconstruct drafted-but-never-sent text.

Note: This guide is provided for informational purposes only and does not constitute legal advice. Consult qualified legal counsel regarding your organization's specific CIPA compliance obligations.

Why it is important

A chat tool that streams keystroke-level or draft-state text to a third-party endpoint before submission is capturing communications the visitor never chose to send. The same unauthorized-interception theory CIPA applies to any other real-time recording tool, and one that plaintiffs' counsel has specifically targeted against chat-widget vendors that offer "live typing preview" features to their own support agents.

Before you start

Because chat widgets vary widely (first-party, third-party, some rendered in an iframe, some as unrecognized custom scripts), this check can't be fully automated against every vendor out of the box. There's no single selector or tag signature that "is" a chat widget across implementations, so any automated version of this check is heuristic: it works well against widgets it can locate and interpret, and needs manual follow-up for the rest.

Implementation

Identify every page carrying a chat widget (first- or third-party), using the wiretap-risk tag inventory as your starting list. For any chat vendor ObservePoint doesn't already recognize as a named tag, request a tag.
For each distinct chat vendor, build a Journey that opens that specific widget and types a unique test string (e.g. "CIPA-TEST-DO-NOT-SEND-xxxx") into its message input, then stops, and completes an additional action that navigates away from the page. This step has to be repeated per vendor; there is no single script that finds an arbitrary chat input across sites.
Where the vendor's traffic is now a recognized tag (via step 1's signature), write a Tag & Variable Rule with an easily identifiable name e.g. "CIPA Risk: Live chat text is not captured". The rule should contain the following logic: WHEN the chat vendor tag contains "CIPA-TEST-DO-NOT-SEND", EXPECT an impossible condition such as an "ObservePoint Custom Tag is present" when no such tag was implemented.
Run each vendor's Journey on a schedule and treat any recognized-tag Rule failure as a finding that needs remediation.

Note: chat transcript data could be encoded. For that, we recommend using ObservePoint's MCP Server and an agentic harness e.g. Claude, Microsoft Co-pilot Agents, ChatGPT, etc. to analyze all variables in the Journeys and decode them looking for the original test string.

Remediation

For remediation, check the next steps:

Where the chat vendor's own script transmits pre-submission text, check the vendor's configuration for a "live typing preview" or similar agent-facing feature and disable it if it isn't a business-critical function, or confirm with the vendor that this data path is contractually restricted from being used for any purpose beyond the live support session itself.
Re-run the Journey after the configuration or signature change and confirm the Rule now passes, and that the manual request review no longer surfaces the sentinel in any encoding

Conclusion

This is a Journey-dependent check because a standard crawl Audit cannot exercise the type-without-submitting sequence, so it must be run through a scripted interaction, and it's worth re-running any time the chat vendor updates its widget script, since these preview features are frequently reintroduced silently in vendor updates.