Apple Health Sync

核心用法

Apple Health Sync 技能实现了 iOS 健康数据与 OpenClaw 代理之间的端到端加密同步工作流。用户通过运行 bootstrap_skill.py 初始化本地运行时环境，生成加密密钥对并创建二维码 onboarding 凭证；随后 iOS 设备使用配套 App「Health Sync for OpenClaw」扫描二维码完成配对。配对成功后，用户可通过手动命令或 OpenClaw CronJob 定期执行 fetch_health_data.py，该脚本会与中继服务进行挑战-响应认证，获取加密数据后在本地解密并执行严格的 fail-closed 脱敏处理，最终持久化至 SQLite 数据库。数据沉淀后，create_health_report.py 可按日/周/月维度聚合生成结构化健康报告。

显著优点

• 端到端加密：所有数据传输均采用非对称加密，私钥永不离开本地环境
• 隐私优先设计：数据在本地解密后立即经过脱敏处理，敏感字段被剔除后才入库
• 自动化就绪：原生支持 OpenClaw CronJob 调度，无需自定义 cron 脚本
• 多维度报告：支持日、周、月三种周期及 text/json 两种输出格式
• 苹果生态原生：与 Apple Health 深度集成，利用 iOS 健康数据的完整性与丰富性

潜在缺点与局限性

• iOS 生态锁定：必须拥有 iPhone 并安装特定 App，Android 用户无法使用
• 手动密钥管理：用户需自行保管 private_key.pem，丢失将导致历史数据无法解密
• 网络依赖：数据获取依赖外部中继服务，离线场景下无法同步
• 存储固定路径：运行时目录强制锁定在 ~/.apple-health-sync，灵活性受限
• 密钥轮换成本：更换密钥需重新执行完整的 iOS 端 onboarding 流程

适合人群

• 注重隐私的 Apple Health 重度用户
• 需要将健康数据用于个人分析或自动化工作流的技术用户
• 希望避免云端明文存储敏感健康数据的隐私敏感型用户

常规风险

• 密钥泄露风险：私钥文件若被备份至非加密介质或误提交至版本控制，将导致数据泄露
• 供应链风险：依赖苹果 App Store 分发的配套 iOS 应用，存在审核延迟或下架可能
• 中继服务可用性：若中继功能故障，同步流程将中断
• 数据完整性风险：脱敏策略配置不当可能导致关键健康指标被过度过滤

核心用法

Apple Health Sync 是一套端到端加密的个人健康数据同步方案，实现 iPhone 与 OpenClaw Agent 的双向安全连接。完整工作流分为五个阶段：首先运行初始化脚本生成本地运行环境、密钥对和 onboarding 载荷；随后通过 QR 码或复制粘贴方式将 USER_ID、PUBLIC_KEY、WRITE_TOKEN 绑定至 iOS 配套应用；接着执行加密数据拉取与解密，应用严格的 fail-closed 数据清洗策略；最后基于本地快照生成日报、周报或月报，并可通过 OpenClaw CronJobs 实现自动化调度。

关键脚本包括：bootstrap_skill.py 负责环境初始化与密钥生成；fetch_health_data.py 执行挑战-响应认证、解密和数据持久化；create_health_report.py 支持按日/周/月聚合数据并输出文本或 JSON 格式。运行时目录固定为 ~/.apple-health-sync，数据默认存储于 SQLite 数据库。

显著优点

1. 端到端加密安全架构：采用 RSA/Ed25519 非对称加密，数据离开 iPhone 前即完成加密，仅本地 Agent 持有私钥， relay 服务端无法解密内容。
2. 零第三方依赖风险：核心功能仅依赖 Python 标准库与系统 openssl 命令，无 PyPI 包引入的供应链攻击面。
3. 严格的输入验证与清洗：fetch 环节实施 fail-closed 策略，异常数据直接拒绝而非容错处理，降低注入攻击风险。
4. Apple App Store 官方分发：配套 iOS 应用通过 Apple 审核上架，来源可信度高于侧载方案。
5. 灵活的自动化支持：原生兼容 OpenClaw CronJobs，支持定时同步与报告生成，无需自建 cron 任务。

潜在缺点与局限性

1. 硬编码服务端点与密钥：Supabase Edge Function URL 和 publishable key 直接写死在源码中，用户无法自主更换后端服务或验证托管方数据政策。
2. 自定义 Sink 的命令注入风险：shell=True 的子进程调用模式在启用 custom_sink_command 时存在注入漏洞，需用户谨慎配置。
3. T3 来源可信度限制：由个人开发者维护，无企业背书或基金会治理，长期维护连续性存在不确定性。
4. iOS 生态锁定：依赖 Apple Health 数据权限，Android 或其他健康平台用户无法使用。
5. 网络依赖与隐私顾虑：数据需经 Supabase 中继，尽管已加密，但元数据（访问时间、IP、数据量）仍可能被服务端记录。

适合的目标群体

• 隐私敏感型用户：希望将健康数据保留在本地而非 iCloud 或第三方健康平台
• 量化自我爱好者：需要定期生成健康趋势报告进行长期追踪
• OpenClaw 生态用户：已部署 Agent 环境并希望扩展健康数据能力
• 开发者与技术爱好者：具备代码审计能力，愿意 fork 后自定义后端服务

使用风险

• 性能风险：加密解密操作增加 CPU 开销，大批量历史数据同步时可能阻塞
• 密钥管理风险：私钥 (private_key.pem) 泄露将导致历史数据全部暴露，需严格备份与权限控制
• 依赖项可用性：Supabase 服务端点或 Apple App Store 应用下架将导致功能中断
• 数据完整性：本地 SQLite 存储无内置备份机制，磁盘损坏可能导致数据丢失
• 合规提醒：CCPA 知情权条款标记为 warn，企业场景使用前建议补充隐私政策披露