Privacy & Security
How ShareTexts Protects Your Data
ShareTexts is designed around a simple principle: your data moves between your devices, not through ours. Here's exactly what that means.
In short: Transfers are encrypted between devices. ShareTexts stores no accounts, no chat history, and no copies of your content. Temporary rooms close automatically when you're done.
What Happens to Your Files
During transfer: Your file travels directly between the two connected devices using encrypted browser technology (WebRTC). It doesn't pass through ShareTexts's servers for storage.
After transfer: The file exists only on the two devices that participated. No copy is kept on any server. The temporary room closes and the connection ends.
What the Server Stores
The signaling server maintains temporary room state in memory only — nothing is written to disk or a database.
| Data | Stored? | How Long | Details |
|---|---|---|---|
| Room ID + secret | In memory | Up to 12 hours idle, 4 hours after both peers leave | Used to match pairing codes. Destroyed when room closes. |
| Pairing code | Derived from secret | Rotates every 40 seconds | TOTP-based. Never stored separately. |
| Peer socket IDs | In memory | While connected | Truncated identifiers for message routing. |
| Device names | No | — | Exchanged directly between devices, not stored on server. |
| Files and messages | No | — | Transferred directly between devices via WebRTC. |
| Accounts | No | — | No sign-up, no login, no user profiles. |
| IP addresses | For rate limiting | Per-request | Read from x-forwarded-for header. Used to limit abuse (40 room creates/min, 10 joins/min). Not stored persistently. |
| Aggregate metrics | In memory | Until restart | Anonymous counters (e.g., "rooms.created", "push.text"). No room IDs or content. |
How Encryption Works
ShareTexts uses WebRTC, which encrypts all data in transit using DTLS (Datagram Transport Layer Security). This is the same encryption used by video calling and other secure browser applications.
- All data between devices is encrypted
- Each transfer uses a unique encryption key
- The pairing code authenticates both devices before any data is shared
What the Server Can See
The signaling server can observe:
- Connection metadata — that a room exists, that two sockets are connected to it, and the device names exchanged during the hello handshake.
- Timing — when rooms are created, when peers join, when connections drop.
- Aggregate counts — anonymous metrics like total rooms created, total joins, total pushes.
The server cannot see:
- File contents (encrypted end-to-end via WebRTC)
- Text messages (encrypted end-to-end via WebRTC)
- Transfer metadata like filenames or sizes (exchanged directly between devices)
- User identities (no accounts)
The server logs truncated socket IDs (first 8 characters) and event names for debugging. No file contents, message text, or full IP addresses are logged.
Temporary by Design
Every ShareTexts room is temporary. When you close the tab or the session expires, the room is destroyed. There is no "recover previous session" or "view history" feature because there is nothing to recover or view.
What ShareTexts Does NOT Do
- Store files or messages on any server
- Track usage across sessions (no persistent analytics)
- Sell or share data with third parties
- Use cookies for advertising or analytics
- Require personal information (no accounts, no email, no phone number)
- Log file contents, message text, or filenames
Limitations
No system is perfect. Here's what to be aware of:
- Both devices must be online during the transfer — there is no offline mode.
- Signaling server sees metadata — the server knows a room exists and two devices are connected, but not what they're transferring.
- Relay fallback — if a direct peer-to-peer connection isn't possible, traffic routes through a TURN relay server. The data remains encrypted end-to-end; the relay only forwards encrypted packets.
- IP addresses are used for rate limiting — the server reads your IP to prevent abuse, but does not store it persistently.
- No protection against screenshot/screen recording — the receiving device can capture content after it arrives.
- No protection against a compromised browser — if your browser is compromised, the encryption cannot protect you.