DOJ Files Suit for Alleged Collection of Geolocation Info

What the DOJ Suit Alleges

According to the federal allegations, a toy maker that sells programmable robot toys for children offered a free companion mobile app used to program and
control the robots. The DOJ filed the complaint in federal court after an FTC referral, accusing the company of collecting (or causing to be collected)
precise geolocation data from children under 13 without providing proper notice to parents and without obtaining verifiable parental consent.

The details matter because they sound like the kind of “normal” app flow many companies treat as routine. The allegations describe an Android experience where
users had to enable location permissions to connect a toy via Bluetooth. Once location permissions were enabled, the complaint says the app collected precise
location data in the background and transmitted it to third-party serverswithout clearly disclosing that third-party collection to users or parents.

“But We Didn’t Mean To” Isn’t a Settings Menu Option

The case highlights a common privacy pitfall: a company can be held responsible not only for what it directly collects, but also for what it
enables third parties to collect through embedded code. In this dispute, the spotlight falls on a third-party software development kit (SDK)
used for app functions like notifications and analytics. The government alleges that the SDK could collect location data and use it for broad purposes.

What the Proposed Settlement Requires

In the public descriptions of the settlement, the company agreed to compliance obligations designed to stop future collection of children’s personal information
without proper parental involvement. The order also includes a civil penalty that is suspended due to the company’s stated inability to pay, with conditions
that could trigger payment if financial disclosures were misrepresented.

The big takeaway: this isn’t “just a privacy policy issue.” It’s a compliance, engineering, vendor-management, and product-design issueall
at once.

Why Geolocation Data Is a Big Deal

People hear “location data” and picture a blue dot on a map. Cute. Unfortunately, precise geolocation is more like a diary that writes itselfquietly, constantly,
and with shocking detail. Even a handful of location pings can reveal a home address, a school drop-off routine, weekend patterns, and where a child spends time.

Specific Risks When Kids’ Location Is Involved

• Safety and stalking risks: Location trails can be exploited to infer where a child lives or routinely appears.
• Profiling and targeting: Location plus device identifiers can enable interest-based or behavioral targetingespecially in ad ecosystems.
• “Sensitive location” inference: Visits to medical facilities, religious sites, shelters, or political events can be inferred from raw location history.
• Data spillover: Once location data goes to multiple vendors, it becomes hard to track, delete, or control.

Regulators increasingly view geolocation as uniquely revealing. It’s not just “personal information.” It can be a behavioral fingerprintone that’s hard to change.
You can reset a password. You can’t reset “everywhere you went last month.”

COPPA 101: The Rules Behind the Lawsuit

The Children’s Online Privacy Protection Act (COPPA) is the U.S. law built to protect children under 13 online. It doesn’t ask companies to be perfect. It does
ask them to be responsibleand very clear with parents.

What COPPA Generally Requires

If you operate an online service directed to kids under 13 (or you have actual knowledge you’re collecting personal information from them), COPPA typically requires:

• A clear, complete privacy policy describing children’s data practices.
• Direct notice to parents about what you collect and why.
• Verifiable parental consent before collecting, using, or disclosing kids’ personal information (with limited exceptions).
• Reasonable retention limits and deletion practices.
• Ongoing accountability for service providers handling children’s information.

Why the DOJ Is Involved

People often assume the FTC handles all privacy enforcement alone. But in certain COPPA matters, the DOJ can file a federal complaint and enter a stipulated court
orderoften after an FTC referral. In plain English: if the FTC believes COPPA was violated, things can escalate into a DOJ-filed federal court action with real
penalties and binding injunctive terms.

And COPPA isn’t frozen in time. The rule has been updated over the years to address modern data flows, third-party sharing, and the way digital services monetize
user information. If your mental model of COPPA is “that one kids’ privacy law from the dial-up era,” it’s time for an update.

The SDK Problem: “It’s Just a Vendor” Isn’t a Defense

Modern apps are built like a layered cake: your code, plus libraries, plus SDKs, plus analytics tools, plus push notification providers, plus “just one more”
marketing pixel somebody snuck in during sprint week. Individually, each component feels small. Collectively, they can become a surveillance machine with excellent
uptime.

How SDK Risk Shows Up in the Real World

The allegations in this DOJ/FTC matter read like a classic: an app needed a feature (like push notifications), so it included an SDK. That SDK had its own data
practices. Then the app’s permissions and background behaviors created a pipeline for location data collection that users and parents weren’t meaningfully told about.

