Security
Security Architecture
How ShareText protects your transfers — from pairing to encrypted transfer to completion.
Summary: All data between devices is encrypted using DTLS via WebRTC. Pairing uses TOTP-based codes. Files are verified with SHA-256 checksums. No data is stored on any server. Rooms expire automatically.
Encryption
In-transit encryption: All data between devices is encrypted using DTLS (Datagram Transport Layer Security) over WebRTC DataChannels. This is the same encryption standard used by secure web browsing and video calling.
How DTLS Works
When two devices connect via WebRTC, they perform a DTLS handshake — the same type of key exchange used by HTTPS. After the handshake, all data flowing between the devices is encrypted with a unique session key. No one else — including ShareText's servers — can read the data in transit.
Key Properties
| Property | Implementation |
|---|---|
| Encryption protocol | DTLS 1.2 over WebRTC DataChannel |
| Key exchange | DTLS handshake during connection setup |
| Session uniqueness | Each connection generates a fresh key |
| Forward secrecy | Ephemeral keys — compromising one session doesn't affect others |
Pairing Security
ShareText uses TOTP (Time-based One-Time Password) for device pairing:
- 6-digit rotating codes — change every 40 seconds
- Server-authoritative — the server validates codes, not the client
- Timing window — ±1 period tolerance so typing isn't interrupted
- No code reuse — each code is valid for one connection window
File Integrity
Algorithm: SHA-256 (Secure Hash Algorithm, 256-bit)
Scope: Every file transfer includes a checksum verification
Process: Sender computes checksum before sending. Receiver computes after receiving.
Result: If checksums match, the file arrived intact. If not, ShareText flags the discrepancy.
Room Security
- Temporary rooms — expire automatically after a set period
- Limited peers — maximum 2 devices per room
- Secret-based access — room secret is a 128-bit random value
- No persistence — rooms exist only in server memory, not on disk
- Rate limiting — creation and join attempts are rate-limited per IP
API Security
- Bearer token authentication — agent API requires room secret
- Timing-safe comparison — secrets compared using constant-time equality
- Size limits — text (256KB) and file (8MB) caps on agent pushes
- Rate limiting — 40 pushes per minute per IP
- CORS allowlist — only configured frontend origins can connect
What ShareText Cannot See
- File contents (encrypted end-to-end)
- Text messages (encrypted end-to-end)
- Transfer metadata (not logged)
- User identities (no accounts)
- IP addresses after connection (not stored)
What ShareText Can See
- That a room exists (room ID)
- That two devices are connected (peer IDs)
- Connection metadata (for signaling)
- Aggregate metrics (anonymous counters)
Known Limitations
- Both devices must be online during transfer
- Relay fallback: if direct connection fails, data passes through a TURN relay (still encrypted)
- Signaling server sees connection metadata (not content)
- No protection against screenshot/screen recording on the receiving device
- No protection against a compromised browser