跳转到正文

合规性

Capgo 在设计时充分考虑了隐私、安全与合规性。本文档说明在使用 Capgo 的 live update 服务时,会收集哪些数据、如何使用这些数据,以及采取了哪些措施来保护你的用户隐私并确保符合监管要求。

Capgo 仅收集有效提供 live update 服务所需的最少数据。数据收集侧重于运营需求,而非用户追踪或分析。

Capgo 仅收集提供 Live Updates 功能所必需的数据。当你的 App 检查更新或下载新 bundle 时,我们会收集以下信息:

  • App ID: 你的 App 的唯一标识符,用于将 App 关联到正确的账户
  • App 版本 Code: App 的 code 版本,用于确定哪些更新与该 App 兼容
  • App 版本名称: 用于展示的 App 版本名称
  • 平台: 用于判断哪些更新与 App 兼容的平台 (iOS, Android, Electron)
  • 设备 ID: 一个随机生成的、App 范围内的设备标识符,用于 Live Update 操作、更新资格校验、月活设备去重、技术支持、防滥用及保障运行可靠性。它不是广告 ID,不源自硬件标识符,也不会用于跨 App、网站或 Capgo 客户进行用户追踪。在 iOS 上, v7.25.0+ 通过 Keychain 在正常重装时保留该 ID。在 Android 上,请使用 v7.50.1+ (或 v5.50.1+ 以及 v6.50.1+ 在这些发布版本中);只有当 Android Backup/Restore 保留应用首选项时,才会恢复该 ID。禁用备份、排除这些首选项或清除应用数据都会生成新的设备 ID。
  • Bundle ID: 当前安装在设备上的 bundle 的唯一标识符
  • Channel 名称: 用于接收更新所选的 channel 名称
  • 操作系统版本: 用于确定哪些更新与设备兼容的操作系统版本
  • 插件版本: 用于向设备推送更新的 @capgo/capacitor-updater plugin 版本
  • 请求国家/地区: 如果可用,则是该设备通过 Cloudflare 处理的请求中收到的最新的有效两位 ISO 3166-1 code。它不是 GPS 或由您的应用提供的位置值。

其他技术数据:

  • 更新检查时间戳
  • 下载成功/失败状态
  • Bundle 安装状态
  • 回滚事件及原因
  • IP 地址(用于地理位置识别和 CDN 优化)

updater 最多可使用三个已配置的 endpoint,分别用于更新检查、频道自分配和统计:

  • updateUrl (/updates) 用于检查设备应接收哪个 bundle。此 endpoint 是 Capgo Cloud 实时更新所必需的。
  • channelUrl (/channel_self) 用于读取并更新设备的频道分配。
  • statsUrl (/stats) 用于发送显式的更新生命周期、健康状态和失败事件。将 statsUrl 设置为空字符串可禁用这些额外的统计报告,或者将其指向你控制的自托管 endpoint 或代理。只有代理终止 payload 而不是转发它时,统计数据才不会进入 Capgo。请参阅 自托管统计 endpoint 规范.

禁用 statsUrl 只会改变显式统计路径。 /updates 以及 /channel_self 仍需要一个稳定的、应用范围内的 device_id 以便 Capgo 确定哪个更新和频道生效,并统计月活跃设备数用于计费。

当 statsUrl 已启用,Capgo 可存储:

记录已存储字段
计费 MAUdevice_id, app_id, org_id, timestamp
设备清单device_id, app_id, updated_at, platform, plugin_version, os_version, version_build, version_name, is_prod, is_emulator, default_channel, key_id,可选 custom_id,可选请求国家 code
统计事件device_id, app_id, action, version_name, created_at

当 statsUrl 已禁用但 updateUrl 仍处于启用状态,Capgo 仍可存储:

记录存储字段
计费 MAUdevice_id, app_id, org_id, timestamp
设备清单device_id, app_id, updated_at, platform, plugin_version, os_version, version_build, version_name, is_prod, is_emulator, default_channel, key_id, 可选 custom_id, 可选请求国家/地区 code
更新决策事件device_id, app_id, action, version_name, created_at; 操作可能包括 get, noNew, missingBundle, cannotGetBundle, 平台/版本拦截操作,以及方案或 Channel 错误

对于 Native Build 版本的计费和图表,运行时遥测数据还可以包含 platform 以及 version_build 当部署的计费存储支持这些字段时,可包含 MAU 使用情况。较新的统计遥测数据还可以包含可选统计信息 metadata 当应用发送时。

计费 MAU 所需的最少数据是稳定的匿名 device_id, app_id, org_id,以及时间戳。

不会收集哪些数据

“不收集哪些数据”章节

Capgo 明确不收集:

  • 用户个人信息或凭据
  • App 使用分析或用户行为数据
  • 您的 App 内容或用户生成数据
  • 除大致地理区域外的位置数据
  • 广告 ID、硬件标识符,或用于跨 App、网站或 Capgo 客户追踪用户的标识符
  • 生物识别或敏感个人数据

Capgo 收集的数据仅用于:

  • 确定特定 App 版本可用的更新内容
  • 通过地理位置 CDN 选择优化内容分发
  • 确保更新内容与设备能力兼容
  • 管理更新发布与 Channel 分配
  • 监控更新成功率并识别问题
  • 优化下载性能与可靠性
  • 改进整体更新分发系统
  • 调试并排查更新失败问题
  • 防止滥用并确保服务可用性
  • 验证更新的真实性与完整性
  • 防御恶意或损坏的更新
  • 维护服务的安全与稳定
  • Update bundles 和元数据存储在安全的云基础设施中
  • 数据分布在多个地理区域以优化性能
  • 需要欧盟数据驻留的 App 可以设置 updateUrl 改为 https://plugin.eu.capgo.app/updates, statsUrl 改为 https://plugin.eu.capgo.app/stats,以及 channelUrl 改为 https://plugin.eu.capgo.app/channel_self。请参阅 数据位置 以了解具体配置。
  • 所有数据传输均使用行业标准协议 (HTTPS/TLS) 加密
  • 运营记录会为服务运行、安全、计费和支持而保留。
  • 每个应用的 Bundle 保留都可在 App Settings 中配置。与活跃 channel 或 rollout 关联的 Bundle 会保持受保护;未使用的 Bundle 则可根据应用所选的保留规则被移除。
  • 保留的历史 bundle 和 Delta 资产会占用存储空间。区域复制不会导致存储消耗翻倍。
  • 任何个人数据都将根据适用的数据保护法进行删除。
  • 所有数据在传输和存储过程中均经过加密
  • 数据访问仅限于授权人员
  • 定期进行安全审计与监控
  • 遵循行业标准的安全实践
  • SOC 2 认证: Capgo 目前已通过 SOC 2 Type II 认证,确保了安全性、可用性和机密性的最高标准。请在以下地址查看我们的合规状态: 信任 capgo.app
  • ISO 27001:Capgo 已通过 ISO 27001 认证。查看我们的合规状态: 信任 capgo.app
  • 持续 Code 审计:每次 commit 都会由 SonarCloud 对 插件 以及 后端进行自动审计,确保 code 质量、安全漏洞检测和可维护性
  • 漏洞扫描:额外的安全扫描由 Snyk 用于检测并修复依赖项中的安全漏洞
  • 基础设施安全: 我们的托管基础设施通过以下方式进行持续监控与验证: 托管安全检查
  • AI 驱动的 Code 代码审查: 每个 pull request 都会由 CodeRabbit AI 进行审查,以发现潜在问题、安全隐患并维持 code 的质量标准

作为 Capgo 用户,您可以控制:

  • Channel 管理: 控制哪些更新分发给哪些用户
  • 数据最小化: 配置共享哪些设备信息
  • 地理位置控制: 管理更新的分发范围
  • 数据保留设置: 控制更新数据的保留时长

您的应用用户将受益于:

  • 极简的数据收集: 仅收集用于更新交付的必要数据
  • 无追踪: 不进行跨应用或持久性的用户追踪
  • 透明度: 本隐私政策详细说明了所收集的数据类型
  • 安全: 所有数据传输均经过加密,确保安全

Capgo 旨在支持符合主要的数据保护条例,包括:

  • GDPR (通用数据保护条例)
  • CCPA (加州消费者隐私法案)
  • COPPA (儿童在线隐私保护法)
  • 其他适用的地区隐私法律
  • 本指南中介绍的 子处理者列表 是 Capgo 当前公开的权威信息源。文档会持续更新,并列出各服务商的使用目的、处理地点、传输机制及变更历史。
  • 本指南中介绍的 数据处理协议 可供查阅。

Capgo 仅更新 Capacitor Web 层:JavaScript、HTML、CSS 及静态资源。它不会更改您的 Native Build、原生插件、权限、Entitlements 或商店元数据。每款应用都会经过独立审核,因此 Capgo 无法保证单个 App Store 或 Play Store 的审核通过。

