パスワードを忘れた？ アカウント作成
Close
12354572 story
インターネット

HTML5のBattery Status APIでユーザー追跡の可能性が指摘される 38

ストーリー by headless
識別 部門より
HTML5のBattery Status APIで取得したデータを利用して、Webサイトがユーザーを特定する可能性が指摘されている(論文: PDF、 The Guardianの記事、 Mashableの記事、 V3.co.ukの記事)。

Battery Status APIは、Webサイトがモバイルデバイスやノートパソコンのバッテリー状態を把握し、必要に応じて低消費電力モードと高パフォーマンスモードに切り替えられるようにするためのもの。現在のところ、Battery Status APIはChromeおよびOpera、Firefoxで利用できる。W3Cではプライバシーへの影響は少ないとして、ユーザーの承認を得ることなく呼び出せるようにしている。

Battery Status APIでは充電中かどうか、バッテリー残り時間/充電完了までの残り時間(秒)、バッテリー残量レベル(0.0～1.0)といった情報のほか、充電状態の変化などのイベントが利用できる。研究チームがFirefoxを使用して検証した環境では、残り時間と残量の組み合わせは14,172,310通りとなり、充電時間を加えるとその2倍になるという。そのため、取得した情報がユーザーを識別するフィンガープリントとして使われる可能性もある。

(続く...)

バッテリー残り時間はPCの動作状況によって変化するため、長期間にわたってユーザーを追跡することは困難とみられる。ただし、情報は30秒に1回しか更新されないので、あるWebサイトを訪れた直後にプライベートブラウズモードで同じサイトを再度訪れた場合など、ユーザーが特定される可能性がある。サードパーティーのスクリプトを複数のWebサイトに配置すれば、ユーザー情報をサイト間でリンクさせることも可能だ。また、NAT越しにアクセスする企業ユーザーの場合にも、バッテリーの情報をもとにして識別が可能になる。

なお、WindowsやMac OS X上のFirefoxで返されるバッテリー残量レベルは小数点以下2桁となっている。一方、UPowerからバッテリー残量を取得するLinux上のFirefoxでは64ビットの倍精度浮動小数点数が返されるため、この値からバッテリーの容量を推定することも可能だという。仕様上のバッテリー容量は同じようなものが多いが、使用期間や使用状況によってバッテリー容量の減少度が異なるため、より正確にユーザーを特定することが可能となる。

研究チームではBattery Status APIで取得可能なバッテリー残量レベルの精度を下げることや、APIの使用にユーザーの承認を必要にするなどの対策を提案している。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

HTML5のBattery Status APIでユーザー追跡の可能性が指摘される More

  • Webサイトがモバイルデバイスやノートパソコンのバッテリー状態を把握し、必要に応じて低消費電力モードと高パフォーマンスモードに切り替えられるようにするためのもの。

    という目的であれば、

    充電中かどうか、バッテリー残り時間/充電完了までの残り時間(秒)、バッテリー残量レベル(0.0～1.0)といった情報のほか、充電状態の変化などのイベント

    なんて情報をWebサイトが取得できる必要性が無いはず。

    ブラウザが、ユーザーの設定や電池残量などを判断して、「低消費電力モードを希望」もしくは「高パフォーマンスモードを希望」のどちらか（その途中が必要ならば10段階でも良い）を返してあげれば十分です。

    大体、バッテリー残量が80%あっても夜まで充電環境が無いから節電したい場合もあるだろうし、残り30%であってもあと20分で充電環境が得られるから高パフォーマンスモードにしたい場合もあるのだから、ブラウザの設定からユーザーが「電池残量により自動的にブラウザが判断する」「低消費電力モードを希望」「高パフォーマンスモードを希望」を選択できる方が望ましいです。

    • > ブラウザが、ユーザーの設定や電池残量などを判断して、「低消費電力モードを希望」もしくは「高パフォーマンスモードを希望」のどちらか（その途中が必要ならば10段階でも良い）を返してあげれば十分です。

      そういうことを実現するために，電池残量を判断する Battery Status API が登場したんですが・・・

      シェア
      親コメント

      • そういうことを実現するために，電池残量を判断する Battery Status API が登場したんですが・・・

        「低消費電力モードと高パフォーマンスモードに切り替えられるようにするため」であるならば、window.navigator.battery [hateblo.jp]で、WebサイトがJavaScriptで「チャージ中かどうか」「充電完了までの時間」「電池０までの時間」「電池残量10段階」を取得できる仕様にしなくても、Webサイトが「低消費電力モードを希望するかどうか」のフラグだけ取得できれば十分ははずです。

        「チャージ中かどうか」「充電完了までの時間」「電池０までの時間」「電池残量10段階」という数値によって自動的に「低消費電力モードを希望」するかどうかの判断を行う場合であっても、その判定はブラウザがやれば良いだけです。その方が、ユーザーが設定によりそれを上書きできる実装にしやすくいため、プライバシーを保護できるだけでなく利便性も高まります。

        シェア
        親コメント
        • ストーリーの方に書いてあるように、電池残量は少なくとも100段階ですよ。雰囲気的にはOSから取得したデータをそのまま返しているだけのように見えます。

          ブラウザーが低電力モードにするかどうかを判断するようにすると、Webサイト側で細かいパフォーマンス調整ができなくなりますし、ブラウザーによって結果が異なってしまう可能性もあります。設定があっても普通の人は使わないでしょう。APIから得られる値の精度を落とすだけだと、ユーザー数が少ない場合には特定しやすくなる可能性もあるので、ユーザーの承認と組み合わせるのが現実的でしょうね。

          なお、navigator.batteryは古い仕様で、Firefoxだけが使用しています。ChromeとOperaは新しいnavigator.getBattery()が実装されています。
          シェア
          親コメント
          • バッテリー、ハード、OS、ブラウザに依存して結果が異なる数値を使って
            Webサイト側で相手の状態を判断して細かいパフォーマンス調整なんやりたくないなあ。
            シェア
            親コメント
            • 細かいといっても、すごくバッテリーの余裕があるときだけ高パフォーマンスモードにするとか、余裕がない時だけ省電力モードにするとかいうことを、処理内容に応じてWebサイト側が選べるという話です。もちろん、バッテリー残量レベルが予測よりも速く低下している場合には省電力モードにする、といったことも可能ですが、そこまでやるかどうかはWebサイト次第ですね。
              シェア
              親コメント

          • Re: (スコア:0)

            by Anonymous Coward

            １００歩譲って、そういうAPIを残すとして、ブラウザでも設定できるようにすべきでしょう。
            ブラウザのバッテリ監視変動設定がデフォルト以外になっているときは、そのAPIが無効になればいい。
            ユーザーの設定が優先されるべきなのは明らかです。

            • 設定可能にするとしてもデフォルトでオンにしなければほとんど使われないでしょうから、Geolocation APIと同様にユーザーへの承認要求は必要でしょうね。実際、設定画面を開いたこともない人は多いと思います。ただ、設定可能にするかどうかはブラウザー側の実装次第なので、APIとはあまり関係なさそうです。
              シェア
              親コメント

            • Re: (スコア:0)

              by Anonymous Coward

              > ユーザーの設定が優先されるべきなのは明らかです。

              「べき」とか「明らか」というのは，あなたの個人的要望であって，他人には何の説明にもなりません
              例えば，プログラム可能にするために Battery Status APIを用意すべきなのは明らかですね，と言われて
              納得できますか？

              設定すべきもの，優先されるべきものは，アプリケーション・運用ポリシーによって異なります．
              ここでBattery Status APIが標準化されば
              たとえば「ユーザーの設定が優先されるべき」Webアプリケーションであれば
              ユーザの設定が優先されるようにjavascriptを実装する，という選択肢が取れることになります

              思いつきでブラウザに新機能を追加するよりは，APIを標準化したほうが，よっぽど合理的だとは思いませんか？

      • Re: (スコア:0)

        by Anonymous Coward

        そのBattery Status APIを、high middle lowとか、もっと詳しく10段階、とかにしておけば、ユーザーが追跡されずに済むって話じゃね？

      • Re: (スコア:0)

        by Anonymous Coward
        だから、本来の目的からして、電池残量渡すAPIなんて必要がなかったんではってことでしょ？
        低消費電力モードか、高パフォーマンスモードかを返せばいいのだから。

        • Re:余計なお世話な機能ですね (スコア:2, すばらしい洞察)

          by Anonymous Coward on 2015年08月09日 13時59分 (#2861397)

          そうなんだけど、これって元々は「HTMLでアプリを実装しよう」っていう動機から来ているから、そういう正論は通じないんだよな。もともとHTML5じゃなくて、nokiaが(当時からみて次世代の)スマホを完全に制御するために策定してたAPIが横滑りで、いつの間にかHTMLに入ってたってやつだから。

          シェア
          親コメント

          • ああ、やっぱりFirefox OSとかPalm webOSみたいなHTMLとJavaScriptでできたGUIデスクトップのための話なのか。

            シェア
            親コメント

          • Re: (スコア:0)

            by Anonymous Coward

            こういう時にMSが新規格の仕様自体の安全性を検討して採用に慎重なのが有りがたい気もする。
            WebGLとかもセキュリティ上の都合でGL_ARB_robustness/GL_EXT_robustnessやクロスドメイン関連とかが対処されるまでヤバイ技術でしたし。

            • Re: (スコア:0)

              by Anonymous Coward

              △：仕様自体の安全性を検討して
              ◯：使用自体のMS帝国に対しての安全性を検討して

              • Re: (スコア:0)

                by Anonymous Coward

                誤字か意図的か判断に困る。

    • Re: (スコア:0)

      by Anonymous Coward

      ブラウザの内部機能の設定で、
      「電池残量が○％未満なら低消費電力モードにする」
      という選択肢をつけるのが正論ですよね。
      webサイト／アプリ側で選択する意味が全くない。

      APIつけるなら、当然通知を拒絶するオプションも用意されるのですよね＞仕様策定者様

      • Re: (スコア:0)

        by Anonymous Coward

        IE9以降はWindowsの電源オプションでJavaScriptの最短タイマー間隔が変わったりします。
        こういう感じで省電力フラグON/OFFが読めるだけで十分な気がしますね。

        # 駆動時間1時間未満のデスクノートPCと半日持つようなノートPCの1%の重みは違うわけだし、いまいちセンスが無い規格よね。

    • Re: (スコア:0)

      by Anonymous Coward

      ただでさえ勝手に起動して貴重なエネルギーを無駄使いするアプリに迷惑してるのに
      電池残量があるからってエネルギーの浪費を加速させるようなことはしないで欲しい
      電気はタダじゃないし貴重な資源と環境汚染から作られてるんだから

      daemonで起動するGoogleマップとか世界中でどれだけエネルギーを無駄に使ってるんだ？

    • Re: (スコア:0)

      by Anonymous Coward

      なんつ～か、本当にアホなソフト屋気質丸出しの機能
      何でWebサイトがモバイルデバイスやノートパソコンのバッテリー状態を把握しなきゃならないんだ？
      それで動作モードを切り替えるなんて余計なお世話

    • Re: (スコア:0)

      by Anonymous Coward

      そんなこと言ったら、省電力モードを実装したいサイトが個々に切り替えボタンを用意するだけでもいいような

  • すぐ改訂されそうな仕様 (スコア:0)

    by Anonymous Coward on 2015年08月09日 14時06分 (#2861399)

    バッテリーの残量・充電中かどうかが取得できても使いづらいなと思った
    バッテリー残量でどれ位の事ができるかは個体によって（バッテリー容量やハードウェア、設定、常駐ソフトなどの要因で）全く違うので「低消費電力モードと高パフォーマンスモードを切り替え」なんてことがちゃんと実装できるのか疑問

    出来るならバッテリー残量の減り具合をモニタしてあと1時間で空になるなら「低消費電力モードを希望するフラグを返す」のような実装にして欲しいな

  • どうせ (スコア:0)

    by Anonymous Coward on 2015年08月09日 18時13分 (#2861478)

    低消費電力モードになると、
    コンテンツは極端に劣化し、広告は前のまま。
    なのでどうでもいいかなあ。

    広告低消費電力モードを実装すべき。
    広告消せってんじゃない、ユーザーの環境によって控えめにしたほうが、ユーザーも広告主もお得だと思うんだよ。

    • Re: (スコア:0)

      by Anonymous Coward

      近頃は電池残量にかかわらず画像を劣化させるのが流行ですし。

    • Re: (スコア:0)

      by Anonymous Coward

      Twitterを開いたまま、タスクマネージャーを見てごらん...

  • 定番の対策を (スコア:0)

    by Anonymous Coward on 2015年08月09日 20時39分 (#2861526)

    メモリ確保のアドレスをランダムにするように,送る値もランダムに誤差をつけよう

    やっぱりバッテリー残量なんか仕様に入れる必要ないのでは…
    サポートされずに消滅することを願う

  • 姑息 (スコア:0)

    by Anonymous Coward on 2015年08月09日 22時21分 (#2861567)

    個人の識別をこういう姑息なことでしようとするから問題になる
    iPhoneのように識別子APIを実装して、必要なサイトはcookie強制のように使用を強制すればいい
    それ以外のAPIで個人識別できるようにするのは仕様のバグ・考慮漏れでしかない

  • くだらない (スコア:0)

    by Anonymous Coward on 2015年08月10日 3時37分 (#2861622)

    お前らがどこのエロサイトを見ようが誰も興味持ってないんだよ
    追跡されるかもとか被害妄想も甚だしい

    • Re: (スコア:0)

      by Anonymous Coward

      実際に追跡されるかどうかは問題じゃないよ。
      こういう仕様は、穴があった時点で広まらない。

  • 私がこの業界に入ったころは。

    「不要な情報は与えない、取らない（余計な責任を追うし、そこがセキュリティ突破の鍵になりかねないから）」
    「ユーザーの選択肢は極力少なく、だがユーザーの設定に対して勝手なこと（反すること）はしない」

    が基本と教えられたもんだが。

  • あなたは××さんですね？ (スコア:0)

    by Anonymous Coward on 2015年08月10日 23時33分 (#2862119)

    知っていたっす。そう、Statusを取得したからね。

typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー