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

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

企業での考慮事項

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

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

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

まとめ

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


Posted by Eiji Kitamura - Developer Relations Team



ほとんどの場合に高速であるだけでは不十分で、いつでも高速でなければならないというのが Chrome チームの考えです。今回の「速さと好奇心」の投稿では、ウェブに関する主な指標を向上させ、最終的にウェブのパフォーマンスを改善できた方法について取り上げます。これは、あらゆるウェブサイトでのユーザー インタラクションへの応答を表す Chrome のフィールド データを調査することによって実現しました。

日々、何十億人もの人々がさまざまなことにウェブを活用しています。ブラウザは同時に多くのアプリをホストしなければならなくなり、リソースの競合が課題になっています。マルチプロセス ブラウザである Chrome では、複数のリソースが競合しています。CPU やメモリはもちろんのこと、内部サービス（この記事では、ネットワーク サービス）間の専用作業キューもあります。

このような理由のため、私たちは Chrome ユーザーのフィールド データから遅いインタラクションを特定し、修正することに重点を置いています。このフィールド データこそ、実際のユーザー エクスペリエンスを表す確かな情報源です。このデータは、Chrome Canary 版で匿名化した Perfetto トレースを記録し、プライバシー保護フィルタを使って報告することで収集しています。

遅いインタラクションのフィールド データに注目したとき、ある 1 つの原因が浮かび上がってきました。それは、ネットワーク サービスから現在のサイトの Cookie を取得するため、同期呼び出しを繰り返し行っていることです。

その経緯から振り返ることにしましょう。

進化するウェブにおける Cookie

Cookie は、その創生期のころからウェブ プラットフォームの一部であり続けています。通常は、次のようにして作成します。

    document.cookie = "user=Alice;color=blue"

すると、次のようにして取得できます。

    // Assuming a `getCookie` helper method:
    getCookie("user", document.cookie)

シングルプロセス ブラウザでは、この実装はシンプルで、Cookie の器はメモリに保持されていました。

しかし時間が経つと、ブラウザはマルチプロセスとなり、Cookie の器をホストするプロセスは、ますます多くのクエリに答えなければならなくなります。ただし、ウェブの仕様では、Cookie は Javascript から同期的に取得できなければなりません。そのため、document.cookie ã‚¯ã‚¨ãƒªã«å›žç­”する操作はブロック操作です。

この操作自体は非常に高速なので、通常、このアプローチは問題にはなりませんでした。しかし、高負荷シナリオでは、複数のウェブサイトがネットワーク サービスから Cookie（およびその他のリソース）をリクエストしており、リクエストのキューが滞る可能性があります。

遅いインタラクションのフィールド トレースから、一部のウェブサイトで、Cookie が連続して複数回フェッチされるという非効率的なシナリオが起きていることがわかりました。そこで追加の指標を作成し、すべてのナビゲーションでの冗長な GetCookieString() IPC（前回と同じ値が返されたもの）の頻度を測定しました。その結果、Cookie アクセスの 87% が冗長で、それが毎秒数百回発生している場合もあることがわかりました。これは驚愕の事実でした。

つまり、document.cookie ã®ã‚·ãƒ³ãƒ—ルなデザインが裏目に出たということです。ウェブの JavaScript では、これをローカル値のように扱っていましたが、実際にはリモート検索が行われていました。これは、古典的なコンピュータ サイエンスのキャッシュを行えばよいケースでしょうか？！早まってはいけません！

ウェブの仕様では、協調ドメインが相互に Cookie を変更し合えることになっています。したがって、レンダラ プロセスごとの単純なキャッシュでは、うまくいきません。そのようなサイト間で書き込みが伝播されないからです（古い Cookie が残り、e コマース アプリケーションでカートが同期されなくなるなどの現象が発生します）。

新たなパラダイム : 共有メモリのバージョニング

これを解決したのが、私たちが共有メモリのバージョニングと呼ぶ新たなパラダイムでした。すなわち、document.cookie ã®ãã‚Œãžã‚Œã®å€¤ã¨、単調に増加するバージョン番号を組み合わせるという考え方です。各レンダラは、最後に読み取った document.cookie ã‚’、バージョン番号とともにキャッシュします。ネットワーク サービスは、そのバージョンのそれぞれの document.cookie ã‚’共有メモリにホストします。このようにすると、レンダラはネットワーク サービスにプロセス間クエリを送信しなくても、最新バージョンを保持しているかどうかがわかります。



この結果、Cookie 関連のプロセス間メッセージが 80% 削減され、document.cookie ã¸ã®ã‚¢ã‚¯ã‚»ã‚¹ãŒ 60% 速くなりました 🥳。

仮説の検証

アルゴリズムを改善するのは良いことですが、私たちが最終的に重視しているのは、改善によって遅いユーザー インタラクションが速くなったかどうかです。つまり、遅い Cookie クエリが遅いインタラクションの主要な原因であるという仮説を検証する必要があります。

これを実現するため、Chrome の A/B テスト フレームワークを使って効果を調査しました。その結果、すべてのプラットフォームで、他の改善によるリソースの競合の減少と合わせて、最も遅いインタラクションを約 5% 改善できたことがわかりました。そして、ウェブに関する主な指標を満たすサイトがさらに増加しています 🥳。こうしたすべてのことにより、ユーザーがさらにシームレスだと感じられるウェブが実現します。



Chrome におけるウェブで最も遅いインタラクションの加重平均のタイムライン。本機能が 1%（11 月）のユーザー、50%（12 月）のユーザー、すべてのユーザー（2 月）にリリースされるにあたっての状況。

シームレスなウェブに向かいましょう！


Posted by Eiji Kitamura - Developer Relations Team


Chrome のアドレスバー（オムニボックスとも呼ばれます）は、毎日何十億回も使われているツールで、ウェブを簡単に検索できるようにしています。これを使うと、タブやブックマークをすばやく探すことも、以前にアクセスしたウェブページに戻ることも、情報を検索することもできます。

最新リリースの Chrome（M124）では、PC 版 Chrome のアドレスバーに機械学習モデルを組み込み、これまで以上に正確かつ適切にウェブページを提案できるようにしました。今後は、このモデルを使って、検索候補の関連性スコアの改善も行いたいと考えています。ここでは、今回の組み込みにつながったいくつかの重要な知見や、新しいモデルに期待されることについて、詳しくお伝えします。

これまでの経緯

アドレスバー担当チームのエンジニアリング リードである私にとって、すべてのリリースは特別なものですが、今回のリリースはとりわけ身近で大切なものです。初めて Chrome のアドレスバーに携わったとき、ユーザーに使いやすいと思ってもらうためのアイデアを周りに尋ねました。その 1 番の答えは、「スコアリング システムを改善する」でした。問題は、スコアが悪いことではありませんでした。実際、URL や検索語句を表示するアドレスバーの機能は、魔法のように感じられることがあります。問題は、それに æŸ”軟性がないことでした。 æ‰‹ä½œæ¥­ã§ä½œæˆã—て調整する方法はうまく機能しましたが、それを改善したり、新しいシナリオに適応させたりするのは困難でした。そのため、スコアリング システムは長い間ほとんど手つかずのままでした。

その大半の期間、明らかに向かうべき方向となっていたのが、ML でトレーニングしたスコアリング モデルでした。しかし、ここにたどり着くまでに、多くの失敗を重ねることになりました。これほど長い間、この課題を解決できなかったのは、文字通り毎日何十億回も使われている機能の中核となる仕組みを置き換えるのが難しかったためです。ソフトウェア エンジニアリング プロジェクトは、「飛行機を飛ばしながら作る」と表現されることがあります。このプロジェクトは、「世界中のすべての飛行機が飛んでいる間に、すべての座席を交換する」ようなものでした。規模が非常に大きく、変更はすべてのユーザーに直接影響します。

有能で献身的なこのようなチームの努力がなければ、この野心的な取り組みは不可能でした。途中でぶつかったり、壁を突破しなければならなかったり、予期せぬ問題が発生してペースが落ちることもありましたが、ユーザーのためにどうしても正しい形でこれを行いたいという誠実な気持ちに突き動かされてきました。

意外な知見

ML システムで作業する楽しみの 1 つは、個人やチームでは困難または不可能な規模で、 ã™ã¹ã¦ã® ãƒ‡ãƒ¼ã‚¿ã‚’考慮したトレーニングを行えることです。そして、それは意外な知見につながる可能性があります。

このプロジェクトで一番驚いたのは、特定のシグナル、すなわち前回のナビゲーションからの時間のスコアリング曲線を見たときでした。このシグナルで期待されるのは、小さいほど（特定の URL に移動したのが最近であるほど）、関連性スコアが高くなることでした。

そして実際に、モデルはそのように学習しました。しかし、詳しく見てみると、驚くべきことがわかりました。ナビゲーションからの時間が非常に短い場合（数時間、数日、数週間ではなく、数秒だった場合）、モデルが算出する関連性スコアは、 æ¸›å°‘ ã—ていたのです。トレーニング データを確認したところ、ユーザーが実際には望んでいない URL に移動し、すぐに Chrome のアドレスバーに戻って、もう一度試すパターンが記録されていることがわかりました。その場合、移動した URL は、ほぼ間違いなく、ユーザーが望んだものでは ã‚りません。そのため、2 回目の試行との関連性スコアは低くなるはずです。

よく考えてみれば、これは当然のことです。そして、ML でスコアリングを始めていなければ、このシナリオを反映させるために、古いシステムに新しいルールを追加していたはずです。しかし、トレーニング システムは、このパターンを見つけて学習してくれました。その前には、このようなことが起きているとは、誰も想像できませんでした。

今後について

この新しい ML モデルを使って、ユーザー エクスペリエンスを向上させる多くの新しい可能性を開くことができると考えています。たとえば、1 日の中の時間帯を区別して関連性を向上させるなど、新たなシグナルを組み込むことができます。モバイル、エンタープライズ、アカデミックといったユーザーごとに、あるいは言語や地域の違いなどに応じて、特定の環境向けの特別なバージョンのモデルをトレーニングすることも模索したいと考えています。

さらに、ユーザーが Chrome のアドレスバーを操作する方法は、時間の経過とともに変化することがわかっています。そのため、関連性スコアもそれに合わせて変化させる必要があると考えています。新しいスコアリング システムを使えば、これまで以上に新鮮なシグナルを収集し、時間の経過とともに新しいモデルを定期的に再トレーニング、評価、展開することができます。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

Chrome はすべてのプラットフォームで優れた機能を発揮するように設計されているので、自宅から PC でウェブをブラウジングするときも、外出先からスマートフォンでブラウジングするときも簡単に使えるようになっています。例えば、Chrome sync のようなツールによって、すべてのデバイスを切り替えてもブックマークやパスワードにアクセスできるようになりました。

今後数週間で iOS 版 Chrome に変更を加え、特に重要な情報をすぐ利用できるようにします。デバイスで Chrome 同期を設定する必要がなくなり、Chrome にログインするだけで、新しい情報を Google アカウントに保存したり、既存の情報にアクセスしたりできるようになります。iOS ですでに動作している Google アプリの数が多いため、これに慣れ親しんでいるように感じるかもしれません。Chrome にサインインすると、ブックマーク、リーディングリスト、パスワード、支払い情報、住所、設定など、重要な情報をアカウントに保存できます。また、タブと閲覧履歴を iOS の Chrome から Google アカウントに別々に同期させることもできます。これにより、別のデバイスで中断した閲覧を再開できます。




以上のアップデートは、データ管理にも役立つように設計されています。Chrome にログインすると、すでにデバイスに保存されている閲覧データは、デバイスのローカルデータとして別に保管されます。ローカルデータとアカウント データは、設定で簡単に区別できます。また、他のデバイスでローカルデータを利用できるようにしたい場合は、設定に移動してアカウントに保存することもできます。

iOS での Chrome へのログインは、今後とも完全に任意です。ログインしなくても、ブックマークやパスワードなどは保存できますが、保存したデバイスでのみ利用できます。また今後も、Chrome にログインしないまま、Gmail などの Google のウェブサービスにログインすることができます。

これらの変更により、求められるあらゆる柔軟性を提供するとともに、さらに簡単に Chrome を活用できるようになることを期待しています。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

最後になりますが、証明書の自動化に関連する課題や教訓、改善の機会を共有したい方は、chrome-root-program [アットマーク] google [ドット] com までお知らせください。

注: この投稿に記載したサービス プロバイダについては、すべてを網羅しているわけでも、いずれかを推奨しているわけでもありません。あくまでも情報提供のみを目的としたものです。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

私たちの最終的な目標は、すべてのユーザーが HTTPS ファースト モードを利用することです。これを実現するため、HTTPS ファースト モードの保護機能をいくつかの新しい領域に拡張します。

試してみる

HTTPS のアップグレードや安全でないダウンロードに対する警告がすべてのユーザーにロールアウトされる前に試してみたい方は、chrome://flags で [HTTPS Upgrades] フラグと [Insecure download warnings] フラグを有効にすると、すぐに試すことができます。さらに保護を強化したい場合は、Chrome のセキュリティ設定（chrome://settings/security）で [常に安全な接続を使用する] を有効にして、HTTPS ファースト モードをオンにすることもできます。

デベロッパーおよび企業向けの情報

デベロッパーの皆さんは、HTTPS を使い、HTTP でしかアクセスできないコンテンツをホストしないようにすることで、ユーザーに警告が表示されたり、サイトのアップグレードが失敗したりすることを回避できます。お勧めの方法は、完全に HTTPS を採用し、すべての HTTP URL を HTTPS にリダイレクトすることです。サイトに個人情報が含まれていないと考えていても、HTTP を使っていれば、ネットワーク攻撃者によってブラウザに悪意のあるコンテンツが挿入されるリスクが高まります。悪意のあるネットワーク攻撃者は、セキュリティで保護されていないサイトを足がかりとして、ユーザーを攻撃します。ユーザーが安全でないウェブサイトにアクセスすることでもたらされるリスクを軽減するため、その他の方法も模索しています。たとえば、HTTP でアクセスできる Cookie の有効期間の短縮などです。今のうちに HTTPS に切り替えておけば、今後の変更によってユーザーのエクスペリエンスに影響が及ぶことはなくなります。まだ HTTPS に対応できない場合は、サーバーがポート 443 のリクエストにまったく応答しないようにするか、HTTPS から HTTP にリダイレクトすると、確実にサイトにアクセスできるようになります。

企業や教育機関のネットワークに独自のニーズがあることは承知しています。HttpsOnlyMode、HttpsUpgradesEnabled、HttpAllowlist、InsecureContentAllowedForUrls の各ポリシーを使うと、以上の機能を早い段階でオンにしたり、カスタマイズしたり、完全にオフにしたりできます。

継続的な取り組みの一環

Chrome には、デフォルトで安全なウェブを目指して取り組んできた長い歴史があります。そして、私たちはここで立ち止まるわけではありません。ゴールは間近に迫っています。ウェブがデフォルトで HTTPS になるときを心待ちにしています。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

Google のチームは、ウェブを量子耐性暗号に移行する準備を整えることに注力しています。この大きな変革に対応するための戦略を継続しながら、技術標準を更新し、新しい量子耐性アルゴリズムをテストおよび展開しているほか、この取り組みを成功させるために幅広いエコシステムと連携しています。

この移行に向けた第一歩として、Chrome 116 から TLS での対称シークレットの確立に X25519Kyber768 がサポートされるようになり、Chrome 115 ではフラグを設定することで利用できるようになります。このハイブリッド メカニズムは、2 つの暗号アルゴリズムの出力を組み合わせて、TLS 接続の大部分を暗号化するために使用されるセッション鍵を生成します。

Google は、この変更に伴うエコシステムの非互換性を洗い出すために、このアルゴリズムを TCP と QUIC の両方で Chrome と Google サーバーに展開し、潜在的な互換性の問題をモニタリングしています。Cloudflare などのサードパーティ サーバー オペレーターがこのセッション鍵のサポートを追加した場合、Chrome は、当該サードパーティ サーバーに接続する際に、この更新された鍵合意を使用することもあります。この変更によって引き起こされたと思われる問題に遭遇したデベロッパーまたは管理者の方は、バグについてご報告ください。ここからは、この変更とその理由を理解するのに役立つ重要な背景情報について記載します。

ポスト量子暗号化へと向かう理由

TLS などの最新のネットワーク プロトコルは、情報の保護（機密性）やウェブサイトの ID 検証（認証）など、さまざまな目的で暗号を使用します。この暗号の強さは、攻撃者がこうした特性の 1 つ以上を侵害するのがどれほど難しいかという観点から評価されます。暗号化の分野では、攻撃はより強力になることはあっても弱くなることは決してない、とよく言われます。これは、攻撃が進化し、時間が経つほど手ごわくなるため、より強力なアルゴリズムへの移行が重要になることを強調しています。

そのような進化の一例として、既存のコンピューティング方式では不可能な特定の計算を効率的に実行できる量子コンピュータの開発が挙げられます。現在使用されている多くのタイプの非対称暗号化は、既存の技術を使用した攻撃に対して強いと考えられていますが、十分な能力の量子コンピュータを使用する攻撃者には対抗できません。

量子耐性のある暗号は、量子暗号解読技術と古典的暗号解読技術の両方に対しても安全でなければなりません。これは理論上の話ではありません。2022 年と 2023 年には、量子耐性暗号アルゴリズムの主要な候補のいくつかが、市販されている安価なハードウェア上で破られました。X25519Kyber768 などのハイブリッド メカニズムは、接続が既存の安全なアルゴリズムによって保護されることを保証しながら、新しい量子耐性アルゴリズムを展開およびテストする柔軟性を提供する必要があります。

こうした要求事項に加えて、このアルゴリズムは、市販のハードウェアでもパフォーマンスを発揮する必要があるため、問題がさらに複雑になります。


なぜ転送中のデータを保護することが、今重要なのか

現代の古典的な暗号を破ることができる量子コンピュータは、今から 5 å¹´、10 å¹´、おそらく 50 年後にも登場しないと考えられています。それでは、なぜ今、トラフィックの保護を始めることが重要なのでしょうか？その答えは、特定の用途の暗号は、今収集して後で解読（Harvest Now, Decrypt Later）と呼ばれる攻撃に対して脆弱だからです。この攻撃では、データは即座に収集されて保存されますが、解読は、暗号解読技術が改良された後で行われます。

TLS では、転送中のデータを保護する対称暗号化アルゴリズムは量子暗号解読に対して安全であると考えられていますが、対称鍵の生成方法はそうではありません。つまり、Chrome では、量子耐性のあるセッション鍵を使用するために TLS を更新するのが早ければ早いほど、将来の量子暗号解読からユーザー ネットワーク トラフィックをより早く保護することができます。

展開に関する考慮事項

X25519Kyber768 を使用すると、Kyber によりカプセル化された鍵素材が追加されるため、TLS ClientHello メッセージに 1 キロバイト以上の追加データが生じます。Google が以前行った、CECPQ 2 を用いた実験では、TLS 実装の大部分がこのサイズの増加に対応できることが実証されましたが、一部の特定のケースでは、メッセージ サイズに対する不適切なハードコード制限のために TLS ミドルボックスで動作不良が起きました。

これらの新しいアルゴリズムが展開される際に、ネットワーク アプライアンスの非互換性に対処しなければならない企業を支援するために、Chrome の管理者は Chrome 116 から利用可能な PostQuantumKeyAgreementEnabled エンタープライズ ポリシーを使用して、X25519Kyber768 を無効にすることができます。このポリシーは一時的な措置としてのみ提供されます。管理者は、影響を受けるプロダクトのベンダーと協力して、非互換性を引き起こすバグをできるだけ早く修正するよう強くお勧めします。

最終的なデプロイのための考慮事項として、X25519Kyber768 と Kyber の仕様はどちらもドラフト段階のものであり、最終的な決定の前に変更される可能性があり、Chrome の実装も変更される可能性があることに注意してください。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

ブログ投稿のメインイメージ。アドレスバーの右側にある Chrome の新しいダウンロード エクスペリエンスを紹介しています。


デスクトップ版 Chrome の最新リリースで、Chrome のダウンロード エクスペリエンスを刷新し、最近のダウンロードに対する操作をさらに簡単に行えるようにしました。Chrome シニア プロダクト マネージャーの Jasika Bawa から、今回の刷新の舞台裏について詳しい話を聞いてみましょう。

Chrome のダウンロードを刷新するという判断をしたのはなぜですか？

ダウンロードは日々のウェブ ブラウジングに欠かせない操作です。猫をテーマにした完璧な背景をパソコン用に入手することから、納税申告書のコピーを保存することまで、その用途はさまざまです。私たちは、Chrome の以前のダウンロード エクスペリエンスについてのフィードバックを長年にわたって受け取ってきました。中核的なダウンロード操作のサポートや潜在的に有害なファイルに対する組み込みの保護など、優れた機能がたくさんあることはわかっていますが、問題点もありました。たとえば、次のようなことです。

  • 画面下部の貴重なピクセルを占有するため、ウェブ コンテンツ領域が狭くなり、画面の幅によって一度に表示できるファイルの数が制限されていた
  • 自動で消えることがなく、固定のオーバーフロー メニューで提供されていたアクションは、一時停止や再開、フォルダを開くなどだけだった
  • モダンでインタラクティブなものでなく、他のブラウザの UI やブラウザのエコシステム全体の外観との整合性がなくなっていた

こういったすべての点について考えれば、ダウンロード エクスペリエンスをさらに直感的なものにするために、Chrome を改善する余地があったのは明らかでした。

今回の刷新によって提供すべきものは何ですか？

画面下部にあった以前のダウンロード エクスペリエンスに代わり、Chrome のアドレスバーの右側に新しいダウンロード トレイが表示されます。ダウンロードが進行中の場合、アニメーションするリングから一目で進行状況を確認できます。ファイルのダウンロードが終わると、トレイが開き、自動的に非表示になります。そのため、すばやく簡単にアクセスできるだけでなく、閲覧が中断することもありません。

Chrome ブラウザの GIF イメージ。カーソルが、ウェブファイルの「保存」オプションをクリックしています。ダウンロードが進行中であることを示すアイコンがあり、その周りに進行状況を表すリングが表示されます。ファイルのダウンロードが終わると、ダウンロード トレイが自動的に開きます。


ダウンロード トレイでは、過去 24 時間のすべてのダウンロードのリストを確認できます。このトレイは、ダウンロードを始めたブラウザ ウィンドウだけでなく、すべてのウィンドウから確認できます。トレイにはインライン オプションも用意されており、ダウンロードしたフォルダを開く、ダウンロードをキャンセルする、なんらかの理由で失敗したダウンロードを再試行する、ダウンロードの一時停止や再開を行うといった操作が可能です。


Chrome ブラウザの GIF イメージ。カーソルが、Chrome アドレスバーの右側にあるダウンロード トレイを開いています。ダウンロード トレイには、進行中のファイルのダウンロードが表示されています。ダウンロードを一時停止するインライン オプションも提供されています。カーソルが一時停止ボタンをクリックすると、ボタンが再生ボタンに変わります。カーソルが再生ボタンをクリックすると、ダウンロードが再開されます。


新しいダウンロード エクスペリエンスは、オンラインで人々の安全を保つことにどう貢献しますか？

私たちがいつも重視しているのは、ファイルをダウンロードする際の安全性です。マルウェアやウィルスの可能性がある場合、Chrome は今後も明確な警告を表示し続け、デバイスやアカウントを守ります。実際に、Chrome の新しいダウンロード エクスペリエンスでは、スペースが広くなり、UI も柔軟になっているので、悪意のある可能性のあるファイルからユーザーを保護するために提供できる情報が増え、高度なディープ スキャン オプションも実現できるようになっています。これは、以前にはできなかったことです。詳しくは、近日公開予定の Google セキュリティ ブログをご覧ください。

ダウンロードの警告だけではありません。ダウンロード トレイは、Chrome のアドレスバーの横の決まった位置に表示されるので、信頼できるブラウザの UI とウェブ コンテンツを明確に分離するうえで役立ちます。これは、今回の刷新でどうしても実現したかった点でした。


ダウンロード トレイを拡大した Chrome ブラウザのイメージ アセット。危険なファイルのダウンロードがブロックされたことを示す通知が表示されています。


新しいダウンロード エクスペリエンスに簡単に移行できるようにする方法として、どのようなことを考えましたか？

重要なことは、Chrome の新しいダウンロード エクスペリエンスで、以前の機能をすべて利用できるようにすることでした。 たとえば、今後も新しいダウンロード トレイから、ダウンロードしたファイルを別のフォルダやプログラム、ウェブサイトにドラッグしたり、「常に開く」などのアクションを行ったりできます。ダウンロードのさらに詳しい表示も、引き続き可能になっています。ダウンロード トレイの [ すべてのダウンロードを表示 ] オプションを選択するか、Chrome のその他メニューから [ ダウンロード ] をクリックするか、Chrome のアドレスバーに chrome://downloads と入力します。

また、初期の試験運用でのフィードバックを真摯に受け止め、ダウンロード トレイを開く頻度を調整するなどの変更を加えています。Chrome の設定から、自動でトレイを開かないようにすることもできます。


Chrome ブラウザの [ダウンロード] 設定メニューのイメージ。ダウンロードが完了したときに、ダウンロードの表示を無効にするオプションを選択できます。



デベロッパーの対応が必要になることはありますか？

デベロッパーの皆さんにぜひお願いしたいのは、ユーザーのダウンロード操作をサポートするためにガイドやビジュアルを作成している場合、それを更新することです。まずは、Google Chrome ヘルプセンターのトピック、ファイルをダウンロードするを参照することを検討できるでしょう。

拡張機能デベロッパーの皆さんは、chrome.downloads 拡張機能 API の変更に注意してください。拡張機能の更新が必要になるかもしれません。具体的には、setShelfEnabled が setUiOptions に置き換えられ、新しいダウンロード エクスペリエンスの表示、非表示を切り替えられるようになっています。

公開されたばかりの新機能ですが、ぜひ使ってみてください！今後のリリースでは、ウェブからファイルをダウンロードする際の安全性を保ちながら、Chrome の生産性を維持できるように、引き続きこの機能を強化していきます。
Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

編集者のメモ: 業界の調査（Chrome などの）と HTTPS の普及を鑑み、Chrome のアドレスバーの鍵アイコンを新しい「調整」アイコンに置き換える予定です。これには、デフォルトで安全な状態であるべきという点を強調する、そしてサイトの設定にアクセスしやすくするという 2 つの狙いがあります。長年にわたるこの取り組みについて、以下をお読みください。

HTTPS でサイトが読み込まれるとブラウザに鍵アイコンが表示されるのは、1990 年代の Netscape の初期バージョンから続いている伝統です。Chrome はこの 10 年間にわたって、HTTPS の採用を増やし、ウェブをデフォルトで安全な場所にするための大規模な取り組みに参加してきました。2013 年時点では、Alexa のトップ 100 万サイトのうち、HTTPS をサポートしていたのはわずか 14% でした。しかし、現在は HTTPS が標準となっており、Windows 版 Chrome で読み込まれているページの 95% 以上が HTTPS を使った安全なチャネルを経由しています。これはエコシステムにとってうれしいニュースであるとともに、ブラウザでセキュリティ保護を知らせる方法を再評価する機会でもあります。中でも特に重要なのが、鍵アイコンです。

鍵アイコンは、ネットワーク接続がブラウザとサイトの間の安全なチャネルであり、サードパーティがネットワーク接続を改ざんしたり盗聴したりできないことを示すためのものです。しかしこれは、HTTPS が一般的ではなかった時代の名残でもあります。もともと HTTPS はかなり珍しいものだったことから、ある時点で Internet Explorer は、接続が HTTPS によって保護されていることを通知するアラートをポップアップ表示するようになりました。これは、ザ・シンプソンズの「万事問題なし」アラームを連想させます。HTTPS が珍しかった時代、鍵アイコンには HTTPS によって追加の保護が提供されていることをアピールするという役割がありました。しかし今は、すでに状況が変わっています。HTTPS は例外ではなく標準となり、Chrome もしかるべく進化してきました。

たとえば、鍵アイコンはウェブサイトの信頼性を表すものではありません。調査の結果、多くのユーザーが鍵アイコンを誤解していることがわかったため、2016 年にこのアイコンのデザインを変更しました。しかし、努力を尽くしたにもかかわらず、2021年の調査では、鍵アイコンの意味を正確に理解していたのは調査対象者の 11% だけでした。この誤解は無害なものではありません。ほぼすべてのフィッシングサイトでは HTTPS を使用しているため、鍵アイコンも表示されています。この誤解は広く浸透しているため、FBI を含む多くの組織が、鍵アイコンはウェブサイトの安全性を示すものではないというガイドを明確に打ち出しています。

調査で Chrome の UI を表示すると、ユーザーは南京錠を見て架空の e コマースサイトの信頼性を評価していました。実験の参加者にサイト コントロールを表示し、この状況で役立つと思われる情報を示すように求めました。これは、そのときのクリック パターンをヒートマップにしてオーバーレイ表示したものです。
現在の鍵アイコンは、Chrome のサイト コントロールの便利な入口になっています。2021 年には、Chrome の鍵アイコンの代わりに、セキュリティを連想させないサイト コントロールの入口を表示する実験についてお知らせしました。HTTP が安全でないことを示す表示は、URL バーに残しました。すると、ユーザーがサイト コントロールを開く回数が増え、大幅に UI を変更したときに起こりがちな戸惑いも見られませんでした。


現在の鍵アイコンからアクセスできるサイト コントロール。

他の団体も含めた調査結果と、HTTPS への移行が普及していることを踏まえて、Chrome の鍵アイコンを調整アイコンのようなものに置き換える予定です。次のような調整アイコンを考えています。
  • 「信頼できる」ことを連想させない
  • クリックできることが明らかである
  • 一般的な設定などのコントロールを連想させる
鍵アイコンを、コントロールや設定を示すときに一般的に使われる調整アイコンのようなものに置き換える予定です。

鍵アイコンをニュートラルなインジケーターに置き換えることで、鍵アイコンがページの信頼性を表す

という誤解を防ぐとともに、Chrome がデフォルトで安全な状態であることをアピールします。また、鍵アイコンをクリックすると重要な情報やコントロールが表示されることを理解していなかったユーザーが多いことも、調査で明らかになりました。この新しいアイコンは、鍵アイコンにつきまとう誤解を防ぎつつ、権限管理やセキュリティの詳細情報に簡単にアクセスできる場所となるはずです。

新しいアイコンは、PC プラットフォーム向けの一般的なデザイン更新の一環として、2023 å¹´ 9 月上旬に公開される Chrome 117 でリリースされる予定です。接続が安全でないことを示す警告は、今後も表示されます。Chrome Canary の chrome://flags#chrome-refresh-2023 で [Chrome Refresh 2023] を有効にすると、新しい調整アイコンが表示されるようになります。ただし、これはまだ進行中や開発中の状態であり、最終版ではないことに注意してください。



同じページ コントロール、新しいアイコン。鍵アイコンは詳細な接続セキュリティ情報の入口として残りますが、トップレベルのアクセス ポイントは新しくなります。


Android の鍵アイコンも、PC 版のさまざまな変更のタイミングに合わせて変更します。iOS の鍵アイコンはタップできないため、完全に削除します。平文 HTTP が安全でないことを示す表示は、すべてのプラットフォームで今後も残ります。

HTTPS が標準になるに伴い、Chrome と幅広いセキュリティ コミュニティの両方では、鍵アイコンを置き換えることが長年の目標でした。年を追って HTTPS の採用が大きく拡大したことで、ようやくこの手順を安全に実施できるようになったことをうれしく思っています。私たちはこれからも、デフォルトで安全なウェブの実現に向けて進んでいきます。


Posted by Eiji Kitamura - Developer Relations Team

Share on Twitter Share on Facebook

Share on Twitter Share on Facebook



Chrome は誕生当初より、効率よく動作するように設計されています。効率がよいとは、単にページをできる限り高速に読み込むことだけでなく、できる限り少ないリソースを使うことを指します。今回の速さと好奇心の投稿では、Mac のバッテリー駆動時間をできる限り延ばすために行った Chrome の改善に注目します。この改善により、ブラウズや動画の視聴をこれまで以上に長く楽しめるようになっています。 


Chrome の最新リリースでは、内部的にたくさんの最適化をし、MacBook の 1 度の充電でできることを増やしています。私たちのテストによれば、MacBook Pro（13 インチ、M2、2022）で 17 時間のブラウズまたは 18 時間の YouTube 視聴が可能です。Chrome の省エネモードをオンにすると、バッテリーでブラウズできる時間がさらに 30 分延びます（1）。私たちは、最新のハードウェアを使っている方だけでなく、すべてのユーザーのことを深く考えています。そのため、古いモデルでもパフォーマンスが向上します。 


以下では、行った変更のいくつかについて詳しく説明します。
 
iframe の微調整

iframe には数秒しか存在しないものが多いことがわかりました。そこで、最近作成された iframe について、ガベージ コレクションとメモリ圧縮ヒューリスティックスを微調整しました。その結果、短期的なメモリ使用量を抑えることができ、消費電力が減少しました（長期的なメモリ使用量には影響しません）。



タイマーの調整 

Javascript のタイマーは、ウェブの黎明期に導入されたものです。その後、ウェブ デベロッパーは、さらに効率的で同じ結果（またはそれよりも優れた結果）を実現できる API を利用できるようになっています。それでも、Javascript のタイマーはウェブページの電力消費の大部分を占めています。そこで、Chrome でのタイマーの呼び出し方法を調整し、CPU の復帰回数を少なくしました。


同様に、必要なくなってキャンセルできるようになった内部タイマーを特定することで、タイマーが CPU を復帰させる回数を減らしました。 


データ構造の効率化

同じキーで頻繁にアクセスされるデータ構造があることがわかったため、そのアクセス パターンを最適化しました。



不要な再描画の回避

ボットを使って実際のサイトを開き、ドキュメント オブジェクト モデル（DOM）の変化パターンのうち、画面上のピクセルに影響しないものを特定しました。こういったパターンを早い段階で検出し、不要なスタイル、レイアウト、描画、ラスタライズ、GPU の操作を省略するように Chrome を変更しました。Chrome UI の変化についても同じ最適化を行っています。

私たちの作業に終わりはありません。2023 年以降は、オープンソース ベンチマーク スイートによって、幅広い開発コミュニティの力を借りて Chrome の電力消費を改善できるようになります。

___
1 2023 å¹´ 2 月に MacBook Pro（13 インチ、M2、2022、8 GB の RAM を搭載し MacOS Ventura 13.2.1 を実行）と Chrome 110.0.5481.100 を使ってテストを実施し、Google の オープンソース ベンチマーク スイートで測定したもの。



Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook