Four checks before anything opens.
Over the internet, getting to a file means passing every check in turn — and the first two are meant to travel by different routes, so intercepting one gets you nowhere. A wrong attempt doesn't burn the connection: five tries are allowed before it locks and the host has to hand out a fresh key and code.
A key only they have
You generate a one-time connection key and share it directly with the one person who should use it. It works exactly once and expires after 5 minutes.
A code that never travelled with it
A 6-character security code is generated on your machine and never leaves it — send it by a different route than the key. The host checks it first, so a key on its own reaches a machine that will not answer.
A password they know — or guest access you granted
Signing in with a username and password opens what you shared with that person. Without one, they connect as a guest and see only the files you marked for everyone.
Permission for that file
Even then, the person only sees the specific files you shared with them. Everything else stays invisible.
All four checks pass
Ten protections working together.
Pull-only: nothing arrives uninvited
The recipient's client always initiates the request for a specific file. There is no command path in the protocol that lets a sender push a file to a peer — a malicious or unwanted file cannot be delivered without the recipient actively requesting it.
WebRTC transport encryption
Every P2P connection is secured by WebRTC's mandatory DTLS handshake, negotiated directly between the two machines — the same transport security behind browser video calls, not a custom protocol of our own.
A one-time key instead of standing trust
Internet connections are gated by a single-use, 32-character key the host generates and shares out of band — it works exactly once and expires after 5 minutes. On the LAN, the connecting machine's MAC address is checked instead.
A second factor that never travels with the key
Since 1.1 the host also generates a 6-character security code. It is created on the host machine and never passes through the relay, so it is meant to go by a different route than the key — read out on a call while the key goes by chat. The host checks it before credentials and before listing a single file, which makes an intercepted key on its own worthless.
Guests see only what you published
A peer without an account on your machine can be let in deliberately: they still need both the key and the code, and once in they see exactly the files you set to Everyone. Anything narrower requires signing in as a user you created, and the panel tells you how many public files exist before you hand out a key.
Rate-limited, then locked
5 wrong security codes or passwords locks the connection — over the internet or on the LAN — until the host issues a fresh key and code or re-approves the device.
Trusted network ranges
Pre-authorise VPN address ranges (Tailscale, ZeroTier, RFC 1918 private ranges), across every network interface on the machine, so remote teammates connect without weakening the model.
Hashed credentials
Account passwords are stored only as scrypt hashes — never in plaintext, and never written to the access log.
You can verify what you installed
The Windows installer and portable build carry an Authenticode signature issued to Royal SoftWorks, so Windows names the publisher rather than reporting an unknown one and you can check the signature yourself before running it. That signature is also what lets an installed copy confirm the build replacing it came from us. macOS signing is in progress.
An open-source, stateless relay
The relay that introduces two peers holds one in-memory table of pending pairings and nothing else — no database, no disk write. It forgets a pairing the instant its two peers connect, relays only the connection handshake — never a file or a password — and it's open source, so you can audit it or run your own instead of the default.
Every knock at the door, written down for good.
On the Enterprise tier, Privatta keeps its own private log of every attempt to reach your files: who, from which device, which file, and whether it was allowed. Since 1.1 that covers internet sessions as thoroughly as local ones — the connection, every sign-in and refusal, each transfer and the disconnect — with each entry marked LAN or P2P. There is no delete button and no admin override: once an entry is written, nobody can remove or edit it, including you. Passwords never appear in it, and when a device tries its luck too many times, the connection locks until you approve it again.
Bring this to your security review.
The full protocol detail — handshake sequence, identity model, NAT traversal — is documented for procurement and IT architecture teams.