The problem
Teams regularly paste API keys, recovery codes, database credentials, and configuration files into channels built for permanent conversation. Those messages become searchable, replicated, backed up, and available to more people than the original exchange required.
How the service works
The sender’s browser encrypts content with AES-GCM before upload. The server stores ciphertext, an expiry time, and the information required to return that ciphertext once. The decryption key remains in the URL fragment, which browsers do not send in ordinary HTTP requests. A recipient confirms the open explicitly; the server then atomically claims and deletes the stored record.
Scope: SecretShare has no user accounts and is intended for temporary handoffs. It does not replace a password manager, workload identity, access review, or credential rotation.
Who writes the guides
The SecretShare Editorial Team maintains the learning center. Articles are reviewed against the implemented product behavior and established defensive-security practices. Each guide carries a review date and is updated when its advice, examples, or supporting standards change.
Publishing principles
The learning center is written to stand on its own. Its guidance does not require SecretShare and distinguishes general security practice from product behavior. We prioritize defensive use, precise limitations, reproducible checks, and corrections when a published claim no longer matches the implementation.
Editorial contact
Questions, corrections, and source suggestions can be sent to hello@secretshare.dev. Security vulnerabilities should be reported privately through the channel listed on the security page.