Privacy Policy

Overview

Orca One is a macOS application operated by DigitalCarbon Inc. It provides dictation, meeting capture, transcription, and note-taking features designed to run locally on your Mac. This policy explains how Orca One handles information, including information received from Google APIs.

Voice, transcripts, and notes

Orca One records only when you start dictation, a voice note, or meeting capture. Audio, transcripts, summaries, dictionary entries, and notes are processed and stored locally on your Mac. Orca One does not send this content to DigitalCarbon or Orca One servers.

App usage and purchases

Orca One automatically sends limited product usage events to our server as part of using the app. Core funnel measurement does not depend on advertising attribution or the optional diagnostics setting. We record the first open of a new installation; setup screens reached, model readiness and setup completion; the first dictation requested, recording started and successful nonempty dictation saved; and the first time you choose Buy. We record dictation trial progress at 25%, 50%, 75% and 100% of the 2,000-word allowance; use of one, two and three shared Notetaker or voice-note trial recordings; and the first attempt blocked by each exhausted allowance. Only predefined milestones are sent, not exact word totals. Daily launches and feature use are optional diagnostics, described below. Each event includes a random installation identifier, event time, a predefined event or feature category, Mac model family and model identifier, chip family, installed RAM in GB, macOS version, app version and build, and measurement version. We forward core funnel events to PostHog to understand setup completion, activation, trial progress and purchase. After successful license activation, our server also reports one activation checkpoint per licensed device and installation pair. Updates keep the same identifier and do not count as another first open. Historical usage is not reconstructed; an existing installation without a previous dictation checkpoint reports its first observed successful save after updating.

When website measurement is allowed, we create a short-lived random journey reference that connects your visit, a link you send to your Mac, and a personalized download to later app milestones. This first-party measurement can work when a third-party analytics script is blocked. A phone link can carry the journey reference, ad click and campaign to the Mac. Checkout can retain the journey reference so a confirmed payment and later license activation can be attributed even when the browser analytics script does not load. Turning off website analytics stops new website journey collection and ad signals. While website measurement is allowed, we also create a separate random Meta visitor identifier that expires after seven days without renewal. The Meta browser script hashes this identifier, and our server sends the same hash with ad events. We store the campaign, Meta click/browser cookies, and the hashed identifier for a download journey for up to seven days. First-open and first-dictation events can use that matching context for ad measurement. A shared link retains acquisition context while creating a separate recipient journey and visitor identifier. If an installer is copied, only its first associated installation can use the original browser matching context. Checkout and a confirmed purchase use the checkout browser’s identifier. We do not send app content, a license, or a payment identifier to Meta. A purchase opened from the app carries the separate random installation identifier to checkout. The identifier briefly appears in a URL fragment, which is removed before website analytics starts, and can attribute a checkout started in that browser tab within 30 minutes. Stripe Checkout metadata retains it so a confirmed payment can complete the same installation's funnel. When you activate a license, the app includes the installation identifier in the existing activation request. We store a link between that identifier and the licensed device, including when checkout began on the website. These identifiers are pseudonymous: they can connect a visit, app milestones, activation, and a purchase. The installation identifier is separate from your website visitor identifier and licensing device key, but we link it to the licensed device after activation.

These analytics events contain no audio, transcripts, notes, note titles, dictionary entries, clipboard content, command names or arguments, text you type, names of the apps you use, serial number, hardware UUID, owner-assigned device name, email, license key, licensing device key, or Stripe identifier. Our hosting provider receives the source IP address when accepting a request; we do not forward it to PostHog for app events. Setup and feature-use events are not sent to Meta. The Share diagnostics setting controls crash and error reports and daily launch and feature-use measurement. Core funnel milestones are independent of that setting.

Usage measurement runs separately from opening or using the app, opening the purchase page and completing payment. A bounded local queue stores at most 68 unsent events. Daily launch and feature-use events are coalesced; repeated actions are not individually reported. Events are retried on a later launch, Buy click or new milestone, and unsent local events are discarded when retried after 30 days. Server delivery retries for up to 30 days after receipt, then removes undelivered payloads. The local identifier, completed-checkpoint markers and latest reported day per category remain with the app data to prevent repeat counts; removing that data can create a new installation count. Activation adds no extra network request; an unavailable installation identifier or reporting write does not prevent a valid license activation. Missing attribution never prevents a purchase.

