.svg)
It’s 2026, and the California Invasion of Privacy Act (CIPA), a nearly 60-year-old California phone-tapping law, is now the most litigated privacy statute in the U.S.
Most companies caught in it thought they were already compliant, but CCPA and CIPA compliance are not the same, and confusing the two is exactly how companies end up receiving demand letters. With $5,000 per violation, no proof of harm required, a one-year statute of limitations, and plaintiff firms that can multiply those numbers very quickly across any website with routine traffic, this is quickly becoming a major priority for companies across the United States.
To address concerns and questions, we recently hosted a webinar on the topic, where Julie Rubash, General Counsel & Chief Privacy Officer at Sourcepoint by Didomi and host of A Little Privacy, Please, was joined by Matthew Pearson, Partner at Frankfurt Kurnit Klein & Selz, and James Ensor, Head of Sales UK at Addingwell by Didomi.
Keep reading for the complete overview, or find the webinar replay at the end of the article.
Disclaimer: CIPA compliance is an evolving topic. Our articles are provided for general, informational purposes only, do not constitute legal advice, and should not be relied upon for legal decision-making. Please consult an attorney to determine how legal updates may impact you or your business.
What CIPA actually says, and why it now applies to your website
Matthew Pearson opened the webinar by walking through what is actually being litigated. Despite the variations in individual claims, he explained, they all come down to the same basic technology doing the same basic thing.
The theory across the board is that there's some surreptitious collection of information about a website visitor. In practice, the most common example is an analytics pixel running on a website, collecting data such as where visitors are from, what they're doing on the site, and what they click. Plaintiff firms identify this by going to a website, right-clicking to inspect, and viewing all outgoing network traffic.
As Pearson pointed out, Google Analytics is visible in that view on the vast majority of commercial websites, and the data being transmitted is more revealing than most companies realize: browser type, screen size, IP address, operating system, unique cookie values, current URL, and referral header. Each additional data point, from a plaintiff's perspective, narrows the gap toward identifying the individual user.
The claims themselves have evolved over time. Early cases focused on chatbots, then on session replay tools, and finally on pixels and tags. Now, plaintiff firms are also targeting mobile SDKs, apps, and AI-powered chat features. The technology changes, but the underlying legal theory remains.
That theory centers on the concept of interception. Under Section 631 of CIPA, the primary provision in most website-tracking claims, the law prohibits the unauthorized interception of electronic communications. The way courts have interpreted this in the context of websites has surprised many companies and their lawyers. As Pearson explained:
The term “interception”, as we would normally use it, is probably not occurring on client-side tags. There's not some third party reaching in as a communication is going on, and grabbing it out of the air.
But if you are just basically duplicating (Matt Pearson's on a website, click a button, shoots off to the website server, and then at the same time I am duplicating and sending a second transmission to a third-party), courts have effectively found that it is interception.
You have to broaden your thought process about what interception is.
- Matthew Pearson, Partner at Frankfurt Kurnit Klein & Selz
Section 632, which covers the unlawful recording of confidential communications, is also increasingly invoked, particularly in connection with chat widgets and real-time interactions. And plaintiff firms are now adding claims under CDAFA (California's computer access statute) alongside CIPA claims, further broadening exposure.
Why CCPA compliance doesn't protect you from CIPA claims
Some companies ask why they've received a CIPA demand letter despite being compliant with the California Consumer Privacy Act (CCPA). But CCPA compliance and CIPA exposure are two separate problems that require two separate responses.
When I have these conversations with clients, I generally try -at least initially- to draw a distinction between the two: CCPA, which I call compliance, and CIPA, which is litigation.
- Matthew Pearson, Partner at Frankfurt Kurnit Klein & Selz
CCPA creates an opt-out regime, requiring companies to give users the ability to say "don't do this." CIPA, as courts have interpreted it, requires prior consent before tracking fires. A company can have a fully functioning, legally -reviewed CCPA opt-out mechanism in place and still face a valid CIPA claim, because the standard is not whether users can opt out, but whether they consented before data collection began.
This tension is compounded by other pressures:
- Marketing teams that resist adding friction to the user experience;
- Advertising dependencies that make removing tracking tags unrealistic;
- Genuine legal uncertainty, with courts still working out how CIPA's various provisions apply to internet communications.
For organizations, the goal is to try to harmonize things that inherently contradict each other. That conflict sits between legal, marketing, and IT teams, each with different priorities and, often, different languages.
What good consent actually looks like (and where companies go wrong)
Julie Rubash picked up from there by addressing the risk mitigation options available to companies. The first option, and the one many companies default to, is seeking consent. But doing this badly can increase exposure rather than reduce it:
The dangerous instinct many companies adopt is that opt-in consent in any form is more compliant than opt-out. (...) This leads companies to carelessly put cookie banners up that aren't based on the laws they're trying to address, aren't tied to their actual data practices, and don't work together with other privacy choices.
As a result, they open themselves up to more litigation exposure for deceptive practices and to regulatory exposure for failure to comply with the requirements under those state privacy laws.
- Julie Rubash, General Counsel & Chief Privacy Officer at Sourcepoint by Didomi
To illustrate the challenges presented to companies and the failure modes organizations need to avoid, Rubash walked the audience through four enforcement cases:
Honda (CPPA enforcement)
Honda's cookie management tool had users opt in by default, but opting out required more steps than opting back in. The settlement found that the path to the more privacy-protective option was deliberately harder than the path to the less privacy-protective one.
Takeaway
If you have an "accept all" button, you need a "reject all" button that is equally prominent and equally easy to use.
Healthline Media (California AG settlement)
Healthline's banner required users to click "More Information" and then uncheck a toggle to opt out. More critically, even when users completed those steps correctly, the banner didn't actually disable tracking cookies. The mechanism was broken.
Takeaway
Any mechanism you offer users must work exactly as described.
PlayOn Sports (CPPA enforcement)
The website asked users to click "Agree" before proceeding, with no alternative offered. A separate "Your Privacy Choices" link directed users to a phone number and email address to opt out, but those methods didn't actually opt users out of data sales via third-party tracking technologies.
Takeaway
Having a consent banner is not a replacement for meeting the CCPA's specific requirements. You still have to provide a functional way for users to opt out of the sale or sharing of personal information via tracking technologies.
Sling TV (California AG settlement)
Sling TV offered two separate mechanisms: cookie preference controls that only worked in the specific browser used, and a separate, harder-to-find web form that covered broader data sharing across all devices. The settlement cited the confusion this created, with users having to realize that rejecting cookies was not the same as submitting a CCPA opt-out request.
Takeaway
If you have separate mechanisms for tracking technologies and broader data sharing, make sure users understand the difference.
CPPA consent checklist
Julie Rubash summarized the consent checklist that emerges from these cases:
- Consent and opt-out mechanisms must work together
- Disclosures must reflect actual practices
- Tracking must not fire unless and until the user consents
- Choice must be symmetrical
- The mechanism must be tested regularly to confirm it actually works.
The risk matrix: sensitivity, interception, and where you sit
Before introducing server-side tracking as a mitigation measure, Julie Rubash presented a framework for thinking about relative exposure, in which risk moves along two axes: the sensitivity of the content on the website (a general retail or news site carries lower risk than a healthcare or finance site, where users have a higher expectation of privacy), and whether tracking is client-side or server-side.
Matthew Pearson noted that it also helps to think of the client-side versus server-side axis as interception versus no interception. Regardless of where a company sits on the sensitivity axis, moving from client-side to server-side reduces exposure.
{{client-side-vs-server-side}}
Server-side tracking as a structural mitigation
James Ensor, Head of Sales UK at Addingwell by Didomi, walked through the architecture of both client-side and server-side approaches.
With client-side tracking, the standard setup for roughly 70–80% of websites, a user's browser sends interactions directly to each third-party tool simultaneously, including Google, Meta, TikTok, and any other platform running on the site. It's these simultaneous transmissions that plaintiff firms seek when they open browser developer tools and inspect network traffic.
Server-side tracking introduces an intermediary step.
Instead of the browser sending data directly to third parties, it sends it to a server controlled by the website owner. That server then decides what to forward to which partner based on consent signals and configured rules. From a browser inspection perspective, there's no longer a list of third-party pixel requests visible. What you see instead is traffic going to the website's own domain.
99.9999% of lawsuits filed thus far are all client-side tags. And the one where they focused on server-side said it's no CIPA violation.
- Matthew Pearson, Partner at Frankfurt Kurnit Klein & Selz
Ensor was careful to address the common misconception that server-side tracking doesn't hide data, but gives the website owner more visibility and control over it, not less.
With client-side tracking, as he put it, the website owner has no visibility of what data is being collected or where it's being sent. On the server side, every request is logged, every consent signal is recorded, and every forwarding decision is documented. When a demand letter arrives, and the question is what your tracking setup was doing on this date, the answer is in the audit log.
There are also performance benefits that make it easier to present the business case to marketing and IT teams. Server-side tracking bypasses ad blockers and browser-level restrictions (such as Safari's ITP) that progressively degrade the quality of client-side data. It improves conversion attribution, enables offline data enrichment, and gives marketing teams cleaner signals for paid media campaigns.
It gives you that element of ability to customize, to change, to make sure everything's working as it should.
But most importantly for the topic at hand, it gives you a proof point. It gives you that audit log and trail of everything that's going on.
- James Ensor, Head of Sales UK at Addingwell by Didomi
Lastly, he emphasized that server-side tracking isn't about choosing between performance and privacy. The goal is to achieve both, something that is reflected in our recently announced renewed vision:
{{opt-for-better}}
Connecting consent and server-side: The Didomi and Addingwell way
The final piece James Ensor presented was the integration between Addingwell’s server-side tagging infrastructure and Didomi's Consent Management Platform (CMP).
With the recent release of a functionality called Event Consent Monitoring, for every event that flows through the server, the system logs whether consent was given, which tags fired, what payload was sent to which partner, and whether the event was compliant. Misconfigurations, such as a tag firing without the correct consent signal, are surfaced in real time rather than discovered through a demand letter or an enforcement notice.
Matthew Pearson underlined why that audit trail matters in practice:
I can't tell you how many times I get a lawsuit and I get on the phone with a client and they're like, 'We know we're running it, but I'm not entirely sure what's going or what isn't going on, and when it was going.
- Matthew Pearson, Partner at Frankfurt Kurnit Klein & Selz
Event consent monitoring turns that uncertainty into a documented record including every event sent, every partner that received it, and every consent state at the time,ensuring that if a question gets raised, the paper trail is already there.
{{event-consent-monitoring}}
Access the full CIPA webinar
The webinar's closing message captures the challenge well by reaffirming that CCPA compliance and CIPA litigation risk are two different problems that require two different responses, but they can be harmonized.
Server-side tracking removes the technical basis for the most common category of CIPA claims. Properly implemented consent, built around the lessons from regulatory enforcement, closes the remaining gap. Getting both right should be the objective for leading organizations.
To continue the conversation, book a time with one of our experts or watch the full webinar replay, available on YouTube:
