Browser-Side Encryption for Secret Sharing

Encrypt before content leaves the sender

For a Strumio SecretLink, the sender's browser generates random key material and encrypts message and file plaintext with the Web Crypto API before upload. The service receives ciphertext and delivery settings rather than the readable protected content. This differs from storage-only encryption performed after a server has already received plaintext.

Local encryption narrows which systems need plaintext, but the surrounding application still performs network requests and processes operational information. Creation time, expiration, one-time status, account relationships, abuse controls, and network data may be needed to operate the service. Browser-side encryption should not be described as invisibility or anonymity.

Decrypt in the recipient's browser

A complete SecretLink carries the random key in its URL fragment after the # character. Browsers do not include that fragment in normal HTTP requests. The recipient browser uses it after retrieving ciphertext, so decryption occurs on the endpoint rather than on Strumio's server.

That complete URL is therefore sensitive. Forwarding it, placing it in a public document, synchronizing it through an exposed clipboard, or scanning its QR code can transfer access. An optional password and expiration can add barriers, but they do not prove the human identity of whoever holds the complete capability.

Understand authentication and integrity

AES-GCM is authenticated encryption: successful decryption also checks an authentication tag so altered ciphertext is rejected rather than silently becoming changed plaintext. Random nonces and keys must be generated and handled correctly by the implementation. Users should not copy ciphertext into home-built tools or invent alternate key formats.

Cryptographic integrity does not certify the sender's real-world identity or make an attachment benign. Verify important senders through a known channel, check the Strumio domain, and treat unexpected macros, archives, and executables cautiously. A valid encrypted file can still contain unsafe or misleading material.

Treat endpoints as part of the security boundary

The sender sees plaintext before encryption and the recipient sees it after decryption. Malware, hostile extensions, screen recording, remote support, synchronized clipboards, browser debugging, screenshots, and deliberate copying can capture content at either end. Use updated devices you control and close unnecessary observation tools.

One-time retrieval and expiration limit future service retrieval, not the first viewer's actions. If the underlying item is a credential, create it with least privilege and rotate it after a temporary handoff. If a downloaded document needs ongoing controls, place it in an approved access-controlled records system.

Choose browser encryption for focused delivery

Browser-encrypted links are useful when you want to keep plaintext out of ordinary email or chat history and need a focused delivery with optional password, expiration, file, or one-time controls. Temporary encrypted chat is more suitable when participants need back-and-forth discussion.

For durable team access, use individual accounts, a password manager, secrets manager, or document platform with ownership, audit, revocation, and recovery. Browser-side encryption is an important technical layer, not a replacement for recipient verification, endpoint security, retention policy, or credential lifecycle management.

Related guidance

When an encrypted delivery link is appropriate, Create a free Strumio account.