/ /

Reducing CIPA & ECPA Exposure

A Technical Configuration Guide for the Osano Consent Manager
Updated last month

This document is intended to help configure the Osano Consent Manager in a way that meaningfully reduces exposure to wiretapping-statute class actions, including claims brought under the California Invasion of Privacy Act (CIPA), the federal Electronic Communications Privacy Act (ECPA), the Video Privacy Protection Act (VPPA), and analogous state laws.

It pulls from the same checklist Osano Implementation Managers use during customer reviews and adds technical considerations that fall outside the standard review but are increasingly relevant in plaintiff filings.

Important: This is not legal advice and is not exhaustive. Consult qualified privacy counsel. Plaintiff theories and tracking technologies evolve continuously. Treat this as a starting point alongside ongoing legal review and technical testing.

Why This Matters

Recent class actions argue that embedding third-party tracking pixels: Meta Pixel, TikTok Pixel, Google Ads tags, session replay tools, chatbots, and others,  constitutes "wiretapping" of a user’s electronic communications when those scripts fire before consent is given.

In Javier v. Assurance IQ, the Ninth Circuit rejected the idea that retroactive consent cures pre-consent interception. Demand letters routinely cite HAR file captures showing third-party requests firing within milliseconds of page load, a window in which no consent could possibly have been given.

The technical configurations below are designed around a single principle: no non-essential script, pixel, beacon, or third-party request should leave the user’s browser before they have meaningfully consented.

Part 1 - Foundational Configurations (Standard Osano Review)

These are the items Osano Implementation Managers check during reviews. They are necessary, but on their own they are not sufficient - see Part 2.

High-Priority Configurations

Script placement and loading

  • osano.js placed inside the <head> tag: so the consent layer initializes before any other script. Placement in the body or before other scripts in the head allows trackers to fire first.

  • No async or defer attributes on osano.js: These attributes delay execution, which means trackers can run before consent is enforced. This is one of the most common findings in our reviews and one of the most common bases for plaintiff arguments.

Consent Settings (Advanced Settings)

  • Strict mode enabled: Strict mode blocks all non-essential scripts by default until consent is granted. For CIPA and ECPA exposure specifically, strict mode is non-negotiable, permissive or opt-out modes allow scripts to fire before consent and reproduce the exact fact pattern plaintiffs rely on.

  • US State Opt-Out turned OFF: CPRA itself is an opt-out regime, so turning this on is compliant with California law on its own terms. However, organizations concerned about wiretapping exposure typically turn this OFF, which presents an opt-in style banner (Banner 3) to visitors in U.S. states that have active privacy laws, while visitors in U.S. states without privacy legislation will continue to see Banner 1. This is a more conservative posture and removes the "scripts fired before opt-out was clicked" argument.

  • GPC (Global Privacy Control) enabled: Browsers send GPC headers as Do Not Sell signals. Enabling GPC honors these automatically and is a CPRA requirement.

  • Google Consent Mode: if you are using Google Consent Mode, ensure it is installed based on GCM requirements. Osano-Centric approach recommended over Google-Centric approach.

Classification hygiene

  • All scripts and cookies classified: Essential, Marketing, Analytics, Personalization, or Hidden. Unclassified items default in ways that may not be defensible.

    • Ensure NO items remain unclassified OR operate Osano in STRICT mode. 

  • No misclassification of trackers as Essential: Meta Pixel, Google Analytics, advertising pixels, and session replay tools are not essential. Mislabeling them is the single most common technical basis for CIPA claims to succeed at the motion-to-dismiss stage -> the configuration itself becomes evidence of inadequate consent.

User experience

  • No dark patterns in the banner: Equal visual weight on Accept and Reject. Reject must be reachable without scrolling through preference menus. No color manipulation (green Accept / red Reject), no shrunken Reject text, no hidden buttons. Consent obtained through a dark-patterned banner is not valid consent.

  • Persistent way to change preferences: The default Osano cookie icon, or a footer link, must remain visible on every page.

Subject rights surface area

  • DSAR form present, accessible, and complete: Access, deletion, correction, objection, portability all called out specifically. Linked from the privacy policy and a discoverable location like the footer.

  • "Do Not Sell" link in the footer: Visibility matters for CPRA.

Medium-Priority Configurations

  • osano.js republished within the last 3 months: so the deployed code includes the most current compliance functionality.

  • Classifications grouped into useful rulesets: for performance and audit clarity.

  • All cookies disclosed: in the preferences drawer for transparency. Partial disclosure is acceptable; no disclosure is risky.

Part 2 - Beyond the Standard Review (Irrespective of CMP Provider)

These are technical considerations not covered in the standard Osano implementation review but that frequently appear in CIPA and ECPA filings. We recommend treating them as part of any defensive configuration.

Session replay tools

