How Volo handles security

Files are not stored

Files aren't uploaded or stored. File data flows directly between the two browsers. Volo has no accounts, no database and no server-side storage for files or messages. Text you share travels the same direct way.

The transfer history and received text shown in a room exist only in that open page's memory. They are gone when the page is reloaded or closed. A file you accept is saved on your own device, and Volo keeps no copy.

How file data travels (direct connection)

Volo uses WebRTC, a technology built into modern browsers, to open a reliable, ordered data channel between the two devices. To find a route, the browsers ask public STUN servers run by Google for their own public network address. They then try to reach each other directly.

Once connected, the sender reads the file in 256KB pieces and sends them over that channel. In desktop Chrome and Edge, the receiver writes each piece straight to the file you chose to save. Other browsers hold the file in memory until it is complete, and are capped at 1GB.

Volo often works across different networks, but same Wi-Fi is most reliable.

Relays (TURN)

Volo does not use a relay (TURN) server today. File data can only flow when the two devices find a direct path to each other. On some networks, such as strict NAT, some corporate networks and some mobile networks, no direct path exists and the devices can't connect.

If a relay is added in the future, the connection would still be encrypted between the two devices. The relay would pass encrypted traffic along and would not be used to store files.

What the signaling server sees

Before two browsers can connect directly, they have to exchange connection details. Volo uses the public PeerJS signaling server (0.peerjs.com) for this. Volo does not operate that server. The signaling server:

• Sees the room code, because the code is the host device's peer ID. The joining device registers as <room code>-guest.
• Relays connection details (session descriptions and ICE candidates). These include the IP addresses and ports each device can be reached on.
• Never receives file contents or the text you share.

Connecting directly also means the other device learns your IP address. This is how WebRTC connections work.

Transport encryption vs end-to-end encryption

Data sent between the two devices is encrypted in transit with DTLS, WebRTC's built-in transport encryption. It cannot be turned off, and it protects data on the network path between the peers.

Volo adds no separate end-to-end encryption layer, and it has no way to compare or verify the two devices' keys, such as a safety code. The encryption keys are agreed through the signaling exchange described above. Your trust therefore depends on that WebRTC connection being set up honestly. In principle, a party able to tamper with signaling messages could try to place itself in the middle, and Volo would not detect it.

Volo also doesn't compute a checksum of each file to compare after it arrives. It relies on the data channel's reliable, ordered delivery.

Room links are the key

Each room code combines a timestamp with 8 random characters from the browser's cryptographic random number generator. The timestamp part is predictable. The random part is what makes a code hard to guess.

• ✓The link is the only access control. Anyone who has it can join while the room is open.
• ✓Rooms are strictly one-to-one. While two devices are connected, a third device is refused with a “room full” message.
• ✓A room has no expiry timer. It stays open until the device that created it closes the tab or disconnects. If the other device leaves, someone else with the link could join.
• ✓Share the link or QR code only with the device you intend to connect, and close the tab when you are done.
• ✓Links you paste into chats, emails or notes stay there, and they also stay in your browser history.

You approve every file

When the other device sends a file, you first see its name and size, then choose Accept or Decline. Volo's sender waits for your answer and sends no file data until you accept. In desktop Chrome and Edge, you also pick where the file is saved.

Text messages are shown in the room without a prompt. They are displayed as plain text and never opened or run. Treat received files like any other download, and only accept files you expect.

Interruptions

Both devices must stay open and online for the whole transfer. If the connection drops or one device goes silent, Volo stops the transfer within seconds. There is no reconnect or resume, and a partially received file is discarded, so you need to send it again.

On iPhone, locking the screen or moving Safari to the background can interrupt a transfer. Where the browser supports it, Volo asks the screen to stay awake while a transfer is running.

Analytics and logs

The site uses Vercel Web Analytics and Speed Insights to count page views and measure performance. Google Analytics is additionally available only after explicit consent and records a small, fixed set of page-view and product milestone events. Before a room page view is sent to either provider, /room/<code> is reported as /room/[id].

Analytics events never contain room codes, transfer or peer IDs, filenames, file metadata, shared text, or raw error messages. Google Analytics can be disabled again from the footer; the full details are in the privacy policy.

Volo is hosted on Vercel, which processes standard request data to serve the site. Volo's own code writes no server logs, has no API routes, and reports errors only to your browser's own developer console.

What we don't claim

• Volo has not had an independent security audit or penetration test.
• Volo holds no security certifications and makes no regulatory compliance claims.
• There is no guarantee that a transfer will succeed or that Volo is safe against every threat.
• Volo is an independent project, not a managed enterprise service.

For highly sensitive material, consider encrypting the file with a tool you trust before sending it, and share the password another way.

Reporting a security issue

If you find a vulnerability, please email umangpancholi555@gmail.comwith a description and the steps to reproduce it. Please give the maintainer a reasonable chance to fix it before disclosing it publicly. Don't include real room links or files you care about in the report.