企业官网建设流程全解析

数据隐私与所有权：Open Wearables自托管安全机制、遥测开关与数据归档策略完整指南

【免费下载链接】open-wearablesSelf-hosted platform to unify wearable health data through one AI-ready API.项目地址: https://gitcode.com/gh_mirrors/op/open-wearables

Open Wearables是一款面向个人与开发者团队的自托管可穿戴健康数据平台，通过统一的 REST API 将 Garmin、Oura、Whoop、Apple Health 等主流设备的数据归一化存储在你自己的服务器上。这意味着：你的健康数据始终掌握在你手里——从加密存储、身份认证，到遥测数据的匿名化、数据归档与保留策略，每一环都提供了清晰的开关与文档。本文将带你从零读懂 Open Wearables 的三大隐私支柱：安全机制、遥测开关与数据归档策略。

为什么"自托管"= 数据所有权

传统可穿戴平台的模式是：设备 → 厂商云 → 你的 App。数据一旦进入厂商服务器，你就失去了实际控制权。Open Wearables 采用了完全不同的架构：

设备 → 厂商云/SDK → 你的 Open Wearables 实例 → 你的应用/AI

所有归一化后的健康数据都写入你本地部署的 PostgreSQL，通过统一的 REST API 暴露给前端、后端或 AI Agent。厂商云只负责"传输"，最终数据的存储、访问、删除权都在你的服务器上。

这种架构下，隐私问题就从"厂商是否泄露数据"变成了"你的实例如何被安全访问、如何控制数据生命周期"。接下来的三章正是围绕这两个问题展开。

安全机制：从密码哈希到 API 密钥的全链路

1. 密码存储：bcrypt 加盐哈希

管理员与开发者账号的密码从不以明文存储。核心实现在 backend/app/utils/security.py：

• 使用bcrypt生成随机盐并对密码加盐哈希
• 超过 72 字节的密码会被安全截断（bcrypt 的硬上限）
• 校验时使用bcrypt.checkpw，杜绝时序攻击

2. API 密钥：只存哈希，明文只显示一次

后端集成的 API 密钥采用更严格的设计，参见 backend/app/services/api_key_service.py：

这意味着：即使数据库被拖库，攻击者拿到的也是不可逆的哈希值，无法还原原始 API Key。密钥轮换功能（rotate_api_key）允许一键生成新 key，旧 key 立即失效。

3. 敏感配置：Fernet 对称加密

对于需要写入.env的第三方密钥（如 S3、OAuth 客户端密钥），Open Wearables 提供了Fernet 对称加密方案，实现在 backend/app/utils/config_utils.py：

• 通过MASTER_KEY环境变量提供主密钥
• 敏感字段在写入配置前自动加密、读取时自动解密
• 配套脚本位于 backend/scripts/cryptography/，可独立生成/加解密密钥

这套机制让.env文件即使被误提交，也拿不到有效的第三方凭据。

4. 会话认证：JWT 短时效 Token

开发者门户登录采用 JWT，过期时间由ACCESS_TOKEN_EXPIRE_MINUTES控制，配合 backend/app/utils/auth.py 中的oauth2_scheme完成统一鉴权。移动端 SDK 使用独立的sdk_token，与开发者 JWT 严格隔离，避免越权访问。

遥测开关：透明、匿名、可一键关闭

默认开启，但绝对透明

Open Wearables 的匿名使用遥测默认开启（backend/app/services/telemetry_service.py），每天最多发送一次 + 启动时一次（12 小时防抖）。API 启动时会明确打印日志提醒：

Anonymous usage telemetry is enabled (aggregate counts only, no user data).

只收集"量级"，不收集"具体值"

所有计数都使用数量级桶（bucket）而非精确数字：

这样设计的原因是：如果每天发送精确数字，攻击者可以通过两次 ping 的差值反推你每天新增了多少条健康数据。桶只在跨越数量级时才变化，从根本上消除了"差分侧信道"。

明确不收集什么

官方文档 docs/dev-guides/telemetry.mdx 列出了硬性边界：

• ❌ 任何用户数据（姓名、邮箱、ID、健康指标）
• ❌ 任何凭据、Token、API Key
• ❌ 主机名、IP、URL
• ❌ 精确数字（只有数量级桶）
• ❌ 原始请求路径、查询串、User-Agent
• ❌ Commit 哈希（可暴露你的自定义分支）

甚至连月经周期数据端点都被完全排除在遥测之外。

一键关闭遥测

在backend/config/.env中设置任一环境变量即可：

# 方式一：显式关闭 TELEMETRY_ENABLED=false # 方式二：遵循开发者工具通用约定 DO_NOT_TRACK=1

两者等效，会彻底停用遥测：无定时任务、无启动 ping、无 HTTP 调用、无请求计数。验证方式：重启后启动日志不再出现遥测提示行。

网络级兜底：如果想让安全保证完全不依赖配置，直接在防火墙拦截出站到telemetry.openwearables.io的流量即可。遥测是 best-effort 设计，被拦截只记WARNING日志，绝不影响实例运行。

数据归档策略：控制存储增长的两大杠杆

时间序列数据（如每分钟心率）会随时间和设备数线性增长。Open Wearables 通过数据生命周期（Settings → Data Lifecycle）提供两个独立策略，实现位于 backend/app/services/archival_service.py，文档见 docs/developer-portal/settings/data-lifecycle.mdx。

杠杆一：归档策略（Archival）

"将 N 天前的原始样本聚合成日级摘要"。

• 阈值范围：1 ~ 3650 天
• 效果：存储体积下降约 500 倍，聚合精度基本无损
• 场景：保留长期趋势分析能力，但不再需要分钟级细节

杠杆二：保留策略（Retention）

"永久删除 N 天前的数据"。

• 阈值范围：1 ~ 7300 天
• 与归档组合时：先归档、再删除归档层，避免"先删后归档"的数据丢失
• 删除不可逆，页面会在配置错误时明确警告

三种策略组合的效果

页面顶部的增长预测图会基于当前摄入速率模拟未来 18 个月的数据库体积，让你在保存前就能看到不同策略组合的差异。任务每日自动执行，也可以点Run Now立即触发验证。

隐私配置速查表

给自托管者的三条落地建议

1. 第一次登录后立即修改默认密码，并邀请团队成员时使用门户的邀请机制，而非共享账号
2. 生产部署前评估遥测：多数场景保留默认开启即可（数据极小、匿名化严格）；若部署在内网隔离环境，建议设置DO_NOT_TRACK=1并在防火墙层面双保险
3. 接入 3 个月以上再配置数据归档：先观察 Data Lifecycle 页面 的增长预测图，再根据实际摄入速率选择合理的归档/保留阈值，避免过早删除仍需要的原始样本

自托管的核心价值不是"多一层防火墙"，而是把每一个隐私开关都交给你自己。Open Wearables 从安全机制、遥测透明度到数据归档策略，都遵循"默认透明 + 一键可控"的原则，让个人开发者与小团队也能真正掌控健康数据的所有权。

【免费下载链接】open-wearablesSelf-hosted platform to unify wearable health data through one AI-ready API.项目地址: https://gitcode.com/gh_mirrors/op/open-wearables