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.

End-to-end encryption, and what it does not cover

Every account holds a private key set derived on your device from your password during sign-in, using OPAQUE. The value it is derived from never reaches the service, so the server cannot reconstruct these keys. They are stored only in a form already encrypted by your device.

A calendar can be marked end-to-end encrypted. On such a calendar, the title, description, location, link, and conferencing URLs of each event are encrypted on your device before upload, as are messages posted in that event's chat. The service stores ciphertext it cannot read, and cannot read that content for any purpose, including support, analytics, or a lawful request.

Space chat can be marked end-to-end encrypted by a space owner, in which case message text is encrypted on each device and the service cannot read it. Event chat inherits the encryption of the calendar its event belongs to. Lists, polls, checklists, and space names remain encrypted at rest with keys the service holds.

External attendee email addresses are never end-to-end encrypted, even on an encrypted calendar. The service has to read an address in order to send an invitation to it. If that matters for a given event, invite people through their Whenary account instead of by email address.

The owner of an encrypted calendar or space can rotate its key, which re-encrypts existing content and re-shares the new key only with the people they keep. Rotation controls access from that point forward. It cannot retract content that someone with prior access already read or copied.

Timing is not encrypted, even on an encrypted calendar. Start and end times, time zone, recurrence rules, excluded dates, colors, attendee IDs, and RSVP status stay readable to the service so reminders fire on schedule, availability works, and date queries stay fast. Reminders for an encrypted calendar are delivered with a generic server-side title. On capable devices (iOS with a Notification Service Extension, or web with a service worker and a locally stored key), the on-device software replaces the generic title with the real event title before display. The server never sees what title was shown. Anyone observing the service can tell that you have an event at a given time, but not what it is.

Turning on end-to-end encryption for a calendar disables features that require the server to read content: CalDAV access, ICS subscription links, two-way sync with external providers, public event links, the public directory, and friend calendar sharing. This is enforced by the service, not left to the interface.

Calendars without end-to-end encryption remain protected by application-level encryption at rest, but the service holds those keys and decrypts content in memory for permissions, search, reminders, notifications, guest links, imports, exports, realtime updates, and collaboration.

If you forget your password and cannot supply your recovery phrase, content on end-to-end encrypted calendars is permanently unrecoverable. The service has no copy of the keys and cannot restore that content for you. This is a consequence of the design, not an operational limitation.

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.

Optional third-party reference data

• Public holidays, location search, weather chips, and inline maps are disabled or contextual unless you enable or trigger them.
• Holiday lookups require authentication. Your chosen country code is read from stored account preferences on the server. The upstream holiday provider receives only the country and year through Whenary infrastructure, not your username or calendar content.
• Location search and weather requests are proxied through the API when you use those features.
• Inline event maps load CARTO basemap tiles (and may fall back to an OpenStreetMap embed) directly from your browser when you view an event with stored coordinates.

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, end-to-end encrypted push reminders with on-device title decryption for encrypted calendars (iOS NSE via Keychain, web service worker via IndexedDB), 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.