How HALO keeps kids safe
HALO carries children. That single fact drives every product decision we make. This page describes the guardrails — not as marketing copy, but as the checklist your community can hold us to.
Community-only carpools — not strangers
HALO drivers are people inside your community: parents, neighbours, vetted volunteers in your school, club, faith group, or camp. There's no public driver signup — the only way to drive on HALO is through a community you already belong to. You ride with people whose names you already know.
Drivers reviewed by your community admin
Every driver uploads a current driving licence and insurance certificate during application. Your community admin (a person inside your community — not a HALO employee) reviews the documents and the vehicle details, and decides whether to approve. The verified badge appears only after approval, and the admin can revoke it at any time.
Verifiable parental consent for children
Children can't use HALO without a real consent record. It's an email double opt-in — not a click-through checkbox. A parent submits the child's details, HALO emails a one-time confirmation link, and only when the parent taps the link is the child profile activated. The record (policy version, timestamp, method, snapshot of the age category at consent time) is preserved and exportable. Parents can revoke at any time. Read the privacy policy for the full data flow.
SOS button on every active ride
Parents, drivers, and admins can trigger SOS during an active ride. The alert fans out to community admins and the child's linked parent account with the live ride context — passenger, route, location. Incidents move through a clear state machine (acknowledged → responding → resolved), and every state change requires a written note so every incident has an account of how it ended.
Capacity and joins go through the server
Ride capacity, joining, and no-show recording are routed through Cloud Functions, not the client app. That eliminates a class of attacks where a crafted client could overbook a ride or join after capacity is exhausted. Driver location is shared during an active ride and cleared the moment the ride ends — no historical tracking trail.
Notification authorisation
Notification deep-links are gated server-side: the recipient must be an active member of the community whose document the link refers to. A leaked push notification cannot be used to walk into a community a user does not belong to.
Deletion that actually deletes
Account deletion is a server-side cascade: ride requests, child profiles, invite codes, ratings the user wrote, member docs, profile and driver documents in storage, and the auth user are all removed in a single operation, with a final audit-log entry recording the action. Driver and parent footprints on completed rides are anonymised rather than deleted so other riders' ride history stays intact.
Operational transparency
- Every privileged admin action is recorded to an append-only audit log.
- Retention windows are documented and operator-flippable.
- Two-factor authentication is available on platform admin accounts.
- Destructive admin actions require step-up re-authentication.
See the privacy policy for retention windows, lawful basis, and your rights, and the terms of service for driver and passenger responsibilities.