Where your screen actually goes during a session

Every remote access app says "encrypted". They are all telling the truth and it settles less than it sounds, because the useful question is not whether the traffic is encrypted but who sits at the ends of the encryption.

The path, step by step

1. Both devices connect outward to a signalling server. Neither phone has a public address, so neither can be reached directly. The server introduces them: this code belongs to that session, here is how each side might be reached.
2. They try to negotiate a direct path. Each asks a helper server what address it appears to have from outside, then both try the combinations in parallel. This usually works, and when it does the video goes phone to phone without touching anyone's server.
3. If no direct path exists, traffic is relayed. Symmetric NAT, carrier-grade NAT on mobile, a firewall that only permits TCP on 443 — in those cases a relay forwards the packets. It always works and it adds a leg of latency.

What each server can see

This is where "it goes through their servers" means very different things.

• The signalling server sees that two parties want to connect, the session code, and their candidate addresses — so IP addresses and timing. It does not carry your screen or your taps.
• The helper (STUN) server sees a single request asking what your public address is. Nothing else passes through it.
• A relay, when used, carries every packet — but the media is encrypted between the two endpoints and the relay is not one of them. It forwards ciphertext it has no key for. What it knows is that two addresses exchanged traffic, how much, and for how long.

What leaks regardless

No architecture hides all of this, and it is worth knowing what remains visible in the best case:

• That a session happened, between which addresses, when, and for how long.
• Roughly how much data moved, which correlates with what you were doing — watching video looks different from reading a settings screen.
• Your IP address and the other device's, which implies approximate location for both.

If the fact that you connected to a particular device is itself sensitive, content encryption is not the property you need, and no remote access product solves that.

The threats that are not the network

Focusing on the wire is a common mistake, because the realistic risks sit at the ends.

1. Whoever is looking at the phone. The shared screen is also visible on the physical device. Someone next to it sees everything you do.
2. Whoever you gave the code to. A session code is a credential. Read out on a call, pasted into a group chat, or visible in a screenshot, it is a real disclosure path.
3. What is on the screen. Notifications, autofill, keyboard suggestions — see what the other person actually sees.
4. Standing permissions. A tool that can connect without anyone agreeing at the phone is a much larger commitment than a per-session code that expires.

Questions to ask any product

1. Can any of your servers decrypt the session? A design that cannot will say so plainly, because it is a selling point. Evasion is itself an answer.
2. Is there unattended access, and can it be turned off?
3. Does the code expire, and is it per session or permanent?
4. What is logged, for how long, and can you see it?
5. Does the app hide itself in any mode? If yes, that is not a support tool — see where help ends and surveillance begins.

More guides