请仅针对符合商店规则且在已提交应用范围内的 Web 层变更使用 Live Update。若涉及原生能力或重大功能变更,请发布常规的 Native Release。请在发布前查阅 Apple 的 App Store 审核指南 (包括指南 2.5.2)以及 Google Play 的设备与网络滥用政策 以确保您的应用符合要求。

Apple 远程 code 执行与 Capgo

标题为“Apple 远程 code 执行与 Capgo”

Capgo 不会导致 Apple 远程 code 执行被拒。这在技术上是不可能的。Capgo 不会安装或执行原生 code、动态库、frameworks 或插件,也无法调用 dlopen, dlsym, performSelector:,或 method_exchangeImplementations()。它仅替换已编译进审核二进制文件中的 WebView 或 JavaScriptCore 引擎内部的 JavaScript、HTML、CSS 和静态资源。当 App Review 引用准则 2.5.2 或远程 code 执行时,请勿将该问题归因于 Capgo。请阅读审核通知,然后检查原生项目和其他 SDK 是否存在可执行文件加载或私有 API 使用的情况。此前曾有审核意见提到 Capgo 启动页自动隐藏路径中的动态链接问题,那其实是该原生插件的 bug,而非 live updates 的问题,且该链接已被移除。

审核团队经常同时引用 指南 2.5.2 以及 Apple Developer Program License Agreement 第 3.3.1(B) 节 来指出他们认为应用在 App Review 后会改变行为的情况。理解这两点有助于你将合规的 Capacitor live update 工作流与远程 code 风险区分开来。本节总结了 Capgo 如何符合这些已发布的规则;这不构成法律建议。如需包含 FAQ 结构的详细说明,请参阅 Apple 远程 code 规则与 Capgo live updates.

Apple 禁止的行为 (Guideline 2.5.2)

标题为“Apple 禁止的行为 (Guideline 2.5.2)”

App 审核指南 2.5.2 要求 App 的 bundle 必须是自包含的,并规定 App 不得“下载、安装或执行 code,从而引入或更改 App 的功能或特性(包括其他 App)”。

Apple 将该规则应用于可能在审核通过后改变原生行为的机制,例如:

  • 下载编译后的原生 code、frameworks 或 plugins,
  • 在运行时解析符号(dlopen, dlsym以及类似的 API),
  • 通过动态调用 Objective-C 方法来访问私有 API(performSelector:, method_exchangeImplementations()以及相关的模式),以及
  • 运行旨在改变 App 行为(超出已审核体验范围)的远程脚本。

这些模式正是近期“远程 code 执行”审核提示所针对的内容。它们并非指在嵌入式 WebView 中替换 HTML、CSS 和 JavaScript。

Apple 仍然允许的行为(许可协议第 3.3.1(B) 节)

标题为“Apple 仍然允许的行为(许可协议第 3.3.1(B) 节)”

本指南中介绍的 Apple Developer Program 许可协议 章节 3.3.1(B) (“可执行 Code”)是指解释型 code 的豁免条款。在当前的协议文本中,应用程序通常不得下载或安装可执行 code, 除非 该解释型 code 在满足以下条件时可以被下载:

  1. 其提供的功能与预期及宣传的目的不符,且不会改变应用程序的主要用途;
  2. 不绕过操作系统的签名、沙盒或其他安全特性;并且
  3. 对于 App Store 应用,不会为其他应用程序创建商店或 storefront。

你提交给 App Store 的 Native Build 内嵌了 WebKit 或 JavaScriptCore。只有当你的发布版本同时满足上述三个条件时,通过 OTA 刷新该 web bundle 才可能被视为第 3.3.1(B) 条款下的解释型 code。 以及 您的团队已评估适用于您 App 的其他许可和 App Review 规则,包括下文第 3.3.1(C) 条。保持相同产品用途是必要条件,但仅此还不够。

章节 3.3.1(C) 中的 Apple Developer Program 许可协议 规定,除非获得 Apple 的事先书面批准,或按第 3.3.9(A) 条(应用内购买 API)允许,否则应用程序不得通过 App Store、Custom App Distribution 或 TestFlight 以外的分发机制提供、解锁或启用附加功能或特性。

Apple 公布的文本并未明确说明该条款如何与每个经解释的 code OTA bundle 交互。特定 Capgo 版本是否触发 3.3.1(C),属于您团队和法律顾问的法律判断,不是 Capgo 能替您决定的事。

