Why the question is hard to answer
"Is the connection encrypted?" is the question remote support vendors are asked most often — and the one that tells you least. Everyone answers yes. The useful question is what data comes into existence at all, what route it takes, and who can see it along the way.
A remote session produces three separate streams that often get lumped together. Separating them is half the answer.
Stream 1: Signalling
Before two machines can talk, they have to find each other. Both usually sit behind a NAT router with no public address. So they check in with a coordination server, exchange candidate addresses and agree on when to punch outwards simultaneously.
That is signaling. It covers:
- sign-in and session identifier
- IP address candidates for both sides, public ones included
- timings for the coordinated NAT traversal
- connection state (connected, dropped, resumed)
The coordination server necessarily sees this — it is the reason the server exists. It therefore knows that a connection existed between two endpoints, when it existed, and the IP addresses of both sides. That is metadata rather than content, but it is not nothing.
Stream 2: The media path
Screen images, mouse movement, keystrokes, clipboard, file transfers. This is the stream most people have in mind, and the only one carrying content.
Here architectures split into two camps, and the difference is bigger than it sounds:
Forwarded through the vendor. The host sends frames to a vendor server, which passes them on to the client. Technically simple and works behind even the harshest firewalls. The price: the data travels through someone else's infrastructure. Whether it is decrypted there is an implementation question — that the bytes physically pass through is not.
Directly between the endpoints. Both sides open their own channel to each other; frames take the shortest path. The vendor never holds the media stream. The price: considerably more engineering, and some network constellations get genuinely difficult.
At WinDesk the second route is not one option among several; it is a fixed commitment: the coordination server forwards no media bytes — no screen content, no input, no clipboard. There is deliberately no TURN fallback, so there is no forwarding path a media stream could divert to when things get hard. We solve difficult NAT cases through signaling instead: synchronised punching, port-range prediction, retry loops.
That has an uncomfortable flip side, and honesty requires naming it: where no fallback path exists, a connection can fail. A vendor with forwarding is more likely to get a session up in such networks. We decided otherwise on purpose — but it is a trade-off, not plain superiority.
Stream 3: What stays behind
The third stream is the one most easily overlooked: what is still there after the session. Per session, WinDesk's server keeps essentially:
- session identifier, start, end, duration
- which account connected, and to which host
- connection type (attended or unattended)
- IP addresses of both sides and a device fingerprint
- billing state
What does not come into existence: no screen content, no input, no clipboard, no recording. That data never crosses our servers, so we cannot retain it — the practical consequence of the architectural decision above.
The key exchange
Encryption is only ever as good as the answer to one question: who knows the keys. A vendor that generates or holds the key can read the traffic, encrypted line or not.
At WinDesk, client and host negotiate the key material directly with each other when the connection is established (elliptic-curve Diffie-Hellman). The coordination server takes no part in that exchange and never learns the session key. It could not read the media stream even if it had it.
How to measure this yourself, with any vendor
You do not have to take anyone's word for it — the data flow can be made visible in ten minutes. Three measurements, no special knowledge required:
1. Where does the traffic go? Start a session between two machines on the same network and use netstat or the resource monitor to see which peers the application is connected to. A sustained, high-throughput connection to a data centre means the media stream runs through the vendor. Traffic straight to the other machine means it is peer-to-peer.
2. How much goes where? The resource monitor shows bytes per connection. A media stream sits at 0.5 to 2 Mbit/s. Signalling sits at a few kilobytes per minute. The difference is not subtle.
3. What is retained? Ask the vendor for a statement of the session data they store. The answer tells you more about the architecture than any datasheet — anyone able to record screen content will have to say so.
What this means for your choice
There is no single right design. If you need sessions through arbitrary firewalls, a forwarding path serves you better. If you want content kept away from anyone outside the two endpoints, you want the opposite.
So the question that actually helps is not "is it encrypted", but:
Which route does the screen data take, who generates the key, and which data stays with whom after the session ends?
Three questions, three checkable answers. Any serious vendor can answer them, and you can measure every one of them yourself.