Native's servers help two of your machines find each other and then get out of the way. Your files move directly between them, encrypted, and we never hold a copy — not briefly, not in a cache, not for any plan.
Four steps. Only the first involves us.
Each machine publishes a small amount of connection information so the other can find it. That is the whole of our server's job, and it is the only part of a transfer we are involved in.
The two machines negotiate a WebRTC data channel secured with DTLS. If they're on the same local network it stays on that network and never reaches the internet. Otherwise it crosses the internet directly, machine to machine.
Your network passphrase derives a key on your own machine — 250,000 rounds of PBKDF2 against a per-network salt — which authorises the connection and encrypts the signalling and metadata that set it up. The passphrase never leaves your device and the key is never transmitted. Our servers see neither.
File contents are encrypted by the channel itself, end to end between your two machines. There is no third party in that path to decrypt anything, because we never receive the bytes at all.
The sender accumulates a rolling hash as it reads, and the receiver checks the file it wrote against it before the file is given its final name. A truncated or corrupted transfer is reported as one rather than silently landing.
Being direct is not the same as being invisible, and we'd rather tell you the shape of what's left than imply there's nothing.
We see that an address exists, when its device was last reachable, and the connection information it published while a transfer was being set up — which includes IP addresses, because that is how two machines find each other. We see that a transfer happened, its size and file count, and whether it completed. We do not see file contents, and we do not see the bytes themselves travel, because they don't come near us.
Every security page lists what a product does. These are the limits, named plainly, because a limit you discover later is worse than one you were told.
The passphrase is the key. There is no copy of it on our side, no escrow and no reset. If you lose it and lose the device, the address is gone and you start over with a new one. That is the cost of us not being able to read your files, and we think it's the right trade.
When you send to a machine that's asleep, the bytes wait on your disk — not on a server. So Native has to stay running on the sending machine for the transfer to complete later. Quit it and the queue waits until you open it again.
A completed transfer is checked against a hash the sender accumulates as it reads. One that was interrupted and resumed currently isn't — the sender doesn't send a hash covering the part it already delivered, so the file is accepted on the strength of the transfer id alone. On a multi-hour transfer that's exactly the case most likely to need checking, and it's the next thing we're fixing.
That's what makes it an address. Anyone who knows or guesses it can see that it exists and whether it's currently reachable. They cannot send you anything without the passphrase or a link you minted, and they cannot see anything about your files.
A few networks block direct connections entirely. On plans that include relay fallback, the encrypted stream passes through a relay we operate. It cannot read the contents — the keys are derived on your devices — but it necessarily observes that a connection exists, how long it lasts and how much data crosses it.
The passphrase authorises access to the network. If you've shared it and want to take that back, the current answer is to generate a new one, which disconnects everyone. Per-person revocation is built for named links and is being extended to the passphrase itself.
No third party has reviewed this. We're saying so rather than letting a page of cryptography terms imply otherwise.
If you find a vulnerability, write to security@usenative.com. We'll acknowledge it, and we won't threaten you for having looked.