Privacy Policy

This policy explains how the hosted Borago Board service at https://board.boragosoft.com (the "Service") collects and uses personal data. For the desktop app's local behavior, see the Desktop Privacy Policy.

1. Data we collect

Account data

• Email address (unique identifier / login).
• Password stored only as a scrypt hash (we never store your plaintext password).
• Display name, role, and account status.
• Subscription tier, status, expiry, and auto‑renew preference.
• A per‑user identifier (UUID).
• A wrapped encryption key and its salt. This is your account's data key, sealed with a key derived from your password. We do not store your password or the unwrapped key. At sign‑in, when a password is set, changed or reset, and when a new recovery code is issued, the key is opened in memory for that one request and handed only to your linked desktop app; nothing from it is kept, so we cannot read the secrets it protects afterwards (see §1a and §8).
• Two‑factor authentication data, if you enable it: your TOTP secret (encrypted), hashed one‑time recovery codes, and an optional recovery email address used only for the account‑recovery process.
• A desktop installation identifier — a random UUID your desktop app sends at login so your account can be linked to exactly one desktop installation. It identifies the installation, not your hardware, and carries no other device information.

Content data you sync/create ("Your Content")

• Projects, tasks (including task titles, descriptions, and the AI‑generated output/history text, which may contain code snippets), and comments.
• Per‑run output archives — the text output of each AI task run, kept per task so earlier attempts can be reviewed.
• Chat conversations with the planning assistant (your messages and the AI's replies, which may include content the assistant read from your repository on your desktop).
• Notes and Flows (your scheduled multi‑step routines — their definitions sync; their run logs stay on your desktop).
• Notifications raised on your board, including whether you have read them (so reading one on any device clears it everywhere).
• Account settings (e.g. theme, time format) and your self‑hosted AI service registry, if you use one — the names and server addresses of model servers you have configured.
• On plans that include attachments (Pro and Max, and the trial), file/image attachment metadata and the file bytes (stored in object storage).
• Encrypted secrets you choose to sync — including entries in the app's key vault — see §1a, which explains exactly which ones, what we can and cannot read, and how to stop syncing any of them.

Technical/security data

• IP address and request metadata used for abuse detection and rate‑limit accounting on sign‑in and other public endpoints.
• Email challenges (a code/token, expiry, attempt count) during signup, password reset, and account recovery.
• Web‑push subscriptions, only if the Service offers browser push notifications and you enable them (it does not at present): the push endpoint and keys your browser issues, used only to deliver your own board/service notifications to that device. A push endpoint belongs to the browser or app installation, not to an account: if you keep more than one account signed in on the same device and switch between them, the endpoint is re‑associated with the account you switch to, so that device receives notices for the account currently in use and stops receiving the previous account's.
• Server logs.

Payment data

• Handled by Stripe; we receive limited billing status, not full card data.

Relayed desktop actions

• If you open a project terminal from the hosted board, the Service relays the terminal input/output between your browser and your desktop over an authenticated tunnel. The same tunnel relays other actions you trigger from the hosted board to your own desktop — chat requests, project‑script runs and their output, and container start/stop/rebuild commands. These streams are forwarded in memory and not stored by the Service (results that are board content — e.g. chat messages — are stored as Your Content above).

Diagnostic reports you choose to send (optional, never automatic)

• The desktop app's Settings → Diagnostics can send us a bug or error report, and so can the hosted board and the mobile app (a report from those carries no log excerpt: your message and, if you include it, your browser's identification string). It is composed and previewed on your device — see the Desktop Privacy Policy §3 for exactly what goes into one — and the Service is where the resulting report is stored.
• A stored report holds only: the report type (bug/error), your message, an optional log excerpt, optional system information (OS, architecture, app version), and the time it arrived. No account id, no device id, no email address is attached, and your IP address is not stored with it (it is used transiently to rate‑limit the endpoint against abuse).
• Because no identifier is attached, a report cannot be linked back to your account by us — which also means we cannot find your reports on request. Tell us at privacy@boragosoft.com what you sent and when, and we will delete it.
• Note what a report can contain: the log excerpt is scrubbed of secrets (API keys, tokens, passwords) but not of ordinary content, so it may include project and task names, file paths, and any email address that appeared in a log line. You see the exact payload before sending. Lawful basis: consent.
• How we read reports. We develop Borago Board with AI coding assistants and may put a report's content in front of one when we investigate it. That transmits the report — message, log excerpt, system information — to the assistant's provider (currently Anthropic, PBC, United States; listed in §4 for this purpose alone) for processing under that provider's terms, including its retention rules. It is the one case in which content you gave us reaches an AI provider through us. Sending a report is your consent to that handling; the way to avoid it is not to send one.

