Security

Encryption

• In transit: all traffic is served over HTTPS/TLS.
• At rest: our database and file storage encrypt data at rest. Our planned machine-learning storage uses server-side encryption with managed keys.

Access control

• Per-account isolation. Every record is protected by database row-level security scoped to the signed-in account, so one family can never read another’s data. Default is deny.
• Private recordings store. Voice recordings live in a private bucket that is not publicly accessible. Uploads happen only through our server; a parent can access only their own child’s recordings.

Authentication

Sign-in is passwordless — a one-time code sent to your email. We do not store passwords, so there is no password database to breach.

Consent-gated audio

Practice runs on-device by default. A child’s audio is only sent to our AI scoring service, or stored, when a parent has granted recording consent, and we verify that consent on our servers before a recording is stored. A separate, optional consent is required before any recording may be used to improve our models.

Data minimization

• Recordings are stored under a random identifier, never a child’s name.
• We use no third-party advertising or analytics trackers. The two embeds we do load from other companies — the cal.com booking calendar and the payment provider’s checkout — load, and can set their own cookies, only after you choose to open them. Our own page-view measurement is first-party and carries no identifier — see below.
• We collect age in months only — never a full date of birth — and never require a child’s real name.

Measurement without identifiers

We count page views ourselves rather than embedding another company’s analytics, and we built the counting so that it holds nothing worth stealing. No cookie, no visitor or device identifier and no fingerprint is involved, and no IP address is stored— an address is used only in memory, to rate-limit the endpoint. The two-letter country we do keep arrives as a header our hosting network adds to the request, rather than being derived by us. A page view carries no user id, so these records cannot be joined back to an account or to a child.

The endpoint that receives them is deliberately narrow, because a public write path into a log table is a liability: it accepts only a fixed list of event names, drops known bots and requests with no user-agent, is rate-limited per address in separate budgets, discards the query string and fragment from a page address before storing it (so a stray token or email in a link cannot land in our logs), and keeps only a capped number of short scalar fields — never free-form objects.

What is recorded, and what is deliberately not, is written out in full in §4 of the Privacy Policy.

Our service providers

We rely on a small set of vetted providers — Supabase (database, auth, storage), Hugging Face (AI scoring), Vercel (hosting), Resend (email), cal.com (booking the free Welcome Session), Dodo Payments and Razorpay (payments), and, planned, AWS (ML infrastructure). Each processes data only to provide its service to us. See the Privacy Policy for the full list and purposes.

Data deletion

You can delete recordings at any time in your account, and you can ask us to delete your account and associated data by emailing privacy@webmobi.com.

How we keep improving

Security is ongoing. We maintain an internal security and privacy review and are actively working on additional hardening — including tighter rate limiting on public endpoints, credential rotation, automatic retention limits on recordings, and moving production data onto dedicated infrastructure.

Reporting a vulnerability

If you believe you’ve found a security issue, please email security@webmobi.com with details. We appreciate responsible disclosure and will work with you to resolve valid reports. Please do not access or modify other users’ data, and give us reasonable time to fix issues before disclosing them publicly.