How you're protected
What Vivoh.Earth can and cannot see when you broadcast, what your audience can see of each other — and the parts we can't protect you from, stated as plainly as the parts we can.
Your video is encrypted in your browser and decrypted in your viewers'. Nothing in between ever handles a frame it can read — not the CDN that carries it, not the relays that fan it out, not the networks in the middle. That part is structural, and no policy of ours can weaken it.
We hold the key, and you should know it. Vivoh.Earth stores the key for
each event and releases it to the people you let in. That is what makes an event joinable
from a plain link like vivoh.earth/abcde. It also means that if a court
ordered us to produce the key, and someone had captured the encrypted stream, we could not
truthfully say we were unable to help.
That is a deliberate trade, and it is not the one our sibling products
make. e2emoq.com and wallflower.tv put the key in the part of the link after the
#, which browsers never transmit, so their operators genuinely cannot decrypt
anything. They pay for it with a link that breaks the moment a calendar invite or a chat
client trims it, and a secret nobody can read down a phone. If that is the trade you want,
use one of those instead — we build them too, and we would rather you were on the right
one.
This changed on 15 September 2026. Before that date Vivoh.Earth worked the way e2eMoQ and Wallflower still do, and this page said we could not decrypt your stream. That was true then and is not true now. Links issued before the change carry their key in the fragment and remain beyond our reach; every link issued since does not.
What each party sees
| Who | Sees | Cannot see |
|---|---|---|
| Us | That a broadcast happened, when, and how long. The key, and the title, description and standby page of a scheduled event. Not the video itself — we store no recording and the stream does not pass through us | Your location. Your video and audio and chat in practice — we never receive them — but this is now a matter of what we do, not what we are able to do |
| Other people in the room | Your name and picture, once you join. If you open a breakout room, the fact that you invited them and when — the invite itself is sealed, but who it was aimed at has to be readable to deliver it | Anything you have not put in the room |
| The CDN | Encrypted bytes, your IP address, timing | Anything inside those bytes |
| Your viewers | The stream, if you gave them the link — and, when sign-in is required, if they are signed in. In a room, also each other (see below) | Anything outside the broadcast and its room |
| 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.
Broadcasters have accounts. Viewers do not have to.
This is the place where Vivoh.Earth differs most from the anonymous-publishing tools it shares code with, so it is worth being exact rather than flattering.
To broadcast, you sign in — with Google, Microsoft or Discord — and an operator has to have granted your email address permission to publish. That means we hold an account for you: your email, the name and picture your provider gives us, and a row for every broadcast you start. Your broadcasts are therefore linkable to each other, and to you, by us. That is the direct cost of the model, and no amount of encryption changes it.
What we do not hold is what you broadcast. The account tells us that you went live, when, and for how long; there is no recording, and the video itself never passes through our servers. Since 15 September 2026 we do hold the key, so read that as a description of what we keep rather than of what we could obtain — the box at the top of this page is the honest version.
To watch, an account is needed only if the broadcaster asks for one. Require sign-in is on by default precisely so a broadcaster knows who is in the room, but it is the broadcaster's switch, not ours. With it off, a viewer holding the link watches without telling us anything about themselves.
If you need to publish without an account at all, that is a real requirement and this is the wrong service for it. Wallflower.tv runs the same code with sign-in switched off and a passcode mixed into the key itself.
We collect no location data
None — not country, not city, not coordinates, for broadcasters or viewers. Earlier versions of Vivoh.Earth did record broadcaster location. Those records were deleted, the columns that held them were removed from the database, and the backup taken beforehand was destroyed.
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.
Controlling who watches
The link is an address, not a key
Your event link is vivoh.earth/ and five characters. It carries no secret, so
forwarding it is not the same as handing over a key — and losing it to the wrong person is
recoverable, which it was not before. What decides whether someone holding it can actually
watch is the sign-in requirement below.
Send it anywhere a link goes: a calendar invite, a Slack message, an intranet page, the bottom of an email. It survives all of them, which is precisely why it was worth changing.
Requiring sign-in is now the lock, and it is on by default
Require sign-in is ticked for every new broadcast. We refuse to hand the key, or a connection, to anyone who is not signed in to Vivoh.Earth, and the broadcaster can see exactly who is watching, by name.
Read that as load-bearing rather than supplementary, because since 15 September 2026 it is. When the key rode in the link there were two independent locks, and the encryption one did not depend on us at all. Now there is one lock and we enforce it — which means we are in a position to grant it, and in principle to be compelled to. A stream we have no settings row for is treated as sign-in-required, so the failure direction is closed rather than open.
Wallflower.tv, which shares this code, makes the opposite trade: a passcode mixed into the key itself, so that nobody — including its operators — can let a viewer in. That is the right design for an anonymous audience and the wrong one for a company town hall, where the organiser needs to know who is in the room and the link has to survive being emailed around. Vivoh.Earth has no passcode.
Turning a viewer's access off stops them joining immediately. Someone already watching stops within about five seconds: their browser is told the stream has ended and closes the connection.
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 secret as the video, through a different derivation, and our chat server relays text it never sees in the clear. We do not read chat and we store none of it.
The same caveat applies as to the video, and for the same reason: since the key is ours, that is a description of what we do rather than a limit on what we could do. It does mean we cannot moderate chat in any practical sense — nothing readable is ever written down, and there is nothing to go back and look at.
The room: when your audience can see each other
A broadcast can be an ordinary one-way stream, or it can be a room, where the people watching appear to one another as a wall of faces, send reactions, raise a hand, and be called on to speak — with video, if they choose it. The room is off unless you turn it on, per broadcast.
Everything in it is encrypted exactly like the video: names, pictures, reactions and the voice of anyone called on all travel sealed under keys derived from the same share link. The server that relays them holds nothing it can read, and nothing about a room is written to our database — when the last person leaves, there is no roster left behind, because none was ever stored.
But this is a genuine change in who learns something, and encryption is not the right lens for it. Everywhere else on this page the question is what we can see. A room changes what your viewers can see: their names and chosen pictures go to everyone else holding the link. That is the entire point of the feature, and it is also its one real cost. If your audience cannot afford to be visible to each other, leave the room off. Nothing else about your broadcast changes when you do.
Joining is deliberately opt-in twice: you have to enable the room, and each viewer has to press Join before their own name and picture go anywhere. Opening the page makes someone a spectator, not a participant.
Nobody can turn on your microphone or camera but you
When a host calls on you, nothing opens. You are asked, and nothing is captured until you choose — Unmute for your voice alone, or Unmute with video if you also want to be seen. This matters more than it sounds: browsers remember device permission per site, so a page that simply called for the microphone would get no prompt at all from anyone who had ever allowed it once.
A camera is more exposing than a microphone, so it is never implied. The plain Unmute asks for no camera at all, and turning one on is a separate press every time — not a setting you can leave on by mistake.
The property that follows is worth stating plainly, because it is unusual: a host cannot unmute anybody. Only a viewer can. It holds regardless of who the host chose or why — and it holds against us as well, since the prompt is in your browser and not something we can answer on your behalf.
If you do speak, your voice — and your picture, if you chose video — is mixed into the broadcast, so everyone watching hears and sees it. You are part of the programme from that moment: as recordable by any viewer as the rest of the stream, and within reach of the same reporting process. The host can drop you at any time, and you can end your own turn whenever you like.
While you are speaking, your turn travels as its own short encrypted broadcast on the same CDN that carries the programme, under a key that is not the one protecting the stream. Two consequences worth knowing: the CDN carries it as ciphertext exactly like everything else, and holding the share link is not enough to open it — only the presenter can, because only they are given the matching key. Your turn is granted for a few minutes at a time and has to be granted again; there is no standing permission to publish into someone else's broadcast.
The same limit as chat applies, and more sharply. We cannot moderate a room, because we cannot see or hear any of it. Stopping the whole broadcast remains the only lever, for rooms as for everything else.
One honest note about GIF reactions: searching for a GIF sends your search words to us, so that your browser never has to contact Giphy directly and Giphy never learns that you are watching anything. We attach nothing to those words — no stream, no session, no account — and do not log them, but we do see them in the moment, which we would rather say than leave you to discover.
Moderation, and what it costs
Because we can't see what anyone broadcasts — or says in its chat, or shows as their face in its room — we can't police content. What we can do is stop a stream: viewers can report one, and an operator can terminate it. 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.
We still cannot say what a terminated stream contained, produce a recording of it, or tell a complainant what they were shown. Stopping is the whole of what we can do.
The limits
These are real. A page that only listed strengths wouldn't be worth reading.
We hold your key. This is the most important limit on the page and the newest. Because the key is on our servers, the protection your broadcast has against us — and against anyone who can compel us or breach us — is an access rule we enforce, not a mathematical impossibility. We do not watch broadcasts, we keep no recordings, and the stream itself never passes through our servers; but "we don't" is a weaker sentence than "we can't", and we are not going to print the stronger one now that it is false. If you need the stronger one, e2emoq.com and wallflower.tv still provide it.
A link can't be un-sent, but access can be withdrawn. Anyone forwarded your link can try to join; whether they succeed is the sign-in requirement's answer, and you can change it mid-broadcast without changing your link. New link is the blunt instrument: a fresh address and a fresh key, so every copy of the old one stops working at once. Neither can reach someone already watching who simply keeps recording.
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.
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:
- Ask for a stream's key without being signed in, on a stream that requires it, and be refused — the position an outsider is in.
- 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.
- Read the database directly after a report is filed, and confirm the report carries no key — the reporter's evidence link is never stored.
- Try to join a room for a broadcast whose link we don't hold, and be refused.
- As an ordinary viewer, try to take the floor, take it from someone else, or push audio into a broadcast without being given it — and fail at all three.
- Confirm in the code that a microphone can be opened from exactly one place: the button the speaker presses.
Those negative tests share a weakness worth naming, because it is the kind of thing this page exists to be honest about: a test that only ever checks that something was refused passes just as happily when it is broken and checking nothing. So each one also proves it can succeed — the same connection that is refused the microphone is first shown doing something it is genuinely allowed to do. A run where only the refusals pass is treated as a failed run.
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 14 September 2026, when the room, reactions and live questions shipped. Three claims on the previous version of this page had gone stale and were corrected: that viewers could see nothing but the stream, that broadcasting needed no account, and that a person's broadcasts were not linkable to each other. This describes Vivoh.Earth as it runs today; it will be rewritten when that changes rather than quietly left standing.