We do not receive your repository through the Service (the task text, run output and chat you sync may quote code, as §1 says), and the Service does not run AI agents or send your data to any AI provider (Anthropic, OpenAI, xAI, Google — that occurs only on your desktop peer, under your own key — see the Desktop Privacy Policy). The one exception is a diagnostic report you choose to send, which we may analyse with an AI coding assistant as described above.

1a. Secrets, and your choice about syncing them

Several kinds of secret can be stored on a project or in your account's key vault: your AI provider API tokens (Anthropic, OpenAI, xAI, Google), a Git access token or SSH key, and your project environment variables.

What we store is always ciphertext, encrypted with a key only your password or recovery code can unwrap. We hold that ciphertext plus the wrapped key, and never the unwrapped key (§1). We cannot read any of it at rest, and the key is opened in memory only at the moments §1 and §8 name. We cannot produce it in response to a request, and a breach of our database does not expose it. Secrets synced from the desktop app are encrypted before they leave your device; the one exception is described immediately below.

You can stop any of them syncing — per project, and for environment variables per VARIABLE. Each secret has its own "keep on this device only" setting, and an individual environment variable can be marked the same way (so a database host can sync while the credential beside it never leaves the machine). A variable marked that way is stored in a separate place on your device that is not part of what we receive at all; we learn only that a variable of that name exists, never its value. Turning the project-level setting on does two things:

1. it deletes that secret from our systems on the next sync, rather than merely stopping future updates; and
2. it keeps the secret on that device only — so your other devices will ask you to enter it again.

Secrets are never used for any purpose other than performing the actions you ask for. We do not read, scan, analyse or share them.

Secrets are never displayed on the web or mobile client, and are never stored by us in a form we can read. Those clients do not hold your key, so a value encrypted there would be readable by us and unusable by the device that runs your tasks — the Service refuses to store one. If a secret looks blank on the web, it is present and safe; it simply cannot be shown there.

