Privacy

The hold-to-talk commands — “move B2 to done” — are recognised by Apple's on-device speech recogniser, with on-device recognition required rather than preferred. That audio is not uploaded, to us or to anyone. If your language has no on-device model, XOBNI tells you so and refuses; it never falls back to a server.

Recording a meeting is the opposite case, and we would rather be plain about it than quiet. On a Mac, XOBNI captures two tracks — your microphone, and the audio from the other participants; on an iPad, the microphone alone — and uploads them, along with the transcript, to your organization's area of Google Cloud Storage. Those files sit under your own person folder: the storage rules let the person who made the recording read them, and nobody else in your organization. That is true of the audio without exception — no colleague, no team lead, no administrator and no member of our staff can play back a recording you made, and there is no route in the app that offers it.

The transcript is shared with the board. A meeting is recorded against one of your boards, and the text of what was said — not the audio — is readable by the people who can already see that board, along with the meeting's title, date, length and status. Who that is depends on the board: a board that is on no team is yours alone, so its meetings are yours alone; a board on a team is readable by its owner and by the people on that team named on it. That is how somebody who was in the meeting can read what was said without asking you to send it to them, and how you read your own transcript on another device.

Three limits belong with that. A very long meeting stores as much of its transcript as fits and says on the page that it stops part-way; the whole of it stays in the recording's own files, which only you can read. A meeting recorded before this change has no shared copy at all — its text is only on the device that recorded it. And the task suggestions a meeting produces are not shared: they stay yours until you accept one, at which point it becomes an ordinary card on the board like any other.

Turning a recording into a transcript, a summary and proposed tasks needs a model, and the model is whichever provider's API key you have saved in Settings. Along with the transcript, the board's name, its column names and the titles of its cards are sent, so the proposals fit the board:

• An Anthropic key. The recording is transcribed on your device by the on-device recogniser, and only the text of the transcript is sent to Anthropic, which returns the proposed tasks.
• An OpenAI key. The audio file itself is sent to OpenAI to be transcribed, and the transcript is then sent to OpenAI for the proposed tasks.
• Both keys saved. An Anthropic meeting whose on-device transcription cannot run — most often because macOS Dictation is switched off — is transcribed by OpenAI instead, which means the audio is sent there. That fallback is deliberately narrow: it does not happen because a recogniser was slow or a permission was refused.
• No key. Nothing is sent to any model provider. The meeting keeps its recording and whatever transcript it has, and says it could not be analysed.

Your API keys are your own: each lives in your device's keychain and is sent only to the provider it belongs to. A key is not used until you have agreed, on that device, to a notice saying exactly what will be sent. Your meeting goes to that provider's public API under your own account, not to a private model run for XOBNI or your company. What the provider then does with a transcript or an audio file is governed by the terms of the account the key belongs to, not by us.

Recording other people is your responsibility. XOBNI shows a red recording pill while a meeting is being captured; telling everyone in the room is up to you, and in many places it is the law.

When you paste a client brief, an email or your own notes and ask XOBNI to suggest cards, that text is sent to the provider whose key you saved — with the board's name, its column names and the titles of its cards — under the same notice and the same account as a meeting. Nothing from it is stored: the suggestions you do not tick are discarded, and the ones you tick become ordinary cards.

Review links. A review link is a private address for one card or one board, which you make, can turn off at any time, and which expires on its own. Anyone holding it can see what it covers — the work's title, notes, column, due date, checklist, uploaded files and earlier client feedback — without an account. It does not show your team's names or your team's comments. What the client sends back — their name and their approval, change request or comment — is added to the card as a comment.

Weekly client updates. If you set one up, the client's address receives a weekly email listing card titles, columns and dates on that board — what moved forward, what is waiting for their approval, with a review link for each, and what is due next — plus any note you add. Internal notes, comments and people's names are never included. Replies go to you, and every email carries an unsubscribe link.

Cards by email. A board can have its own private address. A message sent to it becomes a card, attachments included, only when it comes from someone in your organization who can edit that board. Anything else is dropped without a reply.

Boards, cards, comments, time entries, people, teams and the files attached to cards are stored in your organization's own tenant in Google Firestore and Cloud Storage. Isolation is enforced twice — in the database rules and again in the app — and a row belonging to another organization is refused as though it did not exist.

An organization admin manages people, teams and billing, and that buys no board access: an admin cannot read a board they are not on, and a personal board stays readable by its owner alone.

A file attached to a card can be opened by the people who can see that board, and by nobody else. Deleting a card or a board removes the rows; the stored bytes are not deleted with them.

There is no password. You give an email address, we mail you a six-digit code, and the session is kept in your device's keychain. The address is used to sign you in, to reply to you, and for the emails below.

Beyond sign-in codes, XOBNI emails you about your own work: a daily digest of the cards assigned to you that are waiting for review, overdue or due today; a note when a card assigned to you reaches Review; when somebody @mentions you in a comment; and when a client leaves feedback. You choose which of these you get in Settings ▸ Profile, and every digest carries a one-click unsubscribe.

A support ticket you file from the app, and the replies to it, can be read by everyone in your organization and by XOBNI support staff. Do not put anything in a ticket that your colleagues should not see.

Once you are signed in — then every quarter of an hour while it runs, whenever you bring it to the front, and whenever you choose Check for Updates… from the XOBNI menu — the Mac app fetches the release feed from xobni.io to see whether a newer version exists. That request carries nothing about you, your organization, your boards or your Mac — no account, no identifier, no system profile. An update is downloaded only when you click Install, is checked against a signature held in the app before it is installed, and is installed only when you click Install and Relaunch. On iPad the app makes no check of its own; updates come through the App Store or TestFlight.