← Vela Fox Protect

PROTECT + PARENT · PRIVACY

Privacy Policy

This policy covers our parental monitoring apps. Read the separate Vela EV policy.

support@velafox.com

Last updated: September 7, 2026

Vela is a visible, guardian-configured parental-safety tool for Android. Vela Fox Protect performs safety analysis on the protected phone. Vela Fox Parent can receive selected safety findings directly from a specifically approved nearby Protect phone. Vela does not operate an account, analytics, advertising, or cloud-content service.

The Google Play Protect beta includes a no-charge, non-renewing 14-day trial for each installation, starting when Protect is first opened. It stores trial-start, effective-time, device-uptime, boot-count and expired-state values in separate app-private preferences; these values are not sent to Vela. Updates preserve the local trial record. Clearing app data or reinstalling can reset a local trial; it is not an account-based entitlement. At expiry, new monitoring and analysis are paused, including automatic media, Web Shield and trip collection. Existing findings and deletion, disconnect and privacy controls remain available through Parent access. The Parent companion remains available to review already received findings. A publisher-issued beta access code can grant non-expiring access for app review. Only a local activation flag is retained; the entered code is not stored or sent to Vela. It does not unlock Parent access, grant permissions or restart monitoring. The separate managed distribution does not use this Play beta trial.

Coverage diagnostics show app identities, useful/unavailable notification-preview counts and timestamps from the current listener session. They remain bounded and memory-only on Protect, are hidden when monitoring is inactive, and are not sent to Parent. They describe delivery rather than unique messages or completed AI analysis. Shared-item review lets the user confirm or edit the received text before analysis; edits are not saved as drafts. Vela does not open shared links or download the content behind them. Findings can include flags explaining that only link text or truncated text was checked.

A guardian can run a notification delivery check from Protect's Parent mode. It posts one silent, content-free test notification with a short-lived random receipt token and waits up to 15 seconds for Android delivery. The test notification is removed after completion, cancellation or timeout. Its receipt stays in memory while the check view is open; it never enters app-preview counters, AI analysis, the finding vault or nearby transfer. A successful receipt tests only this notification path. Parent's update-age display uses the existing locally stored completed-sync timestamp, not a new feed of the protected phone's current health or location.

Parent conversation prompts are locally selected, code-authored suggestions and do not send messages. Optional app safety guides open a bundled official URL in an external browser without attaching findings or account details. These app safety guides do not link external accounts or verify settings made in those apps; the destination provider's own privacy practices apply.

Data Vela processes

Depending on features a guardian enables, Vela Fox Protect may process:

Vela cannot bypass another app's encryption or sandbox. It cannot reliably see muted, hidden, deleted, disappearing, or redacted messages. The Google Play build does not read the Android SMS provider and does not become the default messaging app. Usage Access does not reveal screens, keystrokes, URLs, messages, or what happened inside another app.

Android does not provide a general permission for Vela to read modern browsers' private history databases. A browser-history scan therefore works only after the parent exports, downloads, and selects a file through Android's document picker. Vela can recognize a supported standalone export or history file inside the selected archive, but it cannot automatically locate a file in Google Drive or Downloads. It normalizes each visit, removes credentials, fragments, and non-search query fields, then locally checks the hostname, URL path, retained search fields, and title with bounded safety rules and analysis. It does not fetch web pages, recover deleted or private/incognito visits, or retain a complete history database.

Optional Google account reviews

Setup and Parent Settings offer separate read-only Google permission flows for Gmail, Calendar, Drive/Docs, and Tasks. The Google account owner must authorize each scope; parental access to Vela does not bypass Google's account consent. All sources on a phone use the same selected account until disconnected. Account subject, email, chosen source flags, and last-completed-review times are device-bound encrypted. They are not included in nearby transfers. Authorization tokens exist transiently in memory for the current request; Google Play services manages its own consent/token cache under Google's terms.

Reviews run only when the parent taps **Connect & review** or **Review now**, and stop when the originating parent authorization expires or the screen closes. They are not continuous account monitoring. Gmail checks up to 25 recent messages from 7 days (supported plain-text bodies, subject and sender; no attachments or remote images). Calendar checks up to 50 primary-calendar events from the preceding 7 days through the following 7 days (summary, description, location, and event time). An event is not proof of attendance. Drive/Docs requests broad `drive.readonly` consent and checks text exports of up to 10 Google Docs modified in 7 days; it does not scan other file types, comments or embedded media. Tasks checks up to 50 incomplete tasks in the default list (title and notes). Limits, unsupported text, and incomplete passes are shown. Other calendars/task lists are outside this pass. Android's Share to Vela remains an alternative for selected files without broad Drive access.

Supported source text is bounded to 16,000 characters per item and HTTPS responses to 2 MiB. Safe content is not persisted by Vela. A concerning item can enter the existing encrypted finding vault and its approved nearby transfer queue; there is no upload of Google source content to a Vela server or model-training service. Google receives ordinary authorization, account identity, read-only API, and revocation requests. Google-sourced findings remain subject to the same 90-day/1,000-finding retention and parent deletion controls. **Disconnect Google** requests access revocation and deletes local connection/receipt metadata; it does not delete findings already retained or transferred. Revocation failure is shown explicitly. Google Cloud app registration, enabled APIs, and required scope verification remain prerequisites for public availability.

Interactive analytics and appearance

Activity charts, service counters, and network exploration run locally behind Parent access. Usage reports remain ephemeral; Android's detailed event retention and lifecycle gaps can make session charts differ from aggregate app totals. The usage total includes all eligible reported apps even when only the top 50 rows are shown. Service failure/drop counters describe the current process lifetime. Interactive/import text-review telemetry retains cumulative completion/failure/cancellation counts, source-type counts, and the newest 120 completed review durations in memory. It contains no source text, account identifiers, event IDs, or timing history on disk; latency percentiles apply only to those retained samples and do not include the separate notification queues or image/audio pipeline. Missing observations do not establish zero activity or complete coverage.

Evidence networks compare text and timing patterns across at most 72 recent eligible findings on the device. Graph metadata, selection, layout and commentary remain in memory and clear with the parent session. Parent partitions graphs by authenticated protected-phone identity and excludes unknown-origin findings from cross-record relationships. Similarity reflects patterns in the available text; it is not a calibrated probability, proof of a shared person or cause, or confirmation of harm. Gemma 4 commentary is optional on Protect, shares the existing on-device inference engine, and receives only bounded category enums and aggregate counts. Gemma selects a supported focus; deterministic wording supplies factual counts and limitations. No raw source instructions, accounts, senders or coordinates enter this commentary prompt.

Both apps save palette, custom accent/surface, corner, aurora, and motion preferences only on their respective phones. Aurora can be disabled entirely or left static; animated drift pauses when backgrounded, when Android disables animations, or during Battery Saver. Vela does not send these preferences or UI interactions to an analytics service.

Local processing and storage

In Vela Fox Parent, a guardian can keep an alert as New, Follow-up, or Reviewed. The decision and its time are encrypted using that parent phone's vault identity. These decisions are readable only in an unlocked vault, are not included in nearby transfers, and are not shared with the child or another parent. They are removed when the associated alert is deleted or expires under the same retention ceiling. Follow-up is a saved list status and does not schedule a reminder. Reviewed does not confirm an assessment or establish that a situation is safe. If a saved decision cannot be authenticated, Vela shows the status as unavailable and keeps the alert needing review.

Vela Fox Parent does not request Internet access. Vela Fox Protect requests Internet and network-state access for its separately enabled DNS-only Local Web Shield and explicitly authorized Google API reviews. Google Identity Services handles account permission grants and revocation; supported source text is read directly over HTTPS from Google and analyzed on this phone. No Google access or refresh token is stored by Vela. The shield creates an Android VPN interface that routes only a virtual DNS address, relays each supported DNS request to the resolver Android was already using on the underlying network, and analyzes the normalized domain locally. It has no Vela server or remote VPN gateway and does not route or inspect general traffic. Safety rules, enhanced analysis, visual/audio classification, indexing, and English text recognition run on the protected phone using app-bundled models and runtimes. The current apps do not integrate ML Kit GenAI, Gemini Nano, or AICore; therefore they do not use those services' model provisioning or diagnostics/usage-metrics channel. While visible Protection is active and Android's notification listener is connected, Vela automatically processes useful preview text when Android delivers a new or updated notification. A bounded plaintext-free digest cache suppresses identical callback versions, and a bounded active-preview catch-up covers short service or listener-rebind gaps; it does not recover app history or content Android no longer exposes. Optional automatic media intake has its own maximum of 250 images per worker run and checkpoints after each 25-photo batch; the Parent's 1–1,000 manual choice does not reduce that automatic bound. With full access, a debounced MediaStore observer requests a prompt newest-changed pass, but Android may delay, combine, or omit callbacks while the process is stopped, so a separate 30-minute cursor catch-up remains enabled. The two worker paths are serialized, and a bounded content-free media-version ledger suppresses unchanged duplicate decoding. Photo queries merge items from mounted Android shared-media volumes. Full Android photo access is required to cover all shared-library images; selected-photo access covers only the selected subset and does not provide an all-new-photo feed. App-private, disappearing, unsaved, or cloud-only media that Android does not expose is unavailable.

Web Shield stores at most 500 recent domain/app aggregates for 30 days in Android-Keystore-sealed app-private storage. A DNS lookup can be caused by an app, advertisement, notification, prefetch, or background service and is not proof that a person visited a page. Vela does not receive a full URL, path, query, search text, HTTPS page body, password, or decrypted connection. Private DNS, DNS-over-HTTPS, cached results, IPv6 traffic outside the shield's IPv4 virtual-DNS route, another VPN, unsupported transport, and Android/OEM behavior can reduce coverage. A bundled, locally evaluated index of sites whose primary purpose is explicit adult content and conservative hostname rules may create a rate-limited review alert, but that alert states that the page and requesting person were not observed. Each canonical match has a six-hour in-process cooldown; attacker-controlled keyword hostname rules additionally share an eight-alert burst bucket that refills by one every six hours. The default control is Alert only. A guardian may choose Block + alert, which returns a local DNS name error only for a high-confidence indexed adult-domain suffix; keyword-only, self-harm, and drug-sale hostname findings are not blocked. Matching address-family requests wait on one serialized alert decision, and a matched indexed request is allowed normally unless its encrypted alert was already durably stored. The list and rules can become stale or make mistakes, and cached addresses or encrypted/private DNS can bypass a DNS response. If Android unexpectedly ends the local tunnel, Vela keeps its foreground disclosure visible and retries locally with a delay capped at one minute; monitoring and blocking are unavailable during that window. The feature requires a prominent in-app disclosure, affirmative guardian consent, Android's VPN approval, a system VPN indicator, and Vela's persistent Web Shield notification; it can be turned off without disabling normal device networking.

Every successfully decoded photo is orientation-corrected and bounded to one in-memory bitmap, then receives an attempted three-class local-model pass before OCR. A strong visual score immediately attempts to store a code-authored guardian-review finding without waiting for Gemma or text recognition. At most 12 ambiguous results per photo scan may receive a Gemma 4 image label under a 45-second coroutine cancellation deadline. That deadline requests native cancellation, but synchronous native initialization is not proven interruptible and remains a device-qualification requirement. Gemma uses a GPU image path with one image per conversation; it is never allowed to author stored image descriptions, identity, age, or evidence facts. Decode and classifier failures are counted. An ambiguous item whose second review is unavailable, failed, or timed out is reported as incomplete and is not silently promoted to an alert. An item that creates a visual alert skips OCR, which is reported as an intentional text-coverage omission; any encrypted-storage failure is separately reported. A stale authorization or background-generation fence stops the scan before its cursor advances. Scheduled decode, classifier, or storage failure preserves the prior cursor and requests bounded retry rather than silently skipping that batch. Vela attempts visible-English-text recognition on non-alerting items. OCR initialization failure does not disable the independent visual check and is disclosed as partial text coverage. These models can miss unsafe content and can flag benign material. Vela does not detect or determine CSAM and does not infer whether a depicted person is a child.

Decoded pixels, classifier tensors, and the bounded in-memory Gemma image encoding are recycled or wiped after each item and are not persisted. Raw content that does not cross the safety threshold is not added to the alert vault. Only a threshold-crossing finding can cause the existing reduced, size-limited evidence image to be encrypted in the vault. For escalation analysis, up to ten recent previews from one conversation may remain in volatile memory for at most fifteen minutes; at most 64 conversations are retained, each preview is clipped to 1,200 characters, and each temporary analysis context is capped at 8,000 characters. Urgent deterministic work and nuanced model candidates use separate fixed queues of 128 and 32 items. Queued contextual candidates carry the same 15-minute expiry and are discarded before model analysis when stale. Overflow is counted and dropped rather than creating an unbounded plaintext backlog. Context and queued work are cleared when monitoring pauses, notification access ends, the listener binds or disconnects, or the app process ends.

The Parent-only App activity view queries Android only while that screen is opened or refreshed. It offers today, seven-day, and thirty-day aggregate foreground-time and timing-pattern views, excludes common operating-system surfaces, and may show a package identifier when Android does not expose an application label. Vela does not save, place in the alert vault, or transfer the resulting list. The child-facing status screen visibly reports when Usage Access is enabled. Session timing is not classified as harmful content.

Content deliberately selected or shared to Vela is bounded before review: at most 30 system-picker media items or ten Share-sheet items, 24,000 text characters, or 30 seconds/24 MiB of audio. A selected/shared video must be no larger than 512 MiB and no longer than 20 minutes. Vela deterministically chooses at most 24 small still frames, one from each evenly distributed time stratum, and uses exact-nearest frame decoding against a best-effort 90-second soft budget. Authorization and time are checked around each native extraction and classification call, but synchronous native work may return after the soft boundary. A video is skipped below 20% battery unless the phone is charging. At most two ambiguous frames receive enhanced local review. Safe frames are recycled after analysis; only a threshold-crossing sampled frame can become the existing size-limited encrypted evidence image. The original video, its URI, and video audio are not saved or analyzed by this frame path. Vela does not request broad video-library access, and picker/Share-sheet review does not grant continuing access to the originating app or its private database.

In the managed SMS workflow, the parent chooses a global or one-conversation scope and a discrete 100–10,000 limit. A focused-thread picker exists only after Parent authorization plus Android's SMS role/read grant. It loads no message bodies and keeps at most 500 thread/address/date snapshots derived from the newest 10,000 inbox/sent rows in memory. Vela does not request Contacts permission, so it shows SMS numbers or sender addresses rather than claiming contact names. The picker list, query, and thread selection are not persisted and are dropped on cancellation, selection, lock, background, role/permission loss, restoration, or process loss. Every selected row receives local deterministic screening; at most 32 deduplicated context windows receive enhanced review, and up to 256 additional strong rules-only windows can be handled before an explicitly reported per-pass cap. A Parent timeout cancels the scan rather than extending the vault session. Safe history-scan content is not copied into Vela's alert vault. Only a threshold-crossing finding may encrypt the code-grounded SMS address, direction, timestamp, exact focused excerpt, and bounded same-thread context. Enhanced analysis supplies structured classification fields; app code renders the displayed explanation from approved category phrases, so model-authored identity, quote, date, time, and number claims cannot replace or enter the grounded evidence fields. Classification can still be wrong.

The default-SMS role also carries ordinary message-routing duties during the handoff. Android delivers incoming carrier SMS to Vela; Vela saves each one in Android's Telephony SMS inbox and submits its text for local safety analysis so the message is not silently lost. If the user invokes an Android reply-via-message action while Vela is default, Vela may send that SMS, save its status in Android's Telephony store, and analyze its text locally. Safe routed SMS can therefore remain in Android's normal SMS provider even though it is not copied into Vela's encrypted alert vault. These duties end after the parent restores the usual SMS app. Vela has no MMS/RCS inbox, so MMS, RCS, and some group-message delivery may be delayed or lost during the handoff. Every terminal result keeps an explicit Restore action visible and the recovery notification remains until Android reports that Vela no longer holds the role; Default Apps still requires the parent to select the desired SMS app.

Decorative logo orientation readings are used only in process memory to create a small layered offset while the child-status screen is resumed. They are not stored or transferred; sensor registration stops when the screen pauses, and motion is disabled when Android animations are disabled or no suitable sensor exists.

Optional practice uses fixed, invented messages, not personal conversations. Protect can run its safety rules and, if explicitly selected and available, enhanced local AI for an example. Rules and model results are shown separately. Practice never creates an alert, updates real analysis-history counters or transfers a result to Parent. Parent's example review choices are kept only in the practice screen's memory and do not change stored review decisions. Practice is discarded when closed or when the app is backgrounded. The separate silent delivery check tests Android's notification callback only; these exercises do not establish other-app coverage, model accuracy or receipt by another phone.

Protect's optional device-fit screen reads coarse current RAM, Android's low-memory flag, available app-filesystem storage, Battery Saver, thermal status and Bluetooth LE hardware availability when practice opens or is refreshed. The same resource conditions are checked before optional enhanced-AI practice. These readings need no new permission, contain no hardware identifier or app inventory, and are not stored, logged or synchronized. They help explain resource limits, not infer a child's activity, health or wellbeing. No automatic positive/wholesome interaction detector or benign-message history is enabled.

Concerning findings are stored in an encrypted local vault. A small amount of routing metadata—such as time, source, severity, categories, risk score, and delivery state—is stored separately so the locked app can manage its queue. Evidence images are reduced and size-limited before encrypted storage. Completed alerts are retained for no more than 90 days and the vault is capped at 1,000 findings on each phone. A parent can delete individual findings or purge the local vault. Sensitive reads and mutations are authorized by the exact active Parent-mode session; an expired or replaced unlock cannot finish the operation.

Browser-history source files are capped at 16 MiB. The importer can recognize and normalize at most 5,000 visits from the most recent 365 days within a 512 KiB transient working set; one authorized scan analyzes at most the newest 64 recognized visits. Each analyzed visit is isolated as its own record so a concerning visit cannot cause neighboring benign history to be copied into an alert. Credentials, URL fragments, and non-search query parameters are removed. Safe normalized records and Vela's transient copy are discarded after the scan; the external Takeout/Drive/Downloads source remains under the selected document provider and Vela does not delete or wipe it. Only an individual threshold-crossing visit may be encrypted in the alert vault.

Trip detection keeps only a bounded 90-second pre-confirmation window in memory. After sustained speed/displacement confirms travel, the active crash journal and route are encrypted separately in Android no-backup storage. Each saved point includes its timestamp, coordinates, Android-reported accuracy, optional bearing, phone-GPS speed estimate, and whether that estimate was reported, displacement-derived, fused, stationary-filtered, unavailable, or from an older record without provenance. Encrypted aggregates include start/end time, duration, distance, and phone-GPS average and peak estimates. This is sampled phone GPS, not continuous coverage or vehicle telemetry. Live speed expires to zero after 20 seconds without a fix. Arrival requires three accurate fixes in an accuracy-sized destination cluster, a three-minute dwell, and a fresh final confirmation; this is intended to reject stationary drift, a stale provider speed, and GPS loss rather than invent an end point. A valid partial route may still be preserved when GPS continuity is lost for more than 15 minutes or the visible session stops, but its stored end reason and Parent UI identify the endpoint as the last trustworthy recorded point—not a confirmed destination. Routes shorter than 500 feet are discarded rather than added to completed history. Completed trips are retained for no more than 90 days or 200 trips, whichever limit is reached first. A parent can delete one trip or purge all trip history. Automatic trip detection never starts at boot and runs only as a visible Android foreground session enabled by a parent. That same session supplies fixes for place-boundary checks; creating or enabling a boundary by itself does not start location collection.

The recorded-GPS route map and replay use the encrypted points locally in PIN-gated Parent mode. Vela does not automatically send those points to a map service. If a parent chooses the Google Maps preview and accepts its separate disclosure, Vela hands the external app or browser the trip's start, its confirmed destination or last recorded point, and up to three ordered representative coordinates. Those coordinates then leave Vela and are handled under Google Maps' or the selected browser's policies. Google recalculates an approximate driving route; Vela does not export the recorded GPS polyline.

When a parent opens a trip, Vela can derive bounded measurements such as duration, distance, measured speeds, sustained pauses, and route directness. Only those aggregates—not the trip identifier, coordinates, bearings, address, place-boundary names, date, or time—are supplied to the bundled local model. Code renders all numeric facts; the model is allowed to add only a short qualitative movement observation. A successful enhanced narrative is stored inside the same encrypted trip record and follows that trip's deletion and retention. If enhanced analysis is unavailable, Vela shows a deterministic measured summary and may retry later.

Place-boundary definitions, stable inside/outside state, and confirmed visit history are stored in a separate Android-Keystore-backed AES-256-GCM no-backup vault. Vela supports at most 50 circular boundaries with radii from 75 metres through 10 kilometres; the minimum reduces consumer-GPS edge noise. An arrival or departure requires several time-separated accurate readings, dwell time, an accuracy-aware entry/exit margin, and plausible movement; a single fix or boundary jitter cannot create an event. Initial monitoring inside a boundary is labeled as a first confirmed location rather than an exact arrival. Visit history is retained for no more than 90 days or 5,000 events. A parent can edit or delete a boundary and clear visit history; deleting a boundary also deletes its events.

Direct parent-device transfer

Optional coverage sharing is off by default and requires an unlocked Parent-mode choice on Protect. When enabled, a completed nearby sync can deliver a snapshot to each approved parent phone: protection enabled, notification access, listener connection, visible monitoring service, and coarse ages of the latest completed automatic notification rules and optional-model checks. No message text, app inventory, counts, or child timestamps are included. Completion markers are held only in Protect's process memory while sharing is enabled; disabling or changing the preference clears them. Practice, manual scans, failed model calls, and notification-delivery probes do not advance these markers. A completed AI response can still be uncertain; it does not establish safety.

The snapshot is signed by the paired child identity inside the existing encrypted, session-bound manifest and accepted only after the full queue cycle completes. Parent keeps only the latest snapshot per paired child in its existing Android-Keystore-sealed pairing store; it is displayed only after the parent vault is unlocked. Parent also stores local receive time, elapsed time, and its own Android boot count to avoid misrepresenting an old snapshot as recent after clock changes or restart. These local clock values are not sent to Protect. Status becomes old after one hour, and age is unverified after a reboot or significant clock change. Older snapshots remain explicitly historical until replaced or the paired phone is forgotten. Turning sharing off stops future snapshots and interrupts queued sends when detected; an in-flight snapshot may already have arrived. The parent's prior snapshot is cleared by the next completed compatible sync, or by forgetting the paired phone. This is not a remote monitoring or emergency-delivery channel.

Family learning moments use fixed, invented situations about listening, context, and caring actions. Choices and feedback exist only in the current activity's memory; the activity closes and forgets choices when dismissed or when the app leaves the foreground. No score, completion history, notification, AI analysis, or transfer is created. No positive-interaction detector is enabled.

Vela can send approved, queued findings directly over nearby Bluetooth to an approved Vela Fox Parent phone. Initial approval requires matching-code confirmation on both phones and can queue up to 50 recent findings; future findings queue automatically for that parent until either phone revokes trust. After pairing, a parent can enable automatic nearby receiving once, or start one-time retrieval from Vela Fox Parent; on Android 12+ the child-visible Protect service can find and authenticate that short window without another child-side prompt. A family may instead explicitly start a visible live-alert session on both phones. By default, live sync remains active while the approved phones stay connected and ends after five continuous disconnected minutes or an explicit Stop; a family can instead choose an absolute timer in five-minute increments. Live mode transfers newly saved encrypted concern alerts and their saved local analysis, plus an optional coverage snapshot when a queue cycle begins; it does not transmit safe results, raw ordinary messages, aggregate scan receipts, app-activity reports, Web Shield history, trip routes/narratives, or place-boundary definitions/history. An optional NFC tap uses a fresh one-time signed challenge and binds discovery to the later authenticated Bluetooth offer; alert bodies never cross NFC. Protocol v2 negotiates required security capabilities, derives a fresh session key with P-256 ECDH/HKDF, and AES-GCM protects manifests and alert metadata in addition to the alert body/evidence encryption for that parent's identity. Monotonic sequence numbers, signed batch completion, acknowledgments, durable delivery checkpoints, duplicate rejection, and bounded reconnect backoff prevent replay, premature delivery marking, and duplicate loss while allowing interrupted transfer to resume. Nearby delivery requires proximity, Bluetooth, retained permission, and visible foreground protection; Android or radio conditions can interrupt it, and it is not a remote connection.

Automatic nearby receiving remains visible with a persistent notification and accepts only approved phones. It reconnects between visits and may resume after a process restart, reboot after unlock, or app update if previously enabled. Its Stop control turns off the saved choice. Bluetooth, notification access, Android restrictions and force-stop can delay or stop delivery. Newly received findings may trigger a generic local notification; alert details remain behind the Parent unlock. This is a direct, guardian-enabled transfer, not an upload to Vela. Pairing records—including device identity, displayed name, public keys, paired time, last-seen state, and last completed-sync time—remain until a parent uses the PIN-gated revoke/forget control or uninstalls the app. Once an alert reaches a parent phone, that phone keeps its own encrypted copy subject to the same alert retention ceiling. It also retains the authenticated protected-phone identifier and ciphertext digest with a bounded received-event marker, for attribution and duplicate/collision rejection; those markers are retained for no more than 90 days and capped at 5,000. Removing a paired phone stops future transfer but does not remotely erase copies already received.

Permissions and visibility

Vela requests Android permissions only for features the guardian chooses. Monitoring remains visible through the installed app, the protected-device disclosure, Android permission surfaces, and a persistent status notification. Automatic trip detection and Local Web Shield have their own public persistent notifications; Web Shield also displays Android's system VPN indicator. Their enable and disable controls remain inside PIN-gated Parent mode, while Android system controls can still stop a service or app. Disabling a required permission reduces coverage; Vela reports that condition instead of claiming protection is complete.

Sharing, sale, advertising, and analytics

Vela does not sell personal data. It does not use content for advertising, profiling by Vela, model training, or third-party analytics. The only designed disclosure of a safety finding is the direct encrypted transfer to a parent device the guardian explicitly approves. Separately, the optional parent-confirmed Google Maps action discloses the bounded route coordinates described above. When Web Shield is enabled, DNS queries are transmitted to the resolver Android reports for the current underlying network, as they ordinarily would be without Vela; they are not sent to a Vela service. Google Play separately handles ordinary app and model-pack delivery under Google's terms. None of these paths uploads alert contents to Vela.

Deletion and control

A guardian can delete alerts, purge alert history, delete trips and their cached narratives, purge trip history, create/edit/delete place boundaries, clear visit history, revoke a paired parent phone, turn off and clear Web Shield activity, turn off location monitoring, disable optional broad-photo scanning, disconnect Google account access, or pause protection from PIN-gated Parent mode. Uninstalling an app removes its app-private data under Android's normal uninstall behavior. Deletion is not represented as forensic erasure, and a payload already materialized for an active Bluetooth transfer may complete.

Security and limitations

Vela uses Android app-private storage, Android Keystore wrapping for vault identities and trip keys, authenticated encryption, PIN-gated vault sessions, persisted failed-PIN backoff, disabled backups, and blocked screenshots. No software can guarantee detection of every safety concern or defend against a rooted or compromised operating system. Text and visual classifiers can produce false positives and false negatives. The bundled image classifier's publisher reports results from a proprietary dataset; Vela has not independently established production calibration, subgroup performance, or child-safety accuracy. Findings are signals for human review, not proof of abuse, identity, age, criminal conduct, CSAM, illegality, intent, or a medical diagnosis.

Children and guardian responsibility

Vela must be configured by an authorized guardian and used consistently with applicable child-privacy, consent, monitoring, school, employment, and communications laws. The protected-device user must not be deceived about monitoring. Guardians are responsible for responding safely and appropriately to findings, including contacting qualified emergency services when immediate danger is suspected.

Publisher, privacy requests and contact

Publisher: Vela Fox, the Google Play developer of Vela Fox Protect and Vela Fox Parent. Contact support@velafox.com for support, privacy questions, correction requests or deletion assistance. The public policy is available at https://velafox.com/protect/privacy and the same text is packaged in both apps for offline reading. The separate Vela EV vehicle app has its own policy at https://velafox.com/privacy.

Use the Parent controls described above to review or delete data held on your phones. Vela has no cloud copy of your findings, trips or Google-source reviews to retrieve or delete remotely. Delete a received copy separately on each paired phone. For information you deliberately send in a support request, contact the same support address to request access, correction or deletion; do not attach a child's messages, photos, exact location, credentials or other sensitive evidence. Support correspondence is used to answer the request and is not used for advertising or model training.

Your privacy rights depend on where you live. Contact us to exercise applicable access, correction, deletion, restriction or objection rights, or for help contacting the appropriate data-protection authority. A guardian should explain monitoring to the protected child and help them raise privacy concerns. Material changes to these practices will be reflected by updating this policy's date and the app's disclosures. Google's and other user-directed providers' own policies apply to their services.