RELICBEAM · PRIVACY

Privacy Policy

Last updated: October 4, 2026

The short version

No accounts. No email addresses. No contact lists. Rooms, Quick Beams, and Beam Links are temporary. Room files and standard Beam Link files are uploaded to RelicBeam, scanned for known malware, then encrypted at rest while they remain available. Quick Beam always encrypts files end-to-end. Beam Link also offers an optional Private E2EE file mode: file contents are encrypted in the sender's browser, RelicBeam stores only ciphertext for delivery, and those contents cannot be malware-scanned by RelicBeam. Quick Beam text/password messages are end-to-end encrypted in the browsers; the server only handles encrypted payloads for those messages. Room text is ordinary temporary Room content and is not E2EE. Convert tools run locally in your browser and do not upload the file being converted. Device Portal (Remote View and Remote Files) uses end-to-end-encrypted WebRTC between the connected browsers for screen streaming, folder browsing, and file transfer. It connects the browsers directly when possible and can fall back to RelicBeam's TURN relay when networks prevent a direct path. RelicBeam does not record or store the Remote View screen/audio stream or Remote Files transfer as server files.

Where end-to-end encryption applies

Quick Beam text/password messages are end-to-end encrypted. A temporary AES-256-GCM message key is created in the browser and shared with the other device using an ephemeral P-256 ECDH key exchange. The RelicBeam server relays public-key material, a wrapped session key, and encrypted message payloads; it does not receive the ECDH private keys or raw Quick Beam text key.

Device Portal (Remote View and Remote Files) is end-to-end encrypted between the connected browsers. These features use WebRTC. RelicBeam handles temporary signaling so the browsers can connect, and its TURN server may relay encrypted WebRTC packets when a direct path is unavailable, but the TURN relay does not terminate the peer connection or receive the Remote View screen/audio stream or Remote Files file contents as plaintext server files.

Standard server-backed file sharing is not end-to-end encrypted. Room files and standard Beam Link files use server-side malware scanning, which means the server must be able to access actual file content during upload and scanning. That standard path is: upload → temporary plaintext processing → malware scan → encryption at rest → download → automatic deletion. Large standard files are uploaded in resumable chunks; those chunks and the assembled file are temporary plaintext data until the scan finishes. Clean files are then stored encrypted using AES-256-GCM. Temporary plaintext upload/scan data is removed after processing.

Quick Beam files are always end-to-end encrypted; Beam Link offers optional Private E2EE. On these encrypted paths, the file contents are encrypted in the browser with AES-256-GCM before upload. RelicBeam receives and temporarily stores ciphertext, not the plaintext file contents, so the server cannot malware-scan those contents. Quick Beam derives a per-file key from its browser-only E2EE session key. Beam Link creates a separate browser-generated key carried in the URL fragment after #; URL fragments are not sent to the RelicBeam server. RelicBeam still handles operational metadata needed to deliver the file, such as the temporary share identifier, filename, size, and MIME type.

Room text is also not end-to-end encrypted because it is intentionally published to the people in that Room. We do not manually inspect, open, preview, or review users' files or shared text as part of operating RelicBeam. Server logs use internal IDs rather than filenames or shared content.

What we handle

Files you choose to share. Room files and standard Beam Link files are temporarily stored so they can be malware-scanned and delivered; clean files are encrypted at rest after scanning. For every Quick Beam file, or when you enable Private E2EE for a Beam Link file, RelicBeam temporarily stores the browser-encrypted ciphertext instead and cannot inspect or malware-scan the plaintext contents. Files are automatically deleted according to the session rules below.

Text, links, codes, and passwords you choose to share. Room text exists as temporary Room content and is deleted when the Room ends. Quick Beam text/password messages are stored only as end-to-end-encrypted payloads during the active Quick Beam and are deleted when that session ends. Password mode adds visual masking on top of the same Quick Beam E2EE used for ordinary text.

A random browser/device identifier. RelicBeam stores a random ID in localStorage. It lets the service recognize that two tabs belong to the same browser and enforce the single-recipient rules for Quick Beam. It is not tied to a name or email. Clearing site data resets it.

Temporary host recovery state. While a Room or Beam Link is active, the creator capability and session details may be kept in sessionStorage so refreshing the same browser session can restore creator controls. This state is local to that browser session.

Share-to-RelicBeam staging on supported devices. When an installed PWA receives a file through the operating system's Share menu, the item may be staged locally in the browser's IndexedDB long enough to create a Quick Beam and upload it. This staging is on the device, not a separate RelicBeam cloud library.

Remote View connection data. Remote View uses encrypted WebRTC screen streaming and may include a display/tab audio track when the browser provides one. RelicBeam keeps that audio off by default; after the secure connection is live, the sharer can explicitly enable or disable it without stopping the screen share. Remote View does not request microphone access. RelicBeam relays temporary session signaling (such as connection descriptions and network candidates) so the browsers can connect. Cloudflare's public STUN service helps discover a direct route; when a direct route is not possible, RelicBeam's TURN server may relay the encrypted WebRTC traffic. The TURN relay forwards encrypted packets and RelicBeam does not record or store the screen/audio stream. As with normal WebRTC, peers and relay infrastructure process network addresses needed to establish the connection.

