Security
A short route, with clear boundaries.
Transfer in Seconds is designed for live handoffs: the file remains with the sender until a recipient connects, then travels over an encrypted WebRTC data channel.
What protects the transfer
Encrypted in transit. WebRTC data channels use DTLS encryption. When a direct connection is unavailable, an encrypted relay may forward network packets without creating a stored file copy.
Verified on arrival. The receiver calculates a SHA-256 fingerprint and accepts the transfer only when it matches the sender's fingerprint.
One live receiver. The first accepted receiver owns the active session. The sender can revoke availability by closing or resetting the page.
Connection setup
A small amount of signalling data is required to let both browsers find each other. This includes the transfer identifier, connection offers, and network candidates. Transfer in Seconds currently uses PeerJS signalling plus STUN/TURN connectivity services.
The signalling path does not carry the file payload. Network providers can process operational metadata such as IP addresses and connection timing because that is necessary to establish and route a connection.
Important limits
The share link works like a secret: anyone who receives it may attempt to connect. Send it through a trusted channel and compare the displayed safety code when identity matters.
Because file contents are not uploaded to our server, we cannot scan them for malware or enforce data-loss-prevention rules. Only accept files you expect, and follow your organisation's security policy.
Report a vulnerability
Please send a clear description, reproduction steps, and potential impact to hello@transferinseconds.com. Do not access other people's data, degrade the service, or use social engineering while testing.