Half of all declared permissions in the latest batch of AI toy companion apps are classified as dangerous by Android guidelines, and that’s just the tip of the iceberg when it comes to AI toy privacy. Cybernews dissected ten Android apps – from Loona to SPIKE™ LEGO® Education – and uncovered a worrying pattern of over‑reaching access requests and hidden trackers.
Key Takeaways
- All ten examined apps request at least one permission deemed dangerous by Android.
- Seven of the apps embed third‑party trackers, including advertising and profiling modules.
- Six apps need microphone access, five need camera access, and eight scan for Bluetooth devices.
- Regulatory safeguards from the FTC’s Children’s Online Privacy Protection Rule may be sidestepped by these permissions.
- Developers and parents alike must tighten control to protect kids’ data.
AI Toy Privacy: Permissions and Trackers Under the Microscope
When a parent downloads a companion app for a robot dog or a programmable brick, they’re usually focused on getting the toy to work, not on the fine print. The reality is that each of the ten apps we looked at – Loona, Dash & Dot, Sphero, mBlock, Miko, Eilik, SPIKE™ LEGO® Education, Ozobot Evo, Petoi and AIBI Pocket – asks Android for permissions that the platform flags as risky. That includes precise location for Bluetooth Low Energy pairing, but also microphone, camera and Bluetooth scan rights that go far beyond the basics.
The Permission Overload
It isn’t surprising that a toy needs to locate its hardware via BLE, but the fact that all ten apps also request microphone and camera access raises eyebrows. Six of the apps need the mic, five want the camera, and eight scan for nearby Bluetooth devices. While some developers argue those capabilities enable voice commands or visual programming, the breadth of the requests makes it easy for a malicious actor to harvest sensitive data if the app were compromised.
Trackers Lurking in Companion Apps
Beyond permissions, the investigation uncovered third‑party trackers in seven of the ten apps. Most of those were crash‑reporting or analytics services, but two apps carried advertising trackers, another two had profiling trackers, and Loona even bundled a location tracker. Those components can stitch together a behavioral profile of a child, something the FTC’s updated Children’s Online Privacy Protection Rule explicitly tries to curb.
- 7/10 apps contain third‑party trackers.
- 2 apps include advertising trackers.
- 2 apps embed profiling trackers.
- 1 app (Loona) adds a location tracker.
Historical Context: How Permissions Got Dangerous
Android has always separated permissions into “normal” and “dangerous” groups. The split was introduced to give users a clearer picture of what an app could do with their device. “Dangerous” permissions trigger a runtime prompt, forcing the user to approve or deny each request. Over time, developers grew accustomed to asking for many of these permissions at install time, and some began to bundle them together to simplify code paths.
At the same time, the market for AI‑enabled toys exploded. Manufacturers added microphones, cameras, and Bluetooth radios to make toys more interactive. Those hardware additions naturally required the same “dangerous” permissions that Android flags. The result is a convergence: a new class of apps that need to ask for a long list of high‑risk permissions simply because the underlying hardware demands it.
What started as a convenience for developers has morphed into a privacy concern. When a child’s toy can listen, see, and locate nearby devices, the data stream becomes richer than the original intent of the app. The platform’s permission model, designed for adult users, now sits at the front line of a privacy debate that involves minors, regulators, and the broader tech ecosystem.
Regulatory Context and Children’s Online Privacy
The FTC’s chair, Lina M. Khan, reinforced key protections for kids’ privacy online, limiting data retention, demanding opt‑in consent for targeted ads, and requiring clear disclosures. Those rules are meant to stop exactly what we’re seeing: apps that collect more data than they need, and then use that data to build detailed user profiles.
“Data minimization for children’s apps is essential. Responsibility falls both on developers to request fewer permissions and minimize sensitive trackers, and on parents to take greater control over the technology available to their children,” the researchers said.
That quote underscores a simple truth – kids aren’t equipped to understand what data is being siphoned off, and they certainly can’t give informed consent. The UK’s move to ban social media for under‑16s, following Australia’s lead, shows governments are getting serious about protecting minors online. Yet the AI toy market keeps pushing forward, seemingly sidestepping those safeguards.
What Developers Need to Do
If you’re building the next generation of interactive toys, you need to rethink how you request permissions. Start by stripping out any non‑essential access – if a toy can function without a camera, drop that request. Audit every third‑party library for tracking behavior; replace analytics services that harvest location or profile data with privacy‑first alternatives. And document every permission request clearly for parents, so they can make an informed choice.
Practical Steps for Reducing Risk
First, run a permissions audit against Android’s “dangerous” list and prune anything that isn’t mission‑critical. Second, replace advertising SDKs with ones that respect the Children’s Online Privacy Protection Rule, or eliminate them entirely. Third, provide an in‑app toggle that lets parents disable optional sensors like the microphone when they’re not needed.
What This Means For You
For developers, the takeaway is clear: over‑permissioned apps will attract scrutiny, and regulators are watching. Cutting unnecessary permissions not only reduces legal exposure but also builds trust with a savvy parent audience that’s increasingly wary of data‑hungry toys.
For parents, the practical implication is to treat companion apps like any other app that accesses personal data. Review the permission list before you hit “install,” and consider revoking microphone or camera rights in the Android settings once the toy is paired. Remember, the data a child generates today could be used to profile them tomorrow.
Concrete Scenarios
- Developer scenario: You’re releasing an upgrade that adds voice‑controlled commands. Instead of requesting permanent microphone access at install, you can request it only when the user activates the voice feature. That limits exposure and shows a clear intent to the platform’s permission system.
- Founder scenario: Your startup pitches to investors and highlights a “privacy‑first” stance. By publishing a “permission transparency” page that lists each requested permission and why it’s needed, you give investors a tangible proof point that your product respects regulatory expectations.
- Parent scenario: You’ve just bought a programmable brick for your child’s school project. After installing the companion app, you go into the device’s app settings and toggle off Bluetooth scanning when the toy isn’t being used. That simple step prevents the app from constantly probing for nearby devices.
Technical Architecture: Inside a Typical Companion App
Most AI toy apps share a common architecture. The front‑end runs on Android, presenting a UI that lets kids drag blocks, draw paths, or issue voice commands. Beneath that UI sits a communication layer that talks to the physical toy over Bluetooth Low Energy. BLE requires precise location permission because Android treats any nearby scan as a location‑related operation.
The same layer often includes optional modules for voice recognition and computer vision. Those modules hook into the system microphone and camera, respectively. When a developer bundles them together, Android labels the whole package as “dangerous” even if the core toy functionality would work without them. That is why you see a long permission list even for toys that primarily move or light up.
Third‑party SDKs are typically added for crash reporting, usage analytics, or ad monetization. Each SDK brings its own set of permissions and network calls. A crash‑reporting library might request storage access to write logs; an analytics SDK could ask for network state to gauge connectivity; an ad SDK may need location to serve region‑specific ads. The cumulative effect is a permission set that far exceeds the toy’s functional needs.
Developers can mitigate this by modularizing their code. Separate the BLE stack from optional voice or vision features, and load those features only when a user explicitly enables them. Likewise, choose SDKs that expose a “no‑tracking” mode, and turn that mode on for the child‑focused version of the app.
Key Questions Remaining
- How will regulators enforce the Children’s Online Privacy Protection Rule on apps that bundle multiple “dangerous” permissions?
- Will app stores tighten their review processes for AI toys, requiring a justification for each permission?
- Can industry groups develop a shared privacy framework that defines a baseline set of acceptable permissions for child‑focused products?
- What mechanisms will emerge for parents to audit and revoke permissions on a per‑toy basis without breaking functionality?
As AI‑driven toys become more common, will the industry adapt its privacy practices fast enough, or will we see stricter enforcement from regulators?
Sources: TechRadar, Cybernews