Here’s the trap: your privacy policy can say “we comply with COPPA,” and you can still end up in court if your product behavior contradicts it.
Regulators don’t grade you on intention. They grade you on outcomes.

What “Reasonable Steps” Looks Like (In Human Terms)

• Inventory every SDK (and keep the list currentapps change fast).
• Map data flows (what leaves the device, where it goes, and why).
• Review vendor policies and confirm they align with your representations and legal obligations.
• Contract for compliance (audit rights, use limitations, subprocessor controls, breach notice).
• Test what actually happens (network traffic, background collection, permission prompts).

If that sounds like work, yes. It is. The alternative is learning privacy engineering “the hard way,” which is a polite phrase meaning “with lawyers present.”

The Bigger Trend: Location Data Enforcement Heats Up

This DOJ-filed geolocation complaint doesn’t exist in a vacuum. U.S. regulators have been escalating actions focused on how companies collect, share, sell, and
monetize location dataespecially where sensitive places can be inferred.

From Kids’ Apps to the Data Broker Economy

In recent enforcement actions, the FTC has pursued companies accused of selling or sharing location data that could reveal visits to sensitive locations like medical
clinics, places of worship, and shelters. The agency has also focused on businesses that gather location through SDKs embedded in third-party apps, then merge that
data into advertising profiles and targeting products.

What This Pattern Signals

• Location is treated as sensitive by defaultnot merely “personal.”
• Third-party data flows are front-and-center, including ad auctions and SDK ecosystems.
• “We disclosed it somewhere” is losing power when disclosure is unclear, buried, or practically invisible.
• Kids’ data raises the stakes, often triggering stricter obligations and harsher scrutiny.

Translation: If your business model depends on collecting precise geolocation “just in case we find a use for it,” you may want to start pricing in compliance
costsbecause regulators already are.

What Businesses Should Do Right Now

Whether you build kids’ apps, sell connected toys, run an ad-tech SDK, or simply have users who might be under 13, this case offers a blunt blueprint for what
regulators expect. Below is a practical checklist designed for product teams, not just legal teams.

1) Treat Geolocation as “High-Risk” by Default

If your app asks for precise location, you should be able to explainclearly and honestlywhy you need it, what happens if the user says no, and who receives it.
If the real reason is “because the SDK wanted it,” that’s not a reason. That’s a bug report.

2) Fix Permission Design (Don’t Corner Users)

Requiring location permissions as a condition to use a toy feature is a red flagespecially if the feature is Bluetooth pairing or basic connectivity. If there’s a
less intrusive permission path, build it. If there isn’t, document why, and make sure your disclosures and consent flow are airtight.

3) Build a COPPA-Ready Consent Flow

• Use age gates where appropriate (and don’t make them decorative).
• Provide direct notice to parents with plain-language summaries.
• Implement verifiable parental consent methods suitable for your service.
• Log consent in a way you can prove later (because you might need to).

4) Audit SDKs Like You Mean It

“Set it and forget it” is how you end up collecting data you never intended to touch. Maintain an SDK manifest, review default settings, and test after updates.
If an SDK can collect location, assume it willunless you’ve configured and verified otherwise.

5) Align Your Privacy Policy with Reality

Many enforcement actions begin with a simple mismatch: the policy promises one thing, the product does another. Make sure your disclosures cover:

• What data is collected (including precise geolocation, if applicable).
• Whether third parties collect data through your app or service.
• How long you retain data and how users/parents can delete it.
• How you handle service providers and downstream sharing.

6) Prepare for Deletion Requests and Data Minimization

If a parent requests deletion, your systems need to actually delete the datanot “soft delete,” not “we deleted it from one database,” not “it’s gone-ish.”
Make deletion real, test it, and confirm it includes vendor pipelines where feasible.

What Parents and Caregivers Can Do Today

You shouldn’t need a cybersecurity lab to buy a toy. But until privacy-by-design becomes the default, a few habits can reduce risk.

Quick, Practical Steps

• Check app permissions: If a toy app wants precise location, ask why. If the toy still works without it, deny it.
• Use OS-level controls: Prefer “While Using the App” over “Always,” and avoid precise location when it’s not necessary.
• Review the app store listing: Look at data safety disclosures and permission justifications.
• Consider a separate “kid device” setup: Fewer apps, fewer trackers, fewer surprises.
• Ask for deletion: If you stop using the app, request deletion of the child’s data and keep a record.

None of this replaces corporate responsibility or legal compliance. But it can help keep “fun robot toy” from turning into “why does this app know our weekend routine?”

Real-World Experiences: How Geolocation Sneaks In (And What Teams Learn the Hard Way)

Let’s talk about the part nobody puts in the launch deck: the small, seemingly harmless product decisions that accidentally create a location data pipeline.
Below are common “experience patterns” seen across the industrycomposites of recurring scenarios from app audits, enforcement actions, and post-launch cleanup
projects. Names changed. Lessons kept. Humor applied gently.

Experience #1: The Bluetooth Pairing “Location Required” Surprise

A team builds a companion app for a connected device. Pairing uses Bluetooth. On Android, Bluetooth scanning can interact with location permissions depending on
the implementation. Somebody ships the simplest solution: “Enable Location to Continue.” Users comply, because they want the thing to work. Suddenly the app has
location permissionoften precise locationwithout a strong user understanding of why.

The lesson teams learn: If the user experience feels like a hostage note (“Give me location or the robot gets it”), regulators and customers will assume the app
is collecting more than it needs. Better designs include a clear explanation screen (“Android requires this permission for device discovery”), a fallback option
when possible, and a privacy review that confirms location data isn’t being logged, transmitted, or reused beyond the immediate need.

Experience #2: The SDK That “Only Does Push Notifications”… Plus a Few Extras

An SDK is added for push notifications, crash reporting, or analytics. The product team thinks it’s a utility. The marketing team likes dashboards. The developer
likes that it works in five minutes. Then months later, someone reads the vendor documentation or privacy policy and realizes the SDK can collect device identifiers,
network data, anddepending on settingslocation.

The cleanup is always the same movie: update the SDK config, renegotiate vendor terms, edit disclosures, and run network traffic tests to confirm the data flow
actually stopped. Teams learn to treat SDKs like ingredients in food: if you can’t explain what’s in it, don’t serve it to children.

Experience #3: “Our Privacy Policy Says We Don’t Upload Personal Info” (Oops)

This one is painful because it’s so avoidable. A privacy policy is drafted early, using best intentions and a hopeful tone. But the product evolves: new SDKs,
new analytics, new hosting providers, new log pipelines. Meanwhile, the policy stays frozen like a digital museum exhibit.

When a regulator or reporter compares the policy to actual behavior, the company looks deceptive even if nobody intended deception. The fix is boring but powerful:
version-controlled privacy disclosures, release checklists that include data flow review, and sign-off gates when permissions or third-party collection changes.

Experience #4: Kids Use the App Even If You Didn’t “Target” Kids

Some companies convince themselves they’re not child-directed because they didn’t write “for kids” in the app description. But if the product, marketing, visuals,
and real-world audience include children, COPPA questions come fast. If you have actual knowledge kids use the serviceor your service is obviously kid-friendlyyou
can’t wish compliance away with a vibes-based argument.

Teams learn to decide early: Are we a kids product, a mixed-audience product, or an adult product? Then they align everythingdesign, permissions, data collection,
retention, consent flows, and vendorsaround that answer. The cost of ambiguity is usually paid later, and usually with interest.

Experience #5: The “Delete Means Delete” Reality Check

Deletion requests sound simple until you map the systems. Data may exist in app logs, analytics platforms, vendor dashboards, backups, and debug tools. For kids’
data, especially geolocation information, “we deleted it from the primary database” won’t feel good enough when you realize copies exist elsewhere.

The teams that mature fastest build deletion as a real capability: inventory where data lives, automate deletion workflows, document exceptions, and confirm vendors
can comply. The punchline is that this improves security and trust for everyonenot just children.

If these experiences feel uncomfortably familiar, good. That means you’re catching the risk before it catches you. The DOJ suit over alleged geolocation collection
is a reminder that privacy failures are rarely one catastrophic decision. They’re usually twenty small ones that never got reviewed together.

Conclusion

The DOJ’s geolocation lawsuit sends a clear message: when a product touches children, privacy can’t be an afterthought. If an app collectsor
enables a third party to collectprecise location data from kids without proper parental notice and consent, regulators are prepared to act. And as broader
enforcement against location-data practices ramps up across industries, the safest assumption is simple: geolocation is sensitive, compliance is mandatory,
and “we didn’t realize the SDK did that” is not a compliance strategy.

For companies, the playbook is straightforward: minimize data, design permissions responsibly, vet vendors relentlessly, and align disclosures with reality.
For parents, permission hygiene and cautious app setup help reduce exposure. For everyone else: enjoy the robot toysjust don’t let them quietly become tiny
location beacons with excellent customer support.