Proton Meet Isn't What They Told You It Was
Proton built Proton Meet to escape the CLOUD Act. They built it on CLOUD Act infrastructure. Their website promises "not even government agencies" can access your calls. The company routing them hands your call records to the government when asked. Proton hid them from their privacy policy.
Proton’s launch blog post for their new video conferencing product contains this paragraph: “laws like the US CLOUD Act can compel US-owned video conferencing platforms to hand over any data they store, even if the servers reside outside of the United States. This creates serious compliance challenges for organizations bound by GDPR, CCPA, or similar data protection laws. That’s why we’ve created Proton Meet.”
The pitch is that Zoom, Google Meet, and Microsoft Teams are CLOUD Act-subject, and Proton Meet is the safe alternative. Their blog describes the result as “as private as meeting in person.” I spent the launch day investigating that claim. Proton Meet is built entirely on LiveKit Cloud, a US company whose contracts are governed by California law, subject to the CLOUD Act, with an infrastructure chain made up exclusively of American companies.
The disclosure is in Proton Meet's own privacy policy: "Proton Meet relies on infrastructure providers LiveKit Cloud to deliver real-time video conferencing. LiveKit Cloud handles the transmission and routing of data."

LiveKit Cloud is a California-incorporated commercial infrastructure vendor. Their terms of service specify that all disputes are governed by the laws of the State of California, with venue in the federal or state courts of Santa Clara County.

Their privacy policy explicitly acknowledges FTC jurisdiction and states the company will "access, preserve, and disclose your information" to comply with "law enforcement requests, national security requirements, and legal process, such as a court order or subpoena," the exact scope of the CLOUD Act. Proton built their CLOUD Act escape hatch on CLOUD Act infrastructure.
Their security model page compounds this by stating "We utilize a distributed network of data centers around the world like we do for Proton VPN," implying Proton owns and operates the call infrastructure.

The Meet privacy policy confirms LiveKit Cloud handles it. Those data centers belong to DigitalOcean, Google, and Oracle, all American companies under LiveKit's operational control.
I confirmed this at the network layer during a live session. After running ss -tnup to capture a connection baseline, a Proton Meet session in Brave showed active connections to 161.115.177.32 on port 443, a LiveKit-owned IP block (ARIN OrgId LIVEK) hosted on Oracle Cloud Infrastructure, Phoenix, Arizona (AS31898). When a second participant joined with video, a connection appeared to 44.224.75.233, which resolves to ec2-44-224-75-233.us-west-2.compute.amazonaws.com, an Amazon EC2 instance in the us-west-2 Oregon region.
DNS confirms the infrastructure chain: stun.livekit.cloud and turn.livekit.cloud both resolve to Oracle Cloud IPs in Phoenix, and those are the STUN/TURN servers handling WebRTC connection establishment for every Proton Meet call. The browser console during that same session printed livekit-client.esm.mjs:23768 publishing track, LiveKit's own JavaScript SDK, named by filename in the console during an active call.
The browser's Content Security Policy header from meet.proton.me makes the LiveKit dependency explicit. The CSP connect-src directive whitelists wss://*.livekit.cloud, https://*.livekit.cloud, and https://integrations.livekit.io, a permissions declaration built into the browser specifying every server the application can contact.
The CSP also includes wss://*.livekit.proton.me, a subdomain Proton controls, which returned NXDOMAIN on launch day. A future self-hosted SFU on that subdomain could reduce the LiveKit Cloud dependency. At launch, every observed session connected to LiveKit Cloud infrastructure.
The architecture genuinely has two layers. The Proton-controlled layer, the key exchange and MLS cryptographic protocol, runs on Swiss infrastructure: meet-mls.proton.me resolves to 185.70.42.112, AS62371 Proton AG, Plan-les-Ouates, Geneva. The encryption design is real. Proton's business page calls this a "zero-knowledge server architecture," which is true for the MLS key exchange servers in Geneva.
It is not true for the LiveKit SFU servers that process every connection event, see every participant's IP address, and retain call detail records. The SFU routing layer, the servers that carry your actual call, runs on American company infrastructure.
LiveKit's Pinned Region feature lets enterprise customers route audio and video streams through EU nodes in Frankfurt or London; whether Proton has configured that is unconfirmed, and the sessions I observed during the launch window connected to US infrastructure.
What the Pinned Region cannot change is in LiveKit's own Data Processing Addendum: "Observability Data, telemetry, and related logs are stored and processed in the United States regardless of the selected Pinned Region." Call metadata, connection records, and platform telemetry route to the US in every configuration.
LiveKit's disclosed sub-processors confirm where that telemetry lands: Datadog (NYSE: DDOG), a publicly-traded American observability company, processes event logging for LiveKit's infrastructure. Proton Meet connection data flows through Datadog's infrastructure in the United States.
Proton's own Meet privacy policy claims the infrastructure "only processes encrypted data and cannot access any meaningful user information." LiveKit's Data Processing Addendum says they retain call detail records, connection timestamps, IP addresses, and operational metrics as an independent Controller. Those are meaningful enough to build a federal case on.
Proton's privacy policy says they don't store metadata "such as who met with whom after the call ended." Parse that carefully. What's logged during the call is unaddressed. The policy also states "limited technical logs of past calls are kept temporarily for debugging purposes" with no defined duration for "temporarily," the same undefined retention window Proton uses in their email privacy policy for phone numbers.
The exclusions are carefully narrow: they specify no "participant lists or social graphs," but IP addresses and connection timestamps are neither participant lists nor social graphs. The language rules out storing your contact list. It says nothing about storing your IP address hitting an Oracle server in Phoenix.
Proton's security model advertises that "participants can also join meetings anonymously without logging into a Proton account" and criticizes consumer apps like WhatsApp and FaceTime because "these services often default to peer-to-peer connections" where "participants can see each other's IP addresses."

Proton's solution hides your IP from other participants by routing everything through LiveKit's SFU servers. Your IP still hits LiveKit Cloud on Oracle's infrastructure in Phoenix, Arizona.
Anonymous name, anonymous join, your IP address sitting in American infrastructure subject to CLOUD Act subpoenas.
They solved the peer-to-peer IP leak by centralizing every participant's IP at a single US company.
From a government surveillance standpoint, that is worse.
Proton's business-facing page also promises "No tracking and no data collection," which coexists with a 90-day tracking cookie set before login and LiveKit's legally-mandated call detail record retention.

The same page states: "Nobody can ever access your calls, not third parties, AI models, advertisers, hackers, or government agencies. Not even us." LiveKit's privacy policy states they will cooperate with government agencies on legal process. Proton disclosed Zendesk, Stripe, PayPal, and Chargebee in their main privacy policy as data processors with transfer basis and country-of-operation. Proton omitted LiveKit from that list entirely, despite LiveKit handling live call transmission and routing for every Meet user. LiveKit appears only in the Meet-specific sub-policy as an "infrastructure provider," without the country-of-operation and data transfer basis disclosures Proton provides for every other processor on that list.

The same business page markets Proton Meet as "Safeguarded by European sovereignty" with data "kept from U.S. surveillance and foreign access requests." LiveKit Cloud is a US company. Every sub-processor in their chain is American. Telemetry always routes to the US regardless of configuration.
A few more findings from the JS bundle and HTTP headers. Enabling background blur or virtual backgrounds triggers a live HTTP request to storage.googleapis.com to fetch Google's MediaPipe segmentation model, so your IP and timestamp reach Google's servers the moment you enable that feature.
Clicking "Add to Calendar" routes your meeting title, times, timezone, description, and join link directly to Google Calendar or Outlook, both hardcoded in the JavaScript bundle. A 90-day session tracking cookie (Max-Age=7776000) is assigned to every visitor on first page load, before any account login or meeting creation. Three months of tracking on a product marketed as the privacy-first alternative. You haven't logged in or created a meeting, and the cookie is already set.
LiveKit's investors include Jeff Dean, Chief Scientist of Google, so the "Big Tech alternative" routes calls through infrastructure backed by Google's own chief scientist.
From what I found, Proton Meet's encryption is technically real. The MLS protocol is legitimate, the WASM core runs client-side, and the meeting password travels in the URL fragment, which the browser never sends to the server, so Proton's own servers never see it. Those design choices hold up.
They sell Swiss protection from CLOUD Act surveillance while routing calls through an all-American infrastructure stack that explicitly cooperates with US law enforcement, and marketing "trust us, we're Swiss" while the network layer answers Oracle Corporation, Phoenix, Arizona and Amazon EC2, Oregon.
The GitHub repos for the open-source code were published the same day as the launch, with no prior commit history. The audits they cite cover the IETF protocol standard. Proton's implementation has no published review. That I was able to find.
If any of this sounds familiar, it should. Proton Mail used the same playbook: "not even Proton" can access your data, with the asterisk that inbound non-Proton emails are handled in plaintext during receipt before being encrypted to the user's key.
"Swiss privacy" for your inbox, with payments routed through Chargebee and Stripe in the United States. Their own transparency report shows compliance with over 6,000 government orders in 2024 alone.
Proton Meet is the same architecture of promises, the same fine print, identical sub-policies. I'll keep checking as things develop, but this is what the evidence showed on day one.