NimbleCal is built to keep your calendar private by default.
What NimbleCal encrypts
NimbleCal encrypts your calendar content on your devices before storage or sync. This is end-to-end encryption (E2EE): your devices hold the keys needed to read event content, and those keys do not leave your devices in plaintext.
For encrypted calendar records, the providers involved in encrypted calendar storage and sync receive ciphertext plus the limited metadata needed to operate the service, not plaintext event titles, descriptions, notes, or locations.
See: Encryption overview
What NimbleCal still needs to store
Even with E2EE, a calendar app still needs some non-content data to function.
Examples of data that can exist outside the encrypted event payload:
- Account data (like your email address)
- Billing/subscription status
- Limited sync metadata (for example, timestamps used for conflict resolution)
- Reminder scheduling timestamps, which NimbleCal stores outside encrypted event blobs so reminders can be delivered
- Short-lived hashed signup-proof records used to block automated account creation
Signup abuse protection
Account signup currently uses Friendly Captcha plus a NimbleCal-issued signup proof.
- The browser loads the Friendly Captcha widget on the signup form.
- For current details on how Friendly Captcha handles end-user data, see the Friendly Captcha Privacy Policy for End Users.
- When you submit signup, NimbleCal verifies the challenge on its own server path before it asks Supabase Auth to create the account.
- NimbleCal does not store the raw captcha response. It keeps hashed proof records, limited verification metadata, and related timestamps needed to enforce the signup boundary and support incident review. See the Privacy Policy for the current retention details.
This captcha flow currently applies to account signup.
Crash reports
Crash reports are on by default when this feature is available. When enabled, NimbleCal can send a small operational diagnostic report for unexpected client-side errors, such as startup errors, unhandled exceptions, or database errors. These are operational diagnostics, not product analytics.
Included:
- Build version
- A general route area like
/calendaror/settings(/otherfor everything else) - General browser and operating-system family
- Online/offline state
- Error details
Excluded:
- Event titles, descriptions, notes, and locations
- Email addresses
- Invite links
- Full query strings
- Account IDs
- Session replay
- Product analytics data
You can turn crash reports off in Settings. This setting applies only to that browser. Sentry is configured to store crash report data in the EU, IP address storage is disabled in that project configuration, and this path is used only for error monitoring.
Invites: what gets shared
When you send an Email invite, NimbleCal stores recipient email addresses for delivery, plus the invitation details the recipient needs to understand the invite and RSVP. This is the current exception to the end-to-end encrypted calendar storage and sync model.
That summary includes the event title, start/end time, timezone, organizer name/email, optional organizer message, and any event location or description. Those details are separate from the end-to-end encrypted calendar storage and sync model. Email invite details are accessible to anyone with the invite link, so keep invite links private.
See:
ICS import and export
ICS import/export is a compatibility feature, not the same thing as encrypted sync.
An .ics file is plain text while it is stored, downloaded, uploaded, emailed, or shared outside NimbleCal. After you import one, the events inside NimbleCal use the app's end-to-end encrypted storage and sync model. Exported .ics files remain plain text, so anyone with access to the file can read the event details inside it.
See:
Quick Add privacy
Quick Add parsing runs fully on-device:
- The text you type is not sent to NimbleCal servers.
- The text you type is not shared with third-party AI APIs.