ExpressVPN vs Opera VPN

从未公开的内容。 订阅者数量（M08）和服务器总数（U03）未公开。无法从检查过的任何页面确认服务器硬件所有权（C08：自有还是租用）以及应用层设备标识符（C12）。

106个国家，而自称为113个。 U02_server_countries反映了ExpressVPN自有站点地图中的105个国家落地页，另加中国（在线/vpn-server页面上已确认“Available - Virtual Locations”，但没有专属落地页）——共106个代码，而该网站自有营销宣传自称“113 Countries”；在线服务器位置页面是一个非常大的按协议划分的表格，未进行穷尽解析，因此106与113之间的空白被报告出来，但未得到解决。

介于两个类别之间的审计发现。 V11_audit_findings记录为session_metadata，而不是none_linkable或aggregates_only：2025年KPMG报告描述了每次连接的结构化记录（国家、ISP、日期、协议、数据量、稳定的加盐哈希伪名），这超过了纯汇总数据，但缺少IP和精确时间——对于该字段的四个中间类别而言，这是一个确实模糊的案例。

本轮未检查。 ExpressVPN的覆盖范围是否存在于联盟网站之外（X08）、其联盟付款档位（X10），以及由所有者运营的评测媒体是否标示出所有权关联（X11），均未在本轮检查。

P2P，已查找但不存在。 U12a_p2p_allowed因不同于其余字段的原因保持未知：已进行查找，但未公开。无论是站点地图（578个页面和支持URL）还是服务条款，均未在任何地方提及P2P、BitTorrent或文件共享，而每个其他已编目的服务商都在其自有文档中说明了自己的立场。支持文章或条款中的一项条款可以消除这一未知状态；评测网站称其可用则不能。

只有服务器描述，没有证据。 C02、C06 和 C08 背后没有任何证据：Opera 称服务器是物理服务器且归其所有，但这既不能确认磁盘，也不能确认 DNS，或硬件的所有者。U02 未知，因此无法回答 C09b。

一个商店，而不是两个。 只查阅了 Google Play 的数据安全表单；未查阅 iOS 浏览器在 App Store 上的隐私标签，因此 X12 依据的是一个商店，而不是两个商店中较差的那个。

两项解读，而非陈述。 U01 中的 Linux 是根据桌面帮助手册推断的；该手册记录了 VPN，并将 Windows、macOS 和 Linux 合并说明，没有按平台拆分；审计公告则明确列出了 Android 和 iOS。U10 为不限量，因为没有账户，也没有设备上限可以强制执行，这属于对产品的解读，而非已陈述的数字。

C12 是基于服务商自有文案中的 resettable_ad_id，而不是基于商店类别。隐私政策的营销段落称始终会收集安装 ID 和 XV User ID，并且广告标识符——IDFA 或 Android Advertising ID——会在明确同意后收集，所有这些信息都会传给 AppsFlyer；Google Play 的数据安全表则独立声明会将设备或其他 ID 用于广告或营销。

同意门槛，以及此处其他服务商都未提供的一项缓解措施——将发往 AppsFlyer 的流量经由专用 ExpressVPN IP 池路由，使归因无法通过 IP 进行关联——都是真实存在的，因此记录在此，因为评分底线衡量的是能够保留什么，而不是解释得有多好。

U07_protocols 包含完整的选择器：Lightway UDP 和 TCP 标为 vendor_open，另有 WireGuard、OpenVPN UDP/TCP 和 IKEv2。Lightway 是 ExpressVPN 自有的协议，其源代码已公开，并有独立审查作为支持（Cure53，2021 年和 2024 年），这正是 vendor_open 存在的区别所在——proprietary 衡量的是无法判断某种传输是否薄弱，而此处可以判断。

根据服务商自有的协议页面，PPTP 已从 ExpressVPN 应用中弃用；该页面还解释了 L2TP 和 SSTP，但并未提供它们。

Opera 将其自己的声明描述成审计师的结论。这就是 VERIFY 区块会如此拆分的原因。V01 基于实际打开的一份报告——Cure53 自行公开的 2022 年 3 月评估管理层摘要——而不是基于 Deloitte 公告的内容，因而为 yes_verified。

Deloitte 报告本身未在任何地方公开，因此 V02 为 press_only；凡是该报告的调查结果而非有关该项委托的事实的字段，均保持未知：覆盖的服务群（V04）、鉴证标准（V07）、报告所述的留存内容（V11）以及意见的强度（V15）。

