Almost nothing leaves your Mac.

The Daisy app

What gets stored, and where

Recordings, transcripts, screenshots and summaries are written to a folder inside your user Library, on your Mac. Daisy never uploads any of it. You can open the folder from the app menu, back it up, or delete it.

What runs on-device

Audio capture, transcription (Whisper, via Apple’s Neural Engine), and the default summarizer (Apple Intelligence) all run locally. No network call is involved in producing a transcript or a default summary.

What happens if you bring your own LLM key

You can optionally point the summarizer at Anthropic or OpenAI using your own API key. When that’s on, the transcript for that one summary request goes from your Mac directly to the provider you chose. Daisy is not in the middle. We never see your transcripts and we never see your key — the key is stored in your Mac’s Keychain, not on our servers.

What happens if you connect Notion

If you paste a Notion integration token, Daisy sends finished notes from your Mac directly to your Notion workspace. Same shape: your machine to their API, nothing through us.

What happens if you connect a calendar

Daisy can link recordings to meetings on your calendar — useful for naming a session after the event, prefilling attendees, and optionally starting / stopping the recording when the event starts / ends. Two independent paths, both opt-in: Apple Calendar through Apple’s EventKit (no third-party involved), and Google Calendar through Google’s OAuth API. The Google integration is also documented in detail in the dedicated section below so the disclosures Google’s API policy requires are in one place.

What gets downloaded on first run

The first time you pick a Whisper model, Daisy downloads it from Hugging Face (the model publisher). That’s a one-time HTTPS download of the model weights, not telemetry — no identifier about you is sent beyond the standard request that any HTTPS client makes. Hugging Face’s CDN sees your IP and a User-Agent string, like any download.

What checks for updates

Once a day, Daisy fetches mydaisy.io/appcast.xml to see if a newer version is available. The request carries your current version number and a generic User-Agent — no account, no device ID, no usage data, no telemetry of any kind. You can disable automatic checks in About → Updates; the “Check for Updates…” menu item still works manually after that. Update downloads are signed with our EdDSA key and Daisy refuses to install anything whose signature doesn’t verify, so an attacker who hijacks the feed can’t push code at you.

No accounts, no telemetry

There is no Daisy account, no sign-in, no usage analytics, no crash reporter calling home, no feature flagging service. The only background network call Daisy makes is the daily update check above, against our own domain — nothing else runs in a loop, nothing leaves your Mac unless you explicitly connect a provider (Anthropic, OpenAI, Notion, …) yourself.

This website (mydaisy.io)

The landing page is a static Next.js site hosted on Vercel. It uses no cookies, no analytics, no trackers, no fingerprinting, no third-party scripts. Vercel keeps short-lived request logs (IP, user agent, URL) for spam and abuse protection, as any web host would; we don’t read them and we don’t export them anywhere.

If you email essazanov@pm.me, that message lands in a regular inbox and is treated like any other email — kept only as long as needed to reply.

Subprocessors

• Vercel — static site hosting for mydaisy.io.
• Hugging Face — hosts the Whisper model files the app downloads on first use. No account or identifier is sent.
• Anthropic and OpenAI — only if you opt in by adding your own API key. The traffic is between your Mac and them; we are not in the path.
• Notion — only if you opt in by adding an integration token, same shape.

Google Calendar integration (optional)

This section exists to satisfy Google’s API Services User Data Policy disclosure requirements. Daisy’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Connecting Google Calendar is entirely optional — Daisy works fully without it, and Apple Calendar via EventKit covers the same use cases without involving Google.

Data accessed

When you connect Google Calendar, Daisy requests a single OAuth scope: https://www.googleapis.com/auth/calendar.readonly. This is read-only — Daisy can only see events, never create, modify or delete them. From the events Daisy reads, the following fields are used: event title, start and end time, location, description, organiser, and the email addresses of attendees the calendar API returns to you. No other Google services or APIs are accessed.

Data usage

Calendar event data is used only on your Mac, and only to power user-visible meeting features:

• Naming — the upcoming meeting’s title is used as the session title in your transcript.
• Auto-start / auto-stop — if you enable these in Settings, Daisy starts and stops recording at the event’s start and end times.
• Attendee prefill — attendee email addresses are written into the local transcript file as session metadata, and the dominant external email domain is used to auto-suggest a free-form “tag” for filtering sessions in your local library (e.g. acme.com attendees → suggested tag “Acme”).
• Menu-bar “next meeting” — optional, off by default; shows the next event’s title in the macOS menu bar.

Calendar data is never used to train any AI or ML models — generalised or otherwise. Daisy does not run analytics, profiling, advertising, or any kind of automated decision-making on Google user data.

Data sharing

Daisy does not shareGoogle user data with any third party. The OAuth flow runs entirely between your Mac and Google’s servers; Daisy doesn’t operate any backend that touches calendar data. We are not in the path. Calendar data does not leave your Mac except for the original request to Google’s own API that fetched it.

If you later use a bring-your-own-key AI summariser (Anthropic or OpenAI), only the transcript you ask to be summarised is sent — and that’s the transcript text you produced, not raw calendar fields. Even there, no calendar metadata is forwarded to those providers as a standalone payload.

Data storage and protection

OAuth refresh and access tokens are stored in the macOS Keychain on your Mac — system-grade encryption at rest, hardware-backed on Apple Silicon, isolated to your user account. No tokens are stored on any server. Calendar event data is fetched on demand when the app needs it (when arming auto-start, when starting a session, when refreshing the Home view); the only persisted copy of any event field ends up in the local transcript file’s YAML frontmatter inside the sessions folder you picked — which means it’s protected by your macOS user-account isolation and any FileVault encryption you have enabled, the same as the rest of your local files.

Data retention and deletion

Refresh tokens are kept in the Keychain until you disconnect the integration. To disconnect at any time: open Daisy → Connections → Calendar → Google → Disconnect. That revokes the token with Google’s OAuth endpoint and removes the Keychain entry — no leftover credentials remain. You can additionally revoke Daisy’s access from myaccount.google.com/permissions.

Calendar event fields that ended up inside transcripts (titles, attendees, times) live as long as you keep the transcript file. To delete them, delete the session in Daisy’s Library tab, or remove the file from your sessions folder in Finder. Because Daisy stores nothing on our servers, there is no separate “contact us to delete your data” process for calendar data — you delete the files and the data is gone.

Questions or deletion requests: essazanov@pm.me.

Your rights

Because Daisy stores your recordings and transcripts on your own Mac and not on our servers, deleting them is a matter of deleting the folder from inside the app or in Finder. For the minimal personal data we do hold (your email if you wrote to us), reply to your own thread and ask us to delete it — we will.

Changes

If this policy changes in a way that affects what we collect, we’ll bump the “Last updated” date below and, for anything material, note it on the landing page.