经常问的问题
- 为什么这个网站翻译得不好？ ⎃
- 这项服务的安全性如何？
- 为什么我在这里收到一个链接，其中包含解密消息的选项？
- 你删除所有提交到这个网站的东西？
- 为什么要使用这项服务？
- 这是消息服务吗？
- 预期用例是什么？
- 该服务不应该用于什么？
- 为什么不直接使用 PGP/Signal/OMEMO/Matrix/etc.？
- 存在哪些要求？
- 收件人可以复制邮件吗？
- 是否收集任何个人信息？
- 记录了哪些信息？
- 你在做什么来保护服务器？
- 使用本网站时存在哪些安全风险？
- 你对中间人 (MITM) 攻击做了什么？
- 浏览器扩展有哪些优势？
- 我如何确定提交的任何内容都是端到端加密的？
- 端到端加密如何在此站点上工作？
- 解密密码可以在URL中吗？
- 但是解密密码不一定要在URL中？
- 此服务不将链接传递给收件人？
- 如何在使用此服务时尽可能保护我的隐私？
- 如果我不信任美国怎么办？
- 你在做什么来防止垃圾邮件？
- 为什么有一个选项要求接收者完成验证码？
- 谁在运行这项服务，为什么它是免费的？
- 我如何才能相信上述问题的答案？
为什么这个网站翻译得不好？ ⎃
抱歉，目前的作者只会说英语。我们需要帮助将这个项目翻译成其他语言。作为向不会说英语的人提供这项服务的一种简单且廉价的方式，我们使用机器翻译。结果通常是可以接受的，但可能会导致措辞奇怪甚至完全不准确的信息。您可以帮助我们改善每个人的体验 -请提交正确的翻译。
这项服务的安全性如何？
我们已采取许多措施来确保此服务在其预期用途中的安全性。在我们完成这些步骤之前，了解以下内容很重要：
- 由于端到端加密，我们无法读取您的消息，但生成的默认链接包含解密密码/密钥；因此，拥有该链接的任何人都可以阅读您的消息——包括任何能够拦截它的人。
- 该服务只是一种工具，允许通过更持久的传统传输（即电子邮件/文本/即时消息/网站/等）发送不太持久的通信（即在检索时删除的加密消息）。这意味着当您使用此工具时，所选传输（即电子邮件）固有的任何安全/隐私问题都会被继承。
- 还有其他可用的解决方案可根据您的需求和环境提供更好的安全性。与其他服务相比，该服务提供的主要优势是对收件人的要求要低得多（即他们只需要一个网络浏览器和点击链接的能力）。
- 虽然默认设置是在检索时删除邮件，但没有什么可以阻止收件人进行复制。请记住，这适用于所有临时消息解决方案 - 如果接收方可以看到该消息，则可以对其进行复制。
- 所有 Internet 通信都可能损害您的隐私——您是在为了方便而牺牲一些安全性。
- 由于一些基本问题，网络在安全方面是一个具有挑战性的环境 - 这适用于所有网站。但是，基于网络确实可以更轻松地验证我们的声明，即我们无法阅读您的消息。
- 本网站及其数据库位于美国。我们使用总部位于美国的 Cloudflare 作为我们的内容交付网络（所有网络流量都通过该网络）。
- 使用该服务不需要任何个人信息（即姓名/电子邮件/电话/等）。没有账户系统（即登录名/密码等）；因此，任何数据泄露都不会泄露此信息。
- 所有消息内容都是端到端加密的。换句话说，解密密钥/密码永远不会发送给我们。因此，我们或拥有数据库的任何其他人都无法解密和查看消息内容。
- 我们数据库中的每个条目都有一个从 1 分钟到 2 周（默认为 1 周）的生存时间。一旦过了这个时间，该记录将被自动删除。因此，我们数据库中的任何信息将在创建后不久被删除。
- 我们只维护最近 24 小时的网络服务器日志。存储在数据库中的任何 IP 信息都经过安全哈希处理，因此无法提取原始 IP。
- 支持此服务的所有代码都是开源的，可供审查。您可以很容易地看到运行加密的代码- 故意简短、简洁和注释。
- 采取了许多技术预防措施来帮助加强安全性 - 其中一些包括：
- 除了 /api 之外的整个网站都是静态的，并且不支持页面中的服务器代码（即 PHP/JSP/ASP/等）
- Web Crypto API是浏览器的一部分，用于加密所有消息内容。
- TLS 用于加密您的浏览器和我们的服务器之间的通信。它有助于确保代码在传输过程中不会被拦截或修改。支持 TLS 1.3，但我们也支持旧设备的 TLS 1.2。旧版本的 TLS 被禁用，因为它们不那么安全。
- Certificate Transparency日志会受到监控，以防止证书误发。此外，我们还发布了证书颁发机构授权 (CAA) 政策，以降低意外或恶意证书误发的风险。
- 我们利用HTTP 严格传输安全 (HSTS)来确保浏览器始终使用 TLS 协议与我们的服务器进行通信。此外，我们将我们的域包含在预加载列表中。
- 执行严格的内容安全策略以防止跨站点脚本 (XSS) 攻击。
- 通过使用跨源资源策略、跨源嵌入器策略和跨源开启器策略，我们禁止跨源代码，以帮助减轻诸如 Spectre 和 Meltdown 之类的推测性侧信道攻击。这还通过将浏览上下文专门隔离到同源文档来防止来自其他来源的潜在恶意请求。
- 我们采用权限政策来防止浏览器加载可能损害您隐私的资源，例如您的位置、网络摄像头、麦克风等。
- DNSSEC用于我们所有的域，以帮助缓解基于 DNS 的 MITM 攻击。
- 我们采取了许多预防措施来保护服务器。
- 没有加载第 3 方代码（即 jQuery）并且加载的资源很少（继续并打开开发工具中的网络选项卡进行检查） - 这最大限度地减少了审核所需的工作量。一个例外是如果需要验证码 - 从hCaptcha加载第 3 方代码。但是，hCaptcha 代码在其自己的 CSP 规则中加载到自己的 URL 上，并且在任何时候都无法访问与消息有关的任何内容。
- 作为帮助防范MITM 攻击的一种手段，可以使用浏览器扩展。
为什么我在这里收到一个链接，其中包含解密消息的选项？
如果此翻译有错误，我们深表歉意。 此服务只是将加密消息从一个点传递到另一个点，您就是收件人。该消息将很快被删除。该服务的运营商无法读取消息内容。通常当有人不希望消息的内容保留在各种数据库/设备/服务/文件/等中时，他们会使用此服务。这是发送电子邮件/即时消息/文本/等时的典型情况。如果您决定解密，请记住以下几点：
- 消息很可能会在发送到您的设备进行解密后立即被删除。这意味着在您单击按钮解密消息后，我们将不再有副本可以稍后再次发送给您。
- 我们系统地删除收到的所有信息。消息将在创建后一分钟到两周之间的任何时间被删除 - 无论消息是否被解密。换句话说，如果您需要阅读消息，请不要等待太久才能解密。
- 发件人可能认为应该小心处理消息的内容。他们甚至可能表示不希望复制。请尊重他们的意愿。
- 如果系统提示您输入密码来解密消息，请不要关闭浏览器窗口/选项卡。根据此列表中的第一个要点，我们以后可能无法再发送一份副本。只需打开浏览器窗口/选项卡，直到您可以输入密码。如果您输入了错误的密码，系统将再次提示您。必须准确输入密码。请记住，为了适应不同的语言和密码要求，我们接受许多不同的密码字符。
你删除所有提交到这个网站的东西？
忠实于我们的垃圾桶标志......收到后不久所有内容都会被删除。删除所有内容都是自动的 - 将其写入服务器。这样想 - 提交的信息分为两类：
- 我们无法解密其内容的加密消息
- 在网络上提交任何内容所固有的其他信息（即您的 IP 地址等）
- 如果没有人检索到消息，我们应该将消息保留多长时间（范围从 1 分钟到 2 周 - 默认为 1 周）。
- 消息被检索的次数（从 1 到 100 次 - 默认为 1 次）
为什么要使用这项服务？
此服务是一种工具，可帮助您减少发送/接收的消息的永久性。您在 Internet 上交流的大部分内容（聊天、文本、电子邮件等）都被存储起来，很少被删除。通常，当您删除某些内容时，它实际上并未被删除，而是被标记为已删除并且不再向您显示。您的汇总通信年复一年地累积在数据库和您无法控制的设备上。不可避免地，存储您的通信的一个或多个组织/人员/设备被黑客入侵并且您的信息被泄露。这个问题非常普遍，以至于现在有许多网站可以跟踪已受到损害和泄露用户数据的组织。端到端加密临时消息是一种简单的解决方案，可帮助您减少某些通信的永久性。提交到此站点的每条消息都有一个从 1 分钟到 2 周不等的生存时间 - 一旦超过该时间，该消息将被删除。此外，默认设置是一旦收件人检索到任何邮件，就将其删除。此外，所有消息从您的设备一直到收件人的设备都经过加密。使用端到端加密的主要目标是消除我们读取任何提交消息的能力，从而消除一些信任要求。最终结果是现在可以很容易地通过一个简单的链接发送加密消息。该消息在发送后不久或在检索时被删除。您不需要安装/配置特殊软件。您无需创建帐户或提供任何个人信息。收件人不必在您的联系人中，甚至不必了解此服务 - 他们可以单击链接的唯一要求。
这是消息服务吗？
否。此服务旨在补充现有的消息服务，如即时消息/电子邮件/文本/等。通过添加防止发送的消息被长时间存储的功能。我们不会将生成的链接发送给收件人。
预期用例是什么？
那么有哪些场景适合使用这个服务呢？虽然每个人在隐私和安全方面都有不同的需求和要求，但我个人发现以下场景是合适的用例：
- 您一直在通过当地网络论坛就该地区的山地自行车道进行交流，有时会在论坛上与人们会面，一起查看新的路径。本周末论坛上有人想在你的地方接你，拼车到一条小径上。您不希望您的家庭地址永远留在这个网站论坛数据库中。只需通过此服务发送地址 - 该链接位于网站论坛数据库中，但一旦被收件人阅读，该消息/地址将被删除。
- 您需要将您的 Netflix 登录信息发送给您的兄弟，因为您的侄女由于 COVID 锁定而让他发疯，而他仍然没有自己的帐户。你不太关心这个登录，但你的兄弟在我称之为“数字卫生”方面特别糟糕，并且已经对登录和恶意软件进行了多次试验。随后试图让他清理他的行为，甚至为他安装安全消息都未能坚持下去。简单地通过短信发送它可能是最好的选择（可悲的是），但是由于过去的经验，让该登录信息出现在他的消息历史记录中会让您感到不舒服。使用此服务通过文本消息中的链接发送登录信息可满足不让登录信息永远停留在他的聊天记录中。
- 您有时在一个办公室工作，那里有许多共享的租户，他们随时都在来来去去。有可用的WiFi，但由于存在滥用问题，因此每周都会轮换密码。许多租户通过电子邮件/短信询问 WiFi 密码，即使它在前台，因为大多数租户不通过正门进入。使用此服务，办公室经理可以通过电子邮件/文本回复中的链接发送 WiFi 密码，满足不让密码逗留的情况，并且还允许接收者通过在移动设备上不那么笨拙的复制按钮立即复制密码。
- 您的一个托管服务提供商要求您提供有关您报告的服务器的详细信息，该服务器显示硬盘驱动器出现故障的迹象。他们需要的一些信息有点敏感 - 您不希望它永远留在他们使用的第 3 方票务系统中。使用此服务，您可以将信息发送给支持技术人员，而无需将其驻留在工单系统中。由于多个技术人员可能需要多次参考该信息，请将reads-to-live 设置为大于1（即可能为20），以便在第一次检索时不会删除该消息。
- 你需要在 Reddit 上给另一个用户发私信，让他们知道你的电话号码，以便他们可以给你打电话。 Reddit 与许多其他提供商一样，过去曾泄露过用户信息，您不希望您的电话号码在 Reddit 的数据库中保存多年，直到下一次泄露。只需通过此服务发送您的电话号码。
- 您的配偶在您上班时给您发消息，希望登录公用事业，因为她的朋友刚刚尝试了一个新程序，该程序为她节省了电费，而她想查看一下。你提醒她有一个共享的家庭密码管理器，但她只是想让你发送登录信息。 OMEMO 用于与您的配偶进行即时消息传递，因此您对消息传输的安全性非常有信心；但是，聊天记录本身未加密存储。您的配偶并不总是对下载、电子邮件等持谨慎态度。水电费也有点敏感，因为它们可用于身份盗窃以证明居住。您可以使用此服务向她发送登录详细信息，以避免在她的计算机上存储副本。
该服务不应该用于什么？
出于本常见问题解答中解释的所有原因，不应将此服务用于非常敏感的信息。下面是一些不该做的事的例子：
- 不要使用此服务使不适当的消息传输“更安全”。因为默认设置是在可以阅读邮件的 URL 中包含密码，所以任何知道链接的人都可以阅读邮件。如上所述，当您使用此工具时，所选传输（即文本）固有的任何安全/隐私问题都会被继承。因此，例如，如果您由于其敏感性质而永远不会考虑使用电子邮件发送特定信息，那么您不应该使用此服务来“保护”电子邮件的该部分。
- 请勿使用此服务来确保不会复制邮件。仅仅因为我们在检索后立即删除加密消息的副本并使复制变得更加困难，并不意味着该消息不能被复制。如果收件人拍摄了他们的屏幕照片怎么办？如果他们只是写下消息怎么办？最终，如果收件人可以阅读邮件 - 可以制作副本。
- 请勿使用此服务来确保消息无法追溯到您。该服务依赖于另一个消息传输提供商（即电子邮件、聊天等）来将消息从一个点传送到另一个点。使用的消息传输可以很好地将消息追溯到您。
- 请勿使用此服务发送您希望拒绝发送的任何内容。仅仅因为邮件本身被删除，并不意味着指向已删除邮件的链接被删除。如果您向您的朋友发送一封电子邮件，并且该电子邮件的一部分包含指向来自该服务的消息的链接，那么普通读者就会知道该消息中还有其他内容。即使链接所指的消息早已不复存在 - 很明显，还有其他内容被发送，并且是您发送给您的朋友的。
为什么不直接使用 PGP/Signal/OMEMO/Matrix/etc.？
如果您认识要发送安全临时消息的人，经常发送他们，期望类似聊天的界面，和/或期望收件人拥有所需的软件并知道如何使用它，则此网站可能不是最佳解决方案。有很多不错的选择，它们是开源的，支持 E2EE，而不是基于 Web 的，甚至还有一些像Signal这样的也支持临时消息的选项。我个人使用私人XMMP 服务器和OMEMO与亲密的朋友和家人聊天。如果您不知道收件人正在运行什么软件，不知道他们的电话号码/联系人句柄，不知道他们的技术熟练程度（但假设他们可以单击链接），则使用本网站可能是最佳选择，或者您只是希望将您发送的消息保留在底层通信传输之外。
存在哪些要求？
需要一个现代和最新的 Web 浏览器，该浏览器正确实施包括 Web Crypto API 在内的标准。示例包括：Chrome、Firefox、Edge 和 Safari（大约 2020 年或之后）。
收件人可以复制邮件吗？
是的。即使消息在检索时可能会自行删除，收件人仍然可以查看该消息。任何时候接收者可以完全查看消息，都可以复制一份——这适用于所有通信。有一个选项可以让收件人更难制作副本。在这种情况下，实现了三个复制障碍：
- 复制按钮被删除。此按钮默认允许收件人将整个邮件复制到他们的剪贴板中。
- 下载按钮被删除。此按钮默认允许收件人将消息下载为文本文件。
- 删除了在消息文本框中选择文本的功能。
是否收集任何个人信息？
我们不支持用户帐户（即用户名/密码）。我们不会收集任何可以识别您身份的信息（即姓名/地址/电子邮件/电话）。您发送的邮件中可能包含一些个人信息，但这些信息是加密的，我们无法阅读。请查看我们的隐私政策以获取完整的详细信息。
记录了哪些信息？
我们的网络服务器在所有网络活动中保持长达 24 小时的通用日志格式。这包括记录 HTTP 客户端的完整 IP 地址。 24 小时后，此记录信息将自动删除。发送到 /api 的所有请求都已发布，这意味着 Web 服务器不会记录任何特定于消息的信息。此外，保存到数据库中的任何信息都会被有效地记录下来。数据库中的所有条目，包括匿名和散列的 IP 地址，都有一个过期时间 (TTL)，在此之后它们会被自动删除。 TTL 到期时间在 1 分钟到 2 周之间变化。
你在做什么来保护服务器？
服务器安全是一个明显的问题。我们主要关注两个方面来确保其安全：
- 首先，我们在尽可能短的时间内尽可能少地存储，以便如果服务器受到损害，任何信息泄漏都不会对我们的用户造成损害。存储在数据库中的所有消息都经过加密，无法解密。由于我们不会从用户那里收集任何个人信息，因此不会存储任何将任何消息链接到我们的任何用户的内容。数据库中的所有记录都有一个从 1 分钟到 2 周不等的过期时间 (TTL) - 在此时间过后，记录将被自动删除。因此，数据库中曾经存在的绝大多数信息很久以前就已经被删除了。
- 我们采取了许多措施来防止妥协并遏制任何确实发生的妥协：
- Web 服务器nginx以非特权用户身份在隔离容器中运行，对日志以外的任何内容都没有写访问权限。容器在其自己的 SELinux 上下文中运行，进一步防止任何文件系统更改或从容器中轻松逃脱。不支持 PHP/ASP/JSP/等。 - 只提供静态资源。
- 运行 /api 的代码是用 Go 编写的，这应该使它对缓冲区溢出漏洞（一种常见的攻击向量）具有相当的弹性。 Go 进程还作为非特权用户在隔离的容器中运行，对数据库以外的任何内容都没有写访问权限。容器在其自己的 SELinux 上下文中运行，进一步防止任何文件系统更改或从容器中轻松逃脱。数据库badderdb是 Go 进程的一部分（没有外部数据库依赖/进程）。
- 服务器受损的主要危险在于，攻击者可能会以危害我们用户隐私/安全的方式修改文件。一个专门的过程监控所有网站文件的任何更改，并在发生任何更改时立即提醒我们。
- 所有管理访问都受到保护并仅限于授权网络。
使用本网站时存在哪些安全风险？
在具体解决其中一些风险之前，我认为一个半简短的类比可能有助于总结使用任何 Internet 通信的风险。想象一下，任何系统的安全性都取决于链条中最薄弱的环节。现在想象一个场景，有两个人在一个密封的房间里，无法看到、听到或记录他们所做的任何事情。一个人将消息传递给另一个人，后者在阅读该消息时将其烧毁。如果那个房间外的人想要获得已经传递的信息，那将是很困难的。获取消息的最薄弱环节是什么？可供选择的链接并不多——它是一个非常短的链。现在想象一下，当您在 Internet 上发送消息时，链中至少有 100 万个链接 - 其中许多是弱链接 - 其中许多完全不受您的控制 - 这就是现实。
使用加密可以极大地帮助解决上述百万链路问题，并且很容易被诱使认为精心设计的 E2EE 系统提供了最终解决方案。但是，这种想法可能会给您带来麻烦，因为攻击者通常只会攻击系统中较弱的链接。例如，接管您的手机或计算机并设置输入记录器以读取您输入的所有内容可能比通过网络破解加密消息容易得多。底线是，如果我的任务是传达一个至关重要/至关重要的秘密，我只会将电子通信用作最后的手段。
因此，使用任何通信都存在安全风险，但您仍然使用 Web 浏览器进行银行业务、购物、电子邮件等。对于获得的巨大便利而言，这是可以接受的风险。真正的问题是......该站点有哪些半特定的安全风险？想到了几个：
- 也许这项服务最大的风险和最独特的风险是我们的用户在辨别什么是适合发送和什么不适合发送时不会使用良好的判断力。有时，“我很乐意通过电子邮件发送此信息 - 我只是希望在阅读后删除该电子邮件”和“我不喜欢通过电子邮件发送此信息 - 电子邮件是一种不合适的传输方式”之间的区别可能非常微妙。
- 总有一种威胁是，该网站的运营商实际上是不良行为者，诱使人们使用该服务来获得一些黑暗的最终目标。我们遇到了一个看似可信的——让一切变得简单和免费——让很多人使用这项服务——同时带着险恶的意图。哇哈哈哈哈哈！你怎么可能相信我们？
- 我们的代码有可能存在影响安全性的错误，或者我们只是没有好好考虑问题，我们的缺点现在使我们的用户面临不必要的危险。我们当然不希望 - 但我们不能排除它。
- 与拥有 TB 级加密数据不断流入和流出其庞大网络的技术巨头（即 Google/Facebook/Whatsapp）不同，在这些网络中，私人通信很容易与其他流量混合，独立的集中式服务（即 Signal、 Telegram 和我们）脱颖而出。网络运营商甚至大型组织/政府很容易看到 IP 地址 xxxx 正在使用 XYZ 服务。
- 虽然不是真正针对此站点，但由于它可以用于任何网站，因此中间人 (MITM) 攻击是一个值得关注的问题。
你对中间人 (MITM) 攻击做了什么？
网站的所有用户都可能成为 MITM 攻击的受害者 - 在这方面，该网站与网络上的所有其他网站没有什么不同。 MITM 攻击是指攻击者能够拦截和修改用户浏览器与站点 Web 服务器之间的通信。这允许攻击者修改任何站点的代码/内容，同时仍然向最终用户显示他们习惯的站点。我们采取了一些措施来使 MITM 攻击更加困难：
- HSTS 用于强制浏览器仅通过 TLS 进行连接。我们的服务器配置为忽略非 TLS 通信，而不是重定向。仅支持 TLS 1.2 或更高版本。
- DNSSEC 用于签署我们域的区域。如果用户使用 DNSSEC 感知递归解析器，这可以阻止 DNS 欺骗实施的 MITM 攻击。
- 我们使用一项服务来监控证书颁发机构颁发的任何引用我们域的未经授权的 TLS 证书。
- 我们发布了浏览器扩展，以支持使用存储在最终用户设备上的代码进行消息加密。
浏览器扩展有哪些优势？
我们提供浏览器扩展作为一种提供额外便利和额外安全性的手段。简单地说... 扩展使发送临时消息更快、更容易。还获得了一些安全性，因为用于加密和准备消息的所有代码都存储在本地扩展中。由于代码存储在本地，这为发送方提供了一些针对MITM 攻击的保护。然而，值得指出的是，虽然扩展提供了更多的保护来抵御破坏消息内容的 MITM 攻击，但 MITM 攻击仍然可能有效（即，如果不使用 TOR/VPN/等，则确定发件人的 IP 地址）。
我如何确定提交的任何内容都是端到端加密的？
与许多其他流行的端到端加密 (E2EE) 聊天客户端不同，当您提交消息时，查看发送给我们的内容非常简单。下面的视频教程演示了如何确认我们无法解密发送到服务器的消息。
此外，如果您考虑一下，只要我们不是某个试图收集敏感信息的秘密机构，我们能够解密信息就没有任何好处，因为拥有这种能力只会给我们带来问题。我们甚至不想存储消息——然而，传递它们是一种必要的邪恶。端到端加密如何在此站点上工作？
目前，我们正在使用对称加密（AES-GCM 256 位）和从密码派生的密钥（PBKDF2/SHA-256 的最少 150,000 次迭代）。不使用非对称加密，因为存在以下要求：1) 发送方发起通信 2) 发送方和接收方不同时在线 3) 没有关于接收方的信息 4) 我们试图让事情变得真正简单，密钥管理是复杂。标准的 Web Crypto API 用于包括 RNG 在内的所有加密功能。基本上，会发生以下情况：
- 最终用户选择密码或自动生成密码
- 进行 API 调用以获取所需的 PBKDF2/SHA-256 迭代次数（垃圾邮件控制需要此步骤）
- 生成一个 32 字节的盐
- 密钥来自盐和密码
- 生成一个 12 字节的初始化向量(IV)
- 消息使用密钥 + IV 进行加密
- 迭代计数、salt、IV 和密文被发送到服务器（连同一些其他信息，如 TTL、RTL 等）
- 服务器返回一个引用消息的随机 ID
- 浏览器然后向最终用户显示包含返回的 ID 和密码的链接或不带密码的链接（在这种情况下，接收者必须知道并输入密码）
- 如果密码是链接的一部分，它在URL 哈希中，因此当接收者发出 GET 请求时，它永远不会发送到服务器
- 将提示收件人是否希望解密和查看邮件
- 浏览器发出指定消息 ID 的请求
- 如果发件人要求完成 CAPTCHA，则收件人将被定向到另一个 URL 以证明他们是人类（一旦他们通过，他们将被定向回）
- 服务器发送加密的消息，如果实时读取 (RTL) 为 1，则默认情况下此时将删除该消息
- 收件人将使用密码解密消息（如果 URL 中没有，则会提示输入密码）
解密密码可以在URL中吗？
是的。这显然会影响安全性，因为如果用于发送链接的方法是不安全的，则消息通过关联是不安全的。消除此问题的所有变通方法都会引入影响用户体验的额外步骤和复杂性（即，必须在发送消息之前在两端进行设置）。接收者发起消息请求并发送该请求链接的非对称方案可以与我们的“一切都是短暂的”关键要求一起工作 - 这可以实现。最终，如果两方要频繁地相互发送消息，假设双方都可以处理使用这些解决方案，则存在更好的解决方案。
但是解密密码不一定要在URL中？
正确的。如果链接中未包含解密密码，则会提示收件人输入密码。如果密码安全地传达给接收者（或他们已经知道），这将提供防止拦截的保护。但是，缺点是收件人必须知道并正确输入密码。这是将密码发送给收件人的一种方法，它提供了一些防止拦截的保护：
- 使用默认设置加密消息中的密码并将此链接发送给收件人。
- 当收件人单击链接并解密邮件时，他们知道在他们之前没有其他人获得密码，因为包含密码的邮件在检索时会被删除。但是，如果存在活跃的MITM 攻击，或者您的设备或接收方的设备已被盗用，那么另一方仍有可能获得密码。
- 与收件人确认他们已成功获取密码。例如，如果收件人通知您，当他们去取回密码时，该邮件已被删除，那么您知道其他人在收件人之前获得了密码，因此该密码已被泄露，不应使用。
- 使用收件人确认他们拥有的密码，您现在可以使用相同的密码发送消息进行加密 - 只需共享不包含密码的链接版本。
此服务不将链接传递给收件人？
这是正确的 - 我们生成链接并将其留给发件人如何最好地将其交付给收件人。此服务的目标是提供一个选项，在现有消息传输（如电子邮件/聊天/文本/等）中提供较少的持久性。因此，期望我们生成的指向临时消息的链接是通过现有的消息传输发送的。这确实具有用户应该理解的安全隐患。让我们以 SMS 文本消息为例，因为这是一种非常不安全的通信方式。当您使用此服务通过文本消息发送临时消息链接时，如果您使用默认模式，即链接中包含密码，任何拥有链接的人都可以阅读该消息，并且不会提供防止拦截的保护。此服务仍提供更临时的通信，可以增强隐私和安全性。此外，您可以选择在没有密码的情况下发送链接，这将提供防止拦截的保护。
如何在使用此服务时尽可能保护我的隐私？
正如本常见问题解答中其他地方所讨论的那样，尽管我们已经做了很多工作来保护您的隐私，并且即使我们不收集任何个人信息，我们和其他人还是会通过您使用网络浏览器提交和收集一些与日志相关的信息。但是，有多种方法可以更好地保护您的隐私。一种免费使用、基于开源软件并且效果很好的方法是使用Tor 浏览器。该浏览器旨在从多个层面保护您的隐私——包括使用Tor 网络。我们的网站已经可以通过 Tor 洋葱网络访问，这意味着通过 Tor 访问我们的网站不需要使用出口节点，这可以避免有人窃听出口节点流量。但是，请记住，即使在这种情况下，您的 ISP 也可以看到您正在使用 Tor——尽管不是为了什么。您甚至可以连接到 VPN，然后启动 Tor 浏览器以实现两层匿名；但是，请记住，在这种情况下，您的 ISP 仍然可以看到您正在使用 VPN - 尽管不是为了什么。如果您不想让 ISP 知道您使用的是什么协议，您可以连接到大型公共 WiFi 网络，例如图书馆、学校等，然后使用 Tor 浏览器。
如果我不信任美国怎么办？
我们的服务器位于美国。此外，我们的 CDN 提供商 Cloudflare 是一家总部位于美国的公司。我们试图消除信任我们或我们服务器所在国家/地区的需要，因为我们不收集个人信息，无法解密任何消息，并且所有内容在收到后不久都会被删除。但是，我们可以理解一些不信任，因为它是基于网络的，尤其是如果您居住在某些国家/地区。我们计划在冰岛和瑞士为难以信任美国的人们提供选择。请让我们知道这是否适用于您，因为除非有真正的需求，否则我们不会主动提供替代方案。
你在做什么来防止垃圾邮件？
每当您允许某人发布可以通过链接转发的消息时，您就会邀请垃圾邮件发送者。解决这个问题并不完全简单。由于以下几个原因，我们不想在消息发送过程中加载第 3 方验证码：
- 我们讨厌验证码——它们需要时间而且很烦人
- 加载第 3 方 javascript 可能会侵犯隐私和安全
- 运行我们自己的 CAPTCHA 意味着我们正在注册一个永无止境的打地鼠游戏
- 最终人们可能希望能够通过 API 与此服务进行交互
- 增加所需的 PBKDF2/SHA-256 迭代次数
所有消息只能被检索到很少的次数——对于垃圾邮件发送者来说，这是一个没有吸引力的属性，因为他们依赖于发送大量消息。由于垃圾邮件发送者必须为任何给定的垃圾邮件活动创建大量消息 - 我们选择使这项任务的计算成本如此之高，以至于滥用此服务来发送垃圾邮件变得毫无吸引力。这是通过跟踪网络发布消息来实现的——以可能的总检索量来衡量。网络信息本身是经过安全散列的，因此我们无法从散列中推断出真实的网络。随着给定网络发布更多消息，我们增加了发布下一条消息所需的 PBKDF2/SHA-256 迭代次数。这很快导致仅发布一条消息就需要大量 CPU 时间。希望这种方法足以遏制垃圾邮件滥用，同时不会影响真实用户。 - 在用户检索邮件时收集他们的垃圾邮件报告
当用户检索邮件时，邮件正下方有一个“报告垃圾邮件”按钮。如果邮件是垃圾邮件，希望有些人需要 3 秒钟才能单击该按钮。当我们收到垃圾邮件报告时，它会提醒我们，它还会影响给定网络所需的 PBKDF2/SHA-256 迭代。
为什么有一个选项要求接收者完成验证码？
虽然我们确实不喜欢 CAPTCHA，但我们确实认识到它们服务于一个目的并且有时间和地点（至少现在是这样）。这是发件人获得某种保证的一种简单方法，即收件人是人类，并且自动化进程没有访问该消息。
谁在运行这项服务，为什么它是免费的？
我们只是一对夫妇，他们有时会面临没有好的选择来帮助保护我们的隐私的困境。这通常是由于与朋友和家人的沟通导致的，他们对处理设备和信息的方式并不十分小心。有时，在使用 Reddit 等基于 Web 的论坛或使用基于 Web 的支持系统时会出现这种情况。我们找到了一些基于 Web 的临时消息解决方案，但没有一个提供 E2EE，这意味着我们无法信任它们。因此，我们刚刚构建了自己的解决方案，并决定将其分发出去，以便其他人可以从中受益。
我如何才能相信上述问题的答案？
真的，您不应该仅仅因为它说了某些事情就相信任何网站——验证任何声明通常是一个好主意。我们试图通过采用端到端加密来消除尽可能多地信任我们的要求。例如，很容易审核我们无法读取任何消息，因为它们是加密的。我们还让运行本网站的 javascript 代码非常简单，以便于阅读和理解。将所有代码开源，让人们可以验证正在运行的代码；但是，请记住，无法真正验证服务器正在运行的内容。虽然端到端加密确实消除了大部分信任要求，但它仍然是我们的用户在决定是否使用此服务时要考虑的一个重要因素。