Apple Health Sync

核心用法

Apple Health Sync 是一套面向 iOS 用户的隐私优先型健康数据同步方案，通过端到端加密机制将 Apple Health 数据安全迁移至 OpenClaw 智能体本地环境。完整工作流包含四大环节：初始化密钥对与二维码生成、加密数据拉取与解密、卫生化持久化存储、以及周期性报告生成。

初始化阶段 由 bootstrap_skill.py 主导，自动生成 RSA 密钥对、用户标识与写入令牌，并输出可供 iPhone 扫码的 QR 码，完成 iOS 端 Health Sync for OpenClaw App 的配对配置。

数据同步阶段 通过 fetch_health_data.py 执行挑战-响应认证，从中继服务获取加密载荷，本地解密后经严格 fail-closed 卫生化处理，默认写入 SQLite 的 health_data 表。支持手动触发或 OpenClaw CronJob 自动化调度。

报告生成阶段 由 create_health_report.py 实现，可按日/周/月聚合本地快照，输出文本或 JSON 格式，支持指定落盘路径。

显著优点

• 端到端加密：私钥永不离本地，中继仅传输密文，从源头杜绝中间人窥探
• 隐私优先设计：数据卫生化（sanitization）与 fail-closed 策略，异常数据自动丢弃
• Apple 官方生态兼容：直接对接 iOS HealthKit，无需越狱或私有 API
• 自动化就绪：原生支持 OpenClaw CronJobs，可无人值守运行
• 离线优先：解密与报告均在本地完成，无需持续云端连接

潜在缺点与局限性

• 单点密钥风险：若 private_key.pem 丢失且未备份，历史数据永久不可解密
• iOS 生态锁定：必须使用指定 App Store 应用，无 Android 替代方案
• 中继依赖：加密数据获取依赖外部中继服务，若服务不可用则同步中断
• 存储模式单一：强制固定至 ~/.apple-health-sync，不可自定义路径
• 功能范围受限：专注原始数据同步与基础聚合，不含医学级分析或诊断建议

适合人群

• 注重隐私的 Apple Health 重度用户
• 希望自建健康数据仓库、拒绝云端厂商锁定的技术爱好者
• 需要将健康数据接入 OpenClaw 自动化工作流的高级用户
• 对数据主权有合规要求的个人或小型团队

常规风险

• 密钥泄露：private_key.pem 一旦外泄，攻击者可解密全部历史数据
• iOS App 供应链：依赖第三方 App Store 应用，需信任其代码审计与更新策略
• 中继服务可用性：无公开 SLA 保障，存在服务中断导致同步延迟的风险
• 数据完整性：卫生化规则过于严格可能导致边缘场景数据丢失
• CronJob 配置误用：若绕过 OpenClaw CronJobs 使用系统 cron，可能引发权限或环境隔离问题

核心用法

Apple Health Sync 是一款专为 OpenClaw Agent 设计的健康数据同步技能，实现 iPhone 与 Agent 之间的端到端加密数据流转。用户需先在 iOS 安装配套 App「Health Sync for OpenClaw」，随后通过本地脚本完成初始化：生成 RSA/Ed25519 密钥对、创建二维码 onboarding 凭证，并将公钥安全传输至 iPhone。日常使用中，Agent 通过挑战-响应机制向 Supabase Edge Function 请求加密数据，本地解密后经严格净化处理存入 SQLite，最终可生成日/周/月度健康报告。

工作流分为三步：初始化（bootstrap_skill.py）建立安全通道；同步数据（fetch_health_data.py）获取并解密健康快照；生成报告（create_health_report.py）聚合分析。全程支持 OpenClaw CronJob 自动化调度，无需人工干预。

显著优点

安全架构扎实：采用非对称加密+挑战签名的双重验证，私钥永不离本地，传输层强制 TLS 1.2+，数据持久化前执行 fail-closed 净化策略，过滤非数值型敏感字段。

零依赖风险：纯 Python 标准库实现，不引入任何第三方包，彻底规避供应链攻击向量。

隐私优先设计：健康数据（心率、步数、睡眠等）经加密后本地存储，不上传至中心化服务器，符合 GDPR 数据最小化原则。

运维友好：内置 QR onboarding 降低配置门槛，支持 CronJob 自动化，报告输出格式灵活（text/json）。

潜在缺点与局限性

功能耦合度低：必须配合 iOS 专属 App 使用，Android 用户无法接入；若 Apple Health 数据权限未授权，同步将中断。

外部依赖单一：数据中继依赖 Supabase 云服务，虽为官方 API 且 HTTPS 加密，但存在服务可用性风险，自托管需修改硬编码端点。

运维门槛存在：需确保 ~/.apple-health-sync/secrets/ 目录权限为 0700/0600，共享环境或不当备份可能导致私钥泄露。

数据维度受限：净化机制仅保留数值型指标，字符串类健康数据（如症状描述）被过滤，复杂分析场景可能不足。

适合的目标群体

• 健康数据自托管用户：希望将 Apple Health 数据本地化、避免 iCloud 同步的隐私敏感型用户
• 量化生活研究者：需要定期生成健康趋势报告，进行步数、睡眠、心率等指标追踪的分析者
• Agent 自动化爱好者：希望通过 OpenClaw CronJob 实现「每日晨间健康简报」等自动化工作流的效率用户
• 安全合规场景：对企业或研究场景下健康数据处理有加密存储、审计日志要求的中小团队

使用风险

密钥管理风险：私钥文件 private_key.pem 若被复制或备份至非加密介质，将导致历史健康数据泄露。建议禁用云盘自动备份，定期轮换密钥对。

进程调用风险：使用 subprocess 调用系统 openssl CLI，虽无命令注入漏洞，但依赖本地 OpenSSL 版本兼容性，极端环境下可能出现签名/解密失败。

数据完整性风险：fail-closed 净化策略可能过度过滤，导致异常数据点丢失；建议定期核对 iOS 端原始数据与本地快照一致性。

服务连续性风险：Supabase 端点变更或 iOS App 下架将中断同步链路，需关注维护者社区更新。