Ximos logo Ximos

Trust Center — reviewed Sept 2026

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

Powerful parental controls without turning a phone into hidden spyware. This page documents the real architecture behind Ximos and XimosKid — what we store, what we don't, where the trade-offs are, and what independent scanning tools found — instead of asking you to take our word for it.

Independent scan results ↓ Icon & visibility policy ↓ Zero-trust data policy ↓

Principles

Least privilege

Only the permission a feature needs, requested at the moment it's needed — not bundled on install.

Encryption by default

Live streams travel peer-to-peer over encrypted WebRTC (DTLS-SRTP). All API calls are HTTPS-only.

Minimal retention

Three fields server-side, full stop. Live media never touches our servers at all.

Guardian authorization

Every sensitive endpoint verifies the requesting parent actually owns the target device before acting.

Visible monitoring

A persistent, non-dismissable notification runs on the child device whenever monitoring is active.

No absolute claims

No system can guarantee perfect security. We show findings, including open ones, instead of promising perfection.

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.

The design question we asked was simple: if our database leaked tomorrow, what could someone actually do with what's in it? With an account email, a device brand string, and a randomly generated device ID — the honest answer is close to nothing. There's no address, no contact list, no browsing history, no message content sitting in a table waiting to be exposed.

This does mean XimosKid requests permissions that look intimidating on paper — camera, microphone, 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.

Ximos Parent App
authenticated API call (HTTPS + JWT + device key)
Ximos Signaling Server

exchanges connection info only — never touches media, never stores the stream

WebRTC SDP handshake via STUN/TURN
XimosKid — Child Device
encrypted peer-to-peer stream (DTLS-SRTP)
Screen / Camera / Audio → rendered directly in the Parent App
The most important guarantee here: the signaling server is not a media relay. If it were compromised, an attacker could disrupt pairing — they could not intercept a live screen or camera feed, because that never passes through it. This is also why Ximos can run on a lightweight, low-cost backend instead of provisioning heavy media-relay infrastructure for every session.

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.

Data we store, by sensitivity

LevelDataWhere it livesRetention
CriticalLive camera, mic, screenNever touches our servers — peer-to-peer onlyNot stored, ever
SensitiveCaptured photos / recorded clips (Cloud Media Vault)Cloud object storage30 days, then 7-day trash window, then permanent delete
PersonalAccount email, device unique ID, device brand nameXimos databaseUntil account deletion
TechnicalApp version, OS version, session/connection stateXimos databaseWhile session/account is active

That's the complete list — there is no fifth category. We don't build advertising profiles from stream content, sell data to third parties, or keep a copy of live sessions after they end. Notifications, Smart Alerts, on-screen toasts, 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

In transit

  • • All API traffic over HTTPS/TLS
  • • Live screen/camera/audio over WebRTC, which mandates DTLS-SRTP encryption between peers
  • • Pairing keys exchanged only over the authenticated API — never in plaintext links
  • • Firebase Realtime Database connections use Google's standard TLS transport

At rest

  • • Cloud Media Vault files are stored with our storage provider's server-side encryption
  • • Only three low-sensitivity fields sit in our own database (see table above)
  • • We don't yet publish a customer-facing key-rotation schedule — tracked on the roadmap

Conceptual key-management flow (where applicable)

Application KMS Encryption Key Encrypted Data
We're intentionally not claiming a specific customer-facing key-rotation cadence here until it's fully documented and independently verifiable — writing it down before it's true would be exactly the kind of claim this page exists to avoid.

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.

Placeholder — screenshot of the in-app camera permission disclosure dialog
A real screenshot of the in-app disclosure dialog shown before the CAMERA system prompt.
PermissionTypeUsed forWhat it is NOT used for
CAMERADangerousRemote camera sessions started by a parentBackground capture without an active, parent-initiated session
RECORD_AUDIODangerousOne-way ambient listening, timed and indicator-shown. Requires a minimum $0.10 account balance — not covered by free bonus seconds, unlike screen/camera sessions.Continuous background recording
SYSTEM_ALERT_WINDOWDangerousOn-screen toast/priority alerts, remote-touch overlayAd injection or UI spoofing
BIND_ACCESSIBILITY_SERVICESignatureRemote-touch gestures during an active screen sessionReading input from other apps outside a session
PACKAGE_USAGE_STATSSignatureApp usage-time reporting to the parent dashboardReading in-app content of other apps
Device AdminPIN-gated uninstall protectionRemote wipe or device lock — not implemented
REQUEST_INSTALL_PACKAGESDangerousSelf-updating XimosKid to the latest signed buildInstalling any other package
READ_MEDIA_IMAGES / READ_MEDIA_VIDEODangerousUploading a parent-requested capture to the Cloud Media VaultBulk-scanning the existing photo library
POST_NOTIFICATIONSDangerousShowing the persistent "monitoring active" notification itselfMarketing or ad notifications
FOREGROUND_SERVICE (+ camera/microphone/mediaProjection types)NormalKeeping an active session alive and declared to the OS, per Android 14+ requirementsHiding what type of foreground work is running
REQUEST_IGNORE_BATTERY_OPTIMIZATIONSNormalPreventing the OS from killing the monitoring service mid-sessionDraining battery outside an active session

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

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.
Real device screenshot showing the persistent XimosKid notification reading 'Parental monitoring is running on this device' in the Android notification shade
Real device screenshot — the current, non-dismissable notification shown whenever monitoring is active, regardless of icon visibility.
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.

