Privacy Policy

Overview

Whenary is built for private coordination: calendars, spaces, personal calendars, friend schedule sharing, event planning, memories, polls, lists, chat, guest RSVP links, public calendar links, and related scheduling tools. This Privacy Policy explains what information the service processes, why it is processed, who can see it, and what choices you have.

Our posture is user-sovereign: you choose what to share and with whom; we do not sell data, run ads, or proactively review your calendars for enforcement purposes. Where law requires action, we aim to comply narrowly, resist overbroad demands when we can, and protect you with technical minimization and transparency.

This policy applies to the Whenary service at whenary.com and related official domains.

Who operates the official service

The official Whenary service is operated by the project team behind whenary.com. For privacy requests, security reports, or questions about this policy, contact [email protected].

For the official hosted service, primary application data is stored on infrastructure located in Germany (European Union). Edge networking, DNS, and DDoS protection may involve providers that process connection metadata globally. Payment processors and email providers process data according to their own policies when you use those features.

Our privacy commitments

• We do not sell personal information.
• We do not run third-party advertising inside the product.
• We do not use behavioral advertising pixels or product analytics SDKs.
• We do not actively monitor, curate, edit, endorse, or algorithmically recommend user content, and we do not volunteer intellectual-property policing beyond what applicable law compels.
• We process your data to provide the service, protect accounts, prevent abuse, honor your settings, and comply with law only to the extent required.
• We are transparent about the difference between access-controlled privacy, bring-your-own storage, and end-to-end encryption.

Account and profile data

When you create or use an account, we process account identifiers and profile settings such as username, optional email address, display name, avatar, color, timezone, locale, week start, optional birthdate and birthday visibility, notification and quiet-hours preferences, account creation time, and account status. Username and email are encrypted at rest and searched through server-side blind indexes. Email is not required for username-and-password accounts, but password reset links require an email address.

We also process authentication data such as OPAQUE password registration records, session identifiers and last-activity times, CSRF secrets, failed-login counters, lockout state, password reset tokens for accounts with email, email verification tokens for accounts with email, passkey public keys and counters, TOTP enrollment state, encrypted TOTP secrets, recovery codes, and optional OIDC identity linkage when single sign-on is enabled.

You can review active sessions and your recent sign-in history (including failed attempts) in Settings. Sign-in history is visible only to your account and uses daily rotating network fingerprints rather than raw IP addresses or browser user-agent strings.

Registration may be open, invite-only, or closed depending on service settings. Invite codes and registration rate limits may be processed to control who can create accounts.

Space, calendar, and event data

The core service stores content you and your space members create: spaces, memberships, roles, invites, calendars, calendar shares, events, recurring-event rules, attendee lists, RSVP status, reminders, event visibility, optional per-audience visibility overrides, tags, locations, links, cover images, notes, checklists, polls, ranked ballots, availability responses, guest RSVP links, guest responses, and event history needed to operate the service.

Each account also has a personal space that backs its personal calendar. Group spaces remain for collaborative planning; the friend layer is primarily for comparing schedules.

Space names, calendar names, event guest token labels, event titles, descriptions, locations, URLs, and tags are encrypted before being written to the database and decrypted in server memory when needed. Display names and many other user-authored labels (lists, checklist items, poll text, guest RSVP names and notes, photo captions, and similar fields) use the same application-level encryption. Event visibility settings control how event details are shown inside the product, but event data is still processed by the server so reminders, calendars, permissions, search, sync, and collaboration can work.

Friends and public calendar links

You may add friends by username (exact match; this does not require a public profile page). If you turn on your public profile in Settings, anyone who knows your username can open a profile page (for example /u/yourname) showing your display name and avatar so they can send a friend request. New accounts start with this off. You may send a one-time email invitation to connect with someone who is not on Whenary yet; recipients can open your profile through that invite link even when your public profile page is off. We do not upload or scan your contact book. You may block or remove friends and choose whether to share your personal calendar with each friend at a tier such as friends or close friends. Sharing is per-direction: sharing your calendar with someone does not grant you access to theirs unless they share back.

Friend relationships, calendar-audience grants, and friendship status are stored as structured service data. When a friend can view your personal calendar, the server redacts each event according to your visibility and per-audience settings. Friend viewers do not receive your reminders or attendee lists through the friend-calendar path.

You may create revocable public calendar links that expose only events you mark visible to the public audience tier. Anyone with the link can view that redacted schedule until the link is revoked or expires. Public link tokens are opaque bearer values and do not embed user, calendar, or event identifiers in the URL.

Messages, reactions, lists, and collaboration content

Spaces and events can include chats, reactions, custom emojis, lists, checklist items, polls (including ranked-choice and availability polls), poll votes, captions, notes, and related metadata. Space and event message bodies and many other user-authored collaboration strings are encrypted before being written to the database and decrypted in server memory when delivered to authorized users. Collaboration content is visible to other users according to space, calendar, event, or guest-link permissions.

Custom emojis are scoped to a space. If a custom emoji is removed, related visual uses can be removed as part of lifecycle cleanup.

Personal Supporter accounts may access full per-event change history (field-level diffs) for events they are permitted to view; free accounts may see a short preview. History is stored to support accountability inside the product, not for advertising or profiling.

Realtime updates and presence

The service uses WebSockets and short-lived presence indicators so calendars, feeds, chats, and related views can update while you use the app. Presence and connection state are used to deliver realtime features, not to build engagement rankings or behavioral advertising profiles.

Guest RSVP links and public invite data

Event organizers can create RSVP links for people without accounts. Guests may provide a name, optional public display name, email, RSVP status, plus-one count, and note. Guests may optionally request one transactional email reminder about 24 hours before the event start; that requires an email address and uses the same invite link they used to RSVP. Guest-submitted name, alias, email, and note fields are encrypted at rest when stored. Guest contact matching is scoped to the event so the same guest details do not create one reusable cross-event identifier.

Guest links may reveal selected event details to anyone with the link. If guest-list visibility is enabled, attendees may see public guest names or aliases, RSVP status, and plus-one counts. Event administrators can see administrative RSVP details needed to manage the event.

Organizers may optionally choose a custom `/rsvp/{slug}` path per guest link when the account has Personal Supporter (Founders) or Host Pro. Paths are subject to format rules, a reserved-word blocklist, and availability checks (including paths that match an existing username). The slug is tied to that active link and is released when the link is deleted or revoked.

Organizers with Host Pro may set a custom link preview thumbnail for social and messaging apps. If unset, previews fall back to the event cover where available.

The service counts aggregate page views per guest link for hosts. These counts do not include guest names or other RSVP field content. Public RSVP pages may show optional, low-emphasis prompts to create a host account; registration from those pages may include a `ref=rsvp` parameter for product analytics only.

Accounts with Host Pro who change material event details (such as title, time, or location) may trigger one transactional email to guests who previously provided an email on that event, using the same invite link segment they used to RSVP, subject to monthly guest-email limits.

Organizers may optionally list an event on the public discover directory at /discover when the event is configured so the public calendar audience tier shows full details (not merely “shared with friends” or busy). Listing is off by default. Listed pages may include title, time, location, description, cover image, host display name, and an RSVP link when a vanity guest link exists. Events are not listed automatically when you create a guest RSVP link.

Uploads, photos, and media

The service can process avatars, event covers, event memories, custom emojis, and other image uploads. Supported browsers may resize and re-encode images before upload; the server still receives the file to validate dimensions and format, apply any needed server-side processing, and store the result.

When the server processes an image, it uses Sharp and stores the result without camera metadata such as EXIF/GPS. Raw and processed buffers are zeroed on a best-effort basis after processing and storage write. The original upload is temporarily present in server memory during processing and is not intentionally retained as the original file.

Stored media records may include file kind, MIME type, dimensions, size, storage key, storage provider, public base URL, uploader, space, event, caption, sort order, and creation time. Stored object keys are random root-level file names and do not intentionally include user IDs, space IDs, event IDs, or upload categories.

Bring Your Own Storage

Space owners may configure bring-your-own storage for space media. BYOS credentials and provider routing metadata such as bucket, region, endpoint, and public base are encrypted at rest using the server-side encryption key, and uploads for that space are written to the configured bucket when enabled.

BYOS changes where qualifying files are stored. It does not make the application end-to-end encrypted. The server still receives and processes uploads temporarily so privacy-preserving image processing, access checks, and storage dispatch can work.

If you use BYOS, your storage provider may process file names, object metadata, access logs, and object contents according to your account and provider settings.

Calendar imports, exports, and subscriptions

The service supports ICS import and export, token-only read-only subscription feeds, and external calendar subscriptions. Imported calendars and events become service data. Exported files can be opened by other applications, so you are responsible for where you store or share exports.

External subscription URLs, sync status, sync errors, ETags, and last-modified values may be stored to keep subscribed calendars current. Subscription fetches require HTTPS and reject local, private, link-local, multicast, and metadata IP ranges.

Notifications and communications

We process in-app notifications, reminder dispatch records, web push subscriptions, and email delivery information when those features are enabled. Push subscription endpoints and browser key material are encrypted at rest. Reminder Web Push payloads are encrypted by the Web Push protocol, padded, and generic so push providers do not receive event titles, locations, calendar names, or event IDs. Email delivery requires processing email addresses and message content needed to send account, reset, invite, guest RSVP reminders, optional Founders guest event-update notices (when material event details change), and other reminder messages. Users may add a PGP public key to encrypt email bodies before SMTP handoff.

You can change notification preferences in the app, although some security or account messages may still be sent when necessary.

Contact and feedback

You may contact us through the public contact page, by email, or by sending a PGP-encrypted message to our support key when published. In-app submissions let you choose anonymous delivery, an encrypted reply email, or linking the message to your signed-in account. Message bodies, optional reply addresses, and optional client-supplied PGP ciphertext are encrypted at rest. We use daily rotating network fingerprints for abuse prevention on contact submissions, not raw IP addresses or user agents shown to operators in the product UI.

If you enable a PGP public key on your account, we may send optional encrypted acknowledgments for contact messages you choose to tie to your account. That uses the same email encryption path as reminders and account mail.

Device, network, security, and operations data

To operate and protect the service, we process session data, request timing, rate-limit counters, audit logs, worker locks, realtime connection state, presence messages, error logs, and abuse-prevention metadata. Database session, audit, and guest RSVP records store daily rotating network fingerprints instead of raw IP addresses or raw user agents.

Audit logs can include user ID, space ID, action, target, metadata, daily network fingerprint, and time. They exist to protect spaces, investigate abuse, support account recovery, and maintain accountability for sensitive actions without keeping long-lived raw network identifiers.

Paid plans (Personal Supporter, Host Pro, and extras)

Whenary may offer optional paid plans on the official hosted service. Personal Supporter (sometimes called Founders) is stored as server-side account flags and limits; Host Pro and storage extras use separate server-enforced fields. Clients cannot set or spoof paid status.

Personal Supporter may include higher quotas and rate limits, additional custom emoji capacity for spaces you own, faster external calendar sync, more guest reminder emails per month, full per-event change history on events you can view, an opt-in public badge in chats and member lists when enabled, and an option to hide the small “Powered by” footer on public RSVP pages you host.

Host Pro is a separate organizer tier: multiple guest RSVP links per event (with separate labels), per-link RSVP view counts and export, structured guest questions, custom link preview thumbnails for guest RSVP pages, transactional emails to guests when material event details change (for guests who provided an email), and optional SMS reminders when configured. Custom RSVP paths per guest link require Personal Supporter or Host Pro, subject to the same reserved-word and availability rules.

Standalone extras include optional monthly storage packs and a combined Personal Supporter + Host Pro bundle at a discount versus buying both separately.

Any signed-in user may gift any listed plan to another account by username or open redeem code. The purchaser does not need to hold the plan themselves; the recipient receives the purchased plan after redeeming a valid paid gift.

Other users cannot query whether an account is a Personal Supporter unless that user chooses to show the badge. Appearance and client-side display preferences such as theme are not paywalled.

Payment processing (including cryptocurrency methods such as Bitcoin, Lightning, and Monero where enabled, and optional card processors such as Stripe) is not required to use the free product. When billing is enabled, we store order identifiers, plan type, payment status, subscription references where applicable, and provider metadata needed to grant, renew, or revoke access. Cryptocurrency checkout is limited to one-time plans; recurring monthly or yearly gifts require card checkout. Card checkout shares billing contact and payment metadata with the card processor.

Time-limited plans expire unless renewed according to the plan purchased. Lifetime and event-pass style plans run for the stated duration or for the life of the account where described on the Founders page. Gift purchases create a redeem code for the recipient after payment; the purchaser should share the code privately.

Cookies and local browser storage

The service uses strictly necessary cookies for sessions and CSRF protection. Session cookies are HttpOnly. CSRF cookies protect authenticated state-changing requests. We do not use cookies for third-party advertising or cross-site behavioral tracking.

The web app may use browser local storage or similar mechanisms for interface preferences, cached query data, service worker behavior, theme handling, and normal web app functionality. These are first-party, functional uses only.

Legal bases for processing (where required by law)

In jurisdictions that require a stated legal basis for processing, we rely on: performance of a contract (providing the service you signed up for); legitimate interests limited to security, abuse prevention, and operating infrastructure without overriding your rights; compliance with legal obligations when compulsory; and consent only where explicitly required (for example optional marketing, if ever offered separately).

We do not use automated decision-making that produces legal or similarly significant effects about you. The product does not rank, recommend, or monetize your content through engagement algorithms.

How we use information

• Provide calendars, spaces, reminders, chats, lists, polls, memories, guest RSVP links, realtime updates, and account features.
• Authenticate users and protect sessions, passkeys, TOTP, password resets, and recovery flows.
• Enforce permissions, visibility, invite, role, quota, and retention settings.
• Process uploads, remove image metadata, store media, and dispatch BYOS writes when configured.
• Send notifications, email, web push, and operational messages.
• Detect abuse, investigate security issues, rate-limit harmful activity, and keep audit trails without generally reviewing user content.
• Respond to compulsory legal process when required, in the narrowest form we can.

Legal requests and user protection

We are not a content reviewer. We do not search calendars, messages, or uploads for copyright, trademark, or other intellectual-property claims on our own initiative.

When we receive a legal demand (subpoena, court order, or similar compulsory process), we aim to: require valid jurisdiction and specificity; push back on overbroad or non-compulsory requests; produce the minimum data the order clearly requires; and notify affected users before disclosure when the law and the order allow it.

Voluntary third-party complaints (including intellectual-property notices) are not treated as orders. We may acknowledge receipt, but we do not remove or disclose user content based on a mere allegation unless we are legally obligated to do so or the complaint clearly involves non-consensual harm, malware, or other conduct covered in our Terms.

Because the service holds application encryption keys, we can decrypt certain stored fields when compelled. Technical design limits what we can access without keys and without operating the live product; see the Security page and the encryption assessment below. Stronger client-side encryption can reduce operator visibility further.

How information is shared

• With space members, calendar viewers, event attendees, and guests according to product permissions and settings.
• With friends you have accepted and who you have chosen to share your personal calendar with, at the tier and visibility you configure.
• With anyone who has a valid public calendar link you created, limited to public-tier event data.
• With guest-link visitors when an organizer creates or shares a public RSVP link.
• With infrastructure, storage, email, push, hosting, DNS, CDN, reverse proxy, backup, monitoring, and security providers needed to operate the configured service (see Subprocessors below for the official hosted service).
• With user-configured providers such as BYOS buckets, OIDC identity providers, external calendar hosts, and calendar clients that consume exported or subscription data.
• With a limited set of allowlisted platform operators who may access site-level administration tools only for abuse response, billing fulfillment, security, and reliability, not for browsing user calendars or enforcing intellectual property.
• With courts, regulators, or other parties only when compelled by valid legal process or when necessary to prevent imminent serious harm; see Legal requests and user protection.

Subprocessors (official hosted service)

The whenary.com service uses the following categories of subprocessors to run the product.

• Hosting and database: Hetzner Cloud (application servers and PostgreSQL in Germany).
• Edge, DNS, and tunnel: Cloudflare (connection metadata, DDoS protection, and secure ingress).
• Object storage: Cloudflare R2 or equivalent S3-compatible storage for platform uploads when configured.
• Cache and rate limiting: Redis on the same infrastructure.
• Transactional email: Resend or another SMTP provider when email is enabled.
• Web Push: browser push services (for example Google FCM or Mozilla autopush) receive encrypted, generic reminder payloads only.
• Payments (optional): BTCPay Server and/or Stripe when Founders billing is enabled.
• Identity (optional): your OIDC provider when SSO is enabled.

International data transfers

Primary account and calendar data for the official service is stored in the European Union. Some subprocessors (especially edge networks, email providers, payment processors, push services, and optional OIDC providers) may process data in other countries. Where required, we rely on appropriate safeguards such as standard contractual clauses, adequacy decisions, or equivalent mechanisms offered by those providers.

Retention, export, and deletion

The product includes data export and account deletion controls in Settings. Exports can include account, space, calendar, and event data available to your account. Account deletion hard-deletes the account record and account-linked product data that the service can remove, subject to ownership rules and legal obligations.

Spaces include retention controls for chat and memories. Deleted events you remove from your calendar are kept in trash for 30 days so you can restore them, then permanently removed from the primary database. Other deleted calendars, events, and messages may be hard-deleted sooner. Backups are for disaster recovery, not product lookup or long-term deleted-data retention. Deleted or expired content may remain briefly in backups, logs, caches, object storage, or provider systems until normal rotation or deletion completes.

If you are the sole owner of a space, you may need to transfer ownership or delete the space before deleting your account.

Security

Security controls include OPAQUE password authentication, server sessions, CSRF protection, HttpOnly cookies, WebAuthn origin checks, optional TOTP, encrypted sensitive secrets and metadata, blind-indexed account lookups, application-level encryption for selected event and message text, rate limits, audit logs, strict CSP, WebSocket origin checks, outbound subscription SSRF checks, and production startup checks for weak secrets.

No system is perfectly secure. You are responsible for keeping your account credentials safe, managing guest links carefully, choosing trusted space members, and securing any BYOS or external provider accounts you connect.

Children

The service is not directed to children under 13 or the minimum age required by your jurisdiction. Do not create an account or submit personal information if you are not old enough to consent to use the service.

Your choices and rights

Depending on where you live, you may have rights to access, correct, export, delete, restrict, or object to processing of personal information, and to data portability. You can exercise many controls in Settings (export, deletion, sharing, notifications, and security). For requests that cannot be completed in the app, contact us.

We may need to verify your identity and account authority before acting on a request. Some data may be retained when necessary for security, legal compliance, dispute resolution, backups, or legitimate operational needs.

If you are in the EEA or UK, you may lodge a complaint with your local supervisory authority. We encourage you to contact us first so we can try to resolve your concern.

California privacy notice (where applicable)

Where California law applies: we do not sell or share personal information for cross-context behavioral advertising. Categories we collect include identifiers, customer records (calendar and account content you provide), and internet or network activity (security and session metadata). We do not build advertising profiles. Purposes are described in How we use information. Retention follows Retention, export, and deletion. You may request access, deletion, or correction as described in Your choices and rights. We do not discriminate against you for exercising those rights.

Security incidents

If we become aware of a personal data breach that is likely to result in a risk to your rights and freedoms, we will notify affected users and regulators as required by applicable law, using contact information associated with your account or public notice when appropriate.

Changes

We may update this Privacy Policy as the product, laws, or operational practices change. Material changes will be reflected by updating the effective date and, when appropriate, providing additional notice.

Contact

Questions or privacy requests can be sent to [email protected].