• Google Pixel：Google がつくった AI スマホ：リンク
• Vision AI：リンク
• Gemini：リンク
• Imagen 2：リンク

Cookie を盗む情報窃取マルウェアを使うサイバー犯罪者は、ユーザーの安全とセキュリティにリスクをもたらし続けています。この分野では、すでに多くの取り組みが実施されています。たとえば、セーフ ブラウジングによる Chrome のダウンロード保護、デバイス バウンド セッション認証情報、盗まれた Cookie が使われたことを検知する Google のアカウントベースの脅威検出などです。この度、新たな保護レイヤーについてお知らせします。これにより、この種のマルウェアから Windows ユーザーを保護する際の安全性が向上します。

Chrome は現在、秘密情報を保存する必要がある他のソフトウェアと同じように、OS が利用できる技術を使用して Cookie やパスワードといった機密データを保護しています。macOS ではキーチェーン サービスという技術を、Linux では kwallet や gnome-libsecret などのシステムが提供するウォレットを使っています。Windows の Chrome は、システムの他のユーザーやコールドブート攻撃から保存データを保護するために、データ保護 API（DPAPI）を使っています。しかし、悪意のあるアプリケーションがログイン中のユーザーとしてコードを実行できる場合、DPAPI では保護できません。

Chrome 127 で、DPAPI を改善する新しい保護機能を Windows に導入します。これは、アプリケーション バウンド（アプリバウンド）暗号化プリミティブを提供することによって実現します。Chrome は、ログイン中のユーザーとして実行されるアプリがこのデータにアクセスできるようにするのではなく、アプリの ID に紐付けてデータを暗号化できるようにします。これは、macOS のキーチェーンの動作と同様です。

今後、各種シークレットをこの新しいシステムに移行する予定ですが、Chrome 127 では、まず Cookie の移行を行います。今後のリリースでは、この保護をパスワードや支払いデータ、その他の永続的な認証トークンに拡大し、情報窃取マルウェアに対するユーザー保護をさらに強化する予定です。

動作の仕組み

アプリバウンド暗号化では、特権サービスを利用して要求元アプリケーションの身元を確認します。アプリバウンド暗号化サービスは、暗号化する際にアプリの ID をエンコードして暗号データに埋め込み、復号化が試行されたときにその有効性を確認します。システムに存在する別のアプリが同じデータを復号化しようとすると、失敗します。

アプリバウンド サービスはシステム権限で実行されます。そのため攻撃者には、単にユーザーを誘導して悪意のあるアプリを実行させる以上のことが必要になります。つまり、マルウェアはシステム権限を取得するか、Chrome にコードを挿入しなければならなくなります。これは、正規のソフトウェアが行うべきことではありません。そのため、動作の疑わしさが高まり、ウイルス対策ソフトウェアによって検出される可能性が高くなります。この保護とともに、Cookie 復号化のイベントログを提供するといった最近の取り組みも合わせて動作します。その目的は、ユーザーのデータを盗もうとする攻撃者のコストと検出リスクを高めることにあります。

企業での考慮事項

マルウェアは、昇格して実行することでこの保護をバイパスできます。そのため、エンタープライズ環境でダウンロードしたファイルを管理者として実行できないようにすることが特に効果的です。このような環境では、マルウェアが単純に昇格した権限を要求することはできなくなるので、インジェクションなどの技術を使わざるを得なくなります。このような操作は、エンドポイント エージェントでかなり容易に検出できます。

アプリバウンド暗号化では、暗号化鍵がマシンに強くバインドされるため、Chrome のプロファイルが複数のマシンをローミングする環境では正しく動作しません。ローミング プロファイルをサポートしたい企業には、現在のベスト プラクティスに従うことをお勧めします。必要な場合は、新しい ApplicationBoundEncryptionEnabled ポリシーを使ってアプリバウンド暗号化を構成できます。

互換性のない状況の検出に役立つように、Chrome は検証に失敗した際にイベントを発行します。イベントは、アプリケーション ログの「Chrome」ソースの ID 257 です。

まとめ

アプリバウンド暗号化により、攻撃者のデータ盗難コストは増加し、システムでの動作ははるかに目立ちやすくなります。また、システムの他のアプリに許容される動作について、防御側が明確な線引きを行うことができます。マルウェアの状況は継続的に進化します。それに合わせて、セキュリティ コミュニティの他のメンバーと協力しながら、検出の改善、強力なアプリ分離プリミティブといったオペレーティング システムの保護の強化など、バイパス対策の取り組みを続けていきたいと考えています。

今回の「速さと好奇心」の投稿では、Chrome がどのようにして Speedometer 3.0 の史上最高スコアをたたき出したのかについて紹介します。Speedometer 3.0 は、アップグレードされた新しいブラウザ ベンチマーク ツールで、ウェブ アプリケーションのパフォーマンス最適化に役立ちます。今すぐ Chrome をお試しください。 

先日公開された Speedometer 3.0 は、ブラウザのパフォーマンスを測定するためのベンチマークで、企業を超えた業界全体のコラボレーションとして、Google、Apple、Mozilla、Intel、Microsoft などが作成したものです。Chrome を最適化し、すべてのユーザーのブラウザ エクスペリエンスを高速化できる領域を特定する際に役立ったのが、このベンチマークでした。

この更新版のベンチマークが開発されている間に、最新の Chrome のパフォーマンス情報をじっくりと慎重に追跡し、さらに最適化を進めることで、Speedometer 3 の史上最高のスコアをたたき出すことができました。ここでは、その手法について詳しく説明します。2022 年 5 月に Speedometer 3 が構想されてから、Chrome の Speedometer スコアは 72% 増加しました。これは、ユーザーのパフォーマンスが向上したと言い換えることができます。

ワークロードを最適化する

Speedometer のワークロードと Chrome で特に時間がかかっている関数を調べることで、最適化の対象を絞りこむことができ、それによって、Chrome のスコアが向上しています。たとえば、SpaceSplitString は頻繁に使われる関数で、"class='foo bar' " のようなスペース区切り文字列をリスト表現に変換します。この関数で、いくつかの不要な境界チェックを削除しました。重複するスタイルシートが存在することがわかった場合は、重複を排除し、1 つのスタイルシート インスタンスを参照するようにしています。また、メモリ割り当てを調整することで、パスや円弧の描画コストを削減する最適化を行いました。フォーム エディタの作成時には、フォーム要素を作成する際に不要な処理があったことがわかりました。querySelector でよく使われるセレクタを検出し、そのためのホットパスを作成しました。

以前にお知らせしたように、解析に特化した高速パスを使って innerHTML を最適化しましたが、この実装は WebKit にも採用されました。Speedometer 3 のワークロードには DOMParser を使っているものもあるため、同じ最適化を拡張することで、さらに 1% 向上させることができました。

また、Harfbuzz のメンテナンス担当者と協力し、Apple の Mac OS システム フォントで使われているような AAT フォントのレンダリング方法を最適化しました。テキストは、処理済みの Unicode 文字のストリームとして始まり、グリフのストリームに変換されてから、AAT フォントで定義されたステートマシンで実行されます。この最適化により、グリフが実際にステートマシンのルールの一部であるかどうかを高速に判断できるようになり、AAT によるテキスト処理のスピードアップにつながります。

注目すべき適切なコードを選ぶ

高いパフォーマンスを実現するために重要な戦略は、コードのティアリングです。これは、エンジンでさらに最適化できるコードを適切に選択することを指します。Intel は、V8 にプロファイルによるティアリングを提供しました。これは、過去のティアリングの決定を記憶する機能で、ある関数が過去に確実にティアリングされていれば、将来の実行時に積極的にティアリングするようにします。

ガベージ コレクションを改善する

Speedometer 3 で約 3% の向上につながったもう 1 つの変更領域がありました。それは、ガベージ コレクションの改善です。V8 のガベージ コレクタは、かなり以前からレンダラのアイドル時間を利用しています。これは、実際のアプリケーション コードに干渉しないようにするためです。最近の変更も、この考え方に則っています。つまり、レンダラは通常、非常に活発に動作していますが、可能な限り、そのアイドル時間にガベージ コレクションを行うように、既存のメカニズムを拡張します。具体的には、オブジェクトの再利用時に実行される DOM のファイナライズのコードもアイドル時間で実行されるようになっています。これまでこのような操作は、CPU リソースをめぐって通常のアプリケーション コードと競合していました。さらに V8 は、DOM 要素をラップするオブジェクト、つまり JavaScript フレームワークに公開されるすべてのオブジェクトで、はるかにコンパクトなレイアウトをサポートするようになっています。このコンパクトなレイアウトのおかげで、メモリ負荷が軽減され、ガベージ コレクションにかかる時間が短くなっています。

今後、ChromeOS が Android スタックの大部分をベースとしたものになり、Google AI、イノベーション、機能をいち早くユーザーにお届けできるようになります。

私たちは、過去 13 年間にわたって ChromeOS を進化させ、安全かつ高速でさまざまな機能を持つ Chromebook エクスペリエンスを、世界中の何百万人もの生徒や教師、家族、ゲーマー、企業に提供してきました。最近では、Google AI と Gemini を使った新機能も発表され、Chromebook は日常のタスクを支援するツールを多くの人々に届けています。

今後も新しい Google AI 機能をたくさんのユーザーにすばやく展開できるように、ChromeOS の基盤の一部として、Android Linux カーネルや Android フレームワークなど、Android スタックの一部を採用いたします。この 2 つには、すでに充実したコラボレーションの歴史があります。すなわち、ChromeOS で Android アプリが利用できるようになっており、Bluetooth スタックの統合は ChromeOS 122 の時点で始まっています。

Android ベースの技術スタックを ChromeOS に導入することで、ChromeOS の中核である AI イノベーションのペースを上げ、エンジニアリング作業を簡略化し、スマートフォンやアクセサリなどのさまざまなデバイスと Chromebook との連携を強化できます。同時に、ChromeOS ユーザーや企業、学校に愛される比類のないセキュリティ、一貫したルック アンド フィール、幅広い管理機能を今後も提供し続けます。

このような技術スタックの改善は始まっていますが、一般消費者向けに準備が整うのは少し先になります。その際には、シームレスに更新版のエクスペリエンスに移行します。楽しみなことに、それまでの間も ChromeOS は進歩し続けます。定期的なソフトウェア アップデートや新しいイノベーションに変更はありません。

Chromebook は、世界中の何百万人ものお客様、ユーザー、デベロッパー、パートナーにすばらしい体験を提供し続けます。ChromeOS の未来をこれほど楽しみに思ったことはありません。