For the last several years, privacy litigation has focused heavily on websites.

Plaintiffs’ firms learned to open browser developer tools, watch network traffic and identify Meta Pixel, Google Analytics, session replay tools, chat software, advertising tags and other technologies transmitting information to third parties.

That technical evidence helped fuel lawsuits under statutes including the California Invasion of Privacy Act, the Video Privacy Protection Act, the federal Wiretap Act and state consumer-protection laws.

The same scrutiny is beginning to move beyond the browser.

Mobile applications and connected television apps may be particularly attractive targets because they can collect information that is at least as revealing as traditional web tracking while giving consumers substantially less visibility into what is happening underneath the interface.

A website visitor can install privacy extensions, inspect cookies or open the browser’s Network tab.

A person watching a streaming application on a television generally cannot see that pressing “Play” may cause requests to several advertising, analytics and measurement companies.

A mobile-app user may grant location permission to find a nearby store without realizing that an embedded software development kit is also communicating with an advertising or data company.

That gap between what consumers see and what the software actually transmits is likely to receive much more attention.

For organizations operating mobile applications or Connected TV services, the time to understand those data flows is before a plaintiffs’ firm does it for them.

The privacy perimeter has moved beyond the browser

Many companies have substantially improved website privacy controls.

They have installed consent management platforms.

They scan cookies.

They block advertising scripts before consent.

They respond to Global Privacy Control.

They review Google Tag Manager.

But then someone asks a different question:

What does our mobile app send?

Or:

What happens when someone watches our content through Roku, Apple TV, Fire TV, Android TV, Samsung or LG?

The answers are often much less certain.

A company may have spent months analyzing www.company.com while its applications contain:

analytics SDKs
advertising SDKs
crash-reporting libraries
attribution platforms
measurement providers
location services
authentication systems
push-notification SDKs
video analytics
customer-data platforms

Each may establish its own connections.

Some may receive only operational telemetry.

Others may receive identifiers or behavioral information that materially changes the privacy analysis.

This is not theoretical

California privacy lawyers already identify mobile SDKs alongside pixels, session replay and browser analytics as technologies appearing in CIPA litigation. The California Lawyers Association wrote in 2026 that CIPA litigation has targeted website tracking tools as well as mobile software development kits.

The Video Privacy Protection Act creates another obvious path for scrutiny.

Plaintiffs’ lawyers are actively investigating allegations that websites, mobile apps, streaming platforms and televisions transmit information about users and the videos they watch to third parties. At least one plaintiffs’ investigation specifically solicits consumers who watched content through apps, streaming services or televisions for potential VPPA mass-arbitration claims.

Roku has already faced litigation alleging the collection and disclosure of information involving minors, including browsing histories, geolocation information and voice recordings. A federal court compelled those particular claims to arbitration in May 2026, so the decision was not a finding that Roku violated the alleged privacy laws. But the complaint itself illustrates where plaintiffs are looking.

The target is expanding from:

What did the website pixel collect?

to:

What did the application transmit when I opened it,
searched,
logged in,
watched something,
paused it,
or interacted with an advertisement?

Mobile applications create a different tracking environment

Websites depend heavily on browser technologies.

Applications do not.

A mobile application is executable software installed directly on a user’s device. It may communicate with numerous third-party services through embedded SDKs and APIs.

An SDK is essentially prebuilt functionality supplied by another company.

A developer might install an SDK for:

analytics
advertising
attribution
crash reporting
location
payments
social login
push notifications
customer support

The SDK can then communicate directly from the user’s device to the SDK provider.

The application publisher may not manually write every network request generated by that SDK.

That does not eliminate the publisher’s privacy risk.

The Federal Trade Commission has repeatedly emphasized this point.

In its enforcement involving location-data companies X-Mode and InMarket, the FTC focused on data collected through SDKs embedded in third-party mobile applications. X-Mode received precise location information associated with mobile advertising identifiers through apps containing its SDK.

The FTC has specifically warned developers that incorporating someone else’s SDK can expose app users to the SDK provider’s collection practices and that app developers remain responsible for understanding the third-party code they deploy.

That is the mobile equivalent of installing an unknown tracking script on a website.

Except the application can sometimes reach much more.

What can leak from a mobile application?

Depending on the app, operating system, permissions and SDK configuration, outbound traffic can include information such as:

mobile advertising identifier
IP address
device model
operating-system version
application version
account or user ID
hashed email address
phone number
precise or approximate location
session identifier
advertising events
purchase events
product identifiers
search terms
screen names
content viewed
video identifiers
timestamps
device language
carrier information

Some applications can involve much more sensitive information.

A health application might expose:

appointment activity
symptoms
treatment searches
medication information

A financial application might produce events involving:

account type
financial-product interests
transaction categories
credit activity

A dating app, fertility application, religious application or children’s application introduces entirely different risks.

The privacy question is not simply whether the application contains an SDK.

It is:

Exactly what data does that SDK receive, under which circumstances, and what identifiers travel with it?

Connected TV creates an even more unusual privacy environment

CTV advertising is technically different from browser advertising.

Traditional third-party cookies are not the central identifier.

IAB has acknowledged this problem for years. Its CTV privacy guidance notes that connected television operates in a largely cookieless identity environment where platform-specific advertising identifiers, IP addresses and other mechanisms can be used for audience activation and measurement.

Depending on the platform, identifiers can include advertising or device IDs associated with Roku, Samsung, Android TV, Apple tvOS and other ecosystems.

California’s own privacy agency now describes a Connected TV ID as a unique identifier assigned to a smart television and notes that some data brokers use television IDs to track activity across apps and platforms for targeted advertising.

That should get privacy teams’ attention.

A television that many businesses still treat as a passive screen is actually another connected computing device participating in the advertising ecosystem.

What a CTV application may reveal

Imagine a streaming application sending:

Advertising ID: abc123
Content ID: MOVIE_4782
Episode: S02E04
Timestamp: 21:14:36
IP address: xxx.xxx.xxx.xxx
Ad event: completed
Account ID: 781392

Each field viewed separately may appear relatively mundane.

Combined, the event can potentially communicate:

A device or account associated with this household watched this particular content at this particular time.

That combination explains why video-related privacy statutes deserve particular attention in CTV.

The federal VPPA governs certain disclosures of personally identifiable information concerning consumers’ video viewing. Modern litigation repeatedly asks when identifiers, viewing information and third-party data can be linked sufficiently to meet the statute’s requirements.

Courts do not uniformly accept every VPPA theory. Questions such as whether the plaintiff is a statutory consumer, whether information constitutes personally identifiable information and whether the receiving party can identify the viewer can become case-dispositive.

But the basic technical fact is easy to test:

Did the application send viewing information and an identifier to someone else?

Companies should know the answer before litigation begins.

Automatic Content Recognition adds another layer

CTV privacy is not limited to individual streaming applications.

Smart televisions can also use Automatic Content Recognition technology.

ACR can analyze what appears on the television screen and determine what programming or advertising is being watched.

The FTC’s 2017 Vizio case remains one of the clearest illustrations. The FTC alleged that Vizio collected second-by-second viewing information from 11 million televisions without adequate knowledge or consent and used screen-content recognition across sources including cable boxes, streaming devices, DVD players and broadcast television. The settlement required express consent and a comprehensive privacy program.

This issue has not disappeared.

Roku currently explains that, when users enable its Smart TV Experience, ACR can collect information about programs, commercials and channels viewed through television inputs, including information about when and how long content was viewed.

In September 2026, a plaintiffs’ firm publicly announced an investigation into Roku television ACR practices and whether users were adequately informed about the collection and use of viewing information.

The point is not that ACR itself is unlawful.

It is that television telemetry has become discoverable privacy evidence.

How mobile app privacy scanning actually works

A serious application privacy assessment requires more than reading the privacy policy.

The first layer is static analysis.

The application package can be inspected to determine what has been incorporated into the software.

For Android, an assessment can examine items such as:

APK contents
AndroidManifest.xml
requested permissions
embedded SDKs
third-party libraries
domains and URLs
API references
advertising libraries
analytics packages
location capabilities

For iOS, similar analysis can examine:

application frameworks
SDK dependencies
privacy manifests
entitlements
permissions
embedded domains
tracking libraries

Static analysis answers:

What could this application potentially do?

But that does not tell us what it actually does at runtime.

That requires dynamic testing.

Dynamic testing watches the data leave

A controlled test device or emulator can run the application while network traffic is observed.

The application is then exercised like a real user would use it.

For example:

Install app
↓
Launch app
↓
Before consent
↓
Reject tracking
↓
Accept tracking
↓
Create account
↓
Log in
↓
Search
↓
View content
↓
Make purchase
↓
Change preferences
↓
Log out

The scanner records outbound network connections across those states.

For every request, the assessment can examine:

destination
vendor
timestamp
HTTP method
event
parameters
identifiers
payload
consent state
triggering action

Encrypted traffic requires appropriate testing techniques, and certificate pinning or platform restrictions can complicate inspection of some apps. But the objective remains the same:

Build an empirical map of what the application communicates.

CTV scanning follows a similar principle

Connected television platforms require different testing environments, but the methodology is conceptually similar.

Patrol can evaluate supported CTV applications across environments such as Roku, Android TV, Fire TV, Apple TV and other smart-TV platforms through controlled test devices or suitable platform environments.

The system can exercise important states such as:

first launch
logged out
logged in
consent screen
Reject All
Accept All
content browsing
search
video start
pause
ad start
ad completion
video completion
profile change
logout

Network activity can then be attributed to those events.

This is particularly useful because an ordinary viewer cannot access a television equivalent of Chrome Developer Tools.

What looks like this:

User presses Play

may technically look like:

User presses Play
↓
Streaming API
↓
Analytics provider
↓
Video measurement provider
↓
Advertising platform
↓
Attribution vendor
↓
Content delivery infrastructure

Not every connection creates a privacy problem.

The job is to determine which ones transmit personal or potentially linkable information and whether the transmission matches the company’s disclosures and consent state.

What Captain Compliance Patrol should look for

For both mobile and CTV applications, Patrol’s analysis should revolve around four questions.

Who receives data?

Every destination should be identified and classified where possible.

What is transmitted?

The scanner should inspect for identifiers, viewing information, location, account information, search activity and other potentially personal data.

When does it happen?

Timing matters.

Does an advertising SDK fire before the user makes a privacy choice?

Does it continue after Reject All?

Does it start only after affirmative consent?

Why does it happen?

The destination and event should be classified where possible:

Essential
Analytics
Advertising
Attribution
Personalization
Crash reporting
Fraud
Authentication

That creates something far more useful than an SDK inventory.

It creates a data-flow record.

Consent testing is particularly important

The strongest test is often comparative.

Run the application before consent.

Capture every outbound request.

Then select:

Reject All

Repeat the exact same actions.

Then:

Accept All

Repeat again.

Now compare the traffic.

If an advertising or behavioral-tracking endpoint receives identical information in all three states, there is an obvious compliance question.

A scanning report should be able to say:

Consent state: REJECTED

User action:
Played Episode 4

Observed request:
analytics.example.com/view

Data:
Advertising ID
Content ID
Timestamp
Account identifier

Expected:
BLOCKED

Observed:
TRANSMITTED

That is actionable.

It is also evidence.

This could become especially important under the VPPA

Web VPPA litigation taught companies an expensive lesson.

A page containing a video can send a video identifier to an advertising provider along with another identifier.

Plaintiffs then argue that the combination reveals what an identifiable subscriber watched.

CTV and streaming applications remove some of the factual disputes that arise on ordinary websites because viewing is the core service.

A streaming app inherently knows:

who is logged in
what profile is active
what content was selected
when playback began

If third-party advertising or analytics systems receive combinations of those fields, plaintiffs have a straightforward technical record to examine.

Whether that record ultimately establishes a VPPA violation remains a legal question.

But from a litigation-prevention standpoint, a company would rather discover that transmission during an internal Patrol scan than in an exhibit attached to a complaint.

Mobile SDKs create similar CIPA questions

California litigation has already moved beyond the simple Meta Pixel.

SDKs can perform many of the same technical functions as browser tracking technologies.

An SDK may receive communications contemporaneously with a user’s interaction.

It can observe:

screens viewed
buttons selected
search queries
form events
device identifiers

That makes mobile implementations an obvious candidate for the same interception theories plaintiffs have attempted on websites.

Again, application does not equal liability.

CIPA litigation is heavily contested, and California enacted reforms in 2026 affecting parts of the tracking-litigation landscape.

But plaintiffs do not need to wait for certainty before sending a demand letter.

Children create another obvious risk area

Applications used by children deserve heightened scrutiny.

The FTC’s 2025 action involving Apitor Technology illustrates why.

The FTC alleged that a third-party SDK inside an app associated with children’s programmable toys collected geolocation information from Android devices. The agency emphasized that developers using third-party software still must ensure compliance with COPPA.

CTV adds another complication.

A household television may have one account but multiple viewers.

Children may watch programming through a parent’s account.

A device identifier can represent a television rather than a particular human.

This creates difficult questions involving:

age
identity
household data
advertising
profiling
consent

Those should be tested, not assumed away.

Server-side traffic cannot be ignored

Mobile and CTV privacy assessments also need to follow data beyond the device.

A CTV application might send an event only to the publisher:

TV
↓
Publisher server