Remote Files connection data. Remote Files exposes directory listings/search results for one folder explicitly selected by the host and transfers requested file bytes over an end-to-end-encrypted WebRTC data channel. RelicBeam relays temporary signaling and may relay encrypted traffic through its TURN server when a direct peer connection is unavailable, but it does not write Remote Files manifests or transferred files into RelicBeam server file storage. Access is read-only by default. On supported browsers the folder owner may explicitly grant write permission and enable additive uploads; the feature exposes no remote delete, rename, move, or overwrite action. Because Remote Files uploads do not pass through RelicBeam server file storage, they are not scanned by RelicBeam's ClamAV pipeline.

Network information such as an IP address. RelicBeam's infrastructure necessarily handles connection information so requests can be delivered and rate limits can be enforced. We do not keep a user profile or a history that maps IP addresses to Rooms, filenames, or shared text.

Anonymous operational counters

RelicBeam keeps small aggregate counters so the operator can understand whether the service is healthy and being used. Examples include total Rooms, Quick Beams, and Beam Links created, files uploaded, bytes transferred, downloads, malware blocks, scan failures, rate-limit hits, forced closures, and counts of successful local Convert operations such as PDF merges, splits, reorders, rotations, image conversion, and HEIC conversion.

These counters are not tied to a user, IP address, device ID, Room code, filename, or shared content. They are counts, not activity histories. RelicBeam does not use Google Analytics, advertising pixels, or tracking cookies.

How long things last

Rooms close when the host ends them, when everyone has left for about a minute, or automatically after 6 hours, whichever comes first. Files and shared text in the Room are deleted when it closes.
Quick Beams have no fixed time limit. They close after both devices disconnect and a two-minute reconnect grace period passes. Abandoned setup is also removed after this grace period. A shared file is deleted after the intended recipient genuinely downloads it. Previewing a supported file does not count as that final download.
Beam Links carry one temporary file and use the expiry chosen by the creator (currently 1 hour, 6 hours, 1 day, 3 days, or 7 days). A creator can also choose one-time deletion after the first successful download.
Remote View codes wait for a viewer for up to about 10 minutes. Once approved, a Remote View session is capped at 2 hours and ends earlier when either side leaves or the sharer stops screen sharing.
Remote Files codes wait for another device for up to about 10 minutes. Normal approved sessions are capped at 2 hours. If the host explicitly enables Away Access for the already approved viewer device, the session may remain reconnectable for 1 hour, 8 hours, 24 hours, 3 days, or 7 days. Folder access still exists only while the host computer is awake/online, the original host tab stays open, and the browser retains the selected folder permission. Ending host access revokes it immediately.
Unfinished resumable uploads are temporary. Idle upload sessions are cleaned up after about an hour, and orphaned chunk data is removed when the server restarts.
Local Share Target staging is kept only on the device until RelicBeam consumes or clears the pending item.
Aggregate counters described above may persist across server restarts and deployments because they contain no session content or user identity.

Malware scanning

Room files and standard Beam Link files are scanned with ClamAV before they become available to other people. In production, if the scanner is unavailable, RelicBeam fails closed rather than knowingly publishing an unscanned standard file. Files identified as infected are blocked and deleted. Private E2EE files in Quick Beam and Beam Link are intentionally not scanned because RelicBeam does not have the plaintext contents or decryption key. Remote Files transfers also bypass the server scan because they travel over end-to-end-encrypted WebRTC. Malware scanning uses known signatures and heuristics and cannot guarantee that a file is safe.

Convert tools stay local

RelicBeam's image and PDF tools — including image conversion, HEIC conversion, PDF merge/split, page reordering/rotation, PDF-to-images, and images-to-PDF — run in your browser. The file being converted is not uploaded to the RelicBeam server. Browser capabilities and memory limits can still affect whether a conversion succeeds.

What RelicBeam's operator can see

The protected admin dashboard is intentionally limited. It can show active Room/Quick Beam metadata, active Beam Link identifiers and basic operational details, server health, storage and upload status, and anonymous aggregate counters. It does not show filenames, file contents, shared text, passwords, or a user activity history. The operator can force-close an active Room or Quick Beam and can delete a specific active Beam Link when needed for abuse response, legal compliance, security, or service stability.

Third parties involved in running RelicBeam

RelicBeam uses infrastructure providers to operate the service:

Cloudflare sits in front of RelicBeam for HTTPS, network protection, and the tunnel to the origin. Network traffic, including uploads and downloads, passes through Cloudflare's infrastructure as part of delivering the service.
Hetzner hosts the server in Germany. Temporary standard-upload data, encrypted-at-rest standard files, and Private E2EE ciphertext are stored on that server while the relevant temporary session is active.
Google Fonts serves the site's typefaces. Loading a font can create a request to Google's servers. Google Fonts does not receive the files or text you share through RelicBeam from us.

Children's privacy

RelicBeam is not designed to collect personal profiles from anyone, including children. Because there are no accounts, we generally do not know a user's age. Anyone using RelicBeam should follow the rules that apply to them where they live, and adults responsible for minors should decide whether the service is appropriate for a particular classroom or activity.

Changes to this policy

RelicBeam will change over time. If a change affects how data is handled, this page and the date above will be updated to describe the new behavior.

Questions or concerns

If anything here is unclear, or you want to report misuse or a privacy concern, email [email protected].