privacy policy

notes, file contents, and ordinary direct-message bodies are encrypted in your browser with keys we do not hold. other surfaces, including email delivery, public profiles, and necessary service metadata, have the different boundaries described below.

last updated: 2026-08-29 · alpha quality · see also the threat model.

who we are

“dy.ing”, “we”, and “the operator” all mean the same person running this service. we operate pseudonymously. privacy or data questions go to privacy@dy.ing, or use the contact in our security.txt.

what is sealed in your browser

these contents are encrypted on your device with keys we never get. on our side the stored payload is ciphertext:

• ▸note contents and titles
• ▸file contents and file names
• ▸ordinary direct-message bodies

we can’t read it, hand it over, or get it back for you. we don’t have the keys.

received email has a separate boundary. our SMTP service receives ordinary internet mail as plaintext and seals it to your address’s public key. the application writes the sealed copy to inbox storage and does not intentionally persist the incoming plaintext. only the private key held by your browser can decrypt that stored message.

mail you send to an external address is plaintext through our application and mail relay because the recipient holds no dy.ing key. the application does not intentionally persist that outbound plaintext. ordinary SMTP transport may use opportunistic TLS, but email is not end-to-end encrypted and we do not claim resistance to transport downgrade.

what we do handle

• ▸
  a username

  you choose one. creating an account does not require a personal email address, phone number, or real name.
• ▸
  authentication material

  a login check-value computed in your browser, plus your encryption key locked under another key we can’t reproduce. these are designed not to reveal your password or sealed content directly; password strength still matters against offline guessing.
• ▸
  ciphertext blobs

  your encrypted content, plus minimal sizing/quota metadata needed to store and bill space.
• ▸
  email during delivery

  incoming SMTP plaintext while it is being sealed and outgoing plaintext while it is being relayed. stored inbox messages are sealed as described above.
• ▸
  a session cookie

  one HttpOnly cookie to keep you logged in. no tracking or advertising cookies, ever.
• ▸
  necessary metadata and operational records

  routing, ownership, timing, size, quota, and request data needed to run the services, plus aggregate counters and restricted security records. raw IPs, email addresses, user IDs, tokens, and plaintext are not intentionally retained in ordinary long-lived logs. this boundary still requires operational verification across queues, temporary files, and crash behavior.

public profiles

if you turn on a public profile at /@yourname, that page is deliberately readable by us and anyone else because it is meant to be public. owner-chosen fields, links, and uploaded media are stored as plaintext. a published profile can also show operator-granted groups or verification, peer-authored reputation, derived audience information, and optional derived trade statistics. none of it is taken from browser-sealed content or stored sealed inbox messages, but not every displayed field is authored by the owner.

because profile images are public, uploads may be checked against databases of known child-abuse imagery. only a perceptual fingerprint (a hash) is sent to the configured matching provider; the image bytes are not sent to that provider. this applies only to public profile images; browser-sealed content and stored sealed inbox messages are not scanned.

your account & recovery

your encryption key is derived in your browser. if you lose your credentials, the one-time 24-word recovery code is the only way back in. we can’t reset it or recover it for you, and without it we can’t decrypt your data either. lose the recovery code and your data is gone for good.

no trackers, no third parties in your browser

• ▸ no third-party scripts, fonts, analytics, or ads. strict content-security-policy, everything self-hosted
• ▸ we don’t sell or rent personal data; service providers process only the data and purposes described here
• ▸ a CDN edge may serve your files, but only as ciphertext it can’t read
• ▸ hosting and storage providers may process sealed blobs, public profile data, and the necessary metadata described above

retention & deletion

the current account-deletion flow removes the account’s database records and then attempts object-store cleanup. complete online-object cleanup, backup retention, and deletion replay after a restore are not yet verified, so we do not claim a complete purge or public time limit today. the intended policy is prompt access disablement, bounded online deletion, restricted disaster-recovery retention, and replaying deletions after restore; those stronger promises wait for implementation and recovery drills. moderation quarantine follows a separate, restricted retention policy.

your rights

you can access and export your sealed data, and delete your account. we can act on the account, public information, metadata, and stored ciphertext we control, but we cannot decrypt browser-sealed content for you. depending on where you live you may have other statutory rights; contact us to use them.

children

dy.ing is not directed to children and is not intended for anyone under the age of majority in their jurisdiction.

changes & governing law

we may update this policy; material changes will be noted by the “last updated” date above. we run dy.ing pseudonymously and haven’t tied it to a single jurisdiction yet; until we do, this policy is applied to the fullest extent permitted by applicable law.