Privacy Policy

1. Who this policy covers

In this draft, “Lar,” “we,” and “us” mean [LEGAL ENTITY NAME — owner to supply]. This policy covers the Lar desktop, web, and mobile apps, lar.io, and Lar-hosted account, sync, sharing, publication, capture, AI, and entitlement services. A separately operated self-hosted server may have its own operator and privacy terms.

2. Workspace data on your device

Lar is local-first: creating, editing, browsing, and searching a workspace use the copy on your device and do not require an account or continuous connection. On desktop, Lar encrypts the workspace database, including titles, properties, and search data, and protects attachments and authoritative document records at rest. The workspace key is normally sealed by the operating-system keychain; if the keychain is unavailable, the desktop app warns that its fallback key file is unsealed.

Web and mobile also encrypt the local workspace database, search index, authoritative document records, and attachments at rest with the workspace key. Key custody differs: web keeps its custody record in browser storage and trusts the same-origin application context, while mobile uses the operating-system Keychain or Keystore. Device access, browser-origin access, operating-system backups, and exports are outside Lar-hosted services and are governed by your device, platform, backup provider, and chosen export destination.

3. Information the hosted services receive

Account and sign-in data

If you create an account, the identity service stores an account identifier, email address, verification state, optional display name, and creation time. Depending on the sign-in method, it also stores a password hash, passkey public credential and counter, or an OAuth provider identifier and the email observed when it was linked. It stores hashed session and one-time-token values, session timing and revocation state, passkey transports and an optional label, account-deletion state, and an account binding to a local cryptographic principal. Lar does not receive a passkey private key.

Sync, sharing, and recovery

The sync and sharing relay stores and routes encrypted workspace updates. It also needs document and workspace identifiers, access-control account IDs and roles, device IDs and public keys, encryption epochs and wrapped-key lists, update sizes and counts, connection timing. Content keys and note plaintext are not stored by the sync or sharing relay. Sensitive key material in pairing, unlock, and account-recovery records is client-produced ciphertext; those records also carry the identifiers, revisions, checks, and timestamps needed to operate them.

Subscriptions and entitlements

When hosted subscription features are enabled, Lar can store the account identifier, store/source identifier, product identifier, subscription status, event identifiers and timestamps, and period end time received through RevenueCat. Payment-card details are not represented in Lar's entitlement store.

4. Features that disclose content

AI

AI is optional. A local or loopback provider uses one-time workspace enablement. Before a cloud AI dispatch, Lar applies its consent tier and, when approval is required, shows the destination, action, and model. The current dialog does not show the payload itself. You can opt into standing consent for an action type. Dispatch metadata and token counts, but not prompt content, are recorded in a local AI activity ledger. Hosted AI also keeps a per-account or per-principal server-side activity ledger containing dispatch metadata and token counts, not prompt content.

Cloud AI providers receive AI request content, which can include note text and image or audio bytes, and handle it under their own terms. When the hosted AI route is used, the Lar AI service also receives that request content in memory so it can forward the request; that route is not part of the zero-knowledge sync relay. Lar filters Objects marked as excluded from AI across its main retrieval and dispatch paths. That exclusion control does not cover text transforms submitted without an Object identifier or content sent by workflow webhooks.

If you save a personal AI-provider credential for hosted account AI, the server stores that credential encrypted under a deployment-managed key.

Provider-fed capture

If you connect a hosted email or integration capture channel, the configured gateway receives that message in plaintext because the provider sends it to the gateway, not to your device. The gateway normalizes and sanitizes the content, then encrypts it. The implementation does not persist or log the unsealed message, but plaintext exists in gateway memory during that processing window. Hosted capture retains encrypted provider and sender identifiers plus the account, mailbox, workspace-routing, device, delivery, idempotency, timestamp, and byte-count metadata needed to operate the channel.

Published web pages

Publishing creates an encrypted, read-only snapshot containing only the body, properties, metadata, and selected attachment metadata. The server stores ciphertext together with an opaque publication ID, owner account ID, content length, timestamps, and any custom slug you choose. The decryption key is in the URL fragment, which is not sent in the normal HTTP request, and decryption happens in the reader's browser. Anyone with the complete URL can read and copy the snapshot. Unpublishing stops later retrieval but cannot retract copies already loaded, cached, downloaded, or shared.

5. Analytics, logs, and service providers

The desktop app does not send product analytics or crash telemetry. It writes a bounded, plaintext crash/error log on the device, and Lar does not upload that log. Operating-system backups, device-management software, or other local software may copy it; macOS backup and indexing exclusion is best-effort. The publication page is designed without third-party analytics or assets. The relay's own code uses client IP addresses only in memory, to apply rate limits, and does not store them with workspace or account records; a reverse proxy or hosting provider in front of it may still log them. Details of lar.io and hosted-service request logging remain to be supplied: [HOSTING AND SERVER LOG DETAILS — owner to supply].

Some desktop features contact other services directly from your device rather than through Lar-hosted services. The app checks Lar's signed update feed for new versions automatically unless you turn automatic updates off; a manual check in Settings still contacts the feed. Calendar sync talks directly to the Google, Microsoft, or CalDAV server you connect, using credentials that stay on your device. Creating a web link can make the app fetch the linked page, its preview image, and its favicon to show a preview.

Optional features can involve service providers you select or enable, including an OAuth provider, email delivery provider, AI provider, connected integration, app store, or RevenueCat. Those providers process the information required for their feature under their own terms.

6. Retention, deletion, and your choices

You can use local workspaces without an account, disable sync and AI, disconnect integrations, unpublish snapshots, revoke sessions, and request account deletion through the available product controls. Deleting a server account and deleting a local workspace are separate actions.

Specific retention periods and backup-deletion timing are not yet supplied: [RETENTION SCHEDULE — owner to supply]. If applicable law gives you access, correction, deletion, objection, or portability rights, contact us using the address below.

7. International processing and children

Hosting locations and any international-transfer mechanism: [HOSTING REGIONS AND TRANSFER DETAILS — owner to supply].

Minimum user age and children's-data position: [AGE REQUIREMENT — owner to supply].

8. Changes and contact

We will post changes on this page and identify the effective date once this policy is final. Privacy questions and requests: [CONTACT EMAIL — owner to supply]. Postal address: [POSTAL ADDRESS — owner to supply].

Read the draft Terms of Service.