What mdash reads, and what it does with it.

mdash is a private household dashboard. It reads the calendars and rings the people in a household connect, and shows them one shared view of the day. It is not advertising-supported, and nothing here is sold or used to target advertising.

To do that it sends some of what it reads to other companies — a model provider to write the prose, a mail provider to send you a sign-in link, an analytics provider to count what happens. Every one of them is named below, with what it receives and why. If you only want the answer to one question, it is probably who receives your Google Calendar data.

Everyone in a household signs in as themselves and connects their own accounts. Nobody connects an account on someone else’s behalf, and nobody can see another person’s data except through the household views described below.

Google Calendar data

With your permission mdash requests one scope, calendar.readonly, and no other. Signing in to mdash is a separate thing, by emailed link, and does not use Google.

• Which calendar. The primary calendar of each Google account you connect. There is no per-calendar picker — connecting an account connects that account’s primary calendar, and nothing else.
• What is read. For each event: title, description, location, start and end times, all-day flag, busy or free status, cancellation status, and the recurrence identifiers that let a repeating event be recognised across syncs. Also the organiser’s email address and each attendee’s email address with their response. Also the email address of the Google account itself, so the connection can be labelled on screen.
• What is stored. A normalised copy of those events in mdash’s own database, so a screen can be drawn without calling Google on every view: title, description, location, times, all-day flag and busy status. Attendee addresses arenot stored as addresses — each is replaced by a one-way SHA-256 hash, which is how attendance is counted without keeping the list. We do not call that anonymisation: a hash of an email address can be reversed by anyone willing to guess addresses, and mdash’s own code says so where the hashing happens. The Google account’s email address is stored in plain text as the connection’s label. Access and refresh tokens are stored encrypted.
• What the description is for. Nothing, today. It is stored and then read by no screen, no prose, and no connected tool. It is kept because a calendar description is where a school puts the detail a title leaves out, and dropping it at sync time would mean re-reading your whole calendar the day that becomes useful.
• What is never done. mdash never writes to a calendar. It does not create, move, or delete events, and it does not read calendars you have not connected.
• Who sees it inside your household. Every member, and nobody outside it. There is no per-person visibility setting: a calendar you connect is contributed to the household’s shared view, and disconnecting it is how you take it back.

Who receives your Google Calendar data

Two service providers, and one more only if you connect it. This is the complete list.

• Anthropic — receives event titles, times and locations to generate your household’s daily briefing, advice and meal plan. It does not receive event descriptions or attendee addresses. Anthropic processes this data to return those results and does not train models on it.
• Fly.io — provides the hosting and the managed PostgreSQL database in which mdash stores your normalised calendar events, in the United States.
• An AI assistant you connect — receives the household data it requests, and only if you create a connection key and enter it into that assistant. Described under Connecting an assistant below. If you create no key, no assistant receives anything.

Google Calendar data is not sent to any other third party. mdash’s product analytics provider, Amplitude, receives counts, identifiers and yes-or-no answers from a fixed list held in the code; that list contains no calendar field, and calendar content is not sent to it.

The model provider

mdash uses Anthropic’s API to turn what it has read into sentences. This is the largest single recipient of household data, and it is worth being exact about which parts of the product send what.

• Your daily briefing and your advice. First names, ages, event titles, event times, event locations, task titles, dependants’ names, text about who is away, any unsettled scheduling conflicts, and — if a ring is connected — sleep, readiness and capacity numbers. This is the path by which Google Calendar data reaches Anthropic.
• Meal planning. Every member by name with their age, whether they are a child, allergies, food dislikes, likes, cooking skill, any free-text note the household has written, who is cooking and who is away each evening, and the titles of calendar events that affect the evening. This also carries Google Calendar titles.
• Shopping consolidation. Item names and quantities. No calendar data.
• Reading photographs and pages. Photographs or PDFs of recipes, school handouts, school calendars and receipts that you upload, and the text of a recipe page you point mdash at. No calendar data.

Anthropic’s commercial terms state that Anthropic may not train models on customer content submitted through its API, and that API inputs and outputs are deleted within thirty days of receipt or generation, subject to the exceptions those terms set out. mdash sends no household identifier with these requests — the identifier is deliberately withheld at the point the text is assembled. See Anthropic’s commercial terms.

Connecting an assistant

mdash can be connected to an AI assistant that supports the Model Context Protocol, so you can ask about your household from inside it. This is off unless you turn it on: you create a key in Settings and paste it into the assistant yourself.

