How SendMe protects your files.

Our threat model — and what's NOT in it

Every security tool has a threat model — a list of attackers it's designed to stop, and a list it explicitly isn't. SendMe is built to defeat opportunistic attackers and passive surveillance, not state-level adversaries. Concretely:

We defend against: someone sniffing your Wi-Fi at a café; someone guessing or brute-forcing your 6-digit code; someone obtaining a leaked link from a chat archive after expiry; an internal employee at our hosting provider walking off with a raw disk; opportunistic web scrapers indexing public URLs.

We do NOT defend against: a determined attacker who compromises your device before the file is encrypted; a court order compelling us to disclose a specific transfer before it expires; a recipient who screenshots the file and shares the screenshot; a sophisticated state-level adversary with access to undisclosed cryptographic vulnerabilities.

For threats outside our model, layer additional protection: encrypt files client-side with a tool like 7-Zip or VeraCrypt before uploading, and share the encryption password through a fully separate channel (a voice call, an in-person handoff, or a different end-to-end-encrypted messenger).

What we collect — and what we don't

For each transfer we store: the file content, its size, its content-type, a server-generated 6-digit code, the expiry timestamp, an optional bcrypt-hashed password, and a created-at timestamp. We do not store the file name (we use a UUID internally) — though we do return the original name to the receiver so the download works correctly.

For each registered user we store: email, name, hashed password (for email/password accounts) or Google ID (for Google sign-in), and basic plan/billing metadata. We do not store payment card numbers — Razorpay handles those.

We do not run third-party advertising trackers. We do use a single first-party analytics tool (Google Analytics 4) to understand which pages people read — pageviews and a few custom events like "file_upload". We use Google AdSense on blog pages only, and we serve non-personalised ads to EU visitors by default.

Why we're not end-to-end encrypted (yet)

True end-to-end encryption (E2EE) means the service operator cannot read your file even if they wanted to. The encryption key lives only on the sender's and receiver's devices. This is the gold standard, and we plan to ship it.

E2EE adds friction that doesn't fit a "no signup, type a code" product. The receiver needs to also hold a key, which means either both sides need to install software, or the key has to be embedded in the URL fragment (after the `#`) — which then exposes the entire URL as a sensitive secret. We're working on a model where the encryption key lives in the URL fragment and the 6-digit code is a separate authorisation step. That's planned for late 2026, with Pro subscribers getting early access.

In the meantime, our "good-enough" model relies on (a) short expiry, (b) optional password protection, and (c) operator-side encryption-at-rest. For most users this is comfortably above the bar set by email and chat-based file sharing.

Compliance and certifications

SendMe is GDPR-compliant by design. We collect only the data necessary to run the service, we delete it according to a published schedule (transfer expiry and account deletion), and we honour data-subject requests within 30 days. Write to privacy@sendme.co.in to exercise any GDPR right.

We are not currently SOC 2 or ISO 27001 certified — certification is on the roadmap for 2027 as we scale into more enterprise-style team plans. If your organisation requires a security questionnaire before adopting, write to security@sendme.co.in and we'll send a SIG-Lite response.

Responsible disclosure

We don't run a formal bug bounty programme yet, but we treat security reports with priority. Write to security@sendme.co.in with a detailed reproduction. We respond within 24 hours, fix critical issues within 7 days, and credit reporters who request it. We won't pursue legal action against good-faith researchers.