Is it safe to give you my stream credentials?

Two formats, one rule: your login and stream URLs, never readable

We’re new, and we know exactly what pasting an IPTV login into a website you found last week feels like. So the vault assumes you won’t trust us: your subscription isn’t safe because we’re careful — it’s safe because it reaches us already sealed, or not at all.

An Xtream login is the clean case. Creating the source sends us one field: the panel’s host name, which is not a secret. Your browser fetches the catalogue, builds the channel list on your device, and seals your login and each channel’s stream URL — before anything is uploaded. What lands on our side: the channel names and groups in the clear, so your guide and search load fast, plus that sealed login and those sealed URLs, sealed at rest. Your login in the clear is never written anywhere — no readable row, no log line. Catalogue calls and stream dials do route through us — they have to leave from our VPN exits, or your provider would see your home IP — but they pass through in memory and land nowhere.

An M3U link is the awkward case, so we’ll be exact. The URL itself usually carries your username and password, and the playlist behind it has to be fetched before there’s anything to seal. So the link reaches our server once: held in RAM, used for one outbound TLS request, relayed back as raw bytes for your device to parse and seal. Never stored — not in the database, not in logs, not in headers, not in any cache. The honest claim for M3U is “never stored”, not “never left your device”. If you’re offered both formats, pick Xtream — sealed on your device beats passing through ours, even once.

How the sealing works, end to end

“Encrypted” on a pricing page can mean anything from a TLS certificate to a database column with the key taped next to it. Here is ours, mechanism by mechanism. Your browser generates a 256-bit key with WebCrypto — the browser’s own cryptography, run on your device. That key is the account. There is no password.

HKDF-SHA256 derives a key-encryption key — a KEK — from it, and the KEK wraps the DEK, the data-encryption key that seals your provider login and stream URLs, URL by URL, with AES-256-GCM. “Wraps” means the DEK is itself stored encrypted: at rest, the envelope stays sealed. To play a channel, your browser unwraps the DEK and hands the server a session copy, which opens the vault in memory for that session and is wiped when you go idle or the server restarts.

Sign-in is the same key doing a second job. Your device derives an Ed25519 keypair and sends us the public half. The server sends a nonce — a number used once — your browser signs it, we check the signature against your public key. That’s challenge–response: nothing reusable crosses the wire, so there’s nothing to phish — and nothing for us to reset. A service that can email you a password reset holds something it can read. We can’t, so we don’t.

Add it up: at rest, the server’s entire stored holding for your vault is ciphertext, your public key, and wrapped key envelopes. Each is safe to show a stranger. That was the design test — not “is this protected” but “would it matter if it leaked”.

What we can see — and what we can’t

What we can see, plainly. Any email you’ve attached. When you sign in. How many sources you have, and how large the sealed blob is. Your channel names, groups, and logos, too — those stay in the clear so your guide and search work. While you watch: that bytes are flowing through the blind relay to your player — it reads the few framing bytes needed to cut the stream into pieces and forwards the rest unread. No decoder on the box; what’s inside isn’t something we decline to look at, it’s something the machine can’t parse. The byte path’s access log keeps a timestamp and a token, nothing about what you watched.

What the design withholds: your Xtream password, never stored; your M3U link at rest, ciphertext; each channel’s stream URL, same; the inside of your streams, unreadable by the relay. The disclosed residual is the in-memory moments above — the one playlist fetch; the unsealed login held in server memory while you’re signed in, to dial your channels; the dial that opens a channel URL for the instant it takes to connect, then drops it. Moments in RAM, wiped on idle or restart; nothing readable at rest. We’d rather draw that line precisely than draw it flattering.

If twiga is breached

Assume the worst: an attacker walks off with the whole database. They hold account emails, sign-in records, and a pile of vaults — ciphertext with public keys and wrapped envelopes beside it. That pile now includes the recovery material too: a second copy of each envelope wrapped under your recovery code, plus two fingerprints. The envelopes need your key, which was generated on your device and which we never store; the second copy needs the recovery code, which we never took; and the fingerprint that gates a restore opens nothing and can’t authorize a new key by itself. AES-256-GCM without the key isn’t a puzzle that yields to effort. A stolen copy of our database is a box of locked envelopes, not a list of logins — and not a way to mint a key into one, either.

We won’t pretend that’s nothing: your email is real data, and a breach would be disclosed as the incident it is. Your channel names would be visible — they always are, that’s how search and the guide work — but your provider login and every channel’s stream URL would leak as ciphertext. Which is to say: they wouldn’t.

If you lose your key

At setup you save a recovery code. It derives a second KEK, which wraps a second copy of the DEK; we store that envelope and a verifier — a one-way fingerprint that confirms you know the code without us ever holding it. You hold two openers; we store none.

Lose only the key — code still in hand — and you’re not locked out. On the restore screen your device stretches the code, proves it to us, and we hand back the recovery-wrapped copy of your DEK; the code opens it, and your vault rotates onto a brand-new key and a fresh recovery code. Every old session is signed out. The swap is authorized by a signature only the old recovery code can make, so a stolen database can neither open the envelope nor forge the rotation. Nothing you’d sealed is re-encrypted — the same DEK carries over, your sources intact. Save the new code somewhere your new key isn’t.

Lose both and there’s no way back in — not for you, not for us, not for anyone we could be compelled to help. No reset email, because there’s no password; no back door, because a door for you is a door for whoever shows up dressed as you. We know “we can’t help you” is a strange sentence to put on a trust page. It’s also the entire proof: the inability that locks you out of a lost vault locks us out of every vault. You start over with a new invite. Nothing leaks — your provider login was never stored readable. Keep the code somewhere your key isn’t — a password manager works for both.

The receipts

Plain language is cheap; here’s where to check it. The manifesto lays out the five theses and the architecture that carries them. The privacy page lists what is logged and what is never logged, with your rights beside it. The wiki entries on AES-256-GCM, the blind relay, and VPN exits each go a layer deeper than this page. Find a claim that doesn’t hold? Write to [email protected] — not a courtesy line, the bug tracker for this page.

Quick answers

Can twiga employees see my channel list?

Partially, and we’d rather say exactly which half. Channel names, groups, and logos sit in our database in the clear — that’s what lets your guide load and search work, and yes, it means an admin could see your account has a channel called “BBC One”. What stays shut: your provider login and every channel’s actual stream URL, ciphertext at rest, sealed under keys derived from a key you hold. There is no admin view, no support tool, and no database query that unseals either one — they’re opened only in server memory while you watch, never from anything stored.

Do you store my Xtream password?

No. Creating an Xtream source sends us the panel’s host name and nothing else. Your username and password are sealed into the vault on your device; the requests that use them pass through our relay in memory only, so they can leave from our VPN exits instead of your home IP. Neither is ever written to our database or our logs.

Do you store my M3U playlist URL?

No — but it does pass through once, and we’d rather say so than round it off. The link has to reach our server to fetch your channel list: one outbound TLS request, held in RAM, never stored — not in the database, not in logs, not in headers, not in caches. What lands afterwards: channel names and groups in the clear, so your guide and search work, and each stream URL sealed with a key only you hold.

What happens if twiga’s servers are hacked?

The attacker gets what we have: account emails, sign-in records, channel names and groups in the clear, and sealed vaults — ciphertext, public keys, and wrapped key envelopes — including the recovery copies, which need the recovery code we never hold and can’t authorize a new key on their own. Without your key the envelopes stay shut, so your provider login and every channel’s stream URL leak in no readable form. Your email and your channel names are the real exposure — TV listings, not something an attacker can act on — and a breach would be disclosed as a real incident.