What we never collect#
Most privacy pages list what a company collects. This page lists what Ostler is built not to collect. Each entry is a category we have deliberately designed no mechanism for, with a note on why the architecture rules it out.
Why an architectural list, not a promise
"We promise not to look at your data" is what every cloud company says. The interesting question is: if a company changed its mind tomorrow, what would change in the product? For Ostler, the answer is "we would have to ship new code, which existing users could refuse to install." That is the difference between a policy and an architecture.
The list#
Your message bodies#
Never collected
Message bodies from iMessage, WhatsApp, LinkedIn, Apple Mail, or any other source.
Why the architecture prevents it: message content is read locally by the Hub, parsed into the local stores, and never transmitted from the Hub to any Creative Machines server. There is no Creative Machines endpoint that accepts message content. There is no client code path that uploads it.
Your email content#
Never collected
The bodies, attachments, headers, or metadata of your emails.
Why the architecture prevents it: Ostler reads your mail from the local Apple Mail store on your Mac, via macOS Full Disk Access. Creative Machines does not connect to Gmail, Exchange, or any other mail provider on your behalf. We have no Google Cloud OAuth client, no IMAP credentials, no token to revoke. See Apple Mail FDA vs Google OAuth for the full reasoning. Even if we wanted your email, the routing decision means we have no way to ask for it.
Your contacts list#
Never collected
The names, phone numbers, or emails of people in your address book.
Why the architecture prevents it: contacts are imported into the local knowledge graph and stay there. The Hub has no upload endpoint for contact data, and the cloud surface has no inbound contact ingest. (The exception, fully disclosed: when the optional public-data enrichment feature is on, the name of a person being enriched is sent to Wikidata or Wikipedia for the lookup. That is the lookup name only, not the contact record. See What leaves the device.)
Your calendar events#
Never collected
The titles, times, attendees, or locations of your meetings.
Why the architecture prevents it: calendar imports go through the local Calendar store on your Mac. They land in your local graph. There is no telemetry of meetings, no aggregated calendar feed, and no cross-user "people you both met" feature that would require comparing calendars on a server. Calendar data does not leave the device.
Your browsing history#
Never collected
The URLs, page titles, or browse times that flow through the optional Safari or Chrome extension.
Why the architecture prevents it: the extension posts captured pages to the Hub on localhost. There is no remote endpoint configured. HTML is sanitised on the device before processing. The captured page never traverses the public internet to reach Ostler – it goes from your browser to your Hub on the same machine.
Microphone audio#
Never collected
Audio captured by the microphone, transmitted off-device.
Why the architecture prevents it: speech-to-text runs locally. The Hub processes audio with a local Whisper model on your Mac, writes the transcript to the local stores, and discards the audio buffer. No audio stream is sent to a remote service. There is no "voice cloud" component.
Emotion, mood, or sentiment from voice#
Never inferred
Inferences about how you are feeling from voice signals (stress, fatigue, drunkenness, mood).
Why the architecture prevents it: Ostler's voice pipeline does speaker identification only – matching a voice to a known speaker profile – and nothing else. There is no emotion-detection model, no sentiment classifier on audio, and no commercial voice-analytics SDK linked into the Hub. The line between "this voice is Alice's" and "Alice sounds stressed today" is not a fuzzy quality difference; they are different products and Ostler is built for the first, not the second. See voice and speaker identification for the full position.
Screen recordings#
Never collected
Screen captures, screen recordings, or app-window contents.
Why the architecture prevents it: Ostler does not request the macOS Screen Recording permission as part of its core install, and where any optional capture features exist, the captured frames are processed locally. There is no remote endpoint that accepts screen content.
What you type into the assistant#
Never collected
The prompts you type, the questions you ask, or the answers the assistant gives back.
Why the architecture prevents it: the assistant runs against a local language model on your Mac. There is no router that forwards prompts to a hosted model. There is no usage analytics layer that records what was asked. The conversation history that does exist is stored locally so you can scroll back through it; it is not transmitted.
If we ever offer optional cloud-model routing as a user-controlled feature in the future, it will be opt-in, clearly labelled, and disabled by default. It does not exist today.
Behavioural analytics on the app#
Never collected
What you click, what you search for inside Ostler, what features you use, how often you open the app.
Why the architecture prevents it: there is no analytics SDK linked into the Hub. There is no usage event stream. There is no funnel tracking. We do not know how many people are using Ostler, what features are popular, or what bugs you have hit – unless you tell us via a support email. We accept the operational cost of flying blind in exchange for the trust posture.
Aggregated training data#
Never collected
Your conversations, your inferences, your graph, used to train a model – ours or anyone else's.
Why the architecture prevents it: there is no extraction job that pulls training data off your machine. There is no model-improvement pipeline that consumes user data. The model that runs on your Mac is a publicly available local model that we did not train and that we do not improve based on what it sees on your device.
This is a feature, not an oversight. Personal data is the worst possible training material because it is the most sensitive and the most identifying. We do not want it for that purpose, and we have built no mechanism to acquire it.
Cross-user fleet learning#
Never collected
One user's data being used as a feature input for another user's instance.
Why the architecture prevents it: each Ostler install is isolated. Your Hub knows what your Hub has been told. It has no view of any other user's Hub, and it has no aggregator on our side that would join data across users. There is no "people who looked at this person also looked at" surface that would require it.
Backup channels you did not ask for#
Never collected
A "convenience" cloud backup of your encrypted data on our servers, even encrypted, even opt-in.
Why the architecture prevents it: we operate no backup endpoint. Time Machine, iCloud Drive's regular backup of your home folder (if you use it), or your own backup discipline are the supported paths. We are aware that this is friction. It is also the only way to be sure we cannot be compelled to produce something we do not have.
Identity documents#
Never collected
Your government ID, passport, driving licence, or any other identity document.
Why the architecture prevents it: there is no KYC step. You install Ostler. You self-declare you are 18 or over (a Terms requirement). For paid tiers, payment is processed by Stripe or the Apple App Store under their own controls. Creative Machines holds a subscription identifier and your billing email, nothing else.
Comparison with other AI assistants#
This is the part of the page where we compare what stays off our books with what most other personal AI products handle by default. Naming and shaming specific products is not the goal – the pattern is general.
| Category | Ostler | Cloud AI assistants (typical) |
|---|---|---|
| Message bodies | Stay on your Mac | Sent to a remote model for processing |
| Email content | Read locally via Apple Mail | OAuth into your mail provider, content streams to a remote model |
| Calendar events | Stay on your Mac | OAuth into your calendar provider, events sent to a remote model |
| Voice transcripts | Generated locally | Audio uploaded to a remote STT service |
| Conversation history | Local file | Stored on the vendor's servers |
| Behavioural analytics | None | Standard product analytics SDK |
| Training data | None | Often opted-in by default |
| Vendor-side encryption keys | Not held (no vendor-side data) | Held by the vendor |
The categories on the right hand side are not necessarily wrong – they are choices a cloud product has to make, and many of them have legitimate reasons. They are choices Ostler does not make, because Ostler is not a cloud product.
Why we are confident in this list#
A few reasons, in increasing order of strength:
- Policy. This page exists, and we have written it down.
- Engineering rules. Ostler is built with hard-coded rules against telemetry, crash reporters that include user data, and any server that receives graph data. Pull requests that introduce these are not merged.
- Architecture. The Hub does not have a connection to Creative Machines servers for these categories. There is no place to put the data on our side, even if a malicious build of the Hub were to send it.
- Independent audit. We are commissioning an independent security audit from a recognised cybersecurity firm. The report will be published. Trust should be verifiable, not assumed.
- You can watch the wire. The Hub runs on your machine. You can monitor its outbound traffic with the standard tools your operating system already has. The list of expected calls is in What leaves the device.
If we ever change any of this, we will tell you, in advance, in the app. Local-first is not a marketing position. It is how the software is built.
Cross-references#
- What stays local – every category that stays on your Mac
- What leaves the device – the exhaustive list of outbound calls
- Apple Mail FDA vs Google OAuth
- Architecture / Privacy model