In an instant transfer on Transferify, the file goes from your browser to your recipient's browser. It is not uploaded first, and it is never stored on our servers. Our service introduces the two browsers to each other. The file is encrypted twice on the way, runs over several connections at once for speed, and the recipient's browser sets the pace so neither side runs out of memory.
This post explains each of those steps. For the comparison with hosted transfers, see peer-to-peer and hosted transfers.
One instant transfer. Our service checks the link and introduces the browsers. The file goes between the two browsers, through a TURN relay only when a network blocks a direct connection. The key travels in the link you share.
Step 1: the link is ready before anything is sent
When you choose an instant transfer, your browser registers the transfer with our service: the files' details and the options you picked. No file bytes are sent. Once the service answers, your browser makes a new AES-256 key for this transfer and adds it to the share link after the "#". Browsers do not send that part of a link to any server, so the key never reaches our service.
The link works straight away. Your tab now holds the files and waits for recipients.
Step 2: the two browsers find each other
When your recipient opens the link, their browser first asks our service about the transfer. The service checks the link: that it has not expired, that the password is right if you set one, and that its download limit is not used up. Only after those checks does it tell the recipient's browser which browser to contact.
Two browsers on different networks cannot simply call each other. They exchange connection details through our signaling service, which passes short messages between them over a WebSocket. Those messages describe how to connect. They carry no file data and no key. Then each browser works out how it can be reached:
- STUN. Public STUN servers tell each browser its address as the internet sees it, which is enough for most home and office networks.
- TURN, when needed. Some networks block direct connections. For those, our service creates relay credentials on request, valid for 24 hours rather than permanently, and the connection runs through a TURN relay instead.
Fetching relay credentials never holds a transfer up for long: if they take more than two seconds, the browsers start with STUN alone, and the credentials are used on the next connection attempt.
A relay forwards the encrypted stream. It cannot read it.
Step 3: encrypted twice
Every WebRTC data channel is encrypted with DTLS between the two browsers. That alone protects the file from anyone watching the network, including the relay.
DTLS has one dependency, though. Each browser proves its identity with a certificate fingerprint, and those fingerprints travel through the signaling service. A signaling server that was compromised could swap them and place itself in the middle, and DTLS would not notice.
Two layers of encryption on a peer-to-peer transfer. DTLS protects the connection; the inner AES-256-GCM layer, keyed from the link, still protects the file if the signaling service were dishonest.
So Transferify adds its own layer. Your browser seals every piece of the file with AES-256-GCM, using the key from the link, before the piece enters the connection. The signaling service never sees that key. A server in the middle would only see encrypted pieces, and any change it made would fail the recipient's check. Each piece is also bound to this transfer, this file and its position, so pieces cannot be reordered, dropped or swapped with another file's.
This layer cannot be switched off. If your browser cannot set it up, the transfer does not start, and a recipient's browser only accepts encrypted pieces.
Step 4: several connections at once
One WebRTC connection rarely uses a fast line fully, because each connection raises its sending rate cautiously on its own. So a recipient's browser asks yours to run the transfer over four connections in parallel, each with its own route and its own rate. The two browsers use the smaller of the numbers each side allows, never more than eight.
Your browser deals the pieces out across the connections in turn, and the recipient's browser puts them back in order. The connections succeed or fail together: if one drops, the transfer to that recipient stops as a whole.
Step 5: the recipient sets the pace
A network can deliver pieces faster than a slow disk can save them. Without a limit, the waiting pieces would pile up in the recipient's memory until the browser gave up.
Instead, the recipient's browser grants your browser a budget of 32 MiB of encrypted data at a time, and tops it up as pieces are decrypted and written out. Your browser only sends while it has budget left. If the recipient pauses the download, your browser simply waits, and carries on the moment the download moves again.
On the recipient's side, each piece is decrypted and checked as it arrives and streamed into a normal browser download through the site's own download handler, which runs inside the recipient's browser, so even a very large file never has to fit in memory. If any check fails, that download is cancelled rather than saved. On a browser where the download handler is not available, files up to 1 GiB are assembled in memory, and larger ones cannot be received there.
Step 6: you see who has the file
When the recipient's browser has a file whole, it sends your browser a receipt for it. Your page lists each recipient who opened the link and how far they have got, and counts a file as delivered when the recipient's receipt says it arrived whole.
Several recipients can download at the same time, each over their own connections to your browser.
What ends a transfer
- You close the tab. Your browser is where the file is served from, so the transfer stops.
- You delete the transfer. Our service tells your tab, which closes every recipient's connection at once. The file streams from your browser, not from our service, so the instruction has to reach your browser, and it does. The same happens if we suspend a transfer after abuse reports.
- The link reaches its expiry date. New recipients can no longer open it.
When to use it
Instant transfers suit large files when you can keep the tab open until your recipient has them. If you cannot, a hosted transfer keeps an encrypted copy online.
Try it
Pick a file, choose an instant transfer and send the link to a second device of your own: you will see it appear on your page and stream across. Start an instant transfer.
Top comments (0)