Google Chrome、`*.google.com` からのみアクセス可能なAPIを提供
(twitter.com/lcasdev)- 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 と同様の動作を示す
- Microsoft Edge でもこの機能は
競争と規制上の論点
- ブラウザが特定の自社ドメインに対してのみシステム情報を提供すると、他のWebサービスは同じ水準の診断機能を実装しにくくなる
- Zoom は Google Meet のような CPU デバッグ機能を提供されない事例として挙げられており、これはブラウザベンダーによる 自社サービス優遇 の問題につながる可能性がある
- DMAの観点では、ゲートキーパーが機能へのアクセスを平等に提供すべきかどうかが中心的な論点として残っている
1件のコメント
Hacker News の意見
hangout_services という名前を見ると、Google Hangouts の開発を楽にするために作られた古い技術的負債的なハックのように見える
Hangouts チームにテレメトリデータを直接流す用途だったのだろう。Hangouts はブラウザ上でビデオ通話を実現した最初のアプリで、これが後に WebRTC になった。このモジュールは、アプリが本来は見られない CPU/GPU/RAM 使用量やハードウェア情報を公開する。Google はこの Twitter スレッドを見て、単に削除するのではないか。Hangouts はすでに終了した製品だし、サーバー側コードがまだ使っているとしても、今では WebRTC の利用範囲がずっと広いので、Chrome チームが複数サイトの方式でパフォーマンスを直接監視しているはず
非標準ではあるが、ネイティブアプリならこういうことは十分やりそうだ
この部分について少し説明できるかもしれない。ちなみに元 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 監視サポートである可能性が高そうに見える。間違っているかもしれない
Chrome では Meet が使っている CPU なのかシステム全体なのかは分からないが、CPU 使用率を見ることができ、どちらにせよ通常の API で可能なことではなさそうだ。バックグラウンドで
yesをいくつか動かして確認したところ、確実にシステム全体だった。付け加えると、名前の混同はいつも起きるが、GVC は本当に明確で良い名前だ任意の *.google.com ページで直接試せる:
chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });API は *.google.com で実行されるコンテンツにだけ公開されているようだが、それでも「Google が自社サイトを訪れたすべての Chrome インスタンスを照会できる」とほぼ同じだ。Google サービスを使わなくても、Chrome はデフォルトで新しいタブページのコンテンツを Google から取得するので、実質ほぼ100%に近い。悪意をもって使われているとは思わないが、Google がこの方法で問題を診断でき、同じ領域の競合他社にはできないなら、やはり問題だ。Zoom にはこういう API はないのでは?
社内ビデオ会議プラットフォームの内部アプライアンスで CPU 使用率を観察するために、一般ユーザー向けの Google Chrome にこのバンドルプラグインを入れた、ということなのか?
今ごろ何十人ものプロダクトマネージャーが、自分の製品の技術リードに「まあ、とりあえず聞いてくれ…」と近づいていそうだ
この機能は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で丁寧に依頼すれば、開発者たちは既定ドメインの追加を少なくとも検討はしてくれそうだ
ある市場、つまりブラウザでの独占を利用して、別の市場であるビデオ会議で優位を得るものなので、独占禁止法違反かもしれない
ブラウザの間ではかなり標準的なやり方だ。リスクは、ブラウザがソフトウェア更新をダウンロードするドメインを誰かが偽装する場合と同程度であるべきで、本当に嫌なら設定でオフにできる
[0] https://news.ycombinator.com/item?id=40631439
参考までに、Googleで働いているが、ChromeやこのAPIの担当ではない
説明はかなり平凡だと思う。たとえばGoogle Meetを開き、空の会議、つまり「インスタント会議」を開始してから「…」メニューで「トラブルシューティングとヘルプ」を押すと、CPU使用率を含む複数の統計グラフが出る。Meet通話中にマシンに負荷がかかると、タブを閉じるよう親切に提案してくれることもあるようだ。かなり便利なので、ときどき確認している。考え直してみると、タブを閉じろという提案が実際にあるかは確かではなく、実際に使ったことがあるのは統計画面だけだ
Meetのユーザーは会議がなぜうまくいかないのか案内されるが、Zoom、Teams、Slackが同じことをできないなら、Meetのユーザー体験が良くならざるを得ない。他のすべての会議サービスがデスクトップアプリを積極的に使わせようとするのも不思議ではない。Google Meetのデスクトップアプリは、要するにChromeなのだ
もしかすると、Meetはブラウザでうまく動き、Zoomはそうではないため、特に会議参加者が多いときに、Zoomユーザーが適切な性能を求めるならネイティブアプリを使うことになる理由の一つかもしれない
Google社員が、静かに流されそうな部分を自分で言ってくれてありがとう
投稿タイトルを原文から変える過程で少し間違ったように思う。私の理解ではこうだ
Chromeには、他のChrome拡張機能でも簡単に使える公開Chrome APIを使う組み込み拡張機能がある。問題は、この拡張機能がGoogle自身のドメインと通信するときにはその情報を共有するが、他のWebサイトはそうできないということだ。「特別な隠しAPI」はない
「隠されている」というのは、chrome://extensionsに行っても一覧に見えないという意味だ。そしてすでに述べたように、Chrome APIでもある
chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );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 らしい振る舞い。問題は、他の Chromium ブラウザにもこれがあるのかということ。Edge、Brave、Chromium、Ungoogled Chromium はどうなのか?
"google"文字列が出てくる箇所を意図的にすべてかき混ぜているので、おそらくないはずFirefox で試すと「CPU 使用率を見るには Google Chrome を使ってみてください」と表示される
Safari にも Apple 専用機能がある。たとえば Apple アカウントで別のウェブサイトにログインするとき、パスキーやパスワードの自動入力とは異なる挙動をする特殊なダイアログを表示できる
他のブラウザではリダイレクトベースのフローを経由させる。これが JavaScript でどう実装されているのか、ずっと気になっていた。独自引数を入れた WebAuthn のようなものなのだろうか?
Google は以前にもこういうことをしたことがある。詳細はぼんやりしているが、Native Client がドメインレベルの許可リストで Hangouts だけで動作するようになっていた、あるいはそんな感じだったと思う