Polymorph Privacy Policy

Last updated: 19 October 2026

Version: 2026-10-19

This policy explains how Polymorph Technologies B.V. handles personal data when providing Polymorph's apps, websites, encrypted communication, Files, Spaces, account synchronisation, Premium subscriptions and support. It describes the service as currently implemented, not features or retention improvements planned for a future release. Reading or acknowledging this policy is not consent to every kind of processing.

1. Who we are and how to contact us

Polymorph Technologies B.V. is the controller responsible for the processing described here. We are registered in the Netherlands under KvK number 42138293, at Haarlemmerweg 331 A, 1051 LH Amsterdam, Netherlands.

General enquiries and privacy requests: info@polymorph.pm. Our mailbox is hosted with Proton. You do not need a Polymorph account to contact us. Please do not send account keys, recovery secrets, payment-card details or unnecessary private message contents.

2. Our approach

We build Polymorph around end-to-end encryption and limited operational metadata. We do not sell personal data, communication metadata or behavioural profiles, and do not use private communication content to build advertising audiences. Subscriptions fund the service rather than advertising access to users.

Creating an app account does not require a telephone number, email address, real name, date of birth or address-book upload. Paying for Premium requires payment and billing details, which Link and Stripe collect; section 7 explains how we keep payments separate from accounts. If you email support, we receive the address and information you choose to send.

Privacy is not a guarantee of anonymity. Your network, operating system, payment provider, recipients, or information you share may identify you. Encryption does not conceal every routing identifier or network address.

3. Account, device and profile information

To operate an account we process:

Account IDs, public user keys, the account's public signing key and an authentication verifier derived from account credentials.
Polymorph-generated device IDs, hashed session tokens, device public keys and capabilities, platform information, creation times and activity/lifecycle timestamps.
Push and VoIP delivery tokens, notification capabilities and settings sent to the server, including device-squelch, do-not-disturb and quiet-hours state where used.
Recorded User Agreement and Privacy Policy version identifiers and the server-recorded acceptance time.
Plan entitlements, storage usage, limits and access-control records. For Premium bought through Link, this is the tier, its status and its dates rounded to the day, together with a keyed hash of a purchase key held by your devices (see section 7).
Temporary device-linking capabilities, approval state and encrypted delivery packages needed to authorise a new device.

Polymorph device IDs are generated for this service; they are not advertising IDs or hardware serial numbers. The server does not receive your private content-decryption keys as plaintext through the normal encrypted messaging and storage flows.

Handles are public by design: they let people find and contact you, and you can change yours once a month. Handles use indexed lookup and encrypted storage with server-managed keys. We can resolve and decrypt handles: this is different from end-to-end encryption. Persona display names, avatars and other private profile information are shared through encrypted client-controlled data. The people or groups with whom you share a profile can see that presentation. Account and Persona permissions do not prevent a recipient from copying information they receive.

4. Communication, Files and Spaces

Our servers route or store encrypted chat and group payloads, attachments, stories, location messages, account snapshots, your encrypted message archive, and supported Files/collaboration content. Attachments and cloud file contents are encrypted on the device before upload; personal Files names are also encrypted. Messenger uses MLS for encrypted delivery and group-key changes. Calling uses encrypted media; the SFU media path requires end-to-end encryption rather than falling back to unencrypted media when setup fails.

We still process operational metadata: conversation/group IDs, sender and recipient account/device IDs, membership and invitation state, message-type hints, timestamps, acknowledgement state, delivery cursors, scheduling/reveal times and expiry information. Calls require participant and connection state. Files require object identifiers, sizes, references, usage and access permissions. Spaces additionally require ownership, membership, roles, invitations, the membership log of each Space's encrypted control group, quotas and links to conversations. Space titles or file contents being encrypted does not hide all of those relationships.

Spaces are available only to accounts with an active Premium subscription; every member, including the owner, needs their own. We check each member's plan entitlement together with membership, role and quota information whenever a Space is used. A member whose Premium ends keeps their membership, role and read access but cannot post, edit or upload until they renew; other members are not told why. A Space's stored content counts against the storage of the account that pays for the Space, normally its owner, rather than each uploader's personal storage, so that account's storage usage reflects the Space's stored content.

When you leave a Space or are removed from it, or the Space is deleted, your devices delete that Space's channels, history, files and keys stored on them. When an owner deletes their account, the Space and its membership records are kept for ownership succession as described in the User Agreement; during that time the Space's storage is charged to nobody, and at the takeover it moves to the new owner's account.

"Delete for everyone" removes the message from the devices of the conversation's members when their apps process the deletion, and removes it from the encrypted archive: the affected archive pieces are replaced with redacted ones, and the server deletes the replaced pieces after 30 days. It cannot remove copies someone already saved, exported or photographed.

End-to-end encryption does not protect content after an authorised recipient or compromised device decrypts it. People may save, screenshot, forward or report material. One-time-view, deletion and expiry features cannot erase copies outside our control.

Keep your recovery keys and independent copies of important files safely. The app shows the recovery keys once, at account creation. An existing authorised device or your saved recovery keys can assist recovery; support cannot reconstruct lost decryption secrets.

5. Notifications, calls, maps and links

Apple and Google handle push delivery on their platforms, including delivery tokens and technical/routing metadata. Supported message previews are encrypted for the receiving device. That device may decrypt and display a name, avatar or message preview according to its local settings. Encryption does not remove the operating system's role in delivering or displaying a notification. Notification preferences are per-device; incoming-call handling has separate platform requirements. Storage reminders (section 11) are sent as ordinary notifications that name only the deletion date, not files, sizes or counts.

On Android, Firebase Cloud Messaging also uses Firebase installation identifiers, which are separate from Polymorph's own device IDs. Google describes its processing in Firebase privacy information. Turning off message notifications does not mean that every platform identifier or provider backup is immediately erased.

Direct peer-to-peer calls can reveal participants' network addresses to each other. Relayed calls use our calling infrastructure instead; the route depends on connectivity and call configuration. End-to-end media encryption and hiding a network address are different protections.

Maps can load tiles from OpenStreetMap infrastructure. Tile requests expose network/request information and the requested map area to the provider, separately from the encrypted location message. Link previews and favicons may be fetched directly from the linked website by your device, before you open a browser. That website can receive your IP address and request metadata.

6. Diagnostics, reports and support

Client diagnostics can include account/device identifiers, platform/app version, timestamps, event scope, severity, an error message, HTTP status and limited details. Limits and truncation reduce volume but are not a guarantee that an error can never contain a URL, filename or user-supplied value. Diagnostics support reliability and troubleshooting, not advertising profiles.

Abuse reports can include the reporter and reported account, category, optional conversation reference and notes the reporter supplies, together with review/status information. Reporting information to us is different from routine access to encrypted chats: we cannot normally inspect those contents unless someone shares them with us.

Support email includes correspondence, attachments you send and ordinary mail headers processed by Proton and any mail services you use. Email is not an end-to-end encrypted Polymorph conversation. Staff access and administrative actions produce access/security and audit records. Authorised operations recipients may also receive minimal service alerts; those are server-originated notices, not encrypted peer chats.

7. Purchases and billing

Premium is sold on our behalf by Sold Through Link, LLC ("Link"), a Stripe company, as merchant of record; in the EU, payments are processed by Stripe Technology Europe, Limited. When you buy, Link collects your name, email address, billing address, card or other payment details, the country you are in and, if you give one, a tax ID. Link and Stripe use this data as independent controllers: to take the payment, calculate and pay tax, send receipts and invoices, handle refunds, disputes and support for the payment, prevent fraud and meet their own legal duties, as described in Stripe's Privacy Policy and the Sold Through Link Terms. If you create or use a Link account, that is your own relationship with Link. The apps distributed through Apple's App Store and Google Play do not sell Premium, so Apple and Google do not process a Polymorph purchase.

Under the Sold Through Link Terms, Link can share the order data with us, including your name, email address, billing address, payment-method details such as card brand and last digits, tax ID and order details. That data is kept in our account with Stripe, which Stripe hosts for us. We use it only to administer purchases, answer purchase questions, handle refunds and disputes, prevent payment abuse and keep accounting records. It is not copied into our payments service or our account service, and nothing in it identifies your Polymorph account.

We designed billing so that Polymorph does not keep a record linking a payer to an account. Two separate services are involved, on separate servers with separate databases, logs and backups:

The payments service (pay.polymorph.pm) knows the Stripe customer and subscription references, the tier, the subscription status and billing dates. It does not store raw webhook payloads or payer fields such as your name, email address, billing address or card details.
The account service knows your account and its Premium tier, status and dates, rounded to the day.
When you buy, your devices receive a random purchase key and keep it in your encrypted account data. Each service stores only its own keyed hash of that key, made with unrelated keys, and neither stores the key itself. The two records can only be matched with the key your devices hold, which they present when they check the subscription, change the tier or cancel.

Our support and staff tools cannot look up a payer from an account or an account from a payer. For a purchase question, support identifies the purchase by the receipt or invoice number from Link's email and does not ask for your handle or account. "Manage by email" on pay.polymorph.pm/manage sends your email address from your browser directly to Stripe's sign-in page; we do not receive it. When you manage your subscription at link.com, we learn only the resulting change, such as a cancellation, not your Link account.

This design has limits. Someone able to observe both services at the moment of a purchase, a subscription check or a downgrade check could connect them by timing; we keep the services and their logs separate and devices check at varied times to reduce this. While there are few subscribers, the tier and renewal day can narrow down who is who. Link and Stripe know who paid, and so does the order data in our Stripe account, but none of it shows which account. If you send us your handle together with a receipt, or pay with details that identify you to someone who also knows your handle, that link exists outside our design. Account deletion leaves a keyed hash of the purchase key on the account side so the same purchase cannot be attached to another account.

Deleting an app account and cancelling a subscription are separate operations: the app cancels the renewal before deleting the account when the device can. Otherwise use "Manage by email", link.com or your bank.

You can ask Stripe or Link to delete the data they hold about your purchases. Stripe then also deletes it from the purchase records in our Stripe account and cancels your subscription; it tells us that a deletion was requested. Our payments service keeps only the references described above, which no longer lead to a payer.

8. Websites and browser storage

Hosting infrastructure processes network and request information needed to serve and protect the websites, such as IP addresses, requested URLs, request times, browser information and errors. We do not run advertising pixels or third-party behavioural analytics on the marketing site. The payments website does not keep an access log.

The public marketing pages do not use browser storage for tracking. The restricted preview login uses a necessary first-party access cookie. Our checkout and billing-management pages use short-lived, tab-scoped session storage for their authorisation flow. Pages hosted by Stripe or Link, such as the checkout, the billing page and link.com, are separate. See the Cookies & Browser Storage notice for details.

9. Purposes and lawful bases

Where the GDPR applies, the basis depends on the purpose:

Providing the requested service: account authentication, encrypted delivery/synchronisation, calling, storage, permissions, quota enforcement, purchase administration and answering purchase questions are processed to perform our contract with you.
Reliability and protection: proportionate diagnostics, security monitoring, abuse handling, handling payment disputes and suspected fraud, and defence of claims are based on our legitimate interests in protecting users and operating a reliable service, subject to balancing those interests against your rights.
Legal requirements: records or disclosures specifically required by applicable law or a binding order, such as accounting records, are processed to meet that obligation, rather than treating all security activity as a legal obligation.
Consent: where a particular processing activity requires consent, we request it separately and it can be withdrawn. Agreeing to terms or continuing to use the app is not a substitute.

Camera, microphone, location, notifications and other operating-system permissions control access on your device. An OS permission is not automatically the legal basis for every associated processing operation. You can manage permissions in device settings; disabling one can prevent the corresponding feature from working.

Private content may contain sensitive information you choose to share. We do not request a sensitive-data profile or routinely inspect encrypted content. If you disclose sensitive information in a report or support request, handling it needs an appropriate basis and, where applicable, an additional legal condition. Avoid including information unnecessary for the request.

10. Recipients and international processing

Our core infrastructure, including the payments service, is hosted with Hetzner in the EU. Relevant external services also include Apple/Google for platform and push services, Link and Stripe for selling Premium and taking payments, Proton for our support mailbox, and OpenStreetMap tile infrastructure. A link-preview destination or recipient receives information as described above. External providers' roles differ: they are not all processors acting only under Polymorph's instructions.

Provider information is available from Hetzner, Apple, Google, Stripe and Link, Proton and the OpenStreetMap Foundation. Their policies do not replace this policy for processing for which Polymorph is responsible.

EU hosting does not mean every associated service processes data exclusively in the EU/EEA. Platform, payment and other provider activities can involve other countries. Transfers for which Polymorph is responsible require an applicable transfer mechanism and safeguards, such as an applicable adequacy decision or contractual safeguards, rather than reliance on the server's location alone. Contact us for information about the recipients, locations and safeguards relevant to your request and how to obtain a copy where applicable.

Proton AG is based in Switzerland, which has an EU adequacy decision; its data-processing agreement also addresses onward transfers. Link is a United States company and Stripe operates internationally; the data Link collects at checkout is collected by Link as a controller under its own terms and privacy policy. For the order data kept in our Stripe account, Stripe's Data Transfer Agreement and Firebase's data-processing terms include contractual safeguards for relevant international processing. The applicable protection depends on the service, recipient and destination; it is not an assurance that all provider activity takes place in Europe.

We may disclose information we hold where required by a valid legal obligation, or where otherwise lawfully necessary to protect rights and address abuse. We cannot supply plaintext that we do not possess, or a link between a payer and an account that we do not keep. A corporate transaction does not remove data-protection obligations or authorise unrelated use of private communication data; affected people must receive applicable information about changes.

11. Retention and deletion

Different records have different lifecycles. Cleanup runs periodically; outages, valid references and a justified legal hold can affect timing. The following are current rules and limitations, not a promise that all data disappears after one universal period:

Device linking: expired linking sessions become eligible for deletion one hour after expiry, through an hourly bounded cleanup. The grace period protects limited consume retries. A linking package is not a permanent account backup.
Completed/cancelled sends: redundant encrypted send requests and unnecessary dependency details are compacted after terminal state and activity are older than 24 hours. Published attachment/blob/media recovery mappings and delivery/idempotency receipts remain. Pending, publishing and failed sends are not removed by this rule. Receipt rows currently have no automatic age expiry, because a delayed retry must not create a duplicate send.
Delivery queues and group recovery: acknowledgement clears the acknowledging device's queued delivery, not other devices' pending deliveries. Some payloads expire, including passive probes after 24 hours and capability-gated payloads subject to a 30-day cap. This is not a universal 30-day maximum: other delivery and epoch-recovery records can remain longer while devices need to catch up.
Diagnostics: events older than seven days are eligible for daily cleanup. Completed call state uses a 24-hour retention criterion; active calls are excluded.
Files and Recently deleted: files you delete stay in Recently deleted for 30 days unless you empty it sooner, then are deleted. Deleted file/change metadata uses seven-day cleanup criteria with reference and recovery safeguards. Object deletion is queued and retried, and an object still referenced elsewhere is not simply erased because one reference was removed. Story-reference cleanup uses a 30-hour criterion; this does not erase recipients' copies.
Replaced synchronised data: when a device replaces synchronised encrypted data, such as parts of the message archive, the server keeps the replaced encrypted objects for 30 days, so that a faulty device cannot cause data loss, and then deletes them. Pieces replaced by "delete for everyone" follow the same 30-day rule.
Inactive and removed devices: retirement of inactive linked devices uses a seven-day inactivity criterion with active-session, last-device and group-coverage safeguards. A retired device's record is deleted no earlier than 30 days after retirement, once nothing still depends on it, such as a pending removal from an encrypted group, queued messages or documents it signed.
Purchase records on the account side: temporary purchase claims are deleted when the purchase is attached to the account; expired or used claims are deleted after 45 days.
Service notices: the Operations inbox retains notices for 30 days, including unread notices. It is available only to designated recipients.
Support and abuse reports: routine support correspondence and resolved or dismissed reports become eligible for deletion 90 days after closure, handled through a monthly review rather than an automatic timer. Open cases are reviewed monthly for continued need. We remove unnecessary attachments and sensitive details sooner where possible. A specific dispute, safety need or legal obligation may require limited evidence to be held longer, with its purpose and next review recorded.
Staff audit records: our monthly review removes unnecessary free-text/detail fields after 30 days and routine event records after 90 days. Evidence needed for an identified incident or claim is restricted and reviewed separately. These periods are operating rules, not yet universal automatic database expiry jobs.
Privacy requests: we retain a minimal record of the request, response and outcome for 12 months after completion to demonstrate how it was handled. Routine correspondence is eligible for deletion after 90 days. Identity-verification material, if exceptionally necessary, is removed after verification unless a documented need requires a short further period, normally no more than 30 days.
Account and device history: some deleted-account identifiers and lifecycle/acceptance records remain without a general automatic expiry. We review them after 30 days and monthly thereafter for removal or minimisation. Delivery, group-key recovery, shared-content permissions, Space membership logs and preventing duplicate sends can require minimal identifiers or receipts to remain longer. This is a dependency-based rule, not a claim that whole accounts disappear after 30 days. Applicable deletion rights and exceptions still apply.
Storage over the Free limit after Premium ends: from 14 days after Premium ends, if your account stores more than the Free limit, your most recently added or changed personal files and chat attachments you sent, up to that limit, and those you choose to keep, stay backed up. The rest is no longer backed up. As soon as one of your devices has a copy of such an item, we delete its cloud copy for your account; whatever is still only in the cloud 6 months after this starts is deleted, never less than 30 days after we first told you. We choose by sizes, dates and object identifiers only, not by names or contents. A chat attachment you sent that is deleted this way can no longer be downloaded by people who have not downloaded it yet. The encrypted object itself is deleted once no other account still references it. Renewing Premium before the deletion date stops this for what is still in the cloud. Space content and Recently deleted are not affected.
Financial records: we keep only the records necessary for purchase administration and applicable recordkeeping duties. Link and Stripe keep payment, tax and invoice records for these sales under their own obligations. Our own accounting records, such as payout and settlement reports and the invoices Link issues to us, generally have to be kept for seven years under Dutch law. The applicable accounting period and legal duty determine the start and scope. These duties do not justify keeping unrelated chat contents, device descriptions or every billing integration record for the same period.
Host logs: retention varies by host and log type. The current configuration is not a universal seven-day cap: inspected rotations include 14 daily Nginx files, ten weekly PostgreSQL files and four weekly system-log files, while some journals have size-based rather than explicit age limits.
Database backups: the current primary database policy keeps at most two matching local and two off-host snapshots, with additional age settings of 14 days locally and 30 days off-host. Successful daily jobs normally rotate copies sooner because of the count cap; failures can delay cleanup. Payments backups are kept separately and have an approximately 14-day cleanup rule. Backups are not rewritten immediately when an active record is deleted. Not all database metadata is end-to-end encrypted merely because encrypted message contents are included in a backup.

12. Signing out, deleting an account and shared content

Signing out removes that account's data from the device: messages, media, files, keys, caches and settings. Your encrypted archive stays on our servers and your history is restored from it when you sign in again. Anything not yet sent or uploaded is lost. If you sign out while offline, the device records the sign-out and tells our servers when it is next online. Removal from the device is best effort: storage hardware and operating-system backups are outside the app's control, and some data held by the operating system is removed the next time the app starts. Content you saved or exported outside Polymorph, including media saved automatically to your gallery if you turned that on, is not removed.

You can delete your account in app settings. This disables account access and starts removal of account data and unreferenced stored content. Some account identifiers, lifecycle/acceptance information, shared relationships and records covered above can remain; a disabled account record is not necessarily anonymous. Copies held by other people cannot be deleted through your account settings.

Spaces you own are not deleted with your account when they have other active members. Their content, membership and storage records are kept for 30 days of ownership succession and then pass to the new owner, as the User Agreement describes. If nobody can take over, or the Space cannot pass to a new owner because your account was deleted without a signed departure, the Space and its stored content are deleted after 30 days. Space content charged to your account in Spaces that already have another owner moves to that owner's storage. Arrange access and independent copies before closing an account.

Device-local copies, recipient copies, active service data and backups have separate lifecycles. Removal from the live service is not a claim that every backup, recipient or external cache has already been erased.

13. Your choices and rights

Subject to the law and relevant exceptions, you can request access, correction, erasure, restriction, objection and portability of your personal data, and withdraw consent for processing based on consent. Portability applies where its conditions are met; it does not give us the ability to decrypt content without your keys. You can complain to the Dutch Autoriteit Persoonsgegevens or another competent supervisory authority.

Contact info@polymorph.pm. We normally respond to GDPR rights requests within one month; where a lawful extension applies, we explain it within that period. We may need proportionate proof of account control or other information to locate the relevant record. Use an authenticated process where available; never send account keys, private keys or recovery secrets to support. We do not require an unrelated identity document merely because you ask a question. If we cannot identify the account or no longer hold the requested information, we will explain the limitation. Because we do not link payers to accounts, a request about payment data is answered from the payment records found by the receipt or invoice number from Link's email or the payer's email address, not from your account. For the data Link and Stripe hold as controllers, you can also exercise your rights with Stripe as described in its privacy policy.

We do not use communication content for advertising profiling. The service is not intended to make decisions based solely on automated profiling that have legal or similarly significant effects on you; routine authentication, quota enforcement and anti-abuse controls still operate. Link's and Stripe's fraud screening can decline a payment; contact us if you think that happened in error.

14. Age, security and changes

The service is for people aged 16 or over, or a higher minimum where required by applicable law. We do not collect birth dates as part of signup or describe agreement acceptance as verified age. Contact us if you believe an account is being used by someone below the applicable minimum; we will address it and handle associated data under this policy and applicable law.

We use encryption, authenticated access and restricted operational access, but no system is risk-free. We handle and notify personal-data breaches as required by applicable law, including relevant supervisory-authority and affected-person notification duties.

We may update this policy and will identify the version and date. Material changes require appropriate notice; where separate consent is required we seek it rather than treating continued use as consent. Publication of a new policy does not rewrite previously recorded terms acceptance.