Chrome Beta to experiment with a more powerful New Tab page, web highlights and search changes

Google is launching a new version of its Chrome Beta browser today that’s introducing some fairly notable changes to its user interface and design. The browser will introduce an updated New Tab page, which will now include cards directing you back to past web search activities, instead of only a list of shortcuts to favorite […]

Chrome 93: マルチスクリーン ウィンドウの配置、URL ハンドラとしての PWA など

この記事は Chromium Blog の記事 “Chrome 93: Multi-Screen Window Placement, PWAs as URL Handlers, and More” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Android WebView、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 7 月 29 日の時点で Chrome 93 はベータ版です。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

Cross-Origin-Embedder-Policy: credentialless

credentialless キーワードを使って、Cookie やクライアント証明書などの認証情報を省略したクロスオリジン no-CORS リクエストが可能になりました。COEP: require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。現在は COEP: require-corp が存在し、クロスオリジン分離の有効化に利用されています。これは確実に機能しますが、すべてのサブリソースで明示的にオプトインしなければならないので、大規模な導入は難しいことがわかっています。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、一般的なソーシャル メディア、フォーラムなど）では、依存関係の問題が発生します。

マルチスクリーン ウィンドウの配置

Multi-Screen Window Placement API を使えば、マシンに接続された任意のディスプレイへのウィンドウの配置、その配置の保存、任意のディスプレイでのウィンドウの全画面表示が可能です。プレゼンテーション アプリでこの API を使うと、ある画面にスライドを、別の画面に発表者用のノートを表示できます。アートや音楽の制作アプリでは、2 つ目の画面にパレットを配置できます。また、レストランなら、座席側にタッチスクリーン メニューを、従業員側に別のウィンドウを表示できます。この API は、最初のオリジン トライアルでのデベロッパーからのフィードバックに基づいて形状や人間工学が改善され、2 回目のオリジン トライアルに入ります。

インストールされたデスクトップ版ウェブアプリ向けのウィンドウ コントロール オーバーレイ

ウィンドウ コントロール オーバーレイは、ウィンドウ全体を覆うようにアプリのクライアント領域を拡張します。この領域には、タイトルバー、ウィンドウのコントロール ボタン（閉じる、最大化/復元、最小化）も含まれます。ウェブアプリのデベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされたデスクトップ版ウェブアプリを OS のアプリのように見せることができます。詳しくは、PWA のタイトルバーのウィンドウ コントロール オーバーレイをカスタマイズするをご覧ください。

URL ハンドラとしての PWA

URL ハンドラとしての PWA を使うと、music.example.com のようなアプリが、自分自身を https://music.example.com、https://*.music.example.com、https://🎵.example.com といったパターンに一致する URL のハンドラとして登録できます。これにより、インスタント メッセンジャー アプリケーションやメール クライアントなどの PWA の外部からのリンクが、ブラウザのタブではなく、インストールした PWA で開くようになります。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

ウェブバンドルによるサブリソースの読み込み

ウェブバンドルは、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです。この機能は、以前のリソース バンドルへのアプローチが抱えていた問題に対処します。

一部の JavaScript バンドラの出力は、HTTP キャッシュをうまく扱うことができず、設定が難しくなる場合もあります。バンドルされた JavaScript でも、すべてのバイトがダウンロードされるまで実行を待つ必要があります。複数のサブリソースを読み込む場合、ストリーミングと並列化を使用するのが理想ですが、これは 1 つの JavaScript ファイルでは実現できません。JavaScript モジュールでは、決定的実行の関係で、リソースツリー全体がダウンロードされるのを待ってから実行する必要があります。

WebXR Plane Detection API

WebXR アプリケーションで、ユーザーの環境に存在する平面のデータを取得できるようになります。これにより、拡張現実アプリケーションでさらに臨場感の高い体験を実現できます。この機能がない場合、デベロッパーは getUserMedia()（navigator と MediaDevices で利用可能）のデータに対して独自のコンピュータ ビジョン アルゴリズムを実行してユーザーの環境に存在する平面を検知するしかありませんでした。そのため、このようなソリューションでは、ネイティブの拡張現実機能に匹敵する質や精度を実現したり、ワールド スケールをサポートしたりすることはできませんでした。

