Privacy policy

What is accessed

Only what you connect, and only after you agree on Google's or Microsoft's own sign-in page.

A Google account. The scopes requested are:

• openid and email — to confirm which Google account it is
• calendar.readonly — to read your calendars, their events and their timezone, so seeCal can show your day and work out when you are free
• calendar.events — to answer an invitation, or to add an event such as a block for travel, only when you ask for it or approve it in the app

A Microsoft 365 or Outlook account. The scopes requested are:

• User.Read — to confirm which account it is
• Calendars.ReadWrite — to read your calendar, and to add a block to it only after you accept it. A block says "Busy" or names your own travel or prep, is marked private, and never invites anyone.
• Calendars.Read.Shared — to read calendars someone has shared with you, if you switch them on
• offline_access — to keep the connection without signing in again each hour

seeCal also reads public calendar feeds you choose, such as public holidays, over their published web addresses. Those involve no account and no sign-in, and no calendar content is ever sent to them.

Your calendars

When you connect an account, Google or Microsoft gives ccal a credential (a refresh token). ccal keeps it, encrypted as described under "How it is protected", so it can keep your day current while your devices are asleep. Your devices hold only your seeCal session, in your own iCloud Keychain, never the calendar credential.

For the calendars you switch on, ccal reads your events up to two months ahead and, once when you connect, up to six months back, and stores, for each: title, start and end time, timezone, location, attendees, organiser, response status, any joining link, the description, and what ccal has worked out about an event, such as whether it is in person. It also stores the choices you make in seeCal: which calendars are on, an account's name, colour and side, your Home, and the suggestions and proposals seeCal has made and how you answered them. All of it is keyed to you, and none of it is visible to anyone else who uses seeCal.

The Apple Watch app holds no credential. The iPhone sends it a summary of today and tomorrow, and the watch face hides work titles while your wrist is down.

A calendar file you import is read by ccal once, and its events are kept like any calendar's until you remove it.

If you forward an email to seeCal's own address to add an event, ccal reads the event out of it, keeps the event and what it needs to answer, and deletes the email within 30 days.

What seeCal learns about you

seeCal gets better for you by noticing what you do. Everything it learns is kept for you alone, shown in seeCal under Settings › What seeCal knows, where you can put it right or have it forgotten, and deleted with the rest of your data.

• What you do. When you answer an invitation, cancel, move or rename a meeting, end one early, run over, put a card off or pick a time Help me with offered, ccal keeps that it happened and the shape of the event: how long it is, when in the day and week, how many people are on it, whether it has a place or a call link, and whether it repeats. Never its title, its people or its place. It keeps these for two years.
• Words. From the titles of your events, work ones included, it learns what words mean, such as that "Uber" is travel, and keeps the word and what it means. A word from a work calendar is never shared with anyone.
• A shared word list. A word learnt from personal calendars helps everyone only once at least three people's calendars agree on it, and the shared list holds the word and what it means, never who it came from.
• When you meet. From the meetings you organise and the times you pick, it learns which days and hours suit you, and says so only once that has held for several weeks.

None of this is advertising or profiling, none of it leaves seeCal, and none of it is sold or shared beyond the shared word list.

How it is protected

• In transit. Every connection to ccal, and from ccal to Google, Microsoft, Apple and Cloudflare, uses HTTPS (TLS). Nothing is served over plain HTTP.
• At rest. Data is stored in Cloudflare's D1 database, which encrypts it at rest. Calendar credentials are encrypted a second time by ccal: each person has their own random 256-bit key, which encrypts their credentials with AES-256-GCM and is itself stored only encrypted by a master key. The master key exists only as a secret in the service's runtime and in the operator's password manager, never in the database, the code or a log, and it can be rotated without anyone reconnecting.
• Bound to its owner. Every encrypted credential is tied to its person and account, so a stored row moved onto anyone else will not decrypt.
• Isolation between people. Every stored row and every query is scoped to one person. Automated tests sign in as one person and fail on any trace of another's data, on every route.
• Sessions and keys. Sign-in uses Google's or Microsoft's own sign-in with PKCE; seeCal has no password of its own. Session tokens and app keys are stored only as SHA-256 hashes, never the tokens themselves. Sessions expire, and signing out ends them on the server.
• Least access. seeCal asks only for the scopes listed above. The operator's other apps that query ccal get the narrowest access their job needs, most only busy and free periods.
• Limits and logs. Sign-in and requests are rate-limited. Logs record errors, not calendar content: addresses and anything shaped like a token are removed before an error is stored.
• Administration. Only the operator can administer the service. Its keys and secrets are held in a password manager and as runtime secrets, and every change to the service goes through reviewed, automatically tested deployments.
• If something goes wrong. If personal data is ever exposed, the people affected, and the data protection authority where the law requires it, are told without undue delay.

