Why this service?

E2EE Hub exists to make private sharing simple: encrypt on your device first, keep keys off the server, and give you controls like expirations, burn-after-read, and passphrases so you decide who can access your content.

We’re building it because common tools keep plaintext on their servers, track users, and increasingly read content for ads or AI. Meanwhile, real-world threats—doxxing, identity theft, targeted scams, fraud from leaked documents, phishing kits, screenshots, and AI scraping—are growing. A zero-knowledge, user-funded service can stay privacy-first and sustainable without ads or data mining.

How does encryption and key handling work?

Everything is encrypted in your browser before it leaves your device. The decryption key stays in the URL fragment (#k=…) and never reaches the server; adding a passphrase keeps it client-side only. The server stores ciphertext blobs plus minimal metadata needed for abuse protection.

What does the server see, and what stays private?

The server can see plan/quotas, coarse timestamps, sizes, MIME, and (for non-E2EE links) plain targets. It cannot see encrypted link targets, notes, files, photos, collections, passwords, or OTP secrets. Per-item keys stay wrapped for the owner/recipients; plaintext keys never leave your device.

What’s the threat model and residual risks?

E2EE + TLS defends against an honest-but-curious server and network observers. It does not protect against compromised browsers, malicious extensions, malware, or someone grabbing screenshots/forwarded content. Keep devices clean and share keys only with people you trust.

What social and fraud risks should I know about?

Screenshots, forwarding, and insider leaks bypass any crypto. Expiring links, burn-after-read, and sharing only with trusted recipients help reduce exposure. Be cautious of scams or phishing built with shared files—verify who you’re sending to and keep links short-lived.

How do I avoid accidental or AI-driven leaks?

Double-check links before sharing, prefer short expirations, and avoid public/long-lived links for sensitive content. Encrypt or redact locally; avoid uploading raw IDs or sensitive images where possible. Short-lived URLs and encrypted previews help reduce scraping and AI reconstruction risk.

What about state-level attackers?

Strong E2EE blocks mass and most opportunistic surveillance, but a compromised device still wins. Use clean devices, minimal extensions, Tor for sensitive browsing, and keep identities separated. No product can guarantee safety against zero-day, targeted device exploits; our focus is keeping keys off the server and raising the cost for attackers.

How do guest shares behave?

Guests can create one-off, end-to-end encrypted shares with tight limits, shorter expirations, optional burn-after-read, and no history or targeted sharing. Stricter rate limiting applies to keep the service safe from abuse.

What if someone tries to abuse the service for scams?

The product is built for legitimate private sharing. To deter abuse we use tight guest limits, short expirations, rate limiting, and abuse controls while keeping content zero-knowledge. We act on metadata signals and reports and can block abusive traffic under our terms without weakening encryption for everyone else.

Why should I trust this service with my data?

Your content is encrypted on your device; keys stay in the URL fragment, and passphrases never leave your browser. We avoid ads and tracking, keep telemetry minimal (sizes/timestamps/abuse signals only), and publish a clear security model. Even if our servers are breached, attackers only get ciphertext. The client will be open-sourced for independent audit once the codebase stabilizes (with signed builds so binaries match the reviewed source), and we plan external security assessments/ISO-aligned reviews. The backend stays private to protect abuse-mitigation logic and business rules, but it never sees your plaintext.

If we receive lawful requests (regulatory or government/police), we log them and will publish related information whenever legally permitted. Your data remains encrypted end-to-end; only minimal metadata exists to begin with.

What happens to passphrases?

Passphrases never leave your browser and are not stored on our servers. Use strong, unique phrases; password managers may still offer to save them, so disable or decline saving on shared devices.

Do shared links leak referrers or opener info?

Share links open with rel="noopener noreferrer" and the site sets meta name="referrer" content="no-referrer" to avoid sending referrer data or exposing window.opener. Use private windows if you need an extra layer.

How do I move a link to another device?

Use the QR code or the mobile-only “Send to device” action next to Copy. Both keep the key in the fragment so the receiving device can decrypt without the server ever seeing the key or passphrase.