Privacy policy

Last updated 14 September 2026

Who we are

CamyCal is operated by Campbell Ehsman, trading as CamyCal, based in Queensland, Australia. We are the controller of the personal information described here. You can reach us about anything on this page at [email protected].

The short version

Your events, notes and calendar details are encrypted on your device before they are sent to us. We store the result, and we cannot read it. What we can read is much less interesting, and it is listed in full below rather than summarised — because "we can't read your data" is only a meaningful sentence if you know what sits beside it.

What we cannot read

Calendar names, descriptions and colours.
Custom field definitions — the extra fields your group adds to events.
Event and note contents: titles, times, locations, notes, and anything else you type into them.
Your passphrase. It is never sent to us, and the keys derived from it exist only on your device. We hold a hash of one half of that derivation, which lets us check a sign-in and cannot be turned back into your key.

What we can read

This is the complete list, written from the database rather than from memory.

Your email address, and when you signed up. It is stored in the clear, because it is the name of your account.
Your key-derivation settings — the algorithm, the salt, and the memory and time cost used to turn your passphrase into a key. These are not secrets: they have to be readable so the cost can be raised later without locking anyone out.
A hash of your sign-in verifier. We can check it; it does not reveal your passphrase or your encryption key.
Session records — a hash of the session token (not the token itself), when it was created, and when it expires. Sessions last 30 days.
Which calendars you belong to, your role in each, and when you joined. Membership is not encrypted, because the server has to check it on every request.
How much is in each calendar, and when it last changed. We can count your events and notes, see their timestamps and their approximate size, and tell when one is edited or deleted. We cannot see what any of them say.
Who tagged whom. When someone tags you, we record the calendar, whether it was an event or a note, the internal identifier of that record, both account identifiers, and the time — in the clear, so we can send the notification email. The identifier is an opaque string of characters, not a title.
Connection requests you send and receive — when one was made, when it was answered, and whether it was accepted. We store a keyed hash of the email address a request was aimed at rather than the address itself, so a copy of the database does not yield a list of who asked to connect with whom. Note that the person receiving your request does see your email address: they have to know who is asking, and there is no shared secret yet to show them instead. A declined request still reads as pending to whoever sent it, so declining does not tell them anything about you.
Who you are connected to — both account identifiers and the date the connection was made. A connection is what a calendar can be shared with, so this is the social graph as far as this service is concerned.
Your identity public key — a public key, stored in the clear, which is what a calendar key or a conversation key is sealed to when somebody shares something with you. It is a public half by design and is useless without the private half, which never leaves your device unencrypted.
Your conversations, and when they were last read — who is in a conversation with you, how many messages it holds, their sizes, their timestamps and their order. The messages themselves are encrypted, and so is your read marker: we hold it as an opaque value and cannot tell how far through a conversation you are, only that it changed.
Your notification preference — whether you want an email when you are tagged.
Your IP address, in a short-lived counter used to rate-limit sign-in attempts. When you sign in or try to recover an account, we store a counter keyed by your IP address and the email address you typed, so that repeated guesses can be slowed down. That is a security measure, and it is genuinely the least flattering item on this list — an IP address is personal information, and it sits next to an email address. The counters are recorded only on those endpoints, they hold a count and a time rather than a history, and they are not used for anything else. They are not currently swept on a schedule, so a counter for an address that never returns can persist longer than its window; that is a known gap and it is written down here rather than left out.

Why we are allowed to hold it

To perform our contract with you — running your account, storing your encrypted data, sharing it with the people you have shared a calendar with, and sending invitations.
Our legitimate interests — keeping the service secure and working: rate-limiting sign-in attempts, preventing abuse, and diagnosing faults. Tag notification emails are sent on this basis too, because they tell you that somebody has done something to a calendar you are in. You can turn them off in settings at any time.
To comply with the law, where a legal obligation applies to us.

We do not sell your information, we do not share it for advertising, and we do not use it to train anything. We do not make automated decisions about you, and we do not profile you.

Cookies and tracking

There is one cookie. It holds your session, it is set when you sign in, it lasts 30 days, and it is marked HttpOnly and SameSite=Lax so that scripts in the page cannot read it. It is strictly necessary to keep you signed in, which is why there is no cookie banner.

There is no analytics, no advertising script, no tracking pixel, and no third-party anything. The site loads no fonts, scripts or images from another company's servers — the content security policy forbids it, which is a stronger statement than a promise, because it is enforced by your browser rather than by us. There is no geolocation script either: choosing which currency to display uses a country header that our CDN already sends with the request, and nothing is stored or logged from it.

