What we keep, and what we don't.

Who this is for

msgforyou.in is intended for users 18 years of age or older. By using the service you confirm you are at least 18. We don't collect identifying data from anyone, but the service's emotional weight (apologies, confessions, goodbyes) isn't designed for minors and we ask that they not use it.

What we never collect

• No accounts, no passwords, no email addresses.
• No cookies. No localStorage. No persistent client-side identifiers.
• No tracking or analytics scripts. No third-party trackers.
• No phone numbers, no contact lists, no social profiles.
• No images, no audio, no video — the service is text-only.

What we store, and for how long

When you create a message, we store:

• Encrypted ciphertext— the message text after AES-256-GCM encryption, done in your browser. We can't read it.
• The IV (a random number that goes with the ciphertext) and the emotion tag you picked.
• Sender name — only if you typed one. Optional.
• A SHA-256 hash of a preview token — never the raw token. The raw token lives only in your preview link.
• A SHA-256 hash of a keepsake token — never the raw token. The raw token lives only in the keepsake link we show on the share screen, so you can come back and see whether the message has been opened.
• A random slug for the URL, plus timestamps for when the message was created, when it expires, and (after viewing) when it was opened.

What survives a message being opened

When the receiver taps to reveal, an atomic database function called consume_message returns the ciphertext to their browser and immediately overwrites the ciphertext column on the same row. From that moment on, the message body is gone — there is no second copy, no backup, and no way to replay it.

What stays on the row, briefly, is the metadata that makes the "has it been opened?" keepsake work: the timestamps, the emotion tag, and the hashed keepsake token. This row is then automatically reaped:

• If the message is opened: the row (now stripped of ciphertext) is kept for at most 7 days, so you can revisit the keepsake link and still see "they opened it." After 7 days, the row is deleted.
• If the message is never opened: it expires 24 hours after creation, the ciphertext is dropped, and the row is reaped within another 24 hours after that.

We do not keep backups of opened or expired messages. There is no admin tool that can recover the body of a consumed message — by design.

The encryption key never reaches us

The AES-256 key is generated in your browser and lives only in the URL fragment — the part after the #. Browsers do not send fragments to servers. So our database holds ciphertext we cannot decrypt. Even if our database were stolen, the messages would be unreadable without the link itself.

We have not built, and will not build, any way to decrypt messages where we do not already have the link. We have no master key, no override, no admin tool. This is the same position taken by Signal, ProtonMail, and Apple for end-to-end encrypted iMessages.

An honest caveat: the link is the key

The link itself contains the encryption key (in the URL fragment). That is how the receiver's browser is able to decrypt the message in the first place. Mathematically, anyone who holds a complete msgforyou link — including its # fragment — can decrypt that one message, as long as the message has not yet been opened.

This is true of every end-to-end encrypted system that delivers a key via a link (ProtonMail's "send a message to anyone" flow, dropbox-style sharing links, and so on). It is not a flaw — it is the cost of having no accounts and no key servers. It does mean you should treat msgforyou links the same way you treat passwords: don't paste them anywhere they can be archived (not into search bars, not into screenshots, not into chats with bots, not into URL shorteners).

If a complete link is shared with us — for example, in an abuse report — we follow a strict operational policy: see /abuse for the specifics.

Aggregate counts

The landing page shows small aggregate numbers like "N people are writing right now" or "N messages this week." These come from a single SQL COUNT(*) over recent rows — no row content, no sender, no slug, no IP. It is purely a count of how many messages exist, refreshed every minute.

IP addresses

For abuse protection (basic rate limiting), we briefly hash your IP address with SHA-256 and keep that hash in memoryon the server, evicted whenever the server restarts or memory pressure clears it. We never store raw IPs in our database. We never log them ourselves. They aren't written to disk by our code.

Note that our hosting providers (see below) keep their own short-retention access logs, which we do not control.

Third parties

The site runs on Vercel (hosting and edge CDN) and Supabase (Postgres database, hosted in Mumbai). We do not share data with anyone for advertising, analytics, or any other purpose.

Both providers maintain their own request-level access logs (typically including IP and user-agent) for short periods — usually 24–48 hours — for security and operational purposes. We do not control the contents or retention of those logs. Supabase only ever sees encrypted ciphertext; Vercel sees encrypted HTTPS traffic.

One additional caching note: when a sender views the "they opened it" keepsake page and presses Share this moment, a small PNG card is generated for them. That PNG is cached at Vercel's edge for up to 24 hours, keyed on the keepsake token. It contains no message content, no slug, and no identifying data — only the wordmark, a coarse time-ago label ("a few minutes ago"), and the emotion-tinted background.

India's DPDP Act

We aim to comply with India's Digital Personal Data Protection Act, 2023. Because we don't collect personal data — no names tied to identity, no email, no phone, no IP retention, no profiling — most of the Act's obligations don't apply, but we treat the spirit of the Act as our default. If you have a question or concern, see Your rights below.

Your rights

Because we don't identify you, there's nothing tied to you to request, correct, or delete. If you want a specific message slug invalidated, see /abuse.

Changes

If we change anything material here, the updated date at the top will move and the change will be visible. We won't silently start collecting things we said we wouldn't.