この記事は Chrome Developers Blog の記事 "Chrome 111 Beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、ChromeOS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2023 年 2 月 9 日の時点で Chrome 111 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

# CSS

# 新しい CSS カラータイプとカラースペース

CSS カラーレベル 4 に記載されているすべての機能が有効になります。これには、デバイスに依存しない 4 つのカラータイプ（lab、Oklab、lch、Oklch）、color() 関数、グラデーションとアニメーション用のユーザー定義カラースペースが含まれます。

これらの新しいカラータイプやカラースペースの詳細については、高精細度 CSS カラーガイドをご覧ください。

# color-mix() 関数

CSS カラー 5 の便利な color-mix() 関数も導入されます。この関数を使うと、サポートされているあらゆるカラースペースで、ある色と別の色を指定した比率で混ぜ合わせることができます。次の例では、SRGB で 10% の blue を white に混ぜ合わせています。

.item {
  background-color: color-mix(in srgb, blue 10%, white);
}

# CSS セレクタ 4 疑似クラス :nth-child(an + b of S)

:nth-child(an + b) と :nth-last-child() を拡張し、セレクタを受け取れるようにします。たとえば、:nth-child(3 of .c) は指定された親の 3 つ目の .c を表します。詳細については、of S 構文による :nth-child() 選択の細かい制御に関するの投稿をご覧ください。

# CSS ルートフォント単位

既存のルートフォント単位 rem に、ルートフォント単位 ex、ch、ic、lh が追加されます。

# CSS 三角関数

CSS の数式に三角関数 sin()、cos()、tan()、asin()、acos()、atan()、atan2() が追加されます。

# CSS カスタム プロパティのスタイル コンテナ クエリ

@container ルールに style() 関数が追加されます。これにより、祖先要素のカスタム プロパティの計算値に基づいてスタイルを適用できるようになります。

# baseline-source プロパティ

baseline-source プロパティを使うと、インラインレベルのボックスのラインボックス内の位置合わせに first と last のどちらのベースラインを使うかを指定できます。

# ウェブ API

# window-management 権限と権限ポリシー文字列

Chrome 111 では、window-placement 権限と権限ポリシー文字列の別名として、window-management が追加されます。これは、将来的に window-placement のサポートを終了して削除することに備えるため、文字列の名前を変更するという大きな作業の一環です。用語の変更により、今後 Window Management API が進化しても、記述子を長期間利用できるようになります。

# Media Session API: スライドの表示アクション

既存の Media Session API に previousslide と nextslide アクションが追加されます。

# サイズ変更可能な ArrayBuffer と拡張可能な SharedArrayBuffer

ArrayBuffer コンストラクタを拡張し、インプレースでバッファを拡大および縮小できる最大長を受け取れるようにします。同様に、SharedArrayBuffer を拡張し、インプレースで拡大できる最大長を受け取れるようにします。

# 推測ルール : 参照元ポリシーキー

推測ルールの構文を拡張し、推測ルールによってトリガーされる推測リクエストで使う参照元ポリシーを指定できるようにします。また、これによって「十分に厳格な参照元ポリシー」要件が再導入されます。

# ストリーミング宣言型シャドウ DOM

template タグのクローズ時ではなくオープン時にシャドウルートをアタッチすることで、ストリーミングのサポートを追加します。

# View Transitions API

ビューのスナップショットを取得し、状態間で重複することなく DOM を変化できるようにすることにより、シングルページ アプリケーション（SPA）で洗練された画面遷移を実現します。ビュー遷移を使うと、カスタムの遷移を作ったり、デフォルトのシンプルなクロスフェードを使ったりして、ユーザー エクスペリエンスを改善できます。

使ってみたい方は、Chrome デベロッパーの記事の情報やサンプル遷移をご覧ください。

# WebRTC Scalable Video Coding 拡張機能

この拡張機能は、WebRTC の送信動画トラックで利用可能な Scalable Video Coding（SVC）設定を選択する標準手法を定義します。

# WebXR enabledFeatures 属性

XRSessionInit で指定された、この XRSession で有効になっている機能セットと、指定されたモードや機能の仕様で必要となる暗黙機能を返します。付与されたセッションの場合は、すべての requiredFeatures が含まれますが、optionalFeatures のサブセットである場合もあります。ほとんどの機能では、付与されたセッションであるかどうかを別の方法で検出できます。ただし、一部の機能では、ある機能が有効かどうかのシグナルが、今後ずっと利用できないのではなく、今は利用できないだけの機能のデータと密接に結びついている可能性があります。enabledFeatures に問い合わせることで、役立つヒント（たとえば、トラッキングの改善や開始）を表示するべきか、現在のセッションでもう機能がサポートされることはないかを判断できます。

# 進行中のオリジン トライアル

Chrome 111 では、以下の新しいオリジン トライアルにオプトインできます。

# Web Payment API の connect-src CSP バイパスの削除に向けた逆トライアル

Web Payment API がマニフェストをフェッチするときに connect-src CSP ポリシーをバイパスできる機能のサポートを終了します。このサポートが終了した後は、マニフェストをフェッチするためにメソッドからチェーンする他の URL と同じように、PaymentRequest 呼び出しで指定する支払い方法の URL をサイトの connect-src CSP ポリシーで許可する必要があります。

このバイパス機能は Chrome 111 で削除されますが、一時的にバイパスを有効化する必要があるデベロッパーのために、111 から 113 で逆オリジン トライアルが行われます。これにオプトインするには、connect-src CSP バイパスサポート終了の逆トライアルに登録してください。

# ドキュメント ピクチャー イン ピクチャー

ドキュメント ピクチャー イン ピクチャー API は、常に前面に表示されるウィンドウを開く新しい API です。このウィンドウには、任意の HTML コンテンツを設定できます。これは、HTMLVideoElement のみを PiP ウィンドウに設定できる既存のピクチャー イン ピクチャー API の拡張です。ウェブ デベロッパーは、これを使って PiP のユーザー エクスペリエンスを改善できます。

ドキュメント ピクチャー イン ピクチャーのドキュメントをご覧ください。

ドキュメント ピクチャー イン ピクチャーのオリジン トライアルに登録することもできます。

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

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

今回の Chrome のリリースでは、3 つの機能が削除されます。

# PaymentInstruments の削除

PaymentInstruments は、決済アプリの非 JIT インストールを支えるウェブ API です（https://w3c.github.io/payment-handler/ を参照）。これは、ブラウザが実際の決済手段の詳細を保存するという前提で設計されましたが、実際にはそうならず、一部のプライバシーが漏洩します。ほかのブラウザにも導入されていないばかりか、ほかのブラウザ ベンダーもまったく関心を示していません。そのため、この API のサポートを終了し、削除します。

# Web Payment API の connect-src CSP バイパスの削除

Web Payment API がマニフェストをフェッチするときに connect-src CSP ポリシーをバイパスできる機能のサポートを終了します。これが削除された後は、マニフェストをフェッチするためにメソッドからチェーンする他の URL と同じように、PaymentRequest 呼び出しで指定する支払い方法の URL をサイトの connect-src CSP ポリシーで許可する必要があります。

サポート終了のトライアルにオプトインすると、この削除によって必要になる変更を行う時間を延長できます。オプトインの方法については、オリジン トライアルの情報をご覧ください。

# canmakepayment イベントの販売者 ID

canmakepayment Service Worker イベントは、ユーザーがインストールされている決済アプリにカードを保存しているかどうかを販売者に知らせます。また、決済アプリのオリジンの Service Worker に、販売者のオリジンと任意のデータを渡していました。このクロスオリジン通信は、JavaScript で PaymentRequest を作成したときに発生しました。その際にユーザーの操作は必要なく、ユーザー インターフェースは表示されませんでした。このデータ渡しは、canmakepayment イベントと Android の IS_READY_TO_PAY インテントから削除されています。

Posted by Eiji Kitamura - Developer Relations Team

この記事は Chrome Developers  Blog の記事 "Chrome 110 beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、ChromeOS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2023 年 2 月 22 日の時点で Chrome 110 は安定版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

# CSS

今回のリリースでは、2 つの新しい CSS 機能が追加されます。

# CSS 頭文字

頭文字とは、新しいテキスト セクションを始めるときに使う大きな装飾文字を指します。これは、印刷技術が発明される以前から使われています。CSS の initial-letter プロパティを使うと、頭文字が後続のテキストに入り込む行数を設定できます。次の例では、頭文字がテキスト 3 行分にわたって表示されます。

.content::first-letter {
  initial-letter: 3;
}

# CSS 疑似クラス :picture-in-picture

:picture-in-picture 疑似クラスは、動画がピクチャー イン ピクチャーに入ったときや終了したときにメディア プレーヤーをカスタマイズしたい場合に役立ちます。

:picture-in-picture 疑似クラスのデモをお試しください。

# ウェブ API

# AudioContext.setSinkId()

AudioContext.setSinkId は、出力に使うオーディオ デバイスの ID を設定します。これにより、AudioContext は、ユーザーが選択した接続済み出力デバイスにオーディオをルーティングできるようになります。

この機能の詳細については、Web Audio での出力先デバイスの変更に関する投稿をご覧ください。

# クロスオリジン iframe の FedCM

権限ポリシーを通した FedCM API のクロスオリジン iframe サポートを追加します。これにより、ウェブサイトは、ID プロバイダからのスクリプト（クロスオリジン iframe で FedCM API をトリガーするもの）をサンドボックス化し、ページ全体を完全に制御できないようにすることができます。また、iframe 自体がユーザーのログインを要求するユースケースも実現できます。どちらの場合も、親フレームはクロスオリジン iframe に権限ポリシー identity-credentials-get を提供する必要があります。

# credentialless な iframe

credentialless な iframe を使うと、デベロッパーが一時的なコンテキストを新しく作成し、それを使ってサードパーティ iframe にドキュメントを読み込むことができます。credentialless な iframe は、credentialless な COEP を汎用化したものであり、COEP を利用していない可能性があるサードパーティ iframe をサポートします。これにより、サードパーティの iframe を COEP ページに埋め込むには COEP をサポートしなければならないという制約がなくなるため、クロスオリジン分離の採用を検討しているデベロッパーの障害がなくなります。

詳細は credentialless な iframe に関する投稿をご覧ください。

# FileSystemHandle::remove() メソッド

FileSystemHandle の remove() メソッドを使うと、showSaveFilePicker() からファイル ハンドルを取得したものの、結局何も保存せずにファイルを削除するという一般的なユースケースに対応できます。このメソッドを追加する前は、ハンドルを提供したファイルやディレクトリを削除することはできず、親ディレクトリのハンドルを取得して FileSystemDirectoryHandle::removeEntry() を呼び出す必要がありました。

# 推測ルール API からトリガーされるプリフェッチ

プリフェッチを行うと、今後のナビゲーションのためにメインリソースをフェッチしてメモリ内に保存しておけるので、次のナビゲーションを高速化できます。今回のリリースには、同一サイトのプリフェッチと、対象のサイト向けの認証情報が存在しない場合のクロスサイトのプリフェッチの両方が含まれます。

# URL で Non-Transitional IDNA 処理を利用

Non-Transitional モードの URL 処理で IDNA 2008 を有効にし、Chrome の動作を Firefox および Safari と合わせます。現在の Chrome は、IDNA 2008 を Transitional モードの URL 処理に使用しています。Transitional モードと Non-Transitional モードの主な違いは、偏差文字と呼ばれる ß（ラテン小文字シャープ S）、ς（ギリシャ語小文字ファイナル シグマ）、ZWJ（ゼロ幅接合子）、ZWNJ（ゼロ幅非接合子）の 4 文字の扱いです。Transitional モードでは偏差文字が IDNA2003 と同じように扱われ、ß は ss に、ς は σ にマッピングされ、ZWJ と ZWNJ は削除されます。Non-Transitional モードでは、これらの文字を含むドメインが許可され、マッピングされることなくドメイン名として使用できるため、別の IP アドレスに解決される可能性があります。たとえば、Chrome と Firefox で faß.de を入力すると、現在は別々のサイトが開きます。Chrome で Non-Transitional IDNA を有効にすることで、偏差文字がドメイン名として許可されます。Firefox と Safari は 2016 年にこの変更を行っており、Non-Transitional URL 処理を使用し続けています。

# ウェブアプリの起動ハンドラ

launch_handler ウェブアプリ マニフェスト メンバーを追加します。これにより、すべての種類のアプリ起動トリガーで、ウェブアプリの起動動作をカスタマイズできます。たとえば、次のようにすると、Example アプリを起動するたびに既存のアプリ ウィンドウに移動してフォーカスされます（存在する場合）。常に新しいアプリ ウィンドウが起動することはありません。

{ 
    "name": "Example app", 
    "start_url": "/index.html", 
    "launch_handler": {
        "client_mode": "navigate-existing" 
    } 
} 

# web-share 権限ポリシー

navigator.share() へのアクセスを制御します。デフォルトで、サードパーティの iframe は Web Share API を使う権限を持ちません。

# 進行中のオリジン トライアル

Chrome 110 では、以下の新しいオリジン トライアルにオプトインできます。

# ナビゲーション プリフェッチ キャッシュでの No-Vary-Search のサポート

URL クエリ パラメータが変更されても、プリフェッチのマッチングが可能になります。No-Vary-Search HTTP レスポンス ヘッダーは、キャッシュとのマッチングを行う際に、URL クエリの一部またはすべてのパートを無視できることを宣言します。ここでは、クエリ パラメータのキーの順序によってキャッシュミスが起こらないようにしたり、特定のクエリ パラメータが原因でキャッシュミスが起こらないようにしたり、既知の特定のクエリ パラメータのみでキャッシュミスを起こしたりすることを宣言できます。複数のキャッシュに適用することもできますが、このエントリはプリフェッチ キャッシュのサポートについて述べています。

こちらからナビゲーション プリフェッチ キャッシュの No-Vary-Search サポートのトライアルに登録できます。

# PerformanceResourceTiming.deliveryType

リソースがどのように配信されるかについての情報を公開します。たとえば、キャッシュから配信されるリソース（現在 transferSize で公開されているもの）や、以前のページによってプリフェッチされたナビゲーションを識別する際に役立ちます。

# SoftNavigation パフォーマンス エントリ

ソフト ナビゲーション ヒューリスティックス（試験運用版）をウェブ デベロッパーに公開します。PerformanceObserver とパフォーマンス タイムラインの両方を使用します。

こちらからソフト ナビゲーション ヒューリスティックスのトライアルに登録できます。

# 推測ルール: Speculation-Rules ヘッダーによる配信

現在のところ、推測ルールはインライン スクリプトタグでしか指定できません。この機能提案では、"Speculation-Rules" ヘッダーを使った代替策を提供します。値は、application/speculationrules+json MIME タイプのテキスト リソースを指す URL である必要があります。このリソースのルールが、ドキュメントのルールセットに追加されます。

# 推測ルール: ドキュメントをソースとするルール

この推測ルール拡張構文を利用すると、ブラウザがページ内の link 要素から推測の URL を取得します。どのリンクが利用できるかを制限する基準が含まれる場合があります。

# WebView の X-Requested-With

Android WebView で X-Requested-Header の以前の動作を維持するための逆トライアルです。現在、このヘッダーの値には埋め込み元のアプリのパッケージ名が設定されていますが、この動作は徐々にロールアウトして削除される予定です。この逆トライアルでは、機能削除の移行期間中も、サイト所有者がこのヘッダーを受け取り続けられるようになります。

この機能のサポートの終了についての詳しい情報は、別のブログ投稿で改めてお伝えします。こちらから X-Requested-With 逆トライアルに登録できます。

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

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

今回のリリースの Chrome では、2 つの機能が削除されます。

# 安全でないコンテキストでの Web SQL の削除

Web SQL は、安全でないコンテキストで削除されています。オリジン プライベートなファイル システムをサポートしたブラウザで SQLite Wasm に切り替えることをお勧めします。

# window.webkitStorageInfo の削除

以前のストレージ割り当て API である window.webkitStorageInfo のサポートを削除します。この機能はもともと 2011 年に導入されました。Chrome はプレフィックスつきの割り当て API を実装し、その直後に Quota API に機能が引き継がれましたが、その後こちらも非推奨になっています。以前のストレージ割り当て API は他のブラウザで実装されることはなく、2013 年に非推奨になっています。

Posted by Eiji Kitamura - Developer Relations Team

この記事は Dana Jansens (she/her), Chrome Security Team による Google Security Blog の記事 "Supporting the Use of Rust in the Chromium Project" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

近いうちに、Chromium プロジェクトで C++ からサードパーティ製 Rust ライブラリを使用することがサポートされます。現在（元記事公開当時）、ビルドシステムにプロダクション Rust ツールチェーンを追加する作業を懸命に進めています。来年中には Chrome バイナリに Rust コードを含めることができるようになる予定です。この取り組みは徐々に開始し、準備ができたときに検討の対象となるライブラリを明確に予測する作業を行っています。

このブログ投稿では、現時点（元記事公開当時）でサードパーティ製 Rust ライブラリをサポートしつつも、Chromium で Rust を幅広く使うことはしないという決断に至った経緯について説明します。

Chromium に Rust を導入する理由Chromium に Rust を導入する目的は、シンプルで（IPC を使わない）安全な（全般的に C++ よりも複雑でなく、サンドボックスでメモリの安全性に関するバグは発生しない）形で 2 の法則を満たすことにより、Chrome の開発をスピードアップし（書くコードを減らし、設計ドキュメントを減らし、セキュリティ レビューを減らす）、セキュリティを改善する（メモリの安全性に関するバグのないコードの行数を増やし、コードのバグ密度を減らす）ことにあります。そしてこの目的に向かうために、サードパーティ製 Rust ライブラリが役立つものと確信しています。

Rust は、Mozilla がブラウザを書くために特別に開発したものなので、このテクノロジーが Chromium でようやく使われ始めるようになるのは、理にかなったことです。システム ソフトウェア業界に莫大な貢献をしてくださっている Mozilla に感謝いたします。Rust は、安全性とパフォーマンスの両方を言語に期待できることを見事に証明しています。

C++ と Rust は、cxx、autocxx、bindgen、cbindgen、diplomat、（試験運用版の）crubit などのツールを使ってうまく連携できることがわかっています。ただし、制限事項もあります。やがて新しいツールや改良されたツールによって、こういった制限事項の状況は変わるものと期待できますが、今回の決断や説明は現在のテクノロジーの状況に基づいています。

Chromium が Rust の利用をサポートする方法

Chrome セキュリティ チームは、どのように Rust と C++ のコードの併用にアプローチすべきか、時間をかけて調査してきました。Google のソフトウェア スタックでも、C++ ではなく Rust を記述する時間が増えていることの意味を理解し、安全かつシンプルで信頼性の高い相互利用の制限とはどのようなものかを把握するためです。

この調査に基づき、Chromium の方向性について 2 つの結論を出しました。

1. 現時点では、C++ から Rust への一方通行の利用のみをサポートします。Chromium は C++ で書かれており、main() から exit() までのスタック フレームの大半は C++ コードです。前述の方向を選んだ理由はここにあります。利用を一方向に限定することで、依存関係ツリーの形を制御します。Rust は C++ に依存することはできないので、依存関係の注入を除けば、Rust が C++ の型や関数を知ることはできません。こうすることで、Rust は任意の C++ コードではなく、C++ から API を通して渡された関数だけを実行できるようになります。
2. 現時点では、サードパーティ製ライブラリのみをサポートします。サードパーティ製ライブラリはスタンドアロン コンポーネントとして書かれたもので、Chromium の実装についての暗黙的な知識は持ち合わせていません。つまり、シンプルで 1 つのタスクに特化した API を提供しています。言い換えれば、通常はインターフェースが狭く、複雑なポインタグラフや共有所有権は存在しません。C++ で使用するライブラリのレビューし、期待を満たすものであることを確認します。

Chromium での Rust と C++ の相互利用

これまで成功を収めてきたほとんどの C/C++ と Rust の相互利用事例は、狭い API（例 : QUIC や bluetooth のライブラリ、Linux ドライバ）や明確に分離されたコンポーネント（例 : IDL、IPC）によるものが中心でした。Chrome では、//content/public レイヤなど、基本的ではあるものの実に広範な C++ API が使われています。私たちは、こういった種類の API に対して Rust コンポーネントを構築することがどのような意味を持つのかについて検討しました。高レベルでは、C++ と Rust は異なるルールで動作するため、とても簡単に横道にそれてしまう可能性があることがわかりました。

たとえば、Rust は生存期間（推論または明示的記述による）と排他的可変性という 2 つの入力を使った静的解析で一時メモリの安全性を保証します。後者は、Chromium の大半の C++ の記述方法と互換性がありません。冗長な可変ポインタや、可変ポインタに到達する複数のパスを提供するポインタは、システムのいたるところに存在しています。循環する可変データ構造も存在します。（可変）ポインタが相互に連結した巨大な構造が含まれているブラウザのプロセスには、これが特に当てはまります。こういった C++ ポインタが複雑かつ長時間存在する形で Rust 参照にも使われるとすれば、C++ 作成者が Rust のエイリアス ルールを理解し、たとえば次のような方法で、それに違反する可能性を除かなければならなくなります。

• 1 つの関数から同じ可変ポインタを 2 回返し、1 つを保持できるようにする。
• 重複する複数のポインタの片方は可変として Rust に渡し、参照として同時に保持できるようにする。
• 共有または可変の参照を通して、Rust から状態の変化が見えるようにする。

コンパイラや型システムを通してサポートを提供する相互利用ツールがない場合、デベロッパーは Rust コンパイラが前提とする内容をすべて理解し、C++ 側からそれに違反することがないようにしなければなりません。この枠組みでは、C++ は安全でない Rust と同じであるも同然です。また、安全でない Rust はプロジェクトにとってコストがかかるものですが、そのコストはカプセル化を維持し、最低限にとどめることによって管理できます。同様に、C++ は非常に複雑なので、安全な Rust からカプセル化する必要があります。相互利用のために設計した狭い API は、同じようなカプセル化を提供できます。私たちは、言語間で広い API を許可できるような別の方法で、相互利用ツールがカプセル化を提供できるようになることを期待しています。

概念的にまとめると、別の相互利用ツールのサポートがない段階では、次のようになります。

• 言語間でのポインタ渡しや参照渡しにはリスクがある。
• 現実的に正しいコードを書けるようにするには、言語間の狭いインターフェースが重要である。

片方の言語のコンセプトがもう片方にない場合、言語間で任意のコードを相互利用できるようにすると、困難な状況が発生します。Rust が C++ を呼ぶ場合、バインディング ジェネレータではテンプレートや継承といった言語機能をサポートするのが難しいことがあります。C++ が Rust を呼ぶ場合、proc マクロや trait などが同じ課題をもたらします。インピーダンスの不整合は、どちらかの言語でそのような設計が意図的に選択された結果である場合がありますが、言語間の FFI（相互利用）を制限するものでもあります。各言語の考え方を他者にとって妥当な形でモデリングするか、それを許可しないようにする相互利用ツールが必要です。

Chromium から Rust エコシステムにアクセスする

こういった課題は、相互利用を簡単かつシームレスにするための機会であると同時に、両方の言語の幅広いライブラリにアクセスする機会でもあります。Google は Crubit に取り組んでいます。これは、C++ と Rust との相互利用の忠実度を上げ、各言語がもう一方に求める要件を表現したり、カプセル化したりする方法を探る実験です。

Chromium のようなセキュリティを重視したオープンソース プロジェクトにとって、Rust エコシステムはとりわけ重要な存在です。このエコシステムは巨大で（crates.io には 96,000 以上のクレートがあります）、Google を含むシステム開発業界からの大規模な投資を受けて成長を続けています。Chrome はサードパーティ製コードを多用しているので、サードパーティへの投資が行われている場所を把握する必要があります。私たちにとって重要なのは、Rust を Chromium プロジェクトに組み込む対応です。

私たちは、この戦略に従って基準を定め、サードパーティのプロセスを通じて API レビューのレベルを維持する予定です。同時に、相互利用サポートの未来を見据え、Rust と C++ の間で合理的に行えることの限界を押し上げていきます。

その他の関連コンテンツ

メモリが安全でないことは業界全体の問題であり、この領域で変化を起こす戦略の 1 つが Rust の利用です。最近、Android と Apple がこの件に関してそれぞれすばらしいブログ投稿を公開しているので、興味がある方はぜひご覧ください。Chrome には数百万行の C++ があり、MiraclePtr などのプロジェクトを通じて C++ の安全性を向上する作業も懸命に行われています。

Posted by Eiji Kitamura - Developer Relations Team

この記事は Chrome Root Program, Chrome Security Team による Google Security Blog の記事 "Sustaining Digital Certificate Security - TrustCor Certificate Distrust" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

注 : この投稿は、2022 年 12 月に Mozilla "Dev Security Policy" Web PKI 公開ディスカッション フォーラム Google Group で行われたディスカッションの内容をまとめたものです。Google Chrome は、2022 年 12 月 15 日に、この公開フォーラムで TrustCor は信頼できないことを伝達しました。

Chrome セキュリティ チームは、Chrome ユーザーのセキュリティとプライバシーを最優先しており、この価値観において妥協するつもりはありません。

Google はユーザーの安全性を確保するため、適切と見なす場合に、ポリシーに従って Chrome Root Store の CA 証明書の追加や削除します。CA 証明書を選択し、追加を進める取り組みは、Chrome のセキュリティを高め、相互運用性を向上するために行われます。

ウェブのセキュリティやプライバシーを低下させ、損なおうとする行為は、CA 証明書が Chrome Root Store に含まれる組織にとってふさわしいものではありません。このような基本原則を遵守する能力に対する信頼が損なわれたため、以下のバージョンでは、TrustCor Systems が発行した証明書は信頼されたものと見なされなくなります。これは Chrome ユーザーの安全を守るための措置です。

• Chrome バージョン 111（ベータ版は 2023 年 2 月 9 日ごろ、安定版は 2023 年 3 月 7 日ごろに公開）以降
• コンポーネント アップデートを受信できる旧バージョンの Chrome（Chrome 111 の安定版リリース日以降）

この変更は、2022 年 12 月 15 日に、Mozilla "Dev Security Policy" Web PKI 公開ディスカッション フォーラム Google Group で初めて伝達されました。

この変更は、CA インシデントに対応する既存の仕組みに基づき、以下によって実現する予定です。

• 統合証明書拒否リスト
• Chrome Root Store に含まれる証明書の削除

2023 年 3 月 7 日ごろから、以下のいずれかのルートにチェーンされた証明書を使っているウェブサイトを開いた場合、安全でないと見なされ、証明書エラーが全画面にインタースティシャル表示されます。

影響を受ける証明書（SHA-256 フィンガープリント）:

• d40e9c86cd8fe468c1776959f49ea774fa548684b6c406f3909261f4dce2575c
• 0753e940378c1bd5e3836e395daea5cb839e5046f1bd0eae1951cf10fec7c965
• 5a885db19c01d912c5759388938cafbbdf031ab2d48e91ee15589b42971d039c

この変更は、デフォルト ビルドの一部として、Chromium オープンソース プロジェクトにも組み込まれます。特定の Chromium ベースのブラウザで予期される動作について質問がある方は、メンテナにお問い合わせください。

影響を受ける証明書のテストや入れ替えの時間をウェブサイトの運営者が十分確保できるように、この変更は通常の Chrome リリース プロセスの一部に組み込む予定です。リリースのスケジュールやマイルストーンに関する情報は、https://chromiumdash.appspot.com/schedule で公開されています。

ウェブサイトの運営者は、2023 年 2 月 9 日ごろから、Chrome 111 ベータ版でこの変更をプレビューできます。Dev チャンネルや Canary チャンネルを使うと、さらに早く変更をプレビューできます。大多数のユーザーは、2023 年 3 月 7 日ごろに Stable チャンネルに Chrome 111 がリリースされるまで、動作の変更を目にすることはありません。

その他の Google プロダクトのセキュリティ対応の概要 :

• Android では、今後公開されるオペレーティング システムのバージョンで、TrustCor のルート CA 証明書がプラットフォームの信頼済み証明書から削除されます。既存の Android バージョンでも、上記の Chrome と同じスケジュールで、TrustCor のルート CA 証明書が削除されます。
• Gmail は行動計画の最終決定をしているところで、今後アップデートする予定です。

Posted by Eiji Kitamura - Developer Relations Team