1 · Install

XimosKid is installed on the child device and the required Accessibility & Notification permissions are granted.

2 · Scan QR

The parent opens the pairing screen and displays the generated QR code. The child device automatically scans the QR code to identify and authenticate the pairing request.

3 · Connected

Once the QR scan is verified, the parent account is linked to the physical device and the connection status is established automatically.

Screenshot showing the automatic QR code device pairing process
Device pairing is completed through an automatic QR scan, eliminating the need for manual 6-digit pairing codes.

Automatic pairing: The QR-based flow is designed to keep setup simple while linking the authorized parent account with the intended physical device. No manual pairing key entry is required.

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:

In place today

  • • Firebase-backed authentication with hashed credentials
  • • Short-lived access tokens, refreshed rather than long-lived
  • • Every sensitive API call re-verified server-side, not just checked once at login

Roadmap

  • • Optional passkey / 2FA for parent accounts
  • • Login notifications and suspicious-login detection
  • • "Log out of all devices" control in account settings

Retention & deletion

Cloud Media Vault — 30 / 7 policy

Captured photos/clips auto-delete 30 days after capture, move to a 7-day trash window, then are permanently wiped by an automated job — no manual step, no warning email at delete time. Users are warned the first time they use the feature to download anything they want to keep.

Account deletion

Deleting your Ximos account removes your profile, paired devices, pairing records, vault media, and usage data. You'll see a confirmation — "Your deletion request has been completed." — once it's processed, and the action is permanent.

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:

Unauthorized surveillance of an adult
Stalking or partner monitoring
Employee surveillance
Monitoring without legal guardianship
Account or pairing-code sharing to bypass authorization
Automated or brute-force pairing attempts

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.

Ximos (parent app)

64/100 · Grade A
Packagecom.ximexa.ximos
Version1.0.2 (code 10002)
High / Medium / Info findings0 / 8 / 2
Signaturev3, RSA 2048
SHA-256796851ff…de9388
VirusTotal report ↗

XimosKid (child app)

58/100 · Grade B
Packagecom.droid.ximexa
Version1.0.3 (code 10003)
High / Medium / Info findings0 / 14 / 2
Signaturev3, RSA 2048
SHA-256d1ca3b08…f3cb571
VirusTotal report ↗

Native library hardening (both apps, all architectures)

NX bit
PIE
Stack canary
Full RELRO

Open findings we're addressing (not hiding)

FindingAppSeverityStatus
Backup flag allows adb backup of app dataXimosWarningRoadmap
Some exported receivers lack explicit permission checksBothWarningRoadmap
SHA-1 used in one code pathXimosKidWarningRoadmap
Non-cryptographic random number generator in one code pathBothWarningRoadmap
App can read/write external storageBothWarningRoadmap
Temp files created during barcode/QR pairing scansBothWarningRoadmap
Legacy library code paths reference IMSI/SMS APIs, unused by any shipping featureXimosKidWarningScheduled for removal
Anti-emulator (Build.MANUFACTURER/HARDWARE) checks present in compiled codeBothInfoUnder review

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:

ProviderRole
Google FirebaseAuthentication, Realtime Database (signaling), push notifications
Cloudflare (Pages / Workers)Website hosting, edge functions for account/session tasks
ImageKitCloud Media Vault image storage and delivery
RenderChild usage-state backend service
GitHubPublic source releases

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

Version history

VersionAppHighlights
1.2XimosKidWebRTC screen & camera casting, Cloud Media Vault, on-screen alerts, Accessibility remote-touch
1.1XimosPay-as-you-go billing, referral credits, redesigned dashboard
In developmentBothSOS trigger, live GPS location
PlannedBothScreen/app time limits, bedtime restrictions, pairing rate-limiting

Report a vulnerability

If you believe you've found a security issue in Ximos or XimosKid, please report it responsibly before disclosing publicly.

[email protected]

Please include:

  • • Affected app and version
  • • Description and reproduction steps
  • • Potential impact
  • • Supporting evidence (logs, screenshots)

No system can guarantee absolute security. Ximos works continuously to reduce risk through encryption, access controls, data minimization, transparency, and testing — and updates this page as that work progresses. Related reading: technical docs, about Ximos, community & disclosure.