If you do this, understand what it means. The assistant’s servers can then read your household — event titles, times and locations, the names of schools and carers, children’s birthdays, ring readings, shopping items and task titles — and can also make changes, including adding tasks and shopping items. The data it reads goes to whoever operates that assistant under their privacy policy, not this one. If you paste the key into Claude, that operator is Anthropic. Deleting the key in Settings ends the access.

Oura data

If you connect a ring, mdash requests one of Oura’s eight scopes — daily, covering the sleep, activity and readiness summaries for a day. It does not request the continuous heart-rate series, which is the most sensitive thing a ring exposes, and it does not request your Oura email address. What a connected ring reports is visible to everyone in your household. That is deliberate rather than an oversight: mdash manages a household, and a reading only one person can see cannot move a dinner or a week. There is no per-person visibility setting. Nobody can connect a ring on your behalf, so connecting one is the sharing decision — and disconnecting it is how you take it back. Sleep, readiness and capacity numbers are sent to Anthropic as part of your advice, as described above.

Baby monitors

Nanit has no OAuth, so connecting one means giving mdash the email address and password of your Nanit account, which are sent to Nanit to obtain a token. The password is never written to the database; it is held in an encrypted, browser-only cookie for ten minutes while the two-step sign-in completes, and then it is gone. mdash reads your children’s names and the sleep event log. It does not read video or audio.

Calendar feeds and recipes

A published ICS calendar is fetched by URL and needs no account. Be aware that some feed URLs are themselves the credential — a Google “secret address in iCal format” is one — and that fetching a feed necessarily sends its URL to whoever publishes it. mdash stores feed URLs encrypted.

Recipes you import are fetched from the page you point at, which means that website receives a request from mdash’s server. Photographs you upload are stored in object storage operated by Tigris, which is globally distributed rather than pinned to one region; the stored file name contains your household’s internal identifier and nothing else about you.

Shopping

When you search for a product, the words you type, the barcode if you scan one, your household’s five-digit postal code and your chosen store are sent to Kroger to look up the product and its price. No name, email address or account identifier is sent with it.

Product photographs on that screen are loaded by your browser directly from Kroger’s image servers, which means Kroger can see your device’s IP address when the shopping screen is open. mdash does not proxy those images today. If that matters to you, the shopping screen is the one to avoid.

Sign-in

Signing in is a link sent to your email address, delivered by Resend. mdash stores that address, a session record, and nothing else about your identity. There is no password to reuse or leak. Signing in and connecting a calendar are separate decisions, and either can be undone without the other. Invitations reuse the same mechanism.

Product analytics

mdash records what happens in the product — a sign-in link requested, a calendar connected, a recipe imported — and sends those events to Amplitude. What may be sent is a fixed list held in the code: counts, yes-or-no answers and identifiers. The list contains no calendar field.

The browser also reports which screens are opened and where a press gets no response. Automatic capture of on-screen text is restricted to elements marked for it in the code, and text drawn from those elements is removed before any event is sent.

Where the data is held

The application and its database run on Fly.io, in its Northern California region. The database is Fly’s managed Postgres. Uploaded photographs are held by Tigris, which is globally distributed. Everything is served only over HTTPS, and OAuth tokens are encrypted at rest.

Disconnecting, and deletion

Disconnecting a calendar or a ring revokes the grant with the provider directly, not only in mdash — so the app stops appearing in your Google or Oura account permissions rather than lingering there with access you believe you removed. The stored data for that connection is deleted at the same time.

To delete your account and everything associated with it, ask the person who administers your household, or write to the address below. Removing a member from a household revokes their sessions server-side immediately. Deleting a household is immediate and permanent: there is no export and no recovery period.

Retention

mdash keeps a moving window of your calendar: roughly the last thirty days and the next ninety, with all-day events carried up to a year ahead so that a school year entered in August is still there in June. Events inside that window are replaced on each sync.

Events that fall outside that window are not deleted on a schedule. To remove stored calendar data, disconnect the calendar, which deletes that connection’s events, or delete the household, which deletes everything mdash holds for it.

Changes, and getting in touch

If this policy changes in a way that affects what is read or who can see it, the date at the top changes and the change is described here.

13 October 2026. Operational alerts about a failing calendar connection no longer contain the connected Google account’s address or any part of a Google API response; they identify the person by first name and the connection by its internal identifier. Amplitude is no longer sent member email addresses or household names. Added mdash’s statements on Limited Use and on AI and machine-learning model training.

27 September 2026. Named every service provider that receives household data, and corrected the description of what is read from Google Calendar to include the event description and attendee addresses.

29 August 2026. Corrected the Oura section: a connected ring’s readings are visible to the whole household, and no per-person setting has ever existed.

Questions about any of the above go to alyssa.rae.fox@gmail.com.