为什么 VPN 不应该要求你的邮箱
大多数 VPN 产品的核心存在一个被人忽视的矛盾。你注册的目的是向你访问的网站和网络隐藏自己的 IP 地址。但在此之前，服务商先要求你提供邮箱，然后是银行卡上的姓名，然后是账单地址。你的注册动作发生在家庭 IP 下，所以他们也拿到了这个。等到 App 安装完成，你花钱请来保护隐私的这家公司，对你的了解已经超过了你本想屏蔽的大多数网站。
一款匿名 VPN——真正不知道你是谁的那种——应该是默认模式，而不是罕见的例外。本文将探讨这一矛盾为何存在、现实可行的替代方案是什么，以及在 iPhone 上通过 App Store 订阅是如何悄然解决一个行业纠缠了十五年的问题的。
门口的矛盾
无日志流量策略是大多数注重隐私的 VPN 的主打卖点。它意味着服务商不会记录你访问了哪些网站、下载了什么内容，或者你连接了哪些 IP。这是承诺。
这个承诺常常略过的，是第二个数据库——里面存着你的账户。你的邮箱、银行卡上的姓名、你注册时的 IP、你登录时的 IP、你的支持工单、你的续费记录。这些都不是「流量」，却全都是身份信息。而且几乎每一家 VPN 都持有这些。
所以问题根本不是「这家 VPN 会不会记录我的流量」。问题是「这家 VPN 对我究竟了解多少」。流量层面和账户层面是两个不同的问题，而几乎所有关于 VPN 隐私的讨论都只覆盖了前者。
VPN 行业常见的账户模式
退一步看，市面上其实只有几种固定模式。了解它们，才能辨别某家服务商用的是哪种。
邮箱加密码
经典的 SaaS 注册方式。你填写邮箱，设置密码，通过链接确认。服务商从此拥有了你的永久标识符，以及你注册的时间和地点记录。这是最主流的模式，也是风险敞口最大的。
邮箱加支付处理器
与上面相同，另外通过 Stripe 等平台绑定银行卡。支付处理器负责处理卡片信息，但 VPN 仍然持有你的邮箱、银行卡上的姓名以及账单记录。退款和续费都需要邮箱存在。
魔法链接或一次性验证码
这种方式被包装成「免密码」，有时也被称作「注重隐私」。但在隐私意义上，它并不然。服务商依然持有你的邮箱，只是不要求你记住密码而已。
通过 Apple ID 在 App Store 订阅
这是大多数 iPhone 用户从未仔细审视的模式。你点击订阅，用 Face ID 确认，交易通过 Apple 完成。开发者看不到你的邮箱、银行卡或姓名。他们收到的只是 Apple 发出的一张已签名收据，确认订阅有效。我们稍后会详细说这个。
加密货币加无账户
最彻底的方案。用 Monero 等加密货币付款，获取令牌或凭证，从不向服务商透露任何信息。原则上真正匿名，但操作上代价很高——你失去了便捷续费、便捷退款、便捷换设备的能力，还要自己承担管理凭证的负担。对大多数用户来说，这并不现实，即便他们在乎结果。
绑定身份账户的风险
人们很容易对账户层面的数据不以为意——「他们不过有我的邮箱，能怎样。」但「能怎样」很快就会变得具体。
传票和法律请求的波及范围
流量层面的无日志政策确实有用，但它不延伸到账户数据。如果法院命令服务商交出某个邮箱或账单身份的相关信息，他们必须配合。服务商无法以「我们不保留流量日志，所以没有任何内容」为由推脱——他们只能交出账户记录、注册 IP、支持工单和续费历史。
仅凭这份记录，通常就足以证实某个具体的人在某个具体的时间段内是客户。根据司法管辖区和请求性质，即使没有附带任何流量数据，这也是一次有实质意义的信息披露。
数据泄露的暴露
账户数据库会泄露。主要 VPN 服务商、密码管理器以及各类平台都发生过泄露。当 CRM 或身份验证数据库被攻破时，泄露的不只是你的邮箱——它还暴露了一个事实：你，用那个邮箱，曾经是某家 VPN 的客户。这并非无关紧要。对某些地区的某些用户来说，这个事实本身就是敏感信息。
跨泄露的交叉关联
更深层的问题是，没有任何一次泄露是孤立发生的。你的 VPN 账户邮箱同时也是你的购物邮箱、论坛邮箱，很可能还是你的工作邮箱。一旦几个数据库泄露，同一个邮箱就会在所有这些数据库中现身，一份完整的画像便在碎片中拼凑成形。关于账户，最能保护隐私的事，往往是根本不存在这个账户。
关于服务商所说的「无日志」究竟意味着什么，可以参阅我们的文章 VPN 无日志政策的真实含义；关于哪些 VPN 宣传在审视下站得住脚，可以参阅我们的 VPN 常见误区解析。
Apple ID 订阅如何将身份与开发者隔离
App Store 订阅模式在结构上与 SaaS 账户模式有本质区别，理解这一点对匿名 VPN 而言至关重要。
当你通过 App Store 订阅一款 App 时，你与 Apple 达成的是交易，而不是与开发者。Apple 持有你的支付方式、Apple ID、账单地址以及订阅历史。开发者——在这里就是 VPN 服务商——站在那堵墙的另一侧。
当你订阅时，开发者实际收到的是一张已签名的收据。Apple 的 StoreKit 框架向 App 提供一个经过加密的交易对象，开发者的服务器通过 Apple 的服务器验证该交易。验证结果只返回一条有意义的信息：是的，该订阅有效，并且属于这个匿名标识符。没有邮箱，没有姓名，没有银行卡，没有地址。
如果你取消订阅，通过 Apple 操作。如果你要退款，向 Apple 申请。如果你的银行卡过期，你在 Apple ID 设置中更新——开发者永远看不到新卡、旧卡，甚至不知道发生了任何变化。续费也是同理。
对用户来说，这看起来和普通的订阅流程没什么两样。但在结构上，它实现了清晰的分离：Apple 负责身份和资金，开发者负责产品。由于开发者一侧没有注册表单，也就不存在账户数据库。那个在数据泄露中通常会外泄的东西，根本就不存在。
这不是什么隐私技巧，而是所有 App Store 订阅的运作方式。大多数使用这一模式的 App 并没有将其当作隐私卖点，因为它们另外在 App 内要求你填写邮箱来「创建账户」。VPN 完全没有必要这样做，但大多数 VPN 出于习惯依然如此。
Snap VPN 的处理方式
Snap VPN 的设计基础是：App Store 的流程已经足够。首次启动时没有注册表单，App 里没有邮箱输入框，连接之前也没有「创建账户」这一步。
你安装 App，点击订阅，用 Face ID 确认。从 Snap VPN 这一侧收到的，是一张经过验证的收据和一个匿名标识符。收据表明你已订阅，标识符让 App 记住这台设备上你是订阅用户。两者都不包含你的邮箱、姓名或支付信息，因为 Snap VPN 的服务器根本不会收到这些——Apple 收到。
我们这边不存储任何与真实世界身份绑定的用户标识符。你对 Snap VPN 的信任是操作层面的（网络、服务器、协议），而不是那种「我们持有你的身份，请信任我们」的信任——后者是每一个邮箱加密码账户都附带的前提。
实际来说：如果有人要求 Snap VPN 提供「这个邮箱地址对应的所有数据」，不会有任何记录可以提供，因为根本没有邮箱在档案里。这不是营销话术，而是不构建注册表单的自然结果。
如果你想在设备层面进一步加强隐私，我们的 iPhone 隐私设置清单 涵盖了配合匿名 VPN 值得开启的各项设置。
诚实的局限性
如果就此结束，会产生误导。有必要说清楚这种模式做不到什么。基于 Apple ID 的匿名 VPN，并不等同于零信任依赖的 VPN。
你仍然信任 Apple。Apple 知道你订阅了。如果你在意这一点——如果你的威胁模型包括 Apple 本身——那么 App Store 订阅模式并不适合你，用加密货币且无账户的方式才是唯一诚实的答案。对大多数用户来说，这个权衡是合理的：Apple 是已知的，关系本来就在，数据也被限制在你本就身处的生态系统之内。
你仍然信任 VPN 服务商诚实地运营网络。任何账户模式都无法解决这一点。一家没有你邮箱的服务商，同样可能错误配置服务器、记录它声称不记录的连接，或出售不该出售的聚合数据。账户模式解决的是减少被攻破时能暴露的内容，而不是消除对运营商的信任需求。
它改变的是波及范围的大小。如果 Snap VPN 的服务器明天遭到攻击，攻击者将找不到邮箱列表、姓名列表、银行卡号、账单地址，也没有与真实身份绑定的支持工单存档。VPN 泄露事件中通常外泄的那个东西——账户数据库——根本不存在。收集的更少，可被攻击的也就更少。
这就是关键所在。从设计层面实现匿名，意味着在设计上让敏感信息从一开始就不存在，而不是让它「受到保护」「静态加密」或其他种种表达「我们有，但很小心」的说法。
结论
一款要求你填写邮箱的 VPN，其中的矛盾是真实存在的，而整个行业大多选择绕过这个问题而非解决它。解决方案不需要新奇的密码学，也不需要新一轮的无日志审计；而是从一开始就不构建账户数据库。App Store 订阅模式使得在 iPhone 上做到这一点成为可能——对用户来说毫无感知，在结构上对开发者来说也清晰干净。这就是当账户层面被认真对待时，匿名 VPN 应有的样子。
如果你在选择 VPN，而它第一件事就是要求你的邮箱，这是一个公平的信号，说明这款产品在其余地方也会如此对待你的数据。更好的默认选择是存在的。
最后
如果一款不知道你邮箱的 VPN 听起来正是应有的默认状态——因为本该如此—— Snap VPN 从第一次点击起就是这样构建的。无需注册，无需填表，没有任何身份在档案里。只有一款 App、一个锚定在你 Apple ID 上的订阅，以及一个可以使用的网络。