What File-Sharing Encryption Does and Does Not Protect
Saying simply “it is encrypted, so it is safe” hides which stage is protected. For file sharing, distinguish communication from the sender's device to the server, storage on the server, and what happens after the file is saved on the recipient's device. Encryption is important, but it does not replace checking the recipient or managing passwords.
Think in Three Places
- In Transit
- HTTPS encrypts the connection between the browser and server. It makes it harder for a third party on the network path to read or alter the content directly. Check that the browser address starts with HTTPS and that you have not been redirected to a fake domain.
- On the Server
- Services differ in the state in which they store files they receive. Even if the connection uses HTTPS, the same protection is not necessarily used for storage. Check how each feature is handled in the terms of use and privacy policy.
- After Receipt
- Files saved on the recipient's device, screenshots, and forwarded copies are outside the sharing service's encryption and expiry controls. Include the post-receipt storage location and deletion policy in your operating procedure.
Protection Boundaries by FS!QR Feature
With QR-code sharing, the file is encrypted in the browser before being stored on the server, and HTTPS is used for communication. Because anyone who knows the password can enter the sharing page, protect both the URL and password from reaching third parties.
Under the current specification, Group files and Note text are not stored encrypted on the server. These features prioritize the convenience of handling the same content with multiple people; do not assume they have the same protection boundary as QR sharing. For highly sensitive data, choose a service approved by your organization.
A Password Is Not Necessarily an Encryption Key
Some services use the password to authenticate access to the sharing page. It can prevent entry by someone who knows only the URL, but writing the URL and password in the same email or chat hands over both pieces of information at once. If you sent it to the wrong recipient, consider deleting the share and creating a new one.
- Do not post the URL, sharing ID, or password in a public channel.
- Do not reuse short passwords; use the information issued for each share.
- Understand that a copy on the recipient's device is not deleted when the share expires.
- Move information requiring long-term retention or an audit trail to another management system.
Questions to Ask When Reading an Encryption Description
When reading a service description, ask: “Which features are covered?”, “Is encryption applied on the device, in transit, or at rest?”, “Can the operator decrypt it?”, and “What is deleted after expiry?” In FS!QR, storage states differ between QR sharing, Group, and Note, so it is especially important not to judge by the service name alone.
Conclusion: Do Not Overtrust Encryption
Encryption makes it harder for third parties to read content in transit or at its storage location. It does not prevent misdirected sends, weak credentials, malware on a device, or redistribution by the recipient. First decide what information must be protected and what controls are required, then use only features that meet those conditions.