Security and Data Practices

Purpose

This page explains the practical security and privacy boundaries of the product. It is meant to make private coordination understandable without overstating what the system can guarantee.

For a fuller inventory of data categories and legal rights, see the Privacy Policy. For acceptable use and account rules, see the Terms of Service.

We design for user sovereignty: minimize what we collect, encrypt what we can while keeping the product usable, and avoid proactive content review. Compelled disclosure is described in the Privacy Policy under Legal requests and user protection.

What is encrypted

• Password registration, login, and reset use OPAQUE so the API receives protocol messages instead of the account password. The server stores an OPAQUE registration record, not plaintext passwords.
• TOTP secrets are encrypted at rest.
• BYOS access keys, secret keys, bucket, region, endpoint, and public base are encrypted at rest.
• Username, email, OIDC identity linkage, push subscription secrets, display names, space names, calendar names, event guest token labels, event titles, event descriptions, event locations, event URLs, event tags, event message bodies, space message bodies, list and checklist labels, poll text, guest RSVP text, photo captions, passkey labels, subscription and public-link labels, and similar user-authored strings are encrypted in the application before they are written to the database.
• Optional PGP public keys encrypt opted-in transactional email bodies before SMTP handoff.
• Session cookies are protected with server-side secrets and HttpOnly cookie settings.
• OIDC SSO, when enabled, links your account to an external identity provider under that provider's security model.
• Transport security depends on HTTPS being correctly configured for the service.

Sessions and sign-in history

Active sessions can be reviewed and revoked in Settings. Sign-in history records recent successful and failed sign-ins for your account only, using daily rotating network fingerprints instead of raw IP addresses or user-agent strings in product views.

What is not end-to-end encrypted

Calendars are not end-to-end encrypted. Many user-authored strings are protected from plain database snapshots by application-level encryption, but the server still holds the key and decrypts them in memory for permissions, search, reminders, notifications, guest links, imports, exports, realtime updates, and collaboration. Structured metadata such as dates, recurrence rules, attendee IDs, RSVP status, reminder timing, and poll vote structure may remain in forms the service needs to operate.

This is a deliberate product boundary: privacy is normalized through strong access controls, low telemetry, metadata reduction, database-useful ciphertext for selected text, and user-controlled storage options, not through a claim that the server cannot process application data.

Upload processing

Supported browsers may resize and re-encode images before upload. The server still validates uploads and may process them with Sharp when needed. Stored images omit camera metadata such as EXIF/GPS. The service does not intentionally keep the original unprocessed file.

This applies before the file is written to platform storage or qualifying BYOS storage.

BYOS boundary

BYOS lets a space owner place qualifying space media in their own S3-compatible bucket. This reduces dependence on platform storage and gives the space owner direct storage control.

BYOS is not end-to-end encryption. The application still authenticates users, receives uploads, strips metadata, resizes media, writes objects, stores object references, and serves URLs according to the configured storage model.

Paid plans and guest links

Personal Supporter is an optional tier with server-enforced higher limits and an opt-in public badge. Host Pro adds organizer tools such as multiple RSVP links per event and export. Status is not exposed to other users except the optional badge. Client-side theming and display preferences are not paywalled.

Custom guest RSVP paths require Personal Supporter or Host Pro. Paths use a reserved-word blocklist to reduce phishing and impersonation (for example admin, api, support, whenary) and cannot match an existing username. Slugs are leased to an active guest link, not permanently reserved. Bearer secret tokens and permission checks still apply. Professional host tools such as multiple links per event, export, custom link thumbnails, and guest update emails require Host Pro or the combined bundle.

Access controls

• Spaces use member roles.
• Calendars can be shared with different permissions inside a space.
• Personal calendars can be shared with accepted friends per direction and tier; friends see redacted schedule data only.
• Events have visibility settings such as public, busy, and private, with optional per-audience overrides for friend and public tiers.
• Public calendar links are bearer links and expose only public-tier, server-redacted events.
• Guest RSVP links are bearer links and should be treated as sensitive.
• ICS subscription tokens are bearer tokens and should be treated as sensitive.

Abuse prevention

• Global, auth, email, mutation, and upload rate limits protect the service.
• Friend requests and username discovery are rate-limited; public calendar reads have a dedicated limit.
• Audit logs record sensitive actions for accountability.
• Upload size limits, custom emoji limits, storage quotas, and BYOS-specific handling reduce file-hosting abuse.
• Session, CSRF, WebAuthn origin, CORS, and WebSocket origin checks reduce common web attack paths.
• The service does not depend on content recommendation, ranking, or engagement feeds to decide what users see.

Verifiability

Privacy and security claims should be testable from the deployed service. Production browser bundles may include frontend source maps so you can inspect client behavior in DevTools. Source maps should not contain secrets or user data. Browser developer tools, network inspection, response headers, cookie attributes, BYOS storage evidence, export files, and published service documentation can be used to verify key claims from observable product behavior.

The Security page includes a practical verification checklist for major privacy claims.

Platform administration

The service may expose a platform-owner dashboard to a tightly allowlisted set of operators (separate from space admin roles). It is used for site reliability, abuse response, billing, and security, not for advertising, engagement profiling, or voluntary intellectual-property enforcement. Operators with database access can decrypt application-encrypted fields because the server holds the key. Stronger client-side encryption (below) reduces reliance on operator discretion.

Path to stronger confidentiality

Today: OPAQUE passwords, encrypted identifiers, application-level encryption for many user-authored strings (events, messages, lists, polls, guest RSVP text, labels, and related fields), blind indexes, optional browser-side image preprocessing before upload, BYOS for media placement, generic Web Push, and minimal telemetry. The operator can still decrypt those fields and sees substantial metadata (times, attendees, relationships, reminders, poll structure, images during upload processing).

To approach true operator blindness while keeping multi-user calendars, the product would need major architectural work: client-side encryption keys (per user or per space) derived from credentials the server never learns; ciphertext-only storage for events, messages, and media; encrypted or client-side search indexes; key rotation and recovery flows; and likely reduced server-side features (server-side reminder text, ICS import parsing, and full-text search become client-only or use privacy-preserving techniques).

Further steps short of full E2E: optional user-held key mode where ENCRYPTION_KEY is absent for that user's vault; transparency logging for operator decrypt access; warrant canary on the marketing site.

Operational data

Operational records may include daily rotating network fingerprints, session times, audit actions, error logs, rate-limit counters, reminder dispatch records, sync status, and worker locks. Database session, audit, and guest RSVP rows do not intentionally retain raw IP addresses or raw user agents.

Retention and recovery

Users can export data and request or perform account deletion through product controls where available. Space retention controls can remove older chat and memory data. Backups are limited to disaster recovery. Backups, logs, caches, object storage versions, and provider systems may retain data for a limited period after deletion until normal rotation or cleanup completes.

Infrastructure providers

Provider choices and environment configuration are documented for the official service. Public promises should be read together with the provider list on the Privacy Policy.

Vulnerability reports

Please report suspected vulnerabilities to [email protected]. Include enough detail to reproduce the issue. Do not access, modify, delete, or disclose another person data while testing.