What Ximos actually does with access to a child's device.

Principles

Our zero-trust data policy

Most parental-control apps collect broadly — contacts, call logs, full location history, browsing history — because more data feels like more value. Ximos deliberately went the other way: the database is designed so that even a full server breach would expose almost nothing useful about any individual user.

This does mean XimosKid requests permissions that look intimidating on paper — camera, microphone, location, Accessibility, Device Admin, usage access. Those permissions are real and sensitive, and each one is documented below with exactly what it's used for and what it's explicitly not used for. The difference between "sensitive permission" and "surveillance app" isn't the permission list — it's whether that access is authenticated, auditable, and disclosed.

How a live session actually works

The signaling server's only job is to help two devices find each other. It never sees the camera, screen, or audio content — that travels directly between devices over WebRTC.

A TURN server is used as a fallback relay only when a direct peer-to-peer path can't be established (for example, across restrictive mobile carrier NATs). Even in that fallback path, the WebRTC transport stays end-to-end encrypted between the two devices — the TURN relay forwards encrypted packets, it does not decrypt them.

Location relay — separate path, same encryption posture

Location tracking does not use WebRTC — it travels over a separate authenticated WebSocket relay hosted on Cloudflare Workers, isolated per user-device room via a Durable Object keyed to uid + deviceKey. The Cloudflare Worker verifies the Firebase ID token server-side against Google's public JWKS before allowing any broadcast. Location payloads are pushed to the connected parent in real time and are not retained on Ximos servers beyond the in-flight relay.

Data we store, by sensitivity

That's the complete list — there is no sixth category. We don't build advertising profiles from stream content or location, sell data to third parties, or keep a copy of live sessions after they end. Notifications, Smart Alerts, on-screen toasts, clipboard sends, and remote URL/app-open commands are one-shot, serverless commands from parent to child — they aren't logged in a database at all.

Encryption — what's actually implemented

XimosKid permissions, in full

Every permission is requested one at a time, with an in-app disclosure explaining it in plain language — shown before the Android system dialog, with a short forced-read delay so it can't be tapped through blindly.

This table covers permissions only. For the full list of remote-control features (Smart Alert, OnScreen Notify, clipboard send, camera flip/flashlight, Smart Zoom, Smart Focus, Location Tracking, and what each one costs), see the Feature capability map in the Docs.

Location privacy, in plain terms

Location is the newest sensitive data type Ximos handles, so it gets its own section rather than being folded into the general permissions table.

Icon hiding & the persistent notification

This is the part of Ximos most likely to raise a fair question, so it's documented directly instead of glossed over.

What's true

• • A parent can optionally hide the XimosKid launcher icon on the child's device.
• • While the icon is hidden — and at every other time any monitoring feature is active — a foreground notification is always present and cannot be dismissed.
• • A hidden dial code can restore the icon at any time, from the child's device itself.
• • With the icon visible (the default), the app also shows under its own name, "XimosKid," in the device's app list and notification shade.

Why this is different from covert stalkerware: the defining trait of spyware isn't a hidden icon — it's a hidden presence. XimosKid's notification cannot be hidden, muted, or swiped away while any monitoring feature is active, on any build. The device always tells its user something is running, even when the icon doesn't.

The honest limitation: a notification is only a meaningful signal if the person reads it. We're not going to pretend that's a perfect safeguard — it's a real one, not a total one. If you're a parent using this feature, we'd still recommend talking to your child about it directly; that conversation does more than any technical control can.

Device pairing

Pairing securely links the parent's account to a specific physical device. XimosKid uses an automatic QR scan to complete the login and pairing process, so no 6-digit pairing key needs to be entered manually.

Account security

A compromised parent account is the highest-impact single failure in this whole system, since it can reach every paired device on it. Current and planned protections:

Retention & deletion

Abuse prevention

Ximos is built and licensed for authorized parental supervision of minors in the account holder's care. Our Terms of Use explicitly prohibit:

Full terms: ximosapp.com/uno/#terms-of-use

Independent verification

Both APKs are scanned with MobSF (Mobile Security Framework), an open-source static-analysis tool used across the Android security community — so you don't have to take our word for it. Reports were also cross-checked against VirusTotal's multi-engine scan.

Native library hardening (both apps, all architectures)

Open findings we're addressing (not hiding)

Scanned Sept 4, 2026 with MobSF v4.5.2. We'll re-run and update this table with each release.

Subprocessors & infrastructure

Services XimosKid and Ximos communicate with in normal operation, as observed in independent network analysis:

No communication with OFAC-sanctioned regions was found in the analyzed builds.

Version history

Report a vulnerability