Optional diagnostics

The Share diagnostics setting covers crash and error reports and daily launch and feature-use measurement. Previously labeled Share crash and error reports, it starts off during setup. Showing setup does not activate reporting. It starts only after you choose to share and continue. The same control is available in Settings > Permissions. You can use Orca One with reporting off.

Older versions offered crash-only reporting. Existing users keep their saved choice; a saved crash-only choice does not enable error reports. Choose Also share error reports in Settings to expand that choice. Users without a recorded choice remain opted out.

While Share diagnostics is enabled, Orca One records actual app launches and use of dictation, Notetaker, voice notes, notes, the launcher and styles for product and retention measurement, at most once per installation per UTC day for each category. These events use the same random installation identifier and bounded event fields described above and go through our server to PostHog. They are not sent to Meta. An absent or disabled choice produces no daily events or later backfill. Turning diagnostics off discards pending local daily events; a request already sent can finish, and events already received by our server are not withdrawn. Enabling diagnostics during an already-running process does not report an earlier launch. Existing enabled diagnostics choices also control daily measurement; a saved crash-only choice still does not enable technical error reports. Daily launch and feature-use analytics describe installations with diagnostics enabled, not every installation.

With the expanded choice, Orca One sends limited technical reports about failed startup, model downloads or loading, recording, transcription, saving, text delivery, updates, and unexpected licensing or calendar-connection failures. A report can also describe a partial failure where the original transcript was preserved. These reports contain predefined failure codes, the affected feature and processing stage, known model and runtime identifiers, audio-track category, a technical numeric error code when available, and the result or recovery category. They do not contain the content being processed or raw error descriptions.

Normal cancellations, permission refusals, silent recordings, and routine license or sign-in decisions are excluded. Repeated reports are limited. A separate cache holds up to 50 report envelopes when delivery is pending. Turning sharing off cancels delivery and attempts to remove that cache. Failures that occur while sharing is off are not collected for later upload.

Crash sharing captures supported fatal native crashes, including fatal signals and low-level faults such as aborts, bad-memory crashes, and Swift runtime traps. Pending crash reports are normally sent on a later launch while consent remains enabled. This integration does not send hangs, watchdog terminations, force-quits, SIGTERM, logs, session replay, analytics, performance traces, or automatic network-request reports.

To survive a fatal process exit, that temporary local artifact can contain raw process-level crash details before redaction. The dedicated cache also contains a random local SDK installation identifier. Both remain on your Mac at that stage. On the next launch, the outgoing scrubber runs before any event request and removes non-allowlisted data; the raw artifact and local identifier are not uploaded.

DigitalCarbon uses Sentry as its crash and error report processor. Orca One does not add an IP address to the report, but Sentry necessarily receives the source IP address to accept the HTTPS request. Before crash reporting is enabled in a production release, the Sentry project must be configured not to store IP addresses on events. Hosted crash events may be retained for up to 90 days under Sentry's plan terms. Release operators must use the shortest retention available on the selected Sentry plan and re-review that boundary before changing the plan or retention configuration. Sentry debug files expire after 90 days without use.

Separately, release tooling uploads the app's release dSYM symbol file, without source code, so Sentry can resolve crash addresses. A dSYM can contain developer build paths, function and variable names, and line metadata; it does not contain user recordings, transcripts, notes, or files.

Turning report sharing off disables new capture and delivery, cancels the app's in-flight Sentry transport, and attempts to remove queued reports from its separate crash cache. Local cache removal is best-effort deletion because an operating system or file-system interruption can prevent cleanup. Reports already delivered to Sentry cannot be recalled and remain subject to the retention boundary above.

The Local Diagnostics Center is separate. Its bounded lifecycle log, watchdog state, support snapshot, and manually collected diagnostic bundle remain on your Mac and are never attached to a Sentry report. They leave the Mac only if you explicitly export and share them yourself. Turning crash sharing off does not delete these local diagnostics.

Support and feedback

When you choose Send in the app or on our support page, the message you type and any email address you provide are sent to DigitalCarbon through our website and delivered to our private support channel in Slack. Email is optional. Leave it blank if you do not want to identify yourself or receive a reply. No recording, transcript, note, diagnostic bundle, license, or device identifier is attached automatically.

