The risk
A login can become an identity anchor.
A phone number or personal email address can persist for years. It may connect an account to other services, breached datasets, an address book, or a real-world identity. Phone numbers also create an account-recovery path that can be targeted through SIM swapping.
Polymorph’s response
Creating an account does not require a phone number, email address, real name, or access to your address book. Your account is not automatically built around an identifier you already use everywhere else.
The risk
The details around a conversation can reveal plenty.
Who communicates, when, how often, and from where can describe relationships and routines even when nobody reads the message itself. Research into telephone metadata has shown that these records can be readily reidentified and used to draw sensitive inferences.
Polymorph’s response
Polymorph is designed to use limited operational data to deliver, secure, and maintain the service—not to build advertising profiles or turn people’s relationships and behavior into a product.
The risk
Privacy should include protection from the provider.
A private service should not ask users to rely only on a promise that employees, contractors, future owners, or anyone gaining access to its systems will behave correctly. The safer starting point is to limit what the service is technically able to see.
Polymorph’s response
Messages, calls, shared media, Personal Files, Spaces, and online backups are end-to-end encrypted. Polymorph carries and stores encrypted content, but is designed not to hold the keys needed to read it.
The risk
A breach should expose as little as possible.
No responsible service can promise that its infrastructure will never be attacked. Security therefore also depends on reducing the usefulness of whatever an attacker could reach.
Polymorph’s response
Polymorph is designed to reduce what a compromised server could reveal: content remains encrypted, accounts are not inherently tied to a phone number or email address, and unnecessary personal information is not collected. This makes stored information harder to read and harder to connect to a real person—it does not make any system invulnerable.
The risk
Collected data can outlive its original purpose.
Information retained for convenience today can later be exposed, repurposed, combined with another dataset, or requested from the provider. Even well-intentioned collection creates an obligation and a future risk.
Polymorph’s response
We choose through policy and architecture to keep the personal and operational data required to run a reliable service limited. Information that was never collected cannot later be profiled, leaked, sold, or handed over by Polymorph.
The risk
A subscription should not become proof of identity.
Payments necessarily leave information with the services and institutions that process them. If that payment record is attached directly to an account, it can quietly recreate the real-world identity link that a private signup process was designed to avoid.
Polymorph’s response
Payments are handled separately through Stripe. Anyone can buy a subscription for any Polymorph handle—the payer and the person using the account do not have to be the same. Polymorph validates the subscription through a one-way-hashed token linked to the receiving account, rather than attaching the payment record and payer’s identity to that account. Together, these choices effectively sever the direct link within Polymorph between an account and the identity behind the payment that funds it.
Note: This does not make a card payment anonymous: Stripe and the financial institutions involved still process the information needed to complete it. The separation limits what a Polymorph account itself reveals and prevents us from treating the payer as the account holder.
Stripe privacy information