The publisher server may then forward it through server-side integrations:

Publisher
↓
Advertising API
Measurement vendor
Data warehouse
CDP
Attribution provider

A device-only scanner may not see those downstream transmissions.

That means the mature version of application privacy monitoring combines observed client-side behavior with known server-side integrations and data mapping.

Otherwise an organization can honestly say:

“The app doesn’t send anything directly to Meta.”

while its server sends the same event to Meta seconds later.

Privacy law generally cares about the disclosure, not which network hop performed it.

Why plaintiffs may like this environment

Website privacy litigation became scalable because technical testing became repeatable.

A tester could visit hundreds of websites, identify a particular tracking technology and look for the same pattern.

Mobile and CTV applications increasingly offer the same possibility.

A firm can:

download app
↓
run controlled session
↓
capture traffic
↓
identify third parties
↓
inspect payloads
↓
compare privacy disclosures
↓
repeat

Streaming applications add easily understandable facts.

“Company transmitted Episode 7 and advertising identifier X to Vendor Y” is easier to put in a complaint than an abstract argument about modern ad technology.

This does not mean every discovered transmission is unlawful.

It means application owners should expect their network traffic to be examined.

The privacy audit is moving from documents to packets

For years, privacy audits concentrated heavily on paperwork.

Review the privacy policy.

Review contracts.

Review the data map.

Review vendor agreements.

Those remain necessary.

But they tell you what an organization believes should happen.

Application scanning shows what actually happened.

The two should match.

If the privacy notice says advertising tracking does not occur after opt-out, the application’s traffic should prove it.

If the company says precise location is not shared with advertising vendors, packet-level testing should support that representation.

If the streaming service says video activity is not disclosed for behavioral advertising, its CTV traffic should confirm it.

This is where continuous application scanning becomes valuable.

Why continuous matters

Apps change constantly.

A developer releases version 8.2.

Marketing adds an attribution SDK.

An advertising partner changes endpoints.

A video player receives an update.

A CTV platform modifies its APIs.

A new measurement company is introduced.

A developer enables a previously dormant SDK configuration.

An app that passed its privacy review six months ago may behave differently today.

The same logic that supports continuous website scanning applies to applications:

Discover
↓
Classify
↓
Test
↓
Compare
↓
Alert
↓
Remediate
↓
Preserve evidence

That is the role Captain Compliance Patrol can increasingly play across web, mobile and Connected TV.

The real objective is not finding SDKs

An SDK list is useful.

It is not enough.

The more important question is whether Patrol can tell a company:

Your Android application transmitted a mobile advertising ID and precise location to this endpoint before consent.

Or:

Your Roku application transmitted a content identifier and device identifier to this advertising vendor when playback started.

Or:

Your iOS application stopped the advertising SDK after the user declined tracking, but your server-side attribution endpoint continued sending events.

Or:

Version 5.6 introduced a new third-party destination that was not present in version 5.5.

Those findings can be investigated and fixed.

That changes privacy compliance from periodic paperwork into technical monitoring.

The Next Privacy Lawsuit May Not Start on Your Website

Companies have spent years learning that the code running on a website can create legal risk even when nobody inside the legal department knew the code existed.

The same lesson now needs to be applied to apps.

The FTC has already pursued mobile SDK practices involving precise geolocation. Plaintiffs are already alleging CIPA violations involving SDKs. VPPA lawyers are openly investigating applications, streaming services and televisions. Smart-TV viewing data has already produced federal enforcement, and current litigation is examining CTV data collection again.

Mobile and Connected TV are not hypothetical future privacy environments.

They are already regulated data ecosystems.

What is changing is the level of scrutiny.

The strongest defense is not waiting to learn which statute plaintiffs decide to use.

It is knowing exactly what the software does.

For every application, companies should be able to answer:

What third parties are present?

What information leaves the device?

What identifiers accompany it?

What event caused the transmission?

Did the user consent?

Does Reject All actually stop it?

Does viewing information leave the streaming environment?

Does location leave the mobile application?

Does the data continue downstream server-side?

Can we prove what happened?

That is where privacy compliance is moving.

First the website became observable.

Now the app is becoming observable.

The television is becoming observable.

And once plaintiffs’ firms, regulators and privacy engineers can independently see the same network activity, saying “we didn’t know the SDK was doing that” becomes an increasingly weak position.

The companies that get ahead of this will treat mobile and CTV traffic the same way mature security teams treat their networks: continuously monitored, classified, tested and documented.

Because the next major privacy problem may not be hiding in a cookie.

It may be inside the app running on the screen.