We use these messages to provide support and improve Orca One. Slack processes and stores the messages for our team. Our server keeps a random submission reference and a keyed digest to avoid duplicate delivery, without storing message text or email in its database. References older than 24 hours are removed when a new submission arrives. Hosting providers receive your IP address when accepting the request. We use a keyed address digest to limit abuse. Form fields are masked from website analytics and session replay. Contact us to request deletion of a message.

Download link by email

If you ask us to email you the download link, we use your email address only to send it. The link carries any Meta or Reddit ad click ID and campaign tags from this visit, so a download on your Mac can be credited to the ad.

Update checks

When you check manually, or when the setting-controlled daily check is enabled and due, Orca One makes an unauthenticated HTTPS request to https://orcaone.com/releases/macos/stable/appcast.xml. The request contains no installation, account, license, device, analytics, or user content identifier. It sends no transcript, note, dictionary entry, audio, or clipboard content, and Orca One adds no authentication or tracking cookie to the request.

To prevent older application state from being attached, Orca One clears legacy same-origin cookies before Sparkle starts checking and before every manual check. License activation uses a separate ephemeral session that cannot read or store cookies. The public appcast is deployed as a static, non-redirecting response that does not set a cookie.

As with an ordinary website request, our hosting provider may see transport information such as the source IP address, request time, and public Orca One and Sparkle versions. Automatic checks are enabled by default and can be disabled in Settings. When enabled, Orca One checks no more than once every 24 hours. Automatic failures are silent and do not affect offline use. Development, payment sandbox, and unnotarized test builds cannot contact the production update endpoint.

Locally, the updater stores the automatic-check preference, last check time, public release and skipped-version metadata, temporary installation state, and fixed safety values: profiling off, a 24-hour interval, and fixed rollout group 0. These values are shared by every installation; the updater does not create a random per-install update identifier. It does not download an update until you choose to install it. When you select Update & Relaunch, Sparkle downloads the signed and notarized DMG from Orca One's official HTTPS download path, verifies its cryptographic signature and Apple code-signing identity, safely replaces the app, and relaunches it. The app postpones that relaunch while recording, transcription, insertion, or meeting capture is active.

Google user data we access

Connecting Google Calendar is optional. If you connect it, Orca One requests your basic Google account identity and read-only access to your calendar list and calendar events. The app may access:

• Your Google account email address.
• The calendars available to the connected account.
• Event title, start and end time, organizer, attendees, meeting link, and location.

Orca One cannot create, edit, share, or delete Google Calendar events.

How we use Google user data

Orca One uses calendar data only to identify a meeting happening now or beginning within the next 24 hours and to attach the selected meeting's details to a note you choose to start. Google user data is not used for advertising, profiling, or training AI models.

Storage, protection, and retention

• Google OAuth refresh credentials are stored in macOS Keychain.
• Short-lived access tokens are held in memory while needed.
• Upcoming event metadata is cached in Orca One's local database on your Mac.
• Meeting metadata attached to a note remains with that local note until you delete the note.

Orca One uses Google's encrypted HTTPS endpoints for Calendar API requests. Because the app stores data locally, the security of your Mac, macOS account, and device backups also affects that data.

Payments and license activation

Stripe processes Orca One purchases. We receive and retain the Stripe Checkout Session, Payment Intent, and Customer identifiers, the amount and currency charged, purchase and refund or dispute status, and related timestamps. Stripe may receive the contact, payment, tax, device, and network information described in its privacy policy. Orca One does not receive or store your full card number.

Our licensing service stores a keyed digest of your license, not its plaintext code, along with license status. For each activated Mac, it stores the device public key, a derived device identifier, the name you provide for the Mac, app build number, receipt identifier, and activation timestamps. When the app provides its random installation identifier, we also store a link between that identifier and the licensed device. Abuse controls store only HMAC-derived rate-limit buckets, not the submitted license code or raw network address.

Commerce and licensing records are retained while needed to provide lifetime-license recovery, enforce the device allowance, handle disputes, meet legal obligations, and protect the service. Access is restricted and data is encrypted in transit; backups and production access are limited to operational needs. You may contact us about an account or licensing record using the address below.