Language models

Only if your seeCal includes its AI features does ccal show anything to a language model, and only for these jobs:

• What a meeting needs. One upcoming event at a time: its title, time, location, organiser and attendees, and the start of its description, to suggest time to travel or prepare.
• An email you forward, or something you choose to add (a screenshot, a photo, a web page or pasted text), to read the event out of it. What you add is read and not kept.
• A short title for a long one: the title alone.
• An emoji for a title nothing else matched: the title, with the names and addresses of everyone on the event taken out.
• A word seeCal cannot place: one or two words from a title, with everyone's names taken out, and how those events usually look (how long, when, whether they have a place or guests). Never the title, a time or a person.

The answer is stored with the event or the word; what was shown is not kept.

• Which models. Open models run by Cloudflare Workers AI on the operator's own Cloudflare account (Workers Paid plan). Nothing is sent to OpenAI, Anthropic, Google or any other AI provider, and the service is configured so that it cannot be.
• How it gets there. Through foundry, a gateway the operator runs himself on Cloudflare. It forwards the request and records only its size, timing and outcome, never its content.
• No training. Cloudflare does not use what Workers AI processes to train AI models, and does not keep inputs or outputs once the request is answered. Google user data is never used, by seeCal or anyone it passes it to, to develop, improve or train any AI or machine-learning model.

If no model is available, ccal falls back to its own rules; nothing depends on one.

The operator's own calendars

Conor Winders's other apps may ask ccal when he is free, each granted the narrowest access its job needs. Most receive only busy and free periods, never event details. This applies only to his calendars; no app can ask about anyone else's.

Who else handles it

• Google and Microsoft, which hold your calendars and which ccal asks on your behalf.
• Cloudflare, which hosts the service and its database, and runs the language model described above.
• Apple, through iCloud Keychain, which holds your seeCal session on your own devices, and Apple Maps, which is given an event's location (never its title, attendees or description) to time the journey there.

seeCal's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google user data is used only to show you your own calendar and act on it when you ask. It is not transferred to anyone else except as needed to provide that, to comply with the law, or with your consent, and no person reads it unless you ask for help with it. It is never used to develop, improve or train general-purpose AI or machine-learning models.

What is never done

• Calendar data is not sold, rented, or shared with any third party beyond the services named above, which handle it only to do seeCal's work.
• It is not used for advertising, profiling, or training machine-learning models. What seeCal learns about you, described above, is kept for you and used only to make seeCal better for you.
• There are no analytics, trackers or advertising networks on this site or in the apps.

The seeCal waitlist

If you join the seeCal waitlist, your sign-up is kept by launch, the private service that holds the waitlists for Conor Winders's apps, in a database of its own, separate from any calendar data. It keeps your email address, which of the devices you picked, when you joined, the country your connection came from, your browser's name, and the label of the link that brought you, if there was one. It is used to send you a welcome and to tell you when seeCal opens to more people. It is never shared or sold, and joining gives no access to anything here. To be removed, reply to any email from seeCal or write to the address under Contact, and it is deleted.

Retention and deletion

Your events, up to six months back, are kept while the account is connected, and no longer. Remove an account in seeCal's Settings and ccal revokes its access at Google and deletes the credential, its calendars and their events at once. You can also revoke access from your Google account permissions or Microsoft apps page.

To delete everything seeCal holds about you, write to the address under Contact. Your data is removed and your encryption key destroyed, so nothing left in a backup can be read. Deleting the app removes nothing from your calendars.

Contact

Questions about this policy, or a request to delete anything above: conor@seecal.today.