FullStory, Hotjar, Microsoft Clarity, LogRocket, Mouseflow, and similar tools record keystrokes, mouse movement, scroll behavior, and form inputs. They are increasingly the named technology in CIPA class actions because they record more than a pixel does. 

  • Classify them as Marketing or Analytics - never Essential -  and verify they do not load until after consent. Audit which form fields they capture; password and PII fields should be masked at the vendor level as a second line of defense.

Chatbots and live chat

Drift, Intercom, Ada, LivePerson, and AI chat agents typically record full conversation transcripts and share them with the vendor for product analytics. These are now regularly named in CIPA filings under the theory that the vendor is a third-party listener. 

  • Gate their loading on consent, personalization or functional, and review vendor contracts for what they do with transcripts.

Server-side tracking (CAPI, server-side GTM)

Meta’s Conversions API, server-side Google Tag Manager, and similar implementations can route user data to third parties from your servers, bypassing client-side blocking entirely. Osano can’t enforce consent on requests it never sees. 

  • Server-side tracking must be gated on the consent state recorded for the user, and consent signals (e.g., Limited Data Use flags for Meta) must be passed through.

Tag Manager configuration

Google Tag Manager, Tealium, Adobe Launch, and similar tag managers can fire arbitrary tags regardless of what Osano blocks. 

  • Use GTM Consent Mode v2 with all marketing/analytics tags set to "denied" by default. Confirm the same for any non-Google tag manager. A misconfigured tag manager is one of the most common reasons trackers fire pre-consent on otherwise well-configured sites.

Embedded third-party content

YouTube embeds, Vimeo players, Twitter/X widgets, LinkedIn share buttons, Facebook social plugins, and similar embedded content set cookies and beacons the moment they render. 

  • Use privacy-friendly modes where available (e.g., youtube-nocookie.com) or wrap embeds in consent-gated containers that only render after the user has consented.

Pre-consent testing methodology

Plaintiff firms build their cases using HAR file captures from a fresh browser session. You should test the same way:

  • Open an incognito or fresh-profile browser session.

  • Open DevTools, switch to the Network tab, clear it, then load your site.

  • Before clicking anything on the banner, filter for third-party domains (anything other than your own).

  • Any non-essential third-party request that appears is a finding. Document it, classify it, and confirm it is gated correctly in Osano.

    • Check for things like “Collect”, “Track”, or “Ping” pre consent or when consent is rejected. 

  • Repeat on a few pages.

Documentation and audit trail

Maintain dated records of cookie scans, configuration changes, consent rate data, and dated screenshots of the banner UX. If you receive a demand letter, the absence of this record makes early defense significantly harder. The presence of a documented, dated, regularly-reviewed program is a meaningful asset in pre-litigation negotiations.

  • Record notes with every publish within Osano on key changes and utilize Audit Log to keep track. 

Cookie scan frequency

Marketing and engineering teams add tools constantly. A one-time scan at launch decays quickly. Monthly or quarterly scans surface new trackers before they accumulate enough activity to become exposure. Treat scanning as a recurring discipline, not a project. Osano does this by default.

Privacy policy alignment

The privacy policy must describe tracking technologies in plain language and link to the cookie preferences widget and the DSAR form. Plaintiffs routinely cite inconsistency between policy language and observed site behavior as evidence of inadequate notice.

Part 3 - What We See Customers Do

Patterns we observe across the customer base among organizations taking a defensive posture against CIPA, ECPA, and similar exposure:

  • Run opt-in posture for all US traffic: Rather than relying on geo-targeting or US State Opt-Out, they present an opt-in banner to every US visitor. More conservative than CPRA requires; addresses the wiretapping exposure directly.

  • Treat cookie scanning as a recurring discipline: Monthly cadence is common; quarterly is the floor.

  • Pre-launch HAR review: Before any new marketing or analytics tool goes live, someone captures a HAR file from a fresh session and confirms nothing fires pre-consent.

  • Lock down tag manager permissions: Marketing can request tags, but engineering or privacy reviews them before they go live in production. No production tag changes without review.

  • Specific audit of higher-risk vendors: Session replay tools, chatbots, and live chat vendors get individual review of contract terms, data handling, and technical behavior, separate from the general vendor list.

  • Annual third-party privacy review: External counsel reviews the actual implementation, banner UX, network traffic, tag manager configuration, not just the privacy policy.

  • Quarterly republish of osano.js as part of a regular maintenance cadence, not only when something breaks.

Not Exhaustive

This guide covers the configurations and patterns most relevant to current CIPA and ECPA exposure. It is not a complete list of compliance obligations and it cannot account for every new tracking technology, every new plaintiff theory, or every shift in case law.

Use this alongside qualified privacy counsel, ongoing technical testing, and regular review of your actual deployed configuration, not just your intended configuration. The gap between the two is where most exposure lives.

Was this article helpful?
Subscribe to receive updates on this article