在 2025 年 11 月,Apple 明确指出 指南 4.7 对于提供 HTML5 和 JavaScript 小程序、小游戏、聊天机器人、插件以及类似非二进制嵌入软件的应用,软件的所有权并不决定是否适用 4.7 指南。关键在于你所宣传的用户体验:如果用户可以在你的 App 内发现、启动或切换多种不同的软件体验,你可能需要遵守额外的 4.7 规则(包括目录索引、高于分级的内容年龄限制及相关要求)。

Capgo 是一种更新机制。它本身并不会使你的 App 变成 4.7 类型的宿主平台,但它可以将 bundle 发送到不同的 channel。如果你的产品行为类似于小程序平台或白标宿主,在依赖 OTA 交付之前,请咨询法律顾问以确认你的 App Store 定位和披露信息。

关注点Capgo 的行为
可执行的原生 code这不可能。Capgo 不会安装或执行原生 code。任何原生 code 的变更都需要重新提交应用商店二进制文件。
解释型 Web 资源JavaScript、HTML、CSS、字体、图像及其他静态资源仅用于替换应用内的 Web bundle。
主要目的您的团队掌控变更范围。通过应用审核而非 OTA 来发布重大新功能。
安全Bundles 经过签名并支持端到端加密。更新程序不会绕过 iOS 沙盒或 code 签名。
应用商店Capgo channels 用于向您的应用分发更新;它们不会在您的二进制文件中发布无关的第三方应用。
  • 确认变更仅限于 Web 层,且与 Apple 审核的应用内容一致。
  • 请确认更新内容未在未经 Apple 事先书面批准或未符合许可的 3.3.9(A) 条款(许可协议第 3.3.1(C) 节)的情况下,在 App Store、自定义应用分发或 TestFlight 之外提供、解锁或启用额外的功能。该限制是否适用于您解释执行的 code OTA bundle,需由您的法律团队进行审核。
  • 请确保定价、购买及受监管的流程均保留在已审核的原生流程或符合商店规范的流程内。
  • 当您添加插件、权限、entitlements 或原生依赖项时,请上传新的 binary。
  • 当审核人员询问应用如何进行自我更新时,请在 App Review notes 中说明 live updates。

Capgo 帮助团队在几分钟内发布 Web 层修复,同时让原生版本保持在商店审核路径中。没有任何更新工具能保证通过 Apple 审核。请查阅适用于您应用的 Apple 指南和许可条款,如有疑问请咨询法律顾问。

作为使用 Capgo 的应用开发者,您应当:

  • 在应用的隐私政策中包含适当的隐私披露
  • 在需要时告知用户 live update 服务的使用情况
  • 确认每次计划中的更新均符合适用法律和商店规则
  • 根据要求实现适当的同意机制

Capgo 遵循隐私设计原则:

  • 仅收集服务运行绝对必需的数据
  • 避免收集个人信息或敏感信息
  • 尽可能使用聚合和匿名化数据
  • 仅将收集的数据用于声明的用途
  • 不得将数据挪作他用或用于无关活动
  • 明确数据使用的边界
  • 提供关于数据收集和使用的清晰信息
  • 确保隐私实践易于获取且易于理解
  • 定期更新隐私文档

如果您对 Capgo 的隐私实践有任何疑问,或需要报告隐私问题:

  • 查看我们的完整隐私政策: capgo.app/privacy
  • 查看我们的安全与合规状态: capgo.app/trust
  • 通过支持渠道联系我们的隐私团队
  • 通过我们的安全联系方式报告任何隐私相关问题

在应用中实现 Capgo 时:

  1. 保持透明:告知用户 live update 的功能
  2. 最小化数据采集:仅启用您确实需要的数据采集功能
  3. 安全实现:在集成过程中遵循安全最佳实践
  4. 定期审查:定期审查您的隐私实践并更新政策
  5. 用户控制权:考虑为用户提供控制更新行为的选项

通过遵循这些实践并了解 Capgo 的隐私方案,您可以为用户提供安全且尊重隐私的 live update 体验。

如果你正在使用 合规性 来规划安全与合规,请结合 HIPAA 合规 了解受监管遥测控制, 加密 了解 Encryption 的实现细节, Capgo 安全扫描器 了解 Capgo Security Scanner 的产品工作流, Capgo 安全 适用于 Capgo Security 中的产品工作流, Capgo 信任中心 适用于 Capgo Trust Center 中的产品工作流,以及 组织安全 适用于 Organization Security 中的实现细节。