ManyScreens Back to the front page

How it works, and what it can and cannot see

Remote access is a thing you hand your whole computer to, so this page says exactly what happens to the picture, what the servers hold, and what ManyScreens does not have. The last section is the honest list.

The shape of it

ManyScreens has three parts. An app on the computer you want to reach, which captures the screen and injects the mouse and keyboard. A viewer, which is a plain web page in your browser. And a small server in Berlin that introduces the two and then gets out of the way.

The picture never goes through that server. The app and the browser build a WebRTC peer connection: on the same network they find each other directly and nothing leaves the building, and across the internet they punch through both routers. When that fails — a carrier-grade NAT, a corporate firewall that allows nothing but web traffic — the stream falls back to a TURN relay in Frankfurt, which forwards packets without the keys to read them.

What each piece can see

Part	Where	What it sees
The app on your computer	Your machine	Everything, by definition. It is the thing sharing the screen. It notifies you when someone starts watching (and on a Mac shows a dot in the menu bar), names each connection with its address, and one switch ends them all.
The signalling server	Berlin, Germany (IONOS)	Which account owns which computer, when a browser asked to connect and from which address, and the sealed WebRTC negotiation it passes between the two sides without opening. Never the screen, the input, the sound or the clipboard.
The relay	Frankfurt, Germany (Oracle Cloud)	Encrypted packets and the two addresses they travel between. It has no key. It is used only when a direct path cannot be built.
The STUN servers	Berlin (ManyScreens) and Google	To find a direct path, the app and the browser ask both which public address they appear from. They see that address and nothing else.
Your browser	Wherever you are	The session, and thumbnails of your own computers kept in that browser's own storage so the list is not empty on the next visit. Those never leave it.

The encryption, by name

Screen, sound and input travel as a WebRTC peer connection: DTLS-SRTP, negotiated between the two machines, with the keys held only by them.
The relay is TURN over TLS on port 443. It forwards what it cannot decrypt, and its credentials expire after twelve hours.
Everything between your browser and the server is HTTPS with HSTS, and a content security policy that permits two foreign origins: Paddle's checkout on the Pro page, and Cloudflare's bot check on the sign-in page.
Passwords are hashed with argon2. Device tokens and session tokens are 256 random bits, stored only as SHA-256 hashes, so the database does not hold anything that could be replayed.
Two-factor sign-in, once switched on under Settings → Account, is TOTP (RFC 6238): a six-digit code from an authenticator app at every sign-in, each code accepted once, and after five wrong codes the account waits up to 15 minutes. Eight single-use recovery codes cover a lost phone and are stored only as SHA-256 hashes. A password reset by email changes the password but does not sign you in: the code is still asked for.

The one exception: a macOS login window

Apple does not let anyone but Apple capture a Mac's login screen, so ManyScreens does not reinvent it — it carries Apple's own Screen Sharing to your browser instead. That stream is VNC inside the WebSocket to the server, not a WebRTC peer connection, so on that path the transport is TLS to the server rather than end to end between the machines. It only applies before anyone has logged in, the service is off until you switch it on, and a guest code can never reach it.

What is stored about you

An email address, an argon2 hash of the password, with two-factor sign-in on its authenticator key and a hash of each unused recovery code, the names you gave your computers and when each was last seen, one row per signed-in browser, and the timings of sessions so the service can be operated. No screen contents, no keystrokes, no clipboard, no files: none of that ever reaches the server to be stored.

The site sets no analytics and no tracking cookies, loads no third-party fonts, and pulls in no foreign script except Paddle's checkout on the Pro page and Cloudflare's bot check on the sign-in page. Payment details are Paddle's; they never touch this server.

The consent you can see

A notification when someone starts watching, one line per connection with Disconnect on it, and on a Mac a dot in the menu bar for as long as anyone is connected.
One switch stops sharing: every live session ends, the next is refused, and the person at the other end is told why rather than left staring at a frozen frame.
A stranger can only arrive through a guest code, which is shown on the shared machine's own screen, lasts ten minutes, works exactly once, and still has to be approved by whoever is sitting there. A refused code is spent. A guest can never be promoted into a computer on your account.
Every browser you have signed in from is a row you can revoke on its own, plus "sign out everywhere else". A browser you have not called your own keeps a session that dies when the browser closes.

What ManyScreens does not have

Stated plainly, because a security page that only lists strengths is not one.

No independent security audit and no bug bounty. One developer wrote it and no external party has reviewed it.
Not open source, and not self-hostable. If running your own infrastructure is the requirement, RustDesk or MeshCentral are the honest answer.
No audit log or per-session email. The host shows who is connected now; it does not keep a history you can read back.
No view-only mode. A session that can look can also control.
The Windows installer is not code-signed yet, so Windows warns about an unknown publisher. The macOS builds are signed with an Apple Developer ID and notarised.
One server, one database. There is no cluster and no failover; nightly off-site backups and uptime monitoring are planned, not running.
Computer numbers in URLs are sequential. Access is checked by ownership on every request, so guessing one gains nothing, but they are not secret.

Reporting something

If you find a security problem, please report it before publishing it, and you will get an answer. A security contact address on this domain is being set up and will be listed here.