Encrypted doesn't always mean private

Why privacy still hasn't caught up with video-call technology - and what really happens when you hit "Call".

When I was ten years old - back in the 1980s - video calls were the stuff of science fiction. You could talk to someone on the phone, sure, but seeing their face on a screen while chatting? That lived in spy movies and Star Trek, not real life.

Fast-forward to today: I've built my own secure video-calling platform using WebRTC - fully end-to-end encrypted, ephemeral communication, no logs, no analytics, no metadata trails. In a few words: no trace behind.

But I will tell you more about it next time - in another post )) So, keep reading.

Today, in this article I want to talk about privacy - which still hasn't caught up with technology progress. Most people have no idea what's happening when they click "Join" on a video call. And that little green camera light? It doesn't always tell the full story.

Let's pull back the curtain and learn what is really going on.

What happens when you hit "Call"

Launching a video call looks simple. But behind that one click is a complex negotiation between your browser and the other person's browser, trying to connect.

Ideally, your devices create a peer-to-peer (P2P) connection - meaning your video and audio go straight from one machine to the other, with no third party in the middle. But that's not always possible, thanks to routers, firewalls, and corporate VPNs.

This is where WebRTC (Web Real-Time Communication) does its thing.

STUN: discovering your public-facing route

To start, your device uses STUN (Session Traversal Utilities for NAT - Network Address Translation). STUN helps your browser discover its own public-facing IP address - kind of like stepping outside to see what your house looks like on Google Maps.

That's necessary because most home and office networks use NAT, a method that lets multiple devices share a single public IP address. NAT is great for security, but it makes direct connections between devices more complicated.

If STUN succeeds, you get a fast, direct connection.

TURN: when direct connection fails

If STUN can't establish a direct path, the system falls back to TURN (Traversal Using Relays around NAT). TURN acts like a secure middleman - relaying your media traffic through a server. It's reliable and can still be private, but now your data is passing through infrastructure you don't directly control.

Remember: not all encryption is created equal

To protect your call, WebRTC first performs a secure handshake using DTLS (Datagram Transport Layer Security), which establishes encryption keys. Then the actual media - your video and audio - is encrypted and transmitted using SRTP (Secure Real-Time Protocol).

Yes: WebRTC encrypts your media by default.

And because modern browsers won't allow camera/mic access on unsecured pages, the web app must run on HTTPS (Hypertext Transfer Protocol Secure). Think of that as a second guard rail.

But that doesn't mean your call is automatically private.

Encryption in transit vs end-to-end encryption (E2EE)

There's a key difference between encryption in transit (default WebRTC encryption) and end-to-end encryption (E2EE).

Encryption in transit means the data is protected as it travels, but platform systems may still be able to access it - especially if advanced features require content visibility, or if media is processed somewhere along the way. That's fine for keeping outsiders out, but it still leaves room for internal access.

End-to-end encryption, on the other hand, means that only the people on the call hold the keys to decrypt the data. Even the service provider (and any relay infrastructure) can't see or hear what's happening. Media that travels from A to B and from B to A stays encrypted with keys controlled by A and B.

So if you are using a platform that offers recording, transcription, or AI-powered summaries, your data is likely passing through a system that can "see" your call.

E2EE isn't compatible with those features unless you're running advanced insertable streams and managing your own key exchanges.

So, where privacy slips through the cracks

Even if your media is encrypted, plenty of other data can leak out.

Metadata - who you called, when, and for how long. Many platforms log this data and can hold it indefinitely or share it under legal orders.
IP visibility - in true P2P calls, both participants can see each other's IP addresses, which can reveal general location or corporate network details.
TURN logs - TURN servers can log connection attempts and IPs. If you're using a provider's TURN, those logs aren't under your control.
Smart features - noise suppression, AI assistance, real-time translation often require access to unencrypted audio/video somewhere.

This is why video calls with true E2EE, served over HTTPS, and implemented with privacy as a first-class priority are the only path to truly confidential calls.

Browser vs native apps: a quiet privacy divide

Most people don't think about the difference between browser-based calls and native apps, but it matters.

Browser-based calls - especially WebRTC - run in a tightly controlled sandbox. They don't require installation, and once you close the tab, the environment disappears. Encryption happens on your device, and unless the developer adds tracking manually, there's usually less telemetry.

Native apps, by contrast, have deeper system access. They often run background services, sync contacts, log app usage, and store temporary media. Even if they offer encryption, they can collect more telemetry than you realize.

If you want transparency and minimal data trails, the browser gives you a cleaner slate. Native apps can be more convenient - but they raise more privacy questions.

How do big platforms compare?

Different platforms have very different privacy models - not just encryption, but metadata and analytics, too.

FaceTime: strong end-to-end encryption, but metadata (who/when/how long) still exists; some usage analytics may be collected.
Signal: gold standard for privacy; true E2EE, minimal metadata by design; can relay calls to help mask IP visibility. (It's still a native app - check permissions and device-level footprints.)
WhatsApp: E2EE for content, but within a larger analytics ecosystem where metadata can be correlated across services.
Zoom / Google Meet / Microsoft Teams: typically server-based architectures; encryption in transit is standard, but advanced features can require content visibility; extensive analytics are common.
Self-hosted WebRTC: maximum control; you decide what to log (if anything) and where your relay infrastructure lives.

Hosting your own server - on your desk

Want to go full privacy mode? You don't need a data center. A single-board computer like a Raspberry Pi 5 - a tiny computer the size of your hand - can host your own STUN and TURN servers.

It uses very little power, and with good connectivity it can support a meaningful number of one-to-one calls. Total cost? Often around $50�$120 depending on configuration. Total control? Yes - all yours.

No third-party relay servers. No mystery logs. No subpoena-ready data trails. Just a little box on your desk quietly doing the work of keeping calls private.

Final thoughts

WebRTC is powerful, open, and built into every major browser. It was designed with security in mind - but privacy doesn't happen by default. It depends entirely on implementation and hosting.

To get true confidentiality in your calls, you need:

A secure website served over HTTPS
True E2EE, where only you and the other party hold the keys
P2P when possible, or a self-hosted / trusted TURN server with minimal/no persistent logs

Anything less, and your video call might still be flowing through servers you don't control - leaving behind data you didn't mean to share.

YES - "encrypted" doesn't always mean "private." It is more secure, but real privacy comes from architecture, retention choices, and who controls the infrastructure.

Time for thoughts: what is your take?