Summary

  • 電池状態を知れば、ウェブアプリは充電していないときに作業を減らし、電源が尽きる前に文書を保存できる。
  • 残量や残り時間を細かく渡すほど、機器を区別する材料にもなる。W3C の議論は精度の抑制、許可、値のぼかしへ進み、2024年の草案では安全な接続と埋め込みページの利用制限も明記した。

電池が弱っているのに、メールのページが数秒ごとにサーバーへ新着を聞きに行く。働き者だが、少々空気が読めない。文書編集ページなら、電源が落ちる前に保存してほしい。2016年の W3C 提案 はこの二つを用途として挙げた。ブラウザーが電源の状態を伝え、アプリが作業量を決める。電池は休みたい。書き手は文章を失いたくない。その両方に使える合図だった。

2011年4月の最初の公開草案 は、広い System Information API から電池のイベントを切り出したものだ。電池を使っているか、充電中か、0から100の残量、秒単位の残り時間が検討された。いくつかの項目には、まだ強い用途を探していると本文自身が書いている。サンプルは残量を記録する。ここでの仕組みはイベントであり、後の getBattery() と同じ形ではない。メーターを見せる案が先にあり、どこまで見せるべきかの答えは後から追いかけた。

細かい数字には二つの顔がある。残量の変化が分かれば作業を控えられる。充電の有無、残量、残り時間を組み合わせれば、訪問者の機器を区別する小さな動く輪郭も作れる。ページは住所録を盗まなくても、机の上の機械について手掛かりを得てしまう。節電のために置いた時計を、別の人が名札として読むわけだ。

問題は標準の会議室に入った。2015年7月の W3C 作業部会メール で、議長 Frederick Hirsch は電池情報のプライバシー研究を受けた提案を伝えた。高精度の読み出しがフィンガープリントの材料になると書くこと、アクセス許可を考えること、利用を本人に知らせること。記録が示すのは作業部会の具体的な検討だ。すべてのサイトが電池で人を追跡したという話ではない。

2016年の Proposed Recommendation は高精度表示を避けるべきだと書き、許可や値のぼかしも選択肢にした。この時点では navigator.getBattery() が BatteryManager を返し、充電状態、残量、充電・放電までの時間を扱う。実際の状態を報告できない場合、満充電で電源につながっているように見える既定値を返す。値を隠した利用者にアプリが勝手に不利な扱いをしないためでもある。「満タン」は時に電池の自慢ではなく、ブラウザーのカーテンだ。

2024年10月の W3C 草案 では getBattery() を安全なコンテキストで使う。Permissions Policy の battery は既定の許可先が 'self' で、利用を認められない文書には NotAllowedError が返る。高精度に関する注意も残る。ブラウザーは許可を求めたり値をぼかしたりできる。ページが省電力の判断をする入口は残し、残り秒数を誰でも読み放題にする契約にはしない。

W3C の公開履歴 には2011年からの草案、2016年の推薦に向けた段階、2024年の改訂が並ぶ。これは仕様の年表で、すべてのブラウザーの実装日を一列に並べた表ではない。設計が学んだのはもっと身近なことだ。役立つ合図も、細かすぎれば訪問者の名札になる。

電源が落ちる前に文書を保存するのは、今も良い仕事だ。メールの確認を少し減らすのもいい。そのために電池の最後の一秒まで実況する必要はない。