今回のリリースに追加されたその他の機能

AbortSignal.abort() 静的メソッド

静的メソッドである AbortSignal.abort() は、すでに中止された AbortSignal オブジェクトを新しく作成します。これは Promise.reject() と同じような考え方で、デベロッパーの人間工学を改善します。

ウェブ デベロッパーは、中止された AbortSignal オブジェクトをさまざまな目的に役立てることができます。これを使って、作業をしないように JavaScript API に指示します。現在、すでに中止された AbortSignal オブジェクトを作るには、複数行のコードが必要です。AbortSignal.abort() を使うと、次の 1 行で作成できます。

return AbortSignal.abort();

CSS Flexbox: alignment キーワードが start、end、self-start、self-end、left、right をサポート

flexbox と flex 項目が位置ベースの alignment キーワードに従うようになります。これまでの flexbox は、center、flex-start、flex-end のみに従っていました。追加された alignment キーワード（start、end、self-start、self-end、left、right）を使うと、flex 項目の位置をさまざまな書き込みモードや flex フローに簡単に合わせることができます。

これらの追加キーワードがない場合、書き込みモード、テキストの方向、flex の逆方向プロパティ（flex-direction: row-reverse、flex-direction:column-reverse、align-content: wrap-reverse）を変えるたびに、キーワードの値を変更する必要があります。今回実装されたキーワードを使うと、alignment を一度設定するだけで済みます。

Error.cause プロパティ

Error() コンストラクタが cause という新しいオプション プロパティをサポートし、これはプロパティとしてエラーに割り当てられます。これにより、エラーを条件でラップするという不必要で複雑な作業をすることなく、エラーをチェーンさせることができます。

meta name=theme-color が media HTML 属性を反映

meta[name="theme-color"] で meta 要素の “media” 属性が反映されます。これにより、ウェブ デベロッパーがメディア クエリに基づいてサイトのテーマカラーを調整できるようになります（ダークモードとライトモードなど）。最初に一致したものが選択されます。

HTMLMediaElement.controlsList の noplaybackrate

HTMLMediaElement.controlsList プロパティが noplaybackrate をサポートします。これにより、ブラウザが公開する再生速度のコントロールをウェブサイトで有効化または無効化できるようになります。ブラウザ ベンダーが再生速度のコントロールをメディア コントロールに追加したことで、デベロッパーはこの新しいコントロールの表示を制御する方法が得られます。新しいプロパティは、HTMLMediaElement.controlsList のサンプルの noplaybackrate で試すことができます。

Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダー

CSS ユーザー プリファレンス メディア機能の prefers-color-scheme は、ページで提供する必要がある CSS の量とページ読み込み時のユーザー エクスペリエンスに大きな影響を与える可能性があります。新しい Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダーを使うと、サイトのリクエスト時にオプションでユーザー プリファレンスを取得できるので、サーバーは適切な CSS をインラインで提供できます。そのため、一瞬だけ適切でないカラーテーマが表示されることを回避できます。

User-Agent Client-Hint API のアップデート

このバージョンの Chrome には、User-Agent Client-Hint API に 4 つの新機能と変更点が追加されています。

  • Sec-CH-UA-Bitness: ユーザー エージェントが動作するプラットフォーム アーキテクチャのビットネスに関する情報をサーバーに提供するためのリクエスト ヘッダーです。ビットネスとは、特定のシステムが評価できる基本値を構成するビットの数を表します。
  • Sec-CH-UA-Platform を低エントロピー ヒントに変更 : Sec-CH-UA-Platform は、ユーザー エージェントが動作するプラットフォームに関する情報をサーバーに提供するためのリクエスト ヘッダーです。
  • 低エントロピー ヒントを UADataValues.getHighEntropyValues() に追加 : ヒントが高エントロピーから低エントロピーに移動した場合、それに依存するコードの将来性が保証されます。
  • NavigatorUAData.toJSON() メソッドの改善 : このメソッドが便利なデータを返すようになります。

低エントロピー ヒントとは、あまり多くの情報を公開しないヒントや、他の方法で簡単に検出できるため現実的に隠蔽するのは難しい情報を提供するヒントです。Client-Hint においては、関連するオリジンがリクエストしたかどうかにかかわらず、また関連するフレームがファースト パーティかサード パーティかにかかわらず、すべてのリクエストで利用できるヒントを指します。

WebOTP API: クロスデバイスのサポート

デスクトップ向け Chrome と Android Chrome の両方が同じ Google アカウントにログインしている場合、PC でも WebOTP API がサポートされます。WebOPT API は、プログラムによってオリジン宛ての特定の形式の SMS メッセージからワンタイム コードを読み取る機能を提供するため、ログイン時のユーザーの手間を減らすことができます。これまで、この機能は SMS がサポートされるモバイル デバイスのみで利用できました。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.3 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Object.hasOwn

新しい Boolean 型のプロパティである Object.hasOwn は、使いやすい静的メソッド バージョンの Object.prototype.hasOwnProperty を提供します。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

ポート 989 と 990 のブロック

ポート 989 と 990 による HTTP、HTTPS、FTP サーバーへの接続が失敗するようになります。これらのポートは FTPS プロトコルで使われていますが、FTPS は Chrome では実装されていません。ただし、悪意のあるウェブページが FTPS サーバーに対して、綿密に作成された HTTPS リクエストを使ったクロスプロトコル攻撃を仕掛ける可能性があります。これは、ALPACA 攻撃の緩和策になります。

TLS から 3DES を削除

Chrome で、TLS_RSA_WITH_3DES_EDE_CBC_SHA 暗号スイートのサポートが削除されます。TLS_RSA_WITH_3DES_EDE_CBC_SHA は、SSL 2.0 と SSL 3.0 時代の遺物です。トランスポート レイヤー セキュリティ（TLS）での 3DES は、Sweet32 攻撃に対して脆弱です。これは CBC 暗号スイートであるため、Lucky Thirteen 攻撃に対しても脆弱です。TLS では、最初の代替案である AES 暗号スイートが 19 年ほど前に公開された RFC3268 によって定義され、その後も何度かの反復が行われています。

WebAssembly のクロスオリジン モジュール共有

エージェント クラスタが長期的にオリジンにスコープできるように、クロスオリジンでありながら同一サイト環境であるサイト間での WebAssembly モジュール共有が非推奨となります。これは WebAssembly の仕様変更に従ったもので、プラットフォームにも影響します。

Reviewed by Eiji Kitamura – Developer Relations Team
<!—->

【誰でもインフルエンサー】Twitterで全アカウントに認証バッチが付くChromeプラグイン

こんにちはときえのきです。今回は私がTwitterのスクショを投稿するときによく言われる「どうやってスクショに映っている全アカウントを公式化しえるの？」問題についてです。何かと週二以上で聞かれる質問なので、わかりやすくこ […]

The post 【誰でもインフルエンサー】Twitterで全アカウントに認証バッチが付くChromeプラグイン first appeared on FascodeNetwork Blog.

Chrome のサイト分離による保護の強化

この記事は Chrome セキュリティ チーム、Charlie Reis、Alex Moshchuk による Google Online Security Blog の記事 “Protecting more with Site Isolation” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome のサイト分離により、悪意のあるウェブサイトが他のウェブサイトからデータを盗みにくくなる、重要なセキュリティ保護機能です。サイト分離は、Windows、Mac、Linux、Chrome OS ですべてのウェブサイトを他のサイトから保護し、ウェブサイトよりも権限が高い拡張機能とプロセスが共有されないことも保証します。Chrome 92 では、この機能をさらに拡張し、拡張機能が相互にプロセスを共有できないようにする予定です。これにより、既存の拡張機能の動作を一切妨げることなく、悪意のある拡張機能に対する保護が強化されます。

一方で、現在の Android のサイト分離は、パフォーマンスのオーバーヘッドを低く保つため、高価値サイトのみを保護しています。今回は、サイト分離の 2 つの改善についてお知らせします。これにより、Android ユーザーのサイト保護の対象となるサイトが増加します。Chrome 92 以降、ユーザーがサードパーティ プロバイダ経由でログインするサイトや、Cross-Origin-Opener-Policy ヘッダーが設定されているサイトに、サイト分離が適用されます。

Android のサイト分離の継続的な目標は、リソースの制約があるデバイスで、ユーザー エクスペリエンスを低下することなくセキュリティ層を追加することです。ほとんどの Android デバイスにとって、 すべての サイトでサイト分離をすると、コストがかかりすぎる点は変わりません。そのため、保護を追加することで最もメリットを得られるサイトを優先するように経験則を改善することを戦略としています。現在のところ、Chrome はユーザーがパスワードを入力してログインするサイトを分離しています。しかし、多くのサイトが、サードパーティのサイト（たとえば、「Google でログイン」を提供するサイト）を使って、パスワードを入力しなくても認証できるようになっています。ほとんどの場合、これは業界標準の OAuth プロトコルで実現されています。Chrome 92 以降のサイト分離は、一般的な OAuth のインタラクションを認識し、OAuth ベースのログインを利用するサイトを保護します。そのため、ユーザーがどのように認証をしても、データは安全です。

さらに Chrome は、新しい Cross-Origin-Opener-Policy（COOP）レスポンス ヘッダーに基づいてサイト分離をトリガーするようになります。このヘッダーは Chrome 83 以降でサポートされ、セキュリティを考慮したウェブサイトの運営者が、特定の HTML ドキュメントで新しいブラウジング コンテキスト グループをリクエストできるようにします。これにより、信頼できないオリジンからドキュメントが切り離されるので、攻撃者はサイトのトップレベル ウィンドウを参照したり操作したりできなくなります。このヘッダーは、SharedArrayBuffer などの充実した API を使う際に必要なヘッダーの 1 つでもあります。Chrome 92 以降のサイト分離では、ドキュメントの COOP ヘッダーがデフォルト以外の値だった場合、ドキュメントのサイトに機密データが含まれる可能性があるものとして扱い、サイト分離を開始します。そのため、Android でサイト分離によって確実にサイトを保護したいサイト運営者は、サイトで COOP ヘッダーを指定することでそれを実現できます。

これまでと同様、Chrome は新しく分離されたサイトをデバイスのローカルに保存します。ユーザーが閲覧履歴などのサイトデータを削除すると、そのリストもクリアされます。また、Chrome は、COOP によって分離されるサイトに一定の制限を課し、リストを最近使われたサイトのみに集中させ、リストが大きくなりすぎるのを防ぎ、悪用されないように保護しています（COOP サイトがリストに追加される前にそのサイトでのユーザー インタラクションを必須とするなど）。今後も、この新しいサイト分離モードには、最低 RAM しきい値（現在は 2 GB）を設けます。以上の点を踏まえたサイト分離の新たな改善では、Chrome の全般的なメモリ使用量やパフォーマンスに大きな影響を与えることなく、ユーザーの機密データを扱うたくさんのサイトに保護を追加できることがデータによりわかっています。

Android のサイト分離におけるこれらの改善に伴い、Android で Spectre に対応するための V8 ランタイム対策の無効化も行うことにしました。この対策は、サイト分離よりも効果が低く、パフォーマンスのコストがかかります。デスクトップ プラットフォームでは Chrome 70 以降でこの対策は無効化されており、今回の対応によって Android もそれと同等になります。Spectre からデータを保護したいサイトでは、COOP ヘッダーを設定することを検討してください。それによってサイト分離が行われます。

Android デバイスで完全な保護を実現したいユーザーは、chrome://flags/#enable-site-per-process から手動でサイト分離をオプトインすることもできます。これにより、すべてのウェブサイトが分離されるようになりますが、メモリの消費量は増加します。

Reviewed by Eiji Kitamura – Developer Relations Team
<!—->

Chrome 92 でのフィッシング検知の高速化と効率化

この記事は Chrome デベロッパー、Olivier Li Shing Tat-Dupuis による Chromium Blog の記事 “Faster and more efficient phishing detection in M92” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ウェブをブラウジングする Chrome ユーザーの安全を確保することは、Chrome にとって非常に重要です。実際、セキュリティは 4 つの基本原則の 1 つであり続けています。ときに、セキュリティのためにパフォーマンスが犠牲になることがあります。パフォーマンスの探求シリーズの次の投稿では、オンラインのユーザーの安全を確保するフィッシング検知アルゴリズムをどのように改善したかについてお伝えします。ここで紹介する改善によって、現在のフィッシング検知は 50 倍高速になり、電池使用量も少なくなっています。

フィッシング検知

Chrome は新しいページに移動するたびに、ページの一連のシグナルがフィッシング サイトのシグナルと一致するかどうかを評価します。これを行うため、アクセスしたページのカラー プロファイル（ページで表示される色の範囲と頻度）と、通常のページのカラー プロファイルを比較しています。たとえば以下のイメージでは、ほとんどがオレンジ色で、緑と少しばかりの紫が含まれていることがわかります。

サイトが既知のフィッシング サイトと一致した場合、Chrome は警告をし、個人情報を保護して認証情報が漏れることを防ぎます。

フィッシングの試みが検知された場合に表示される画面

プライバシーを守るため、Chrome のセーフ ブラウジング モードは、デフォルトでブラウザ外にイメージを送信することはありません。これはプライバシーにとってはよいことですが、マシンはイメージを分析する作業をすべて自力で行わなければならないことになります。

多くの場合、イメージ処理は重いワークロードになる可能性があります。イメージの分析には、一般的に「ピクセルループ」と呼ばれる処理をし、各ピクセルを評価する必要があるからです。最新のモニターの中には最大で 1400 万ピクセルを超えるものもあります。そのため、各ピクセルで単純な操作をするだけでも、積もり積もってかなりの CPU 使用量になります。フィッシング検知で各ピクセルに対してするのは、基本色を数える操作です。

この操作は、次のようになります。この数は、ハッシュマップと呼ばれる連想データ構造に格納されます。各ピクセルについて RGB のカラー値を抽出し、その数を色ごとに 1 つずつ、3 つの異なるハッシュマップのいずれかに格納します。

効率の改善

ハッシュマップに 1 つの項目を追加するのは高速ですが、この操作は何百万ものピクセルに対して行う必要があります。分析の質が損なわれないように、ピクセルの数を減らすことは避けますが、計算自体は改善できます。

次のようにパイプラインを改善します。

  • このコードでは、3 つのハッシュマップで RGB チャンネルを追跡するのではなく、ハッシュマップを 1 つだけ使って色ごとにインデックスを管理します。これで、数える回数が 3 分の 1 になります。
  • 連続したピクセルは、ハッシュマップで数える前に合計します。これにより、均一な背景色のサイトでは、ハッシュマップのオーバーヘッドがほぼゼロになります。

その結果、色を数える操作は次のようになります。ハッシュマップの操作が大幅に減っていることに注意してください。

高速化の成果

Chrome M92 以降のイメージベースのフィッシング分類は、50 パーセンタイルで最大 50 倍高速に、99 パーセンタイルで 2.5 倍高速に実行されます。平均で、ユーザーがフィッシング分類結果を取得するまでの時間は 1.8 秒から 100 ミリ秒に短縮されます。

これにより、Chrome を使ううえで 2 つのメリットがあります。1 つ目かつ最大のメリットは、同じ作業をするために消費する CPU 時間が減り、総合的なパフォーマンスが向上することです。CPU 時間が減れば、電池の消耗もファンが回る時間も少なくなります。
2 つ目は、結果を早く取得できるため、Chrome が警告を早く表示できることです。この最適化により、処理に 5 秒以上かかるリクエストの割合が 16.25% から 1.6% 未満に下がりました。この速度の改善により、特に悪意のあるサイトでパスワードの入力を防ぐという点で、セキュリティに大きな違いが生まれます。 

総じて、今回の変更により、Chrome のレンダラー プロセスとユーティリティ プロセスが使用する合計 CPU 時間を約 1.2% 削減できました。

Chrome の規模では、わずかなアルゴリズムの改善であっても、全体では膨大なエネルギー効率の向上になります。つまり、何世紀分にも相当する CPU 時間を節約できます。

今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。

Reviewed by Eiji Kitamura – Developer Relations Team<!—->

HTTPS の採用を増やすために

この記事は Google Chrome チーム、Shweta Panditrao、Devon O’Brien、Emily Stark による Chromium Blog の記事 “Increasing HTTPS adoption” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ブラウザが（HTTP でなく）HTTPS でウェブサイトに接続すると、ネットワーク上の盗聴者や攻撃者は、その接続で共有されるデータ（個人情報やそのページ自体など）を傍受したり改変したりできなくなります。ウェブのエコシステムにとって、このレベルのプライバシーとセキュリティは不可欠です。そのため、Chrome では HTTPS のサポートを広げるための取り組みを継続しています。
ありがたいことに、HTTPS の採用はここ数年で大幅に増加しています。また、ほとんどのオペレーティング システムで、Chrome が読み込むページの 90% 以上が HTTPS になっています。しかし、HTTPS をウェブの優先プロトコルにし、HTTPS をサポートしていない残りのウェブでユーザーの保護を強化するために、まだできることがあります。そこで今回は、この領域での今後の作業についてお知らせします。

HTTPS ファーストの世界をオプトインする

M94 以降の Chrome は HTTPS ファースト モードを提供します。このモードでは、すべてのページ読み込みが HTTPS にアップグレードされ、HTTPS をサポートしないサイトを読み込む際には、ページ全体に警告が表示されます。このモードを有効にすると、可能な場合には常に HTTPS でサイトに接続し、HTTP でサイトに接続する前には警告が表示されることが保証されます。エコシステムからのフィードバックに基づき、将来的には、すべてのユーザーで HTTPS ファースト モードをデフォルトにする予定です。Mozilla も、将来的に Firefox のウェブ ブラウジングを HTTPS 専用モードにする予定であることを発表しました。

鍵アイコンの実験

HTTPS ファーストの未来に向かうにあたり、ブラウザがサイトを HTTPS で読み込んでいることを示すために使われることが多い鍵アイコンの再検討も行っています。とりわけ、Google の調査によると、実際に安全なのは接続のみであるにもかかわらず、ユーザーはこのアイコンを信頼できるサイトとみなすことがわかっています。最近の調査では、鍵アイコンの意味を正しく認識できたのは、回答者の 11% だけでした。Chrome の M93 では、この混乱を減らすための試みとして、アドレスバーの鍵アイコンをこれまでよりも中立的なページ情報の入口に置き換える実験をする予定です（下の例を参照）。この実験により、重要なプライバシーとセキュリティの情報や、ページ情報で提供されるコントロール（サイトのパーミッションなど）が見つけやすくなることを期待しています。重要なのは、HTTPS がサポートされていないサイトで「保護されていない通信」のインジケーターが表示される点は変わらないことです。また、この実験には、オプトアウトを希望する組織のためのエンタープライズ ポリシーも含まれています。いずれの場合も、全面的にリリースを行う場合は、事前にお知らせします。

HTTP ウェブのユーザーを保護する

今後のバージョンの Chrome でユーザーが HTTPS ファースト モードを採用することを楽しみにしていますが、その一方で、Chrome の HTTP 接続のサポートを継続し、安全でない接続を使用しているときに常にユーザーを保護して通知をするための追加策を実施します。新機能を安全なオリジンに限る、安全でないオリジンで充実した機能を使えなくするといったこれまでの取り組みの続きとして、ウェブ プラットフォームのさまざまな機能を評価して HTTP ウェブページで制限すべきかどうかを判断する作業に着手する予定です。

ユーザーに最大限のセキュリティ強化を提供する変更に注力できるように、この領域で今後優先する作業は、以下の原則に従って判断します。

  • 安全でない接続を利用するサイトを、信頼するかどうか判断する際の情報提供を強化する
  • 安全でない接続では、サイトでセキュリティ ポリシーをオプトアウトできないように制限する
  • 安全でない接続で提供されたサイトのコンテンツを Chrome が保存する方法や期間を制限する

この原則に基づく行動予定の詳しい説明や、影響を受ける機能リストの改訂版は、Chromium Wiki で管理されています。また、今年中にさらに詳しい情報をお伝えする予定です。

Reviewed by Eiji Kitamura – Developer Relations Team<!—->