2 ポイント 投稿者 GN⁺ 2024-07-10 | 1件のコメント | WhatsAppで共有
  • Google Chrome は *.google.com サイトに対してのみ、システム/タブのCPU使用量、GPU使用量、メモリ使用量、詳細なプロセッサ情報、ロギング用バックチャネルへのアクセスを許可するAPIを提供している
  • 他のサイトには同じAPIが公開されておらず、ブラウザベンダーが自社Webサイトに 特別な権限 を与えてよいのかが議論になっている
  • DMAは、インターネットのゲートキーパーであるブラウザベンダーがすべての相手に同じ機能を提供すべきだという考えを法文化しており、解釈によってはGoogleのプロパティにのみ追加情報を公開する行為が DMA違反 となる可能性がある
  • Zoom は Google Meet と同様の CPUデバッグ機能 を提供されておらず、競争上不利な立場に置かれる可能性がある
  • この機能は無効化できず、拡張機能パネルにも表示されない 組み込みChrome拡張機能 として実装されており、Microsoft Edge と Brave でも *.google.com ドメインに対してのみ同じ機能が提供される

*.google.com 専用APIが公開する情報

  • Chrome は *.google.com サイトに対してのみ、システム状態やデバッグに近い情報を提供する
    • システムおよびタブの CPU使用量
    • GPU使用量
    • メモリ使用量
    • 詳細なプロセッサ情報
    • ロギング用バックチャネル
  • 同じAPIは他のサイトには公開されず、*.google.com ドメインでのみ利用できる

実装方式とChromium派生ブラウザでの動作

  • この機能は無効化できず、拡張機能パネルにも表示されない 組み込みChrome拡張機能 として実装されている
  • ソースコードは Chromium の hangout_services パスにある
  • 同じ拡張機能が他の Chromium 派生ブラウザにも含まれているかは不明だったが、その後の更新で次の動作が確認された
    • Microsoft Edge でもこの機能は *.google.com ドメイン専用 として提供される
    • Brave にも、Google が *.google.com でのみこの情報を取得できるようにする拡張機能がプリインストールされており、Chrome および Edge と同様の動作を示す

競争と規制上の論点

  • ブラウザが特定の自社ドメインに対してのみシステム情報を提供すると、他のWebサービスは同じ水準の診断機能を実装しにくくなる
  • Zoom は Google Meet のような CPU デバッグ機能を提供されない事例として挙げられており、これはブラウザベンダーによる 自社サービス優遇 の問題につながる可能性がある
  • DMAの観点では、ゲートキーパーが機能へのアクセスを平等に提供すべきかどうかが中心的な論点として残っている

1件のコメント

 
GN⁺ 2024-07-10
Hacker News の意見
  • hangout_services という名前を見ると、Google Hangouts の開発を楽にするために作られた古い技術的負債的なハックのように見える
    Hangouts チームにテレメトリデータを直接流す用途だったのだろう。Hangouts はブラウザ上でビデオ通話を実現した最初のアプリで、これが後に WebRTC になった。このモジュールは、アプリが本来は見られない CPU/GPU/RAM 使用量やハードウェア情報を公開する。Google はこの Twitter スレッドを見て、単に削除するのではないか。Hangouts はすでに終了した製品だし、サーバー側コードがまだ使っているとしても、今では WebRTC の利用範囲がずっと広いので、Chrome チームが複数サイトの方式でパフォーマンスを直接監視しているはず

    • いや、これは今 Google Meet で使われている。Chrome で meet.google.com の「Troubleshooting」パネルを開くと、システム全体の CPU 使用率がリアルタイムで見える :)
    • プライバシー侵害はさておき、これは明らかな反トラスト問題ではないかと思う。Google がブラウザでの支配力を乱用して、ビデオ会議市場で自社製品に優位性を与えている
    • CPU/GPU 使用率などを追跡して、どの品質の映像ストリームを使うかを細かく調整する用途なのかもしれない
      非標準ではあるが、ネイティブアプリならこういうことは十分やりそうだ
  • この部分について少し説明できるかもしれない。ちなみに元 Google 社員です
    かつて Google 社内のビデオ会議プラットフォームである GVC で働いていた。2010〜2011年当時、社内の多くのビデオ会議機器は Cisco Tandberg のようなプロプライエタリな機器で、価格が高く、数千の会議室に展開するにもコストが大きかった。似た時期に別のチームが Hangouts を開発中で、当時の名前が Google Meet だったのか、後からそうなったのかは記憶があいまいだ。Hangouts という名前は、Google+ が出て製品に統合されるときに採用されたように思う。GVC の構成はいくつかあったが、最も一般的だったのは All-in-One(AIO)モニター/コンピューターの組み合わせで、完全な Intel PC だった。そのため GVC プラットフォームはカスタム Linux ディストリビューションで、Google サービスと通信し、ソフトウェアアップデートを配布するよう設計されていた。起動失敗に備えて古いディストリビューションも保持していたし、機器名の付け方などいろいろな問題があった。タッチパネル、大型 PTZ カメラ、複数のマイクといったさまざまなハードウェアのサポートも必要だった。最終的に Hangouts が GVC の基盤スタックとなり、ほぼすべての Tandberg を置き換えて大きな費用を節約した。このシステムは少なくとも2017年までは使われていたが、その後は分からない。監視もその一部だったので、*.google.com 専用 API が見えるなら正確に見る必要がある。Google が世界中のすべての Chrome インスタンスを照会できるのか、それとも google.com でだけ可能なのかは、Tweet だけでは分からない。ただし hangouts_services という名前とドメイン制限を見ると、GVC 向けの組み込み Chrome 監視サポートである可能性が高そうに見える。間違っているかもしれない

    • これはそれではないと思う。さっき Firefox で Meet 通話をしてみたところ、トラブルシューティングボタンを押すと CPU チャートが無効化されていて、「CPU 使用率を見るには Chrome を使ってみてください」という文言が出た
      Chrome では Meet が使っている CPU なのかシステム全体なのかは分からないが、CPU 使用率を見ることができ、どちらにせよ通常の API で可能なことではなさそうだ。バックグラウンドで yes をいくつか動かして確認したところ、確実にシステム全体だった。付け加えると、名前の混同はいつも起きるが、GVC は本当に明確で良い名前だ
    • 興味深い話だが、この件と遠い形であってもつながっている可能性はなさそうだ。カスタム Linux ディストリビューションで GCV プラットフォームを運用している人たちが、マシン統計を報告する方法として「自分たちが作ったカスタム拡張を世界中のすべての Chrome インストールに入れよう」を選んだとは考えにくい
      任意の *.google.com ページで直接試せる:
      chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
    • 「Google が世界中のすべての Chrome インスタンスを照会できるのか、それとも google.com でだけ可能なのか」という区別がよく分からない
      API は *.google.com で実行されるコンテンツにだけ公開されているようだが、それでも「Google が自社サイトを訪れたすべての Chrome インスタンスを照会できる」とほぼ同じだ。Google サービスを使わなくても、Chrome はデフォルトで新しいタブページのコンテンツを Google から取得するので、実質ほぼ100%に近い。悪意をもって使われているとは思わないが、Google がこの方法で問題を診断でき、同じ領域の競合他社にはできないなら、やはり問題だ。Zoom にはこういう API はないのでは?
    • Google で働いたことはないが、この説明にはあまり納得できない
      社内ビデオ会議プラットフォームの内部アプライアンスで CPU 使用率を観察するために、一般ユーザー向けの Google Chrome にこのバンドルプラグインを入れた、ということなのか?
    • 興味深い。もしかすると Google の大半の人も、これが可能だということを今まで知らなかったのかもしれない
      今ごろ何十人ものプロダクトマネージャーが、自分の製品の技術リードに「まあ、とりあえず聞いてくれ…」と近づいていそうだ
  • この機能は2013年10月に追加されたようだ: https://github.com/chromium/chromium/commit/422c736b82e7ee76...
    Chrome に Hangouts Services 拡張をバンドルするというコミット。BUG=291271、レビュー URL: https://codereview.chromium.org/35873003。該当のレビュー URL は https://codereview.chromium.org/35873003

  • このAPIが正確に何で、なぜ存在するのかは分からないが、Firefoxも似たようなことをしている
    拡張機能のインストールや初回起動体験の補助のように、MozillaおよびFirefoxのドメインでしか使えない特殊なAPIがある。12か月も経たないうちに関連するブログ記事がHacker Newsに上がっていたが、見つけにくい

    • ほとんど同じことではない
      APIは公開され、文書化されており、ドメインの許可リストもUIとabout:configに入っている。Android Play Store版は、ブラウザを純粋なゴミにしようとしているのか、すべてを隠しているので例外だ。そして優れたユースケースを持ってBugzillaで丁寧に依頼すれば、開発者たちは既定ドメインの追加を少なくとも検討はしてくれそうだ
    • それはブラウザ運用に直接関係するWebサイトのためのものだ。一方Chromeは、Google Meetのような別のGoogle製品で使うAPIを公開している
      ある市場、つまりブラウザでの独占を利用して、別の市場であるビデオ会議で優位を得るものなので、独占禁止法違反かもしれない
    • かなり前にUITourの部分について書いたことがある: https://www.mkelly.me/blog/content-uitourjs/
      ブラウザの間ではかなり標準的なやり方だ。リスクは、ブラウザがソフトウェア更新をダウンロードするドメインを誰かが偽装する場合と同程度であるべきで、本当に嫌なら設定でオフにできる
    • 先月、WebKitのQuirks.cppのコミットが共有されていた [0]。たぶん探していたものではないだろうが、似た雰囲気はある
      [0] https://news.ycombinator.com/item?id=40631439
    • そうしたAPIはブラウザ機能とオンボーディングに関するものだ。Mozillaの別製品を、他社の類似製品より有利にするために入ったものではない
  • 参考までに、Googleで働いているが、ChromeやこのAPIの担当ではない
    説明はかなり平凡だと思う。たとえばGoogle Meetを開き、空の会議、つまり「インスタント会議」を開始してから「…」メニューで「トラブルシューティングとヘルプ」を押すと、CPU使用率を含む複数の統計グラフが出る。Meet通話中にマシンに負荷がかかると、タブを閉じるよう親切に提案してくれることもあるようだ。かなり便利なので、ときどき確認している。考え直してみると、タブを閉じろという提案が実際にあるかは確かではなく、実際に使ったことがあるのは統計画面だけだ

    • 「かなり平凡だ」という説明とは違って、これはまったく平凡ではない。自社製品に不公正な競争上の優位を与える完璧な例だ
      Meetのユーザーは会議がなぜうまくいかないのか案内されるが、Zoom、Teams、Slackが同じことをできないなら、Meetのユーザー体験が良くならざるを得ない。他のすべての会議サービスがデスクトップアプリを積極的に使わせようとするのも不思議ではない。Google Meetのデスクトップアプリは、要するにChromeなのだ
    • むしろそれが核心だ。他のビデオ会議ツールはこうしたデバッグオプションを提供できず、今述べたようにその機能は有用だ
    • 競合であるZoomにはブラウザ版がある。性能問題を診断するためにこのAPIを使えるのか。使えないなら、欧州の規制当局が関心を持つかもしれない
      もしかすると、Meetはブラウザでうまく動き、Zoomはそうではないため、特に会議参加者が多いときに、Zoomユーザーが適切な性能を求めるならネイティブアプリを使うことになる理由の一つかもしれない
    • Googleが自分たちにだけ有用な機能を提供する反競争的なブラウザを作ったのは実に素晴らしい
      Google社員が、静かに流されそうな部分を自分で言ってくれてありがとう
    • 独占力の転移は平凡なことではなく、違法だ
  • 投稿タイトルを原文から変える過程で少し間違ったように思う。私の理解ではこうだ
    Chromeには、他のChrome拡張機能でも簡単に使える公開Chrome APIを使う組み込み拡張機能がある。問題は、この拡張機能がGoogle自身のドメインと通信するときにはその情報を共有するが、他のWebサイトはそうできないということだ。「特別な隠しAPI」はない

    • 「特別」というのは、他の拡張機能のようにユーザーがインストールしたものではなく、Chrome組み込みだという意味だ
      「隠されている」というのは、chrome://extensionsに行っても一覧に見えないという意味だ。そしてすでに述べたように、Chrome APIでもある
    • GoogleサイトのChrome DevToolsコンソールにこれを貼り付けてみると、特殊APIのように見える:
      chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
    • 「組み込み拡張機能」でも無効化できないなら、依然としてブラウザの一部だ
    • 無害で単純な説明も可能だ。ブラウザ機能の一部が、コンパイル/リンクされたC++ではなく、google.com署名のWebアプリとして実装されていると想像できる
      PWAとして実装されたブラウザコードがシステム情報にアクセスするために別途権限を要求しなければならないとしたら、おかしなことだろう。ブラウザ機能そのものの一部だからだ。昔から存在していた非公開APIのもう一つの用途は、Chrome Web Storeのように中核機能を提供するGoogle専用WebサイトとChromeブラウザを統合し、Webページから拡張機能のインストールと削除を許可することだ
    • 機能的には同じことだ
  • これは "system.cpu" 権限があればどの拡張機能でもアクセスできる chrome.system.cpu API を使っているように見える
    https://developer.chrome.com/docs/extensions/reference/api/s...
    この拡張機能が要求するすべての権限はここで確認できる:
    https://source.chromium.org/chromium/chromium/src/+/main:chr...

    • その通りで、まさにそこが問題。Google はブラウザ自体の動作とは関係ない拡張機能を Chrome にバンドルし、別製品である Hangouts に特権アクセスを与えている
      他のビデオ会議アプリには、ユーザーが別途拡張機能を手動でインストールするという大きな手順を踏まない限り、このようなアクセス権はない
  • あまり驚きはない。非常に Google らしい振る舞い。問題は、他の Chromium ブラウザにもこれがあるのかということ。Edge、Brave、Chromium、Ungoogled Chromium はどうなのか?

    • 他は分からないが、ungoogled chromium はこういうものを避けるために、コード内で "google" 文字列が出てくる箇所を意図的にすべてかき混ぜているので、おそらくないはず
    • Edge では有効になっている。Edge で Google Meet のトラブルシューティングを開くと、システム CPU を確認できる
      Firefox で試すと「CPU 使用率を見るには Google Chrome を使ってみてください」と表示される
  • Safari にも Apple 専用機能がある。たとえば Apple アカウントで別のウェブサイトにログインするとき、パスキーやパスワードの自動入力とは異なる挙動をする特殊なダイアログを表示できる
    他のブラウザではリダイレクトベースのフローを経由させる。これが JavaScript でどう実装されているのか、ずっと気になっていた。独自引数を入れた WebAuthn のようなものなのだろうか?

  • Google は以前にもこういうことをしたことがある。詳細はぼんやりしているが、Native Client がドメインレベルの許可リストで Hangouts だけで動作するようになっていた、あるいはそんな感じだったと思う