Held

Here. For a while.

What Held protects, and where the limits are

Held is designed to keep message, chat, and file contents between participating browsers. That design depends on the delivered application, cooperating browsers, and the coordination service following the protocol. Held has not received an independent security audit.

Read the privacy information

Encrypted content, visible connection metadata

The intended application exchanges encrypted messages, chat posts, files, filenames, room names, and peer signing identities directly over browser-to-browser connections. Its coordination server handles admission, live-session leases, and connection setup; it does not receive message or file payloads.

The server still sees room identifiers, room status, session control information, and signaling. Hosting and connection-discovery providers can observe addresses and timing, and peers may learn network addresses. Held provides no IP anonymity or promise that provider logs are deleted. Ended rooms retain server records that prevent their IDs from being reused.

Secret links grant access; IDs identify keys

The secret fragment of a room link supplies the reading capability. Anyone who obtains the complete link may be able to join while a holder keeps the room available. Avoid publishing it or submitting it to a URL shortener.

Automatic signing identities differ by room. A saved identity deliberately reuses the same public key across future sessions, allowing peers to recognize it. Fingerprints authenticate signing keys, not real-world identities. A local identity seed persists in the browser; exporting a backup creates a saved copy under your control.

Temporary access is not remote erasure

Message text and chat history are held in memory rather than a server mailbox. Received file pieces use a temporary encrypted device cache with a separate key kept in memory. Leaving or losing session access invalidates that key and starts cleanup; crashes can leave encrypted pieces until a later cleanup or clearing site data.

Creator-held messages require the original creator session. Carried messages and group chats require at least one admitted holder. Connection loss and expiry end access under those rules; there is no read-once destruction guarantee.

Recipients can save text, screenshots, files, or ciphertext together with its key. Held cannot erase those copies, browser history, clipboard history, operating-system copies, or provider backups. Original file metadata is not scrubbed.

Trust your endpoint and distinguish the tools

A compromised browser, extension, device, dependency, or delivered frontend can access content available to that endpoint. Direct WebRTC connections can fail on restrictive networks, and the registry remains necessary for availability. Held offers no guaranteed delivery or complete chat history.

The Short link tool stores ordinary destination URLs on the server until expiry and is not end-to-end encrypted. Feedback is also separate: its text and optional email are stored for the creator to read. A disguised voice recording changes the sound, but cannot guarantee anonymity.

Review the public security guide when evaluating Held. Automated checks support development; they do not replace an independent security assessment.

Ready when you are.

No account needed. Encryption and peer connections run in your browser.

Read the privacy information