Entering a secret from the web or mobile app: what actually happens. You can set a project secret or environment variable from those clients when you are away from your machine (a saved key in the vault and a self‑hosted service's API key can be entered only in the desktop app). Because only your desktop can encrypt it correctly, the value you type is passed through the Service to your own desktop app over an authenticated connection, and your desktop encrypts and stores it. Stated plainly, because it is the one place the guarantee above is weaker:

• the value reaches us in plaintext (protected in transit by TLS) for as long as it takes to forward it — it is held in memory, never written to our database, logs or backups;
• it therefore passes through software we operate, and a compromise of the running Service at that moment could observe it — unlike a secret entered on the desktop, which we only ever see as ciphertext;
• your desktop app must be running and connected, or the attempt fails rather than the value being stored anywhere.

If that residual exposure matters to you, enter secrets on the desktop app, where the value never reaches us in readable form at all.

What this means if you forget your password. Because we cannot unwrap your key without your password or recovery code, a password reset alone cannot recover your synced secrets. You are shown a one‑time recovery code when your key is created; it is the only other way in. If you lose both your password and that code, the affected secrets become permanently unreadable and you will need to enter them again. We cannot restore them — not as a policy choice, but because we do not hold the means to.

The limit of this protection, stated plainly. Encryption at rest protects against someone obtaining our stored data. It does not protect against a compromise of the running Service itself, because you send your password to it in order to sign in. The web client is served with a Content Security Policy and Subresource Integrity on its assets (see §8), and the desktop app is the stronger option if this matters to you: it holds your key locally, and your secrets travel to us only as ciphertext.

2. How we use data

• Provide and operate the Service (accounts, board, cloud sync, subscriptions).
• Investigate and fix problems you report to us (diagnostic reports, §1), including with AI‑assisted tooling.
• Authenticate you and secure the Service (rate‑limiting, fraud/abuse prevention).
• Communicate service, security, and billing messages.
• Comply with legal obligations and enforce our terms.

3. Legal bases (EEA/UK GDPR)

• Performance of a contract — operating your account and syncing Your Content.
• Legitimate interests — security, abuse prevention, service improvement, balanced against your rights.
• Legal obligation — tax/accounting, responding to lawful requests.
• Consent — where specifically requested (e.g. optional communications).

4. Sub‑processors

We use the following providers to run the Service:

We put data‑processing agreements in place with each and use appropriate transfer safeguards (e.g. SCCs/UK IDTA) for international transfers.

5. Sharing

We do not sell personal data. We share it only with the sub‑processors above, where required by law or lawful request, and in a business transfer (merger/ acquisition) subject to this policy.

6. Retention

• Account and content data: kept while your account is active. Self‑service deletion (Terms §8a): after the reactivation window (6 months for a disabled account, 14 days for a terminated one) plus a 14‑day recovery hold — or immediately on an explicit delete‑now request — all account data (projects, tasks, attachments, profile, remaining credits) is permanently deleted and a confirmation email is sent. Billing ledger entries (amounts, dates, an internal account number — no content) are retained for tax, accounting, and fraud‑prevention purposes.
• Attachment hold (Terms §8b): the attachments of an account that moved to a plan without attachments, or whose trial ended with no plan bought, are retained for 90 days (restored if the account subscribes to a plan with attachments in that time), then permanently deleted. On a move to a plan without attachments you may choose immediate deletion instead.
• Email challenges (signup and password reset): deleted on completion/expiry (and after failed attempts).
• Server logs: the Service keeps no request or access log. The application's own error log (failed requests by method and path, never a request body, an email address or an IP address, which appear only in the transient rate‑limiter) is kept for at most 14 days.
• Backups: a daily database backup is kept for 30 days, daily disk snapshots for the most recent 7 days, and superseded or deleted attachment files for 30 days, all removed automatically. A deletion in the live Service therefore disappears from every backup within 30 days.
• Diagnostic reports (§1): 30 days, then deleted automatically. Because a report carries no identifier, we cannot look up your reports by account. If you tell us what you sent and when, we can find it by its content and time and delete it (§1); otherwise this window is how it is erased.
• Deleted projects (recycle bin): 30 days. Deleting a project does not erase it immediately — it is marked deleted, hidden from the board, and kept for 30 days so it can be restored, then permanently deleted together with its tasks, comments and attachment files. Emptying the bin from the desktop app deletes it straight away. The 30‑day purge runs on the hosted service and on your own device independently, so the deadline is the same on both.
• Deletion note: the sync engine uses soft‑delete tombstones — a deleted row is retained, marked deleted, so the deletion can propagate to your other devices. Those tombstones are purged automatically after the 30 days above. A deletion request under §7, and "terminate and delete immediately" (Terms §8a), delete the live rows at once and are not subject to that window; copies in backups age out within the 30 days stated above.

7. Your rights

Depending on where you live (EEA/UK GDPR, California CPRA, others) you may have rights to access, correct, delete, port, restrict, or object to processing, and to withdraw consent or lodge a complaint with a supervisory authority. Exercise them via privacy@boragosoft.com; we will verify your identity and respond within statutory timeframes. We do not use your data for automated decisions with legal effect.

8. Security

We use reasonable technical and organizational measures: encryption in transit, AES‑256‑GCM encryption at rest, scrypt password hashing, JWT‑based authentication (changing or resetting your password invalidates existing sessions), per‑account scoping, and rate‑limit accounting on the sign‑in endpoints.

Your synced secrets are encrypted under a key we never store (§1, §1a). We hold your account's data key only in a form sealed by your password or recovery code; it is opened in memory only at sign‑in, when a password is set, changed or reset, and when a new recovery code is issued, and handed only to your linked desktop app.

Client integrity. The web client is served with a Content Security Policy and Subresource Integrity on its assets, so an asset that does not match what the page expects is refused by the browser.

No system is perfectly secure. Report concerns to security@boragosoft.com.

9. Children

The Service is for adults: account creation requires confirming you are 18 or older (see the Web Terms §2), it is not directed to children, and we do not knowingly collect their data.

10. Changes & contact

We will post updates with a new effective date and notify you of material changes. Controller: Borago Soft Limited · privacy@boragosoft.com · 7a Garner Place, Glenfield, Auckland 0629, New Zealand. No EU/UK representative or Data Protection Officer is appointed; direct requests to privacy@boragosoft.com.