Who else is involved

Three companies process data on our behalf. Each is bound by a data processing agreement, and none of them is given access to your decrypted content — because there is no decrypted content on the server to give.

Fly.io — hosts the application and stores the database. The volume is in the Sydney, Australia region.
Cloudflare — sits in front of the site for DNS and protection, and terminates TLS. Like any proxy it sees the traffic it forwards, which it cannot read beyond the usual metadata.
Resend — sends the notification email when you are tagged. It receives the recipient's email address and the contents of that email, which contain no calendar data at all: no event title, no note text, no calendar name, and not the name of the person who tagged you. It says only that something in CamyCal needs your attention, and links to the app.
Your payment provider, once paid plans exist. Not built yet, so nothing is named here and no card details are collected today. When it is, the provider will be named in this list, and it will hold your card details directly — we will never see a card number.

We will also disclose information if the law requires it. Because the content is encrypted, what we could hand over is limited to the list above: an email address, membership of a calendar, and the fact that somebody was tagged — not what any of it says. Note that the operator of this service is one person in Australia, and a lawful request directed at them is a request they must answer.

What the server can never read

Nothing you put in a calendar. Your events, notes, field values and calendar names are encrypted on your device before they are sent, and the keys are derived from your passphrase and never transmitted — so the machine that stores your data is holding blobs it has no way to open.

This paragraph used to be about the iOS Calendar feed, which was the one exception: it had to be decrypted on the server to be rendered as a calendar file, and this page said so. That feature has been removed. There is now no request this service can answer by decrypting anything, and that is a stronger statement than the one it replaces.

Where your data is held

The database is stored in Sydney, Australia. Our providers operate globally, so data may also be processed in the United States and the European Union — for example, when a notification email is delivered. Where personal information is transferred out of the EEA, the UK or Switzerland, that transfer is covered by the data processing terms of the provider concerned, which incorporate the European Commission's standard contractual clauses. If you need the detail of any of those arrangements, ask us and we will send it.

How long we keep it

Sessions expire 30 days after sign-in, and are deleted when you sign out.
Your email address and your encrypted calendars stay until you ask us to close the account.
Rate-limit counters are overwritten as their window rolls over; see the caveat in the list above.
A tagged-mention record is kept while the calendar exists, so that the notification is not sent twice.

Your rights

You can ask us for a copy of the personal information we hold about you, ask us to correct it, ask us to delete it, or ask us to restrict what we do with it. You can also object to processing we do on the basis of our legitimate interests. Email [email protected] and we will respond within 30 days.

Two honest caveats, both of which follow from the design rather than from policy:

What we can hand over is limited. We can give you your ciphertext and the account information listed above. We cannot give you readable copies of your events, because we do not have them — your passphrase does. There is no export button and no self-service download of everything at once; both are worth having and neither exists yet.
Deleting your account does not reach copies you already have. Anything you have already opened or saved on a device of your own keeps working until you delete it yourself.

Closing your account

There is no self-service delete button yet. We are being straight with you about that rather than describing a feature that does not exist. Email [email protected] from the address on your account and ask, and we will delete your account and its encrypted content by hand. If you are the only member of a calendar, that calendar goes with it.

Deletion is permanent, and it is unrecoverable in both directions: once the ciphertext is gone, nobody can reconstruct it — including you, even with your passphrase.

Security

Content is encrypted on your device with AES-GCM before it is sent, and keys are derived from your passphrase with Argon2id. Traffic is encrypted in transit. Sign-in attempts are rate-limited and the service does not reveal whether an email address has an account. There is no third-party script on any page, and the content security policy is the reason that is enforceable rather than merely intended.

No system is perfect, and this one has known limits — the threat model is published in the project's repository and lists them, including what someone who can read the server's memory during a request could see, and what the metadata around your ciphertext still gives away. We would rather you read it and decide for yourself than take a paragraph of reassurance on trust.

Children

CamyCal is not intended for children under 16, and we do not knowingly hold their personal information. If you believe a child has created an account, email [email protected] and we will close it.

Changes to this policy

The date at the top changes when this page does. If a change is significant — a new sub-processor, or a new category of information — we will tell account holders by email before it takes effect.

Complaints

Tell us first at [email protected], and we will try to fix it. If you are not satisfied, you can complain to the Office of the Australian Information Commissioner at oaic.gov.au, or — if you are in the EU, the UK or Switzerland — to the data protection authority in your own country. Neither route requires you to come to us first.