Summary

  • 电池状态接口让网页按电源情况调整工作：邮箱在断电运行时少轮询，文字编辑器在关机前先保存。
  • 精确的电量与时间读数也能成为识别设备的线索。W3C 从 2015 年的隐私讨论走到降低精度、可选授权、模糊数值，以及后来的安全上下文和 Permissions Policy 边界。

电脑快没电时，网页邮箱还每隔几秒问服务器“有信吗”，多少有点不识趣。文字编辑器若能趁最后一点电把文章保存，倒算办了正事。2016 年 W3C 的规范提案 就举了这两种例子。浏览器只需告诉应用电源大致如何，应用自己决定少做点事还是先把事做完。电池和作者都可能受益，只是偏爱的选项不一样。

最初的设计是一声提醒，还不是后来熟悉的 getBattery()。2011 年 4 月首份公开草案 从更庞大的 System Information API 中抽出了电池状态事件。它考虑是否用电池、是否充电、从 0 到 100 的电量，以及以秒计的剩余时间；部分字段的高价值用途仍在寻找。示例程序把电量写到日志里。仪表已经摆上桌，但还没人说清每个路过网页都该读到哪一格。

应用确实有用途。全天开着的邮箱减少轮询，能少耗一些电；文稿在机器熄火前落盘，能救回一段写了一下午的文字。但精确度也把信号变成别的东西。电量百分比、充电状态和不断变化的时间估计放在一起，可以勾出一台设备的短期轮廓。网站没拿到通讯录，也可能从仪表上得到辨认来客的线索。好心帮人省电的表，忽然有了陌生观众。

这种担忧进入了标准制定现场。2015 年 7 月 W3C 工作组邮件 中，主席 Frederick Hirsch 转述了针对电池读数的具体建议：写明高精度信息带来的设备指纹风险，考虑访问许可，并让用户知道脚本正在使用接口。邮件对应的是当时的原始隐私研究；它证明工作组正在讨论问题，不是“所有网站都靠电池追踪人”的统计。

2016 年的 Proposed Recommendation 把担忧写进隐私章节。浏览器应避免过高精度，可以征求许可，也可以模糊返回值。接口此时由 navigator.getBattery() 提供 BatteryManager，含充电状态、电量、充电时间和放电时间。如果无法报告实际情况，默认值模拟“已充满、接着电源”。这样网站不能仅凭一个被隐藏的读数，就擅自给使用者降级体验。有时显示满电，并非电池真在庆祝，而是浏览器拉上了窗帘。

到 2024 年 10 月草案，门口又加了明确规则：getBattery() 位于安全上下文，Permissions Policy 的 battery 默认允许列表为 'self'，被禁止的文档会得到 NotAllowedError。避免高精度读数的提示依然在。浏览器仍可要求许可或模糊结果。网页要做省电决定，理应先过浏览器这道门，而不是理直气壮地索取电池生命的逐秒实录。

W3C 发布年表 从 2011 年草案延伸到 2016 年推荐路线上的文本与 2024 年修订。这些是规范日期，不等于所有浏览器同一天开放或关闭接口。真正的故事是一次设计纠偏：网站要一个省电提示，却发现提示过于精确时也会给访客贴标签。

电脑仍该在关机前保存文件。邮箱仍可以识趣地少敲几次门。完成这些小善意，不需要端着放大镜盯住电池每一口气。