文件分享加密能够保护和不能保护的范围
如果只用“因为加密所以安全”来解释，就会忽略究竟保护了哪个阶段。文件分享需要分别考虑从发送设备到服务器的通信、服务器上的存储，以及文件保存到接收设备之后的情况。加密很重要，但不能代替确认收件人或管理密码。
按三个位置分别考虑
- 传输中
- HTTPS 会加密浏览器与服务器之间的连接，使通信路径上的第三方难以直接读取或修改内容。请确认浏览器地址以 HTTPS 开头，并检查是否被带到伪造域名。
- 服务器上
- 服务收到的文件以何种状态保存，各服务并不相同。即使通信使用 HTTPS，保存时也不一定有同样的保护。请在使用条款或隐私政策中确认各功能的处理方式。
- 接收后
- 保存到接收设备的文件、截图和转发副本不受分享服务的加密或期限设置管理。操作流程还应包括接收后的保存位置和删除方针。
FS!QR 各功能的保护范围
二维码分享中，文件会先在浏览器端加密，再保存到服务器，通信使用 HTTPS。由于知道密码的人可以进入分享页面，因此要管理好 URL 和密码，避免两者都落入第三方手中。
按当前规格，Group 文件和 Note 正文不会以加密状态保存在服务器上。这些功能优先考虑多人处理同一内容的便利性，不应认为它们与二维码分享具有相同保护范围。处理高机密数据时，请选择组织批准的服务。
密码不一定是加密密钥
有些服务使用密码对分享页面进行认证。即使知道 URL，没有密码也无法进入，但如果把 URL 和密码写在同一封邮件或聊天中，就等于同时交出了两项信息。发错收件人时，应考虑删除分享并重新创建。
- 不要把 URL、分享 ID 和密码贴到公开频道。
- 不要重复使用短密码，使用每次分享生成的信息。
- 要理解分享期限结束后，接收设备中的副本不会消失。
- 需要长期保存或审计记录的信息，应转移到其他管理系统。
阅读加密说明时要确认的问题
阅读服务说明时，要确认“适用于哪些功能”“加密发生在设备、通信还是存储环节”“运营方能否解密”“期限后会删除什么”。在 FS!QR 中，二维码分享、Group 和 Note 的保存状态不同，因此尤其不能只看服务名称作判断。
不要过度依赖加密的结论
加密技术让第三方更难在传输或存储位置读取内容，但不能防止误发、薄弱的认证信息、设备恶意软件或接收方重新分发。先确定要保护的信息类型和管理要求，再只使用满足这些条件的功能。