App-open and purchase notifications

Our server sends operational alerts to our private Slack channel when an installation first reports opening the app or a payment is confirmed. First-open alerts contain the app version, build, event time, and an event reference. Purchase alerts contain the amount, currency, and an event reference. Installer downloads do not generate Slack alerts.

These alerts contain no IP address, customer contact details, license code, browser or installation identifier, hardware details, audio, or text from the app. Our server retries pending Slack alerts for up to 30 days, removes delivered payloads, and keeps hashed references to prevent duplicate delivery. Slack stores the alerts for our team.

Website analytics

We also use Google Analytics to measure visits to public website pages and the sites that referred visitors. Google receives basic browser and device information and uses cookies to distinguish visits. We exclude purchase pages and remove URL query strings and fragments from the page addresses we send. We do not send names, email addresses, license codes, or app content to Google Analytics, and advertising personalization is off. The website analytics opt-out also disables this measurement.

This section is about orcaone.com, not the app. The website uses PostHog, a product analytics service, to measure how visitors use it. It runs only in the website. It does not read anything on your Mac, and it does not change what the app does with your audio, transcripts, or notes.

On this website, PostHog records the pages you view, the links and controls you click, scroll and pointer positions, a replay of the pages as you saw them, page performance timings, browser console messages, and JavaScript errors. It also receives your IP address, which it uses to estimate country and city, along with the page that referred you, any campaign parameters in the link you followed, and your browser, operating system, and screen size. Cookies and browser storage hold a random visitor identifier so that repeat visits are recognised as the same browser.

We measure download-link clicks, checkout creation, and Stripe-confirmed purchases. A click does not tell us whether you downloaded, installed, or used the app. Where available, we associate checkout and purchase events with the browser's random visitor identifier or its journey reference. These events contain the product, validated campaign context, amount charged, and currency, not your name, email, license code, payment details, or a hardware identifier. Browser information cannot reliably identify your exact Mac model; location is an approximate estimate and may reflect a VPN or network provider. Purchases without either identifier remain unattributed and cannot be matched to a website visit.

Queued server analytics are retried for up to 30 days. We remove their visitor identifier and event details from the delivery queue after successful delivery or expiry, while keeping a minimal record to prevent duplicate purchase counts.

The purchase confirmation page is excluded from replay, and the Stripe Checkout Session identifier is removed from recorded addresses, so license codes are not collected. Analytics requests are sent to orcaone.com and passed to PostHog by our server. We do not sell website analytics data.

Advertising

The website uses Meta's pixel and Conversions API to measure our ads on Facebook and Instagram. Meta receives the pages you view here, download clicks on a Mac, and checkout starts and purchases with their amount and currency, along with your IP address, browser details, and Meta's cookies. It also learns when you send yourself the download link. We also measure our Reddit ads: when you arrive from one, we keep Reddit's click ID in a cookie. Our server tells Reddit about download clicks on a Mac, and about purchases with their amount and currency, along with the page it happened on, that click ID, your IP address, and browser details. We never send your name, email, license code, or payment details.

Sharing and transfers

DigitalCarbon does not sell Google user data or share it with advertisers, data brokers, or other third parties. Calendar API requests travel directly between Orca One on your Mac and Google. DigitalCarbon does not operate a server that receives or stores your Google Calendar data.

Payment and tax information is shared with Stripe as necessary to complete and support a purchase, prevent fraud, and comply with financial and tax requirements. We do not sell licensing or payment information.

While report sharing is enabled, DigitalCarbon sends only the technical events described above to Sentry, which processes them on DigitalCarbon's behalf. DigitalCarbon does not sell diagnostic report data or share it with advertisers or data brokers.

Your controls and deletion

You can disconnect Google Calendar from Orca One at any time. Disconnecting removes the credential from macOS Keychain, attempts to revoke it with Google, and clears the local upcoming-event cache. You can delete notes containing meeting metadata inside Orca One. You can also revoke Orca One's access from your Google Account security settings.

Google API Services User Data Policy

Orca One's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Changes and contact

We may update this policy as Orca One changes. We will post revisions on this page and update the effective date. For privacy questions or requests, email [email protected].