委托事实——事务所、其类别、日期、列明已测试的内容——取自公告。一个已明确重新描述过这次审计的供应商，不是审计结论内容的来源。C01 为 none_linkable，因为隐私声明中的声明就是如此；V11 是调查结果，而没有可读取的调查结果。

Cure53 的报告真实存在，这也是 V14 为 yes_verified 的原因：七名测试人员、二十四人日，采用白盒方式，覆盖四个工作包，涉及 VPN 客户端、服务器配置和基础设施，以及用于交付 VPN 配置的 Opera Mini 协议。共发现十四个与安全相关的问题，其中八个为实际漏洞，五个被评为高严重性，没有一个为严重。

截至 2022 年 3 月，九项已修复且修复结果已得到验证，一项部分修复，三项接受风险，一项为误报，一项仍在处理中。Opera 的博客称，直接涉及浏览器 VPN 的七项问题“随后均已解决”，表格也证实了这一点——剩余问题位于 Opera Mini 工作包中，而不在 VPN 本身。

所有权已完全公开，且最终归属于一个义务国家，因此 X03 和 C11 指向相反方向，却并不互相矛盾。

Opera 自己的隐私声明中列明的数据控制者是 Opera Norway AS，这是一家挪威公司，透明度报告也以该名称提交。

控股公司是 Opera Limited，这是一家于 2018 年 3 月在开曼群岛注册成立的豁免公司，自身没有实质性运营。2025 年的 Form 20-F 将 Hong Kong Kunlun Tech Holding Limited 列为持股 68.0% 的主要股东；该公司是 Kunlun Tech Co., Ltd. 的子公司，于中国注册成立，并声明 Kunlun“是 Opera 的最终母公司，并由 Opera 的执行董事长控制”。

因此，M06 为 NO，C10 为 no，而 M11 为 CN，C11 为 yes。

C12 是 VPN 的声明与其所在应用之间最明显的空白。隐私声明的 VPN 部分声明不记录日志；同一文件的另一部分则表示，安装 Opera 应用时“会生成一个随机安装 ID。我们会收集此标识符以及 Machine ID、硬件规格（型号、发布日期等）、操作系统、环境配置和功能使用数据”，留存时间最长可达三年。

Machine ID 源自硬件，因此，无论隧道记录或不记录什么，服务商持有的标识符都是 persistent_hardware_id，而不是应用范围内的随机标识符。

X12 对比了 Opera 自行提交的两份文件。com.opera.browser 的 Play 数据安全表单声明会为分析收集已安装的应用，而隐私声明完全没有提到收集设备上已安装的应用。已安装的应用属于行为而不是标识符，因此为 undisclosed_behaviour。

同一表单声明会出于广告目的与其他公司共享设备或其他 ID，这正是 C07a 被判为 ads 的原因。C07b 依据的范围更窄，因此标记为 B：产品页面标记中唯一提供服务的第三方主机是 Google Tag Manager，而该容器在运行时加载的内容没有逐项列出。

U02 因产品设计而未知，并非因为搜索失败：免费 VPN 提供三个区域——Opera 将它们命名为美洲、亚洲和欧洲——但从不提供国家。C09 和 C09b 由此得出，在这一情况持续期间无法确定。

X05 是 Opera 自己说明页中的 ads_supported；该页面将广告列为三条收入来源中的第一条，并说明 Opera Ads 会收集随机生成的用户 ID、城市或国家以及所浏览网站的宽泛类别，留存时间最长可达一年；与 U05 = unlimited_free 合在一起，这正是 R15 要标记的情况。

X06 是 2026 年文章中关于 AES-256 的说法，即“即使使用速度最快的计算机，也需要黑客花费十亿多年才能破解”。X09 是两篇 2026 年文章中的 self_disclosed_prompt：Opera 公布了外部研究人员向其报告的漏洞，以及相关分析和修复版本——这些是浏览器漏洞，而不是 VPN 事件，且目前未知有任何 VPN 事件。

C05 为 not_sold。免费 VPN 完全没有付款步骤——没有订阅，也没有账户——因此不存在以匿名或其他方式付款的问题。

这条记录最初写作 none，其含义是“仅提供已识别的付款方式”，但这里并不属实，因为当时的词汇中没有表示服务不收取任何费用的标记；写作 unknown 则会声称搜索未找到结果，这同样不属实，在两个错误解读之间，记录了对服务商不利的那个。现在该标记已经存在，价格为零，这是诚实的答案：没有付款，就没有会泄露的付款身份。