Legal

Omnesis Mobile App Privacy Policy

Last updated: 2026-09-25

Summary

Omnesis is a local-first personal data indexer. The Omnesis mobile apps (iOS and Android) read data you explicitly grant on your phone and send it only to the Omnesis gateway you paired with the app. Ordinarily, that gateway runs on your own hardware — a machine you control. If another person or organization supplies the gateway, that gateway's operator receives and controls the data you send to it, so pair only with an operator and endpoint you trust. Distributing the app does not itself give Adrien Conrath, the developer of Omnesis, a copy of your data. Platform speech, assistant, geocoding, and notification services may process the limited data described below under Apple or Google's terms. Omnesis operates a small push relay that can wake an official mobile app, but it never receives notification titles, bodies, kinds, queries, indexed content, or an application-level gateway identifier. It receives the carrier token and public app identity described below. There is no Omnesis account, advertising SDK or advertising identifier, and nothing is reported to Omnesis. On Android, Google's ML Kit library sends Google its own limited diagnostic data, described below.

Cloud inference is off by default. If you or the operator of your paired gateway enables a cloud model or cloud AI agent for a configured role, Omnesis sends the inputs needed for that role to the selected provider. That provider's privacy and retention terms then apply.

If you are reading this to review a TestFlight, App Store, or Play Store submission: the short version is local-first, indexed content sent only to the paired gateway, notification content bypassing the relay, and no analytics or advertising SDK calls.

Who we are

Omnesis is developed and maintained by Adrien Conrath. There is no shared hosted data backend required for every user: users ordinarily run their own gateway on their own hardware, though a gateway can be supplied by another person or organization. That party is the operator of the gateway and controls the data sent to it. Omnesis operates the limited notification relay described below. In this policy, “we” refers to Adrien Conrath as the developer of Omnesis.

What the apps access, and how it is used

The apps access only what you grant, through your operating system's permission prompts or settings controls. Access is used to build a searchable index on your paired gateway or to provide a feature you invoke, such as voice input or QR pairing. Each permission or special access grant can be denied or revoked through the controls provided by the operating system.

• Health (Apple HealthKit on iOS / Health Connect on Android) — body composition, activity, vitals, sleep, nutrition, mindfulness, mood or mental wellbeing, reproductive and cycle data, sexual activity, environmental exposure, and workouts, where supported and in the categories you allow. Read on your device and indexed on your gateway. The apps never write back to Apple Health or Health Connect.
• Motion & activity (iOS Core Motion / Android activity recognition) — your motion-activity history (stationary, walking, running, cycling, driving), indexed on your gateway.
• Photos (iOS Photo Library / Android photos & screenshots) — the apps extract text, captions, and metadata, which can include capture time and location coordinates, from your images to make them searchable. No photo or image itself ever leaves your device — only the extracted text and metadata are sent to your gateway.
• Microphone, speech recognition, and voice assistants — when you invoke dictation or a Siri, Google Assistant, or Gemini action, the app uses the platform's speech recognizer to turn your voice into text. On iOS 18 and later Omnesis requires on-device recognition; on iOS 17, recognition can fall back to Apple's service. On Android, Omnesis requests offline recognition, but the installed recognition service decides whether processing is local or remote. Siri, Google Assistant, or Gemini may also process the invocation and supplied phrase under Apple or Google's terms. The resulting text is sent to your gateway when you submit the action.
• Location — on iOS, a location can be attached to a note captured in the foreground, and the optional Location Visits source records visited places in the background. On both platforms, photo metadata can include a photo's location. Exact coordinates, accuracy, time, and a resolved place name, when available, can be sent to your gateway. Resolving coordinates into a place name may use the operating system's geocoding service and therefore disclose those coordinates to Apple or Google.
• Call log (self-built Android editions only) — your call history (who, when, and duration — not call audio). Indexing it makes calls searchable and places them alongside other activity in your timeline, helping you recover context around a person or period. The Google Play edition does not contain this source and does not request the call-log permission. Omnesis does not access call audio or conversation content.
• App usage (Android) — app-usage statistics, indexed on your gateway.
• Camera — used only to scan the pairing QR code shown by your gateway on first setup. Never recorded, never stored.
• On-device storage (Keychain / app storage) — the gateway URL, pairing token, device identifier, and your per-category settings.

Beyond what is listed above, the apps do not access your contacts, calendar, or reminders.

Where your data goes

The mobile apps send permitted data directly from your phone to the gateway paired with the app.

• The app sends the data it reads (for photos, only the extracted text and metadata) to the gateway URL you approve at pairing time. If you run the gateway, you control that endpoint. If someone else supplies it, that party controls the endpoint and processes the data sent to it. Mobile apps require HTTPS and reject plain-HTTP gateway addresses.
• A gateway ordinarily runs on the user's own hardware. A user may instead pair with a gateway supplied by another person or organization; that operator's privacy and retention terms apply to the gateway.
• To enable notifications for a self-hosted gateway, the app may enrol with an Omnesis-operated push relay. During enrolment the relay receives the platform, carrier token, public app identity, and, on iOS, the sandbox or production environment. It does not receive an Omnesis account, gateway identity, or notification content.
• After enrolment, the gateway sends the relay an authenticated request with an empty body. The relay asks Apple Push Notification service or Firebase Cloud Messaging to deliver a fixed, content-free wake. The app then retrieves the actual notification directly from its paired gateway. Apple or Google therefore receives the carrier token, public app identity, and fixed wake payload, but not the notification title or body.
• Speech recognition, Siri, Google Assistant, Gemini, and operating-system geocoding may process voice, action text, or coordinates as described above. These are platform services selected and controlled through your device; their privacy and retention terms apply.
• On Android, Google's ML Kit library reads text and labels from photos on the device. It sends Google limited diagnostic and usage information about the library itself: device and app information, a per-installation identifier, performance metrics and error codes. It does not send the photos, the text read from them, or their labels. Google's ML Kit terms apply.
• As with any internet service, the relay's hosting and network providers necessarily process source IP addresses and basic transport metadata to route and protect requests. The relay application does not put source IP addresses in its notification database.
• There is no third-party analytics or cross-device data sync through our relay.

Cloud models are your choice

On a gateway, Omnesis can use AI models for tasks like turning documents into search vectors, transcription, OCR, and answering questions. If you operate the gateway, you choose where inference runs; otherwise its operator chooses:

• a local model — runs on the gateway, so inputs remain with its operator; or
• a cloud model or AI agent — the inputs needed for the configured role are sent to the selected provider.

Cloud inference is off by default. When you or the gateway operator enables it for a configured model role, Omnesis sends the inputs needed for that role to the selected provider. That provider's privacy and retention terms apply. Gateway operators should choose a provider and account plan that offers suitable retention for the API in use and disclose that choice to users. Omnesis does not verify or enforce a provider's retention policy.

What Omnesis does NOT do

• Distributing the app does not send us your indexed content or queries. If you deliberately pair with a gateway operated by us or another party, that operator processes the data sent to the gateway under the terms presented for that service. The notification relay still never receives indexed content, queries, or notification content.
• We do not include any advertising, analytics or crash-reporting SDK. The only third-party diagnostics are ML Kit's on Android, described above.
• We do not use IDFA or any advertising identifier.
• We do not sell, rent, or lease your data. Indexed content is shared only as directed by the paired gateway's operator, including with a selected inference provider. Notification content is not shared through our relay. Limited carrier metadata is sent only to Apple or Google to deliver a wake as described above.
• We do not profile you for any purpose.

Retention

Indexed content retention is controlled by the operator of the paired gateway. For the ordinary self-hosted setup, that operator is you; if another party supplies the gateway, consult that operator's retention terms. On the phone, the apps can store:

• Pairing credentials, device identity, feature settings, and continuity state. Pairing credentials remain until you unpair, subject to the iOS Keychain behavior described below.
• Pending notes and failed-upload batches. Pending captured notes can contain their full text and attached location and remain until they upload or you discard them. Failed source-upload batches are capped in size and evicted oldest-first; successfully uploaded batches are deleted.
• Source cursors and local indexes, such as permission state and the photo asset identifiers needed to find new items without rescanning the whole library.
• Location and activity state. On iOS, completed raw visits can remain for up to 14 days, whether or not they have already uploaded. Android keeps a local history of resolved movement segments, including activity type, time, confidence, and date, until app data is cleared or the app is deleted. Pending Android activity transitions remain until processed; qualifying segments are uploaded and non-qualifying transitions are discarded. Permanently refused transitions can be quarantined locally, capped at 5,000, until they are discarded or app data is cleared.
• Photo pixels are processed transiently and are not retained by Omnesis as a local photo library. Indexed content that has reached your gateway is retained there according to the paired gateway's configuration.

The Android app disables Android's cloud-backup mechanisms. On iOS, corpus-derived app storage such as pending notes, failed-upload batches, and the local photo index is marked to be excluded from device and iCloud backups. Other preferences and Keychain retention follow Apple's platform behavior; in particular, Keychain items can survive deleting and reinstalling an app. Unpair before deleting the iOS app if you want its pairing credentials removed from Keychain.

The notification relay retains limited operational metadata:

• Enrolment challenges contain carrier addressing and expire after ten minutes. Expired challenges are removed during subsequent relay operations.
• An active relay credential is stored only as a SHA-256 digest, together with its carrier token, public app identity, platform, environment, and creation time. It has no automatic expiry and remains until rotation, revocation, or operator removal.
• Successful rotation or individual revocation erases the old carrier token and app identity. Its digest and revocation time may remain as a security record.
• Per-credential wake timestamps used to enforce abuse limits are retained for a rolling 24-hour window and removed during subsequent relay operations.

User control

• Revoke any permission at any time in your OS settings (iOS: Settings → Privacy & Security; Android: Settings → Apps / Permissions, Usage Access for app-usage statistics, and the Health Connect app for health data). Revocation stops new access or collection. Data already queued on the phone can still upload unless you discard it or clear the app's data.
• Pause individual categories inside the app — toggle any category off and the sync rotation skips it.
• Unpair — removes the pairing credentials. Some device preferences, local indexes, or queued data can remain; use the app's available queue controls or operating-system app-data controls if you also want to remove those items.
• Delete the app — removes its ordinary local app data. Android cloud backup is disabled, and iOS corpus-derived app storage is excluded from backups. On iOS, Keychain items can survive app deletion, so unpair first if you want the pairing credentials removed.

Data already on your gateway

This policy covers the mobile apps. If you operate the paired gateway, data already pushed to it is under your direct control there — for example, via the Omnesis CLI. If another party supplies the gateway, use the deletion controls and contact process that operator provides; its terms govern data retained on that gateway.

Children

Omnesis is not intended for users under the age of 13 (or the minimum age of digital consent in your jurisdiction, whichever is higher).

Changes to this policy

When this policy changes, the Last updated date at the top of the page moves. Material changes will be reflected on this page.

Contact

Questions about this policy can be emailed to contact@omnesis.dev.