What the case was about
What happened in Frasco v. Flo Health? On August 1, 2025, a unanimous jury in San Francisco found Meta Platforms liable under the California Invasion of Privacy Act for capturing sensitive reproductive health data through a software development kit embedded in the Flo period-tracking app — without the consent of the app's users. The court then denied Meta's post-trial motions to overturn the verdict. With a certified California class and CIPA's $5,000-per-violation statutory damages, Meta faces potential exposure that the company itself has described as reaching multiples of billions of dollars.
This is the first major CIPA jury verdict in the statute's history. It is not a motion to dismiss where a court found allegations sufficient to proceed. It is not a settlement where liability was never adjudicated. It is a unanimous jury finding, upheld on post-trial review, that a technology company's use of an SDK to capture user communications in real time violated California's 1967 wiretapping law — and that the company's broad privacy policy did not constitute valid consent.
The implications reach far beyond health apps. The legal principles the jury applied — on SDK liability, on consent, on intent — apply to any website or app that uses third-party SDKs, pixels, or tracking tools to capture user communications. This post explains what happened, why the verdict survived post-trial challenge, and what five compliance lessons every website operator should take from it.
What the jury decided and why it survived post-trial challenge
The jury was asked three questions. Did Meta intentionally eavesdrop on and/or record the plaintiffs' communications using an electronic device? Did the plaintiffs have a reasonable expectation that the communications were not being overheard or recorded? Did Meta have the consent of all parties to eavesdrop on or record the communications?
The jury answered yes to the first two and no to the third. The verdict was unanimous.
Meta moved to overturn the verdict after trial. The court denied the motion. In doing so, the court made several holdings that are independently significant for any business thinking about CIPA compliance.
On what counts as an "electronic recording device"
Meta argued the SDK was software, not a physical device, and therefore could not be an "electronic recording device" under CIPA. The court rejected this, holding that CIPA's plain meaning extends beyond physical devices to electronic means of recording communications. The SDK integrated into the user's phone, with the phone itself acting as the device, was sufficient. The court noted that a physical device may not even be required to fall within CIPA's scope.
On capturing one party's communications
Meta argued it only received data about what users communicated to Flo — one party's communications — rather than intercepting a two-way communication. The court ruled that capturing one party's communications is sufficient under CIPA. The interception occurs at the moment the user's input is captured and transmitted, regardless of whether the full exchange is recorded. The court found the SDK captured communications "in real time," not as secondhand repetitions.
On intent when an SDK developer doesn't control what data is sent
Meta argued that Flo Health configured the SDK and decided what data fields to include — Meta merely provided an empty envelope that Flo chose to fill with health data. The jury rejected this defense, finding that Meta intentionally designed a system to capture and transmit user data, actively encouraged app developers to incorporate its SDK, and only began restricting the acquisition of sensitive health information after bad press about its practices. The court held that intentional interception may be implied when a company fails to stem the flow of sensitive data it is receiving, even if the recipient has contractually required the sender not to share it.
On whether broad privacy policies constitute consent
Meta argued that Facebook users had consented through Meta's broad privacy policy, which stated Meta could receive data from third-party apps. The court focused on whether a reasonable user would believe they had consented to the specific type of data collection at issue. The jury found Meta's privacy policies too vague to inform users that intimate health data was being collected via the SDK. The disclosures did not explicitly cover collecting sensitive menstrual and pregnancy data from a third-party health app. Flo's own policy — which promised not to share personal health data with third parties — further supported the finding that users had no reason to believe their data was being transmitted.
Why this verdict matters beyond health apps
The Flo case involved unusually sympathetic facts — sensitive reproductive health data, a privacy policy that expressly promised not to share it, and a major technology company receiving that data for advertising purposes. But the legal principles the jury applied are not health-specific. They apply to any deployment of a third-party SDK, pixel, or tracking tool that captures user communications in real time.
The SDK liability principle. Every company that embeds a third-party SDK in its app or website is potentially in the same structural position as Flo Health. The SDK captures user communications. The SDK vendor receives those communications on its own servers. If the vendor uses the data for its own commercial purposes — including improving its own product, advertising, or analytics — the third-party eavesdropper theory applies. This is not a novel theory that succeeded because of health data sensitivity. It is the same theory the Ninth Circuit endorsed in Javier v. Assurance IQ. The Flo verdict is the first time that theory survived a full jury trial.
The intent implication from failing to restrict data flow. The court's holding that intent may be implied when a company fails to stem the flow of data it is receiving has significant implications for any company running third-party tools. If your Meta Pixel is transmitting sensitive URL data to Meta — product search queries, health-adjacent product category URLs, financial product interest signals — and you have not taken steps to restrict that transmission, the Flo verdict suggests that passive receipt of sensitive data can satisfy the intent element under CIPA.
The consent standard. The jury found that Meta's broad privacy policy did not constitute valid CIPA consent for capturing specific health data from a specific third-party app. Generalised privacy notices that describe data sharing in broad terms do not satisfy CIPA's all-party prior consent requirement. The consent must be specific to the interception at issue, obtained before it occurs, and clear enough that a reasonable user would understand what they are consenting to. Boilerplate terms of service that mention data sharing with third parties in generic language will not hold up if the specific data being captured is sensitive.
Five compliance lessons from Frasco v. Flo Health
1. De-identified data is not safe harbor data
Meta argued the data was de-identified. The jury disagreed because the data included device and advertising identifiers that could be linked to individual profiles. For CIPA purposes, data that can be re-linked to an individual through identifiers is not de-identified in any legally meaningful sense. If your tracking tools transmit data that includes device IDs, advertising IDs, or any other persistent identifier alongside behavioral data, the de-identification argument is unlikely to succeed.
2. Your privacy policy must accurately describe what your tools actually do
Flo's privacy policy expressly promised not to share health data with third parties — and then shared it with Meta through an SDK. That mismatch between policy and practice was central to the verdict. Policies that promise not to share data while SDKs or pixels are actively transmitting it are not just misleading — they are the specific factual pattern that CIPA demand letters and class actions are built around. Every tracking tool running on your site or in your app must be accurately disclosed in your privacy policy.
3. Broad consent to third-party data sharing does not cover specific sensitive interceptions
The court's holding that Meta's general privacy policy did not constitute consent to capturing intimate health data from a third-party app establishes that specificity matters. Generic consent to "data sharing with third parties" is not consent to real-time interception of specific sensitive data by a specific third-party vendor. For any SDK or tracking tool that captures sensitive data — health-adjacent URLs, financial product interest, reproductive or sexual health information — the consent required is specific, not bundled into general terms.
4. SDK developers face liability, not just the apps and websites that deploy them
The jury found Meta liable as the SDK developer, not just as a data recipient. The holding that intent can be established by designing a system to capture data and encouraging app developers to embed the SDK means that the tool's developer — not just its deployer — can be a defendant. For businesses evaluating SDK vendors, this changes the risk calculus: you are not just responsible for what you do with the data, you are also potentially responsible for what the vendor designed the SDK to do.
5. Post-trial motions did not save Meta — and they won't save you
Meta had substantial legal resources and strong defenses: the de-identification argument, the consent argument, the physical device argument, the one-party communications argument, and the intent argument. The jury rejected all of them. The court upheld the verdict on post-trial motions. This does not mean CIPA claims always succeed — courts continue to dismiss claims on standing and contents grounds — but it demonstrates that the legal theories supporting CIPA liability for SDK and pixel-based tracking are not procedural weaknesses that collapse at trial. A business that is relying on the assumption that these claims will be dismissed before trial is making a bet the Flo case has now materially undermined.
Frequently asked questions
Does the Flo verdict only apply to health apps?
No. The legal principles the jury applied — on SDK liability, on what constitutes an electronic recording device, on what satisfies consent, on when intent may be implied — are not limited to health data or health apps. They apply to any deployment of a third-party SDK or tracking tool that captures user communications in real time. The health data context made the case sympathetic and newsworthy, but the doctrine travels beyond it.
Meta says it will appeal. Does the verdict still matter?
Yes, for two reasons. First, the post-trial motions were already denied, meaning the verdict survived its first challenge. Second, even if Meta appeals to the Ninth Circuit, the trial record — the jury's findings on consent, intent, and the electronic recording device question — establishes a factual precedent that plaintiffs' attorneys will use to structure future claims. The appeal may limit or expand the doctrine, but the verdict has already changed the CIPA litigation landscape by demonstrating that these claims can win at trial.
What are the actual damages Meta faces?
The jury was not asked to award damages during the liability phase. The damages question — $5,000 per violation multiplied by the certified California class of Flo users during the class period — is to be resolved in subsequent proceedings. Meta itself has said the exposure could reach multiples of billions of dollars if the full class is awarded statutory damages. The damages phase has not yet concluded at the time of this writing.
Does the verdict affect my use of Meta Pixel specifically?
The verdict does not directly create liability for every Meta Pixel deployment. It establishes that SDK-based real-time capture of sensitive user data without adequate prior consent violates CIPA — a principle that applies to pixel-based tracking tools as much as it does to SDKs. The specific risk for Meta Pixel deployments on websites with health-adjacent content, sensitive product category URLs, or Advanced Matching enabled is elevated by the verdict's reasoning, even though the Flo case involved a mobile app SDK rather than a browser pixel.
What does "consent" actually need to look like after this verdict?
Specific, prior, and technically enforced. The verdict makes clear that broad privacy policies mentioning third-party data sharing do not constitute valid CIPA consent for specific interceptions of sensitive data. Consent must be obtained before the interception occurs, must specifically describe what is being collected and by whom, and must be technically enforced so that the collection does not proceed until the consent signal is received. A general terms of service checkbox is not adequate for sensitive data. Prior consent at the tag execution level, with the specific vendor named and the specific data described, is what the verdict establishes as necessary.
What this verdict means for your compliance program
Frasco v. Flo Health is the first CIPA verdict to survive a full jury trial and post-trial motions. It establishes that the legal theories underpinning the current wave of CIPA demand letters and class actions can win at trial, not just survive motions to dismiss. It establishes that broad privacy policies do not constitute valid prior consent for specific tracking tool interceptions. It establishes that SDK developers — not just the apps and websites that deploy them — face CIPA liability. And it establishes that de-identification arguments fail when persistent identifiers allow data to be linked to individual profiles.
The compliance program that the verdict points toward is the same one CIPA's text has always required: prior consent that is specific to the tracking at issue, technically enforced before any collection occurs, documented in a privacy policy that accurately describes what each tool does, and supported by vendor contracts that restrict independent data use where the tape recorder exception is available.
The infrastructure answer
The free PieEye compliance scan identifies whether your current tracking configuration has the specific vulnerabilities the Flo verdict illuminates — tracking that fires before consent, consent mechanisms that don't actually block collection, and policy-to-practice mismatches between what your privacy policy says and what your tracking tools do.
For the complete technical architecture for prior consent and vendor contract review, the CIPA compliance guide covers the implementation requirements alongside every other high-risk tracking tool in your stack.
Run a free PieEye compliance scan — it takes minutes, requires no code changes to initiate, and tells you exactly what a plaintiffs' attorney's scanning tool would find if it looked at your website today.