Warp: browser-to-browser file transfer where the server provably can't see your bytes (WebRTC/DTLS, open source)
Warp is an open-source browser-to-browser file transfer application that uses WebRTC and DTLS to enable end-to-end encrypted peer-to-peer file transfers. The server only acts as a signaling broker for connection setup and never sees or stores any file data. This design ensures that file contents remain private from the server, ISPs, and network intermediaries. However, Warp does not use TURN relays, so transfers fail if both peers are behind symmetric NATs that prevent direct connection. The signaling server does see metadata such as connection timing and IP addresses. The project is open source and can be self-hosted to verify the code and trust model.
AI Analysis
Technical Summary
Warp provides a peer-to-peer file transfer mechanism using WebRTC data channels secured by DTLS encryption, where encryption keys are generated and held only in the browsers of the two peers. The server component is limited to WebSocket signaling that facilitates the SDP/ICE handshake to establish direct peer connections. No file bytes transit or are stored on the server, preserving confidentiality against the server operator and network observers. The lack of TURN relay means that if NAT traversal fails due to symmetric NATs on both ends, the transfer fails with an explicit error rather than silently relaying through a server, maintaining the privacy guarantee. Signaling metadata such as session initiation and IP addresses are visible to the signaling server. The entire system is open source under the MIT license, allowing users to self-host and audit the code. The threat surface includes the signaling server and the ICE path, but no known exploits or vulnerabilities have been reported.
Potential Impact
The impact is primarily related to the privacy and confidentiality of file transfers. Because file data never transits the server and is end-to-end encrypted, the server operator and network intermediaries cannot access the transferred file contents. However, signaling metadata (connection timing and IP addresses) is exposed to the signaling server. There are no known exploits or vulnerabilities reported, and the design intentionally avoids server-side data exposure. The lack of TURN relay can cause transfer failures in some network configurations but does not degrade security.
Mitigation Recommendations
No specific security vulnerabilities or exploits have been reported for Warp. The project is open source and can be self-hosted to ensure trust in the signaling server and client code. Users should be aware that signaling metadata is visible to the server and that transfers may fail if both peers are behind symmetric NATs due to the absence of TURN relay. No patch or fix is applicable as this is a design and architectural approach rather than a vulnerability. Users should verify the code and deploy their own signaling server if they require full control over metadata.
Warp: browser-to-browser file transfer where the server provably can't see your bytes (WebRTC/DTLS, open source)
Description
Warp is an open-source browser-to-browser file transfer application that uses WebRTC and DTLS to enable end-to-end encrypted peer-to-peer file transfers. The server only acts as a signaling broker for connection setup and never sees or stores any file data. This design ensures that file contents remain private from the server, ISPs, and network intermediaries. However, Warp does not use TURN relays, so transfers fail if both peers are behind symmetric NATs that prevent direct connection. The signaling server does see metadata such as connection timing and IP addresses. The project is open source and can be self-hosted to verify the code and trust model.
Reddit Discussion
Sharing this here for the threat model rather than as a "check out my app" post, because the interesting part is what the server is architecturally prevented from seeing.
Most "send a file" services are a trust-me box: you upload plaintext (or "encrypted, but we hold the keys") to someone's bucket and hope. Warp is built so the operator cannot be a meaningful adversary:
- The only server component is a WebSocket signaling worker. It brokers the SDP/ICE handshake to introduce two peers, then steps out. No file byte ever transits it. You can watch the network tab: the transfer traffic goes peer-to-peer, not to my origin.
- The actual transfer rides the WebRTC data channel, which is DTLS-encrypted end to end. Keys are generated in-browser and never leave the two endpoints. Your ISP, the coffee-shop AP doing a MITM, and the signaling server all see ciphertext only.
- No account, no stored file, no cloud bucket. Nothing at rest to subpoena, leak, or expire.
Honest limitations, since this crowd will (correctly) poke at them:
- No TURN relay by design. If both peers are behind symmetric NATs and STUN can't establish a path, it fails with a real error instead of silently relaying through a server. That keeps the "server never sees bytes" guarantee true, at the cost of some hostile-NAT pairs not connecting. Same-LAN and most NAT combos punch through fine.
- Trust still rests on the client you're served. It's open source (MIT) and you can self-host the whole thing (static frontend + a free Cloudflare Worker), so you can verify the code that runs and pin it yourself.
- Signaling metadata (that peer A and peer B connected, when, and their IPs during ICE) is visible to the signaling server, like any WebRTC app. It's the file contents that stay private, not the fact a session happened.
Repo + protocol write-up: https://github.com/Ishannaik/warp Threat-model / how-it-works deep dive (NAT, STUN, DTLS, chunking, and why a truly-free relay is impossible): https://warp.ishannaik.com/how
Interested in where you'd attack this. The signaling worker and the ICE path are the obvious surface.
Links cited in this discussion
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Warp provides a peer-to-peer file transfer mechanism using WebRTC data channels secured by DTLS encryption, where encryption keys are generated and held only in the browsers of the two peers. The server component is limited to WebSocket signaling that facilitates the SDP/ICE handshake to establish direct peer connections. No file bytes transit or are stored on the server, preserving confidentiality against the server operator and network observers. The lack of TURN relay means that if NAT traversal fails due to symmetric NATs on both ends, the transfer fails with an explicit error rather than silently relaying through a server, maintaining the privacy guarantee. Signaling metadata such as session initiation and IP addresses are visible to the signaling server. The entire system is open source under the MIT license, allowing users to self-host and audit the code. The threat surface includes the signaling server and the ICE path, but no known exploits or vulnerabilities have been reported.
Potential Impact
The impact is primarily related to the privacy and confidentiality of file transfers. Because file data never transits the server and is end-to-end encrypted, the server operator and network intermediaries cannot access the transferred file contents. However, signaling metadata (connection timing and IP addresses) is exposed to the signaling server. There are no known exploits or vulnerabilities reported, and the design intentionally avoids server-side data exposure. The lack of TURN relay can cause transfer failures in some network configurations but does not degrade security.
Mitigation Recommendations
No specific security vulnerabilities or exploits have been reported for Warp. The project is open source and can be self-hosted to ensure trust in the signaling server and client code. Users should be aware that signaling metadata is visible to the server and that transfers may fail if both peers are behind symmetric NATs due to the absence of TURN relay. No patch or fix is applicable as this is a design and architectural approach rather than a vulnerability. Users should verify the code and deploy their own signaling server if they require full control over metadata.
Technical Details
- Source Type
- Subreddit
- ExploitDev+pwned+hacking
- Reddit Score
- 0
- Discussion Level
- minimal
- Content Source
- reddit_link_post
- Post Type
- link
- Domain
- null
- Newsworthiness Assessment
- {"score":38,"reasons":["external_link","newsworthy_keywords:rce","established_author","recent_news"],"isNewsworthy":true,"foundNewsworthy":["rce"],"foundNonNewsworthy":[]}
- Has External Source
- true
- Trusted Domain
- false
Threat ID: 6a57969d68715ace43dded5f
Added to database: 07/15/2026, 14:18:05 UTC
Last enriched: 07/15/2026, 14:19:22 UTC
Last updated: 07/15/2026, 16:47:40 UTC
Views: 4
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.