Skip to content
The world does revolve around you.

Privacy model#

Ostler's privacy posture is not a policy document. It is a consequence of the architecture. Because there is no cloud, there is no place a vendor can read your data from. Because the AI model runs on your Mac, there is no API call carrying your prompts to a third party. Because the storage lives on a disk you own, there is no shared database where your information sits next to anyone else's.

This page explains the model at the architectural level – what is local by default, what is optional, what crosses the network, and why the answer to "can Creative Machines see my data?" is "no, by construction."

This is the technical detail behind the marketing privacy page

The shorter, plain-English version lives at ostler.ai/privacy. This page is for readers who want the architecture, not just the promise.

The one-line version#

Your data lives on your Mac. The model runs on your Mac. Nothing about you is sent to a server we, or anyone else, operates.

The four guarantees#

1. No cloud account is required to use Ostler#

You do not sign up. You do not log in. There is no Creative Machines account because there is no Creative Machines backend that needs one.

The Hub asks you to set a passphrase at install (this protects your data on disk). Day-to-day unlock is biometric – Touch ID, Face ID, or your Apple Watch – using the same Secure Enclave hardware that protects Apple Pay. We never see a password because there is no password to see, and the passphrase never leaves your machine.

You may, optionally, connect Ostler to your own external accounts (Google Calendar via CalDAV, an email mailbox, and so on). Those are your accounts, your credentials, your decision. Ostler holds those credentials locally, on your machine, and uses them on your behalf without telling us.

2. The model is local#

The language model that powers Ostler runs on your Mac via Ollama. It is a binary on your disk, talking to a process on your machine, over localhost. No prompt you ever type, and no document Ostler ever reads, is sent to a hosted inference API.

This is the difference that matters most for privacy. A traditional "AI assistant" sends every question, every email it summarises, every document it indexes, to someone else's GPU. Ostler does not. The ceiling on how much your assistant can know about you stops being "how much your vendor lets it see" and starts being "how much your local hardware can compute."

3. Storage is local#

Every database that holds something derived from your data lives on your Mac:

  • The vector store for semantic search.
  • The graph store for relationships and structured facts.
  • The cache that makes lookups fast.
  • The SQLite databases for app state and coaching observations.

All of them run inside Docker containers bound to localhost. None of them is reachable from the internet. None of them is mirrored to a server we operate.

4. Transit is local#

Day-to-day traffic between the Hub and the iOS app runs over your home Wi-Fi, end-to-end TLS-encrypted, with the iOS app pinning the Hub's certificate at pairing time. There is no relay. There is no WebSocket gateway. There is no push-notification service carrying your content.

If you want to reach the Hub from outside your home, we recommend Tailscale – a zero-trust overlay network you install yourself. We do not host your tunnel.

What is intentionally not in the model#

This is the bit that separates "local-first" from "less cloud than the other guys." Ostler does not have:

  • A backend. There is no api.ostler.ai. There is no server-side database. There is no internal admin tool that could read your information because there is no place your information lives that we could read.
  • Telemetry. No usage analytics. No crash reporter. No anonymous metrics. We do not know how many people are running Ostler today, or what they are using it for.
  • Account recovery on our side. If you lose access to your Mac and your iPhone and your recovery phrase and your Time Machine backup, we genuinely cannot help you. The same architecture that prevents us from reading your data prevents us from helping you recover it.
  • A "share with support" button. When you contact us, we ask you to describe the problem in words. We do not have a mechanism that uploads diagnostic data from your machine. If we ever build one, it will require explicit, payload-by-payload consent and you will be able to read every byte before it leaves.

What is intentionally in the model#

Local-first is a posture, not a religion. Some things are unambiguously better with a network connection:

  • Pulling public data in. Wikidata and Wikipedia for biographical enrichment. A privately-hosted SearXNG instance for web search when you ask the assistant to look something up. AI model downloads from Ollama's registry the first time you install. These pull public information towards your machine. None of them carry personal data outwards.
  • Software updates. Homebrew packages, Docker images, the Sparkle-based Hub updater. Your Mac asks distribution servers whether a newer version is available, the same way every modern app does. The update check carries the version of Ostler you currently have, not what is in your knowledge graph.
  • Optional external accounts you bring yourself. If you connect Ostler to your Google Calendar, Ostler talks to Google Calendar. That is the deal you opted into when you connected the account. Ostler does not invent traffic to a third party that you have not authorised.

The critical distinction is direction: public data flows in, personal data does not flow out.

Why we prefer Apple Mail over Google OAuth#

Email is one place where the local-first architecture shows its work in a very practical way.

If you use Gmail, the easy path for a vendor is Google OAuth – ask the user to authorise the app, then read their inbox over the Gmail API. That works, but it has consequences: the vendor's OAuth scope is on file with Google, the read traffic flows through the vendor's servers in the typical case, and Google's CASA / annual API audit obligations attach to the vendor.

We took a different path. Ostler reads your email by reading Apple Mail's local database with Full Disk Access. Apple Mail is already on your Mac. It already syncs Gmail, iCloud, Outlook, and any IMAP mailbox you add. By reading from Apple Mail, Ostler:

  • Never sees a Google OAuth scope.
  • Never carries email through a server we operate.
  • Inherits whatever security and sync model Apple has chosen for your mailbox.

There is a longer write-up of this trade-off in Apple Mail FDA vs Google OAuth. The short version: structurally, the email content path stays inside Apple's ecosystem and your machine. There is no third-party server between you and your inbox.

Encryption at rest, in plain language#

The privacy posture would not survive a stolen laptop without encryption. Ostler stacks several layers:

  • macOS FileVault – your whole disk, including everything Ostler writes, sits inside an AES-256 volume tied to your Mac's hardware. The installer verifies FileVault is on and warns you if it isn't.
  • SQLCipher (AES-256) for Ostler's relational databases – encrypted-at-rest with a key derived from your install-time passphrase, wrapped under a key the Secure Enclave releases on successful biometric.
  • Realm (AES-256) for the iOS app's secure store – the key is bound to the device.
  • macOS Keychain for sensitive items – with appropriate accessibility flags so wrapped keys never travel in Time Machine or Migration Assistant.

The full cryptographic detail – primitives, key derivation, key wrapping, recovery – is on the Encryption page.

Independent audit, not self-attestation

"Trust us, we encrypt" is not enough. We are commissioning an independent security audit from a recognised firm, scope covering authentication, data handling, storage encryption, network posture, and dependency analysis. The full report will be published.

What this doesn't protect against#

A privacy model is a contract about specific threats. We are explicit about which ones Ostler does and does not address:

  • Other software running on your Mac. Anything you have given permission to run on your Mac inherits your user's ability to talk to localhost. Treat your Hub Mac the way you would treat a password manager or a banking app.
  • Supply-chain compromise of upstream dependencies. Ostler runs on Docker, Ollama, a model file, a Python runtime, and a small set of packages. We pin versions and read changelogs. We cannot promise the rest of the open-source ecosystem will never have a bad day.
  • You. The recovery phrase is the worst-case backdoor. If you take a photo of it, paste it into a cloud notes app, or read it out on a video call, you have created the attacker's shortcut. We make it easy to do the right thing, but the final link is you.

These are honest limits, written down where you can read them, not buried in a 30-page legal document.

How this maps to the Privacy section pages#

The Privacy section of these docs walks through the architecture from the data side rather than the system side:

  • Hub and iPhone – the two-device topology this privacy model rests on.
  • Encryption – the cryptographic primitives.
  • Data flows – every piece of data, traced end to end.