Security Architecture & Boundaries

1. Security Overview

ShareOnline is engineered around the principle of zero custody. We do not store, buffer, or retain user files on our infrastructure. By utilizing browser-standard WebRTC DataChannels, data flows directly between the sender and receiver without passing through application file servers.

2. Transport Encryption

All direct peer-to-peer data channels enforce Datagram Transport Layer Security (DTLS) encryption as required by the WebRTC specification (RFC 8826 and RFC 8827):

• Cryptographic Standards: Modern browsers negotiate DTLS 1.2 or DTLS 1.3 with authenticated cipher suites (such as AES-GCM or ChaCha20-Poly1305).
• Endpoint-Generated Keys: Ephemeral encryption keys are generated directly inside each participant's browser sandbox and exchanged during the DTLS handshake.
• Protection Against Eavesdropping: Intermediate network routers, internet service providers, and Wi-Fi operators cannot decrypt or read the transmitted file payload.

3. WebRTC Security Architecture

WebRTC operates under strict browser security models:

• Browser Sandboxing: All WebRTC network operations execute within the standard browser security sandbox, preventing direct access to the client filesystem without explicit user interaction.
• Origin Isolation & CSP: ShareOnline enforces strict Content Security Policies (CSP), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Strict-Transport-Security (HSTS) to prevent cross-site scripting and framing attacks.

4. Session Security

Transfer rooms are protected by ephemeral, high-entropy identifiers:

• Random Room Codes: Generated using alphanumeric character sets excluding ambiguous glyphs.
• Automatic Session Expiration: Rooms remain valid for a maximum of 15 minutes of inactivity before being purged automatically.
• Immediate Termination: Closing either browser window closes the WebRTC peer connection immediately.

5. Server-Side Storage Policy

ShareOnline maintains zero server-side file storage. There are no relational databases storing uploaded files, no object storage buckets (such as S3 or Cloudflare R2) receiving file chunks, and no temporary disk caches. Transmitted bytes exist exclusively in volatile memory on the client devices.

6. Metadata Processing & Retention

To negotiate peer connections, the signaling broker processes minimal session metadata:

• Room codes and connection timestamps (purged upon session completion or 15-minute expiration).
• WebRTC SDP offers and answers (session connection parameters).
• Client IP addresses processed in memory strictly for sliding-window rate limiting to prevent denial-of-service abuse.

7. Known Limitations & Threat Model Boundaries

We believe in technical honesty regarding security boundaries:

• Peer IP Disclosure: To establish a direct peer-to-peer UDP connection, WebRTC ICE candidates exchange network IP addresses between the two participating devices. If you need complete IP anonymity from your recipient, route your browser traffic through a VPN.
• Recipient Authentication: Anyone with the room code or QR code can connect while the sender is waiting. Senders must share room codes only through trusted, secure channels.
• Endpoint Security: If either device has malware or an insecure browser, the security of the transferred file depends on the health of the host operating system.

8. Security Reporting & Vulnerability Disclosure

If you identify a security vulnerability or security concern in ShareOnline, please report it immediately through our Safety & Abuse Reporting form. Reports are reviewed promptly by our engineering team.