How you're protected
What e2eMoQ can and cannot see when you broadcast — and the parts we can't protect you from, stated as plainly as the parts we can.
We cannot watch your broadcast. Not as a policy we promise to keep, but
because the key doesn't exist on our side. Your browser encrypts every frame before it
leaves, using a key derived from a secret that lives only in the part of your share link
after the # — and browsers never send that part to a server.
So the secret key never reaches our servers, our database, our logs, or the CDN that carries your video. If we were asked for your stream we would have nothing to give.
What each party sees
| Who | Sees | Cannot see |
|---|---|---|
| Us | That a broadcast happened, when, how long, and how many sessions watched | Your video, your audio, your chat, your location, who watched |
| The CDN | Encrypted bytes, your IP address, timing | Anything inside those bytes |
| Your viewers | The stream, if you gave them the link — and the passcode too, if you set one. Anyone holding the link can also ask how many people are watching | Who those other people are, or anything else |
| Everyone else | Nothing at all | Even encrypted bytes are out of reach without the link |
Your broadcast is also not announced anywhere. There is no directory, no index, no public listing, and nothing published to any outside network that would reveal a stream exists or where it is being carried. The only way anyone learns about your broadcast is because you sent them the link.
You are not an account
There is no sign-up, no email address, no password, and no profile. Broadcasting needs a publish code, which you can request in a few seconds without telling us anything about yourself. We don't store the code, so there is no record connecting you to anything you broadcast — nothing for us to look up, and nothing for anyone to compel from us.
Each broadcast also identifies itself with a fresh cryptographic key that is created in your browser and never leaves it. That means your broadcasts are not linkable to each other, even by us.
What we count
We do record that a broadcast had an audience: for each viewing session, which stream it was, when it began, and when it ended. That is how a broadcaster sees a viewer count, and how we know what our own bandwidth is being used for.
A session is a browser tab, not a person. Nothing attached to it identifies anyone — no IP address, no IP hash, no cookie, no fingerprint, no location. The practical consequence is the part worth checking: because there is no identifier, two sessions can never be shown to be the same human, whether on one stream or across different ones. One viewer who reloads the page is counted twice, and we cannot tell that they were the same person. We accept that inaccuracy deliberately — the only way to fix it is to keep something that identifies a viewer, and that is precisely what must not exist here.
An operator can read and export these counts per stream. What they get is how many sessions watched and for how long. What they cannot get, because it was never recorded, is who.
What a broadcaster sees about their audience
A live count beside the share button, refreshed every five seconds, and behind it a list with one row per viewer: the word Viewer, and how long that session has been open. There are no names and no places in it, because there is nothing of the kind to put there. Two viewers are indistinguishable from one viewer who opened the stream twice.
What is held per session is the whole of it: which stream, when it began, when it ended, a watermark of the last heartbeat, and whether it ended because the viewer left or because the heartbeat stopped. A session also carries the hash of a token held only in that browser tab's memory — that is what lets a viewer end their own session and nobody else's, and it is destroyed with the tab.
Anyone holding your share link can ask how many people are watching. That question is authorised by a tag derived from the link secret, and every viewer necessarily has that secret — it is the thing that decrypts your video. Our viewer page never shows the number, but the service would answer someone who asked it directly, and they would learn the audience size and how long each session had been open. So audience size is visible to everyone you gave the link to, not only to you. It is not public: without the link there is no tag, and the answer is the same "offline" a stranger gets for a stream that does not exist.
The count is of tabs, and it is generous rather than exact. A viewer who reloads can be counted twice for up to two and a half minutes, because the abandoned session is only closed once its heartbeat has been silent for 150 seconds. A viewer whose network drops is credited with what we actually saw — their last heartbeat — rather than with the moment we noticed. Neither can be improved without keeping something that identifies a viewer across sessions, which is the one thing this table must not contain.
These rows are kept indefinitely at present. There is a retention setting that deletes viewing sessions older than a given number of days, and it is not switched on, so the sessions recorded since this table was built are still there. They say that somebody watched a stream for a while; they do not say who, so age does not make them more revealing — but "we delete them" is not a claim we can make today, and this page will say so until it is.
Controlling who watches
The link is the key
Anyone holding your complete share link can watch. Anyone without it cannot — not even someone who knows your stream's name, and not us. Treat the link the way you'd treat a door key, and send it through a channel you trust.
The passcode is a second lock, and you switch it on
By default, your link is the only thing needed to watch. Anyone you send it to can open it; anyone without it cannot. For most broadcasts that is the whole of what people want, and it is what you get without touching anything.
Under Protect there is a second secret. Switch it on and a viewer needs the passcode as well as the link. It is deliberately not part of the link — send it separately, by a different app or out loud — so intercepting one channel gets an eavesdropper nothing. The control reads Protected for as long as it is armed, because a passcode you have forgotten you set is a room nobody can get into.
Decide before you go live. Once you go live the choice is frozen, because by then every link you have sent already carries the answer, and changing it would strand the people holding those links. Encryption itself is never optional and cannot be switched off; the passcode governs only whether the link is sufficient on its own.
This default has moved twice and it is worth being straight about why it moved back. It was on by default until 28 August 2026, on the argument that a protection nobody enables protects nobody — which we still think is true. What it left out is who pays for it: a second secret has to reach every viewer by a second route, and someone sending a link to five friends does not want a second errand, they want the link to work. It was also put in front of people before they had done anything, as a decision they had not asked to make. A protection that makes the ordinary case harder gets switched off rather than used, and this one mostly was.
Re-keying it mid-broadcast takes effect within a second or two: anyone watching with the old passcode stops being able to decrypt, and your link doesn't change. (The change lands on the next keyframe, so the picture they already have finishes first.)
Or start a new link
If the link itself has gone somewhere you didn't intend, New link is the blunt fix. It ends the current broadcast and starts another one with a new address and a new key, so nothing that was shared before still works. Your camera and microphone stay exactly as you had them — only the address changes — but everyone watching drops, so you'll need to send the new link to the people you still want there.
Chat is protected the same way
Messages and display names are encrypted in your browser under a key derived from the same link. Our chat server relays text it cannot read. That also means we cannot moderate chat — there is nothing there for us to read.
Why there is no DRM
Studios protect video with DRM: the picture is decrypted inside hardware the browser cannot reach, and travels to the screen on a path the operating system guards. It is why a Netflix window comes out black in a screen recording. We do not do that and will not, and the reason is worth saying plainly rather than leaving it to look like something we never got around to.
DRM and end-to-end encryption defend against opposite people. DRM protects a distributor from the viewer — the viewer is the adversary, and it works by putting a license server in the middle to hand out keys on conditions. End-to-end encryption protects you from us — we are the adversary, and it works by making sure nobody but the two ends ever holds a key at all.
You cannot have both, and that is structural rather than a matter of effort. A protected path needs a key authority, and a key authority is the exact thing we have built ourselves out of being. The day we could deliver your video to a guarded screen is the day we held a key to it — and a key we hold is a key that can be demanded from us. Every other claim on this page rests on our not having one.
It is worth knowing what DRM would buy you even if we built it, because it is less than it sounds. Software DRM is captured routinely. Hardware DRM is beaten by a phone pointed at the screen, as it has been since the first camcorder. The choice was never between leakproof and leaky. It was between leaky with a license server and leaky without one, and we took the second — the same choice that lets us tell you we cannot watch.
The cost is real and worth naming: we will never carry licensed studio content, because those contracts require the protected path we refuse to build. That door is closed on purpose.
Moderation, and what it costs
Because we can't see what anyone broadcasts, we can't police content. What we can do is stop a stream. Terminating takes effect for people already watching — it doesn't merely stop new ones — and it works whether or not the software they're using cooperates.
There is no in-product reporting path, and that is a real cost rather than an oversight. On a service that cannot see its own traffic, a viewer holding a share link is the only party who can observe a problem at all — so removing the report button removes the only sensor an operator ever had. What is left is out-of-band: somebody has to email us. That is slower, it reaches nobody who does not already know where to write, and it is the honest description of where this service stands.
Nothing is stored from a broadcast in any case. We cannot say what a terminated stream contained, produce a recording of it, or show a complainant anything at all. Stopping is the whole of what we can do, and now it is the whole of what we can be asked to do.
The limits
These are real. A page that only listed strengths wouldn't be worth reading.
A link can't be recalled. Once you've sent it, anyone who receives it — or is forwarded it — can watch. We can't revoke it for one person, because we can't decrypt it either. What you can do is cut off everyone: New link starts a fresh broadcast under a new address and a new key, so every copy of the old link stops working — including ours, if we had kept one. If you set a passcode, re-keying it is the finer instrument: it cuts people off without changing your link or interrupting the broadcast. Without one, New link is the only instrument you have.
Anyone watching can record. A viewer's own device necessarily decodes your video to display it, so it can also save it. No system that shows people video can prevent this, and we don't claim to. Why we do not even try is answered at Why there is no DRM.
Your IP address is visible to the network. The CDN that carries your stream sees the address you connect from, and so does Cloudflare, which serves this site. We don't store it — but we can't hide it from them. If being located matters to you, use a VPN or Tor. That's the one protection we can't provide for you.
We can see that you broadcast, even if not what. Times, durations and how much data moved are visible to us and to the CDN. Encryption hides content, not the fact that something happened.
How to know this is true
None of the above is taken on trust internally either. Each claim is checked against the running service by automated tests, and the ones that matter most are the negative ones — tests that try to break a promise and must fail:
- Open a live stream without the
#part of the link — the position we're in — and nothing decodes. - Watch what the chat server actually receives, and confirm the text isn't in it.
- Terminate a stream while a deliberately uncooperative viewer is watching, and confirm it stops anyway.
A fuller written assessment, including every known weakness and its severity, is kept as a dated security posture document. Ask and we'll send you the current one.
Last reviewed 28 August 2026. This describes e2eMoQ as it runs today; it will be rewritten when that changes rather than quietly left standing.