オリジン トライアル

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

Anonymous iframe

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

このオリジン トライアルは、Chrome 108 まで継続される予定です。オリジン トライアルに登録するには、登録ページをご覧ください。

ポップアップ API

ポップアップ API を使うと、ウェブアプリの他のインターフェース要素の上に表示される一過的なユーザー インターフェース要素を構築できます。この API は、アクション メニュー、フォーム要素の表示、コンテンツ ピッカー、ユーザー インターフェースの説明などのインタラクティブ要素の作成に活用できます。

この API は、新しい popup コンテンツ属性を使って、任意の要素を最上位レイヤーに表示します。この属性がポップアップに与える効果は <dialog> 要素と同等ですが、いくつかの重要な相違点があります。たとえば、簡易的な閉じる操作、ポップアップのインタラクション管理、アニメーション、イベントのサポート、非モーダルモードなどです。

このオリジン トライアルは、Chrome 110 まで継続される予定です。オリジン トライアルに登録するには、登録ページをご覧ください。

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

Android WebView の Client Hint 永続化

Android WebView で Client Hint が永続化され、他のウェブ プラットフォームと一致するようになります。これまでの WebView では、ページがリクエストする Client Hint のリストが永続化されなかったため、ウェブサイトを最初に読み込むときに Client Hint が含まれることはなく、ヒントを受け取ることができたのは対象ページのサブリソースだけでした。この動作は、ウェブサイトがユーザー エージェントに合わせてコンテンツを提供できるようにするという Client Hint のシステムの利便性を損なうものでした。Client Hint の詳細については、HTTP Client hints のページをご覧ください。

CSS

grid-template プロパティの補完

CSS グリッドの 'grid-template-columns' プロパティと 'grid-template-rows' プロパティを使うと、行の名前を定義してグリッドの列と行のサイズを追跡できます。これらのプロパティで補完がサポートされたことで、複数の状態間でグリッドのレイアウトをスムーズに遷移させることができ、アニメーションや遷移が途中で中断することはなくなります。

長さの単位 'ic'

長さの単位 'ic' length unit は、中国語や日本語などの一部のアジア系フォントで使われる表意文字である「水」を基準にした相対的な長さを CSS で表現します。これにより、上記のフォントで、所定の文字数の全角文字グリフに要素のサイズを合わせられるようになります。Gecko と WebKit はすでにこの単位をサポートしています。Chrome にこれを追加する作業は、Interop 2022 の一環として行われています。

'forced-color-adjust' CSS プロパティの 'preserve-parent-color' 値

'forced-color-adjust' CSS プロパティに 'preserve-parent-color' value has been added 値が追加されました。これまでは、カラーモードの強制を有効化すると、'color' プロパティが継承されました。今後は、'preserve-parent-color' 値を使った場合、'color' プロパティは親の値を使うようになります。そうでない場合、'forced-color-adjust: preserve-parent-color' 値は 'forced-color-adjust: none' と同じ動作となります。

-webkit-hyphenate-character プロパティのプレフィックス削除

Chrome で、-webkit-hyphenate-character プロパティに加え、プレフィックスなしの hyphenate-character プロパティがサポートされます。今後、-webkit-hyphenate-character プロパティは非推奨となる予定です。

JavaScript: Intl.NumberFormat v3 API

Intl.NumberFormat に以下の新機能が搭載されました。

• 数値範囲の書式を指定する 3 つの新しい関数 : formatRange()、formatRangeToParts()、selectRange()
• グルーピング用の enum
• 丸めと精度の新しいオプション
• 丸め優先度
• 文字列を 10 進数として解釈
• 丸めモード
• 負数のみに符号を表示（ゼロに負の記号を表示しない）

詳しくは、オリジナル提案の README をご覧ください。

SerialPort BYOB リーダーのサポート

SerialPort が提供する ReadableStream のベースとなるデータソースは、読み出し可能なバイト ストリームになります。SerialPort "bring your own buffer"（BYOB）には、パラメータなしの port.readable.getReader() を呼び出す既存のコードとの下位互換性があります。この機能がサポートされているかどうかを検出するには、getReader() を呼び出すときに mode パラメータとして 'byob' を渡します。次に例を示します。

port.readable.getReader({ mode: 'byob' });

古い実装に新しいパラメータを渡すと、TypeError がスローされます。

BYOB リーダーを使うと、ストリームがチャンクごとに新しいバッファを割り当てるのではなく、デベロッパーがデータを読み込むバッファを指定できます。ストリームは提供されたバッファのスペース以上のデータを返すことはできないので、メモリの使用量を減らせる可能性が生じるだけでなく、どのくらいのデータを受け取るかをデベロッパーが制御できるようにもなります。詳しくは、シリアルポートの読み取りと書き込みをご覧ください。

WebCodecs の dequeue イベント

dequeue イベントとそれに関連するコールバックが audio と video インターフェースに追加されました。具体的には、AudioDecoder、AudioEncoder、VideoDecoder、VideoEncoder の各インターフェースです。

デベロッパーは、最初に encode() または decode() を呼び出すことで、エンコードやデコードの作業をキューに入れることができます。新しい dequeue イベントは、ベースとなるコーデックがキューに格納された作業の一部または全部を取り込んだタイミングを通知するために発行されます。encoder.encodeQueueSize と decoder.decodeQueueSize 属性の値はすでに減少しており、キューサイズの減少はすでに反映されています。この新しいイベントにより、キューが減少したタイミング（すなわち、キューに作業を追加すべきタイミング）を判定するために setTimeout() を呼び出す必要がなくなります。

WebXR ローカメラ アクセス

WebXR Device API を使うアプリケーションが、WebXR が提供するその他の AR 機能も操作できる状態にある場合、姿勢と連動したカメラ画像テクスチャにアクセスできるようになります。

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

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

Cookie の domain 属性から非 ASCII 文字を削除

最新の仕様（RFC 6265bis）に準拠するため、Chromium は非 ASCII 文字（éxample.com など）を含む Domain 属性を持つ Cookie を拒否します。

Cookie の IDN ドメイン属性のサポートは長いこと規定されておらず、Chromium、Safari、Firefox のすべてで動作が異なります。今回の変更により、非 ASCII ドメイン属性を持つ Cookie を拒否するという Firefox の動作が標準になります。

これまでの Chromium は、非 ASCII 文字を受け入れ、正規化した punycode に変換して保存しようとしていました。今後は厳しいルールを適用し、有効な ASCII（該当する場合は punycode）ドメイン属性が必須となります。

HTTP/2 プッシュの削除

Chrome で、サーバーが送信する HTTP/2 プッシュ ストリームの受信、メモリ内保持、利用の機能が削除されます。詳細と提案されている代替 API については、Chrome から HTTP/2 サーバー プッシュを削除するをご覧ください。

Next '22 が 10 月 12 日（日本時間）に開幕し、太陽を追うように世界をめぐる 24 時間のグローバルなデジタル配信が繰り広げられます。注目は、ニューヨーク、サニーベール、東京、ベンガルール、ミュンヘンの 5 か所から届けられるグローバル規模の基調講演です。

コンピューティングの未来を形作る当事者が自ら語ります。Google Cloud のリーダーやコミュニティ インフルエンサーがビジネスで直面する最大級の課題に対処している方法を聞く機会をぜひご活用ください。

Google Cloud Next のウェブサイトでは、最新のニュース、プロダクト、Google Cloud のテクノロジーについて学び、技術やトレーニングのコンテンツを体験することができます。

6 つの大陸で 200 件を超えるイベントが開催されます。パートナーやデベロッパーのコミュニティと連携して開催される、地域ごとのイベントもあります。Next '22 にご登録いただければ、お近くで開催されるイベントをお知らせします。

Next '22 では、お客様の分野に関連する役に立つ知識やノウハウをご紹介します。各コンテンツは、アプリケーション開発者、データ サイエンティスト、データ エンジニア、システム アーキテクト、ローコード / ノーコードの開発者向けにパーソナライズされています。Google Cloud Next は多くの皆さまにお楽しみいただけるよう、参加費は無料です。

Next '22 の注目すべき点はこれだけではありません。

設定言語でコンテンツを閲覧可能 - Next '22 のネイティブ ウェブ エクスペリエンスは Cloud Translate API を使って 9 言語に翻訳されます。ライブ配信やセッション コンテンツは、YouTube の UI で字幕を有効にできます。180 以上の言語がサポートされています。

独自のプレイリストを作成可能 - カスタム プレイリストを作成、探索、共有できます。Google Cloud のおすすめプレイリストもあります。

デベロッパー向けのコンテンツ - エンジニア、デベロッパーの皆さま向けに、Next '22 サイト内に Developer Zone をご用意しています。日本では 10 月 14 日（金）に実施する Innovators Hive のライブ配信、Developer Profile でのバッジ獲得、おすすめのリソースなどもお楽しみください。

コミュニティとのつながり - セッション チャットでは、他の参加者とつながり、プレゼンターに質問をして、コンテンツを最大限に活用できます。

世界各地のオンサイト イベントを実施 - Google のパートナーやデベロッパーのコミュニティと連携して、一連の小規模なオンサイト イベントを世界各地で開催します。お住まいの地域で今後開催されるオンサイト イベントに関する情報をお届けします。

Next '22 にぜひご登録ください

Next '22 のイベントはすべて参加無料ですので、どうぞお見逃しなく。お住まいの地域の Google Cloud コミュニティのイベントに関する情報もお届けいたします。Next で「明日」に出会いましょう。

今すぐご登録ください。

- Google Cloud, Global Experiential Marketing, Marketing Director, Matt Kaufman

ユーザーはウェブをブラウジングするときに、さまざまな脅威に遭遇します。誤認させるサイトや偽物のサイトにパスワードなどのプライベートな情報を入力するように欺かれる場合があり、これはフィッシングとも呼ばれます。マルウェアと呼ばれる悪意のあるソフトウェアをインストールさせられ、個人データを収集されたり、身代金を要求されたりすることもあります。Google Chrome（以降は Chrome と記述します）は、このようなインターネット上の脅威からユーザーを守ります。Chrome ユーザーがセーフ ブラウジング保護をオンにしてウェブをブラウズすると、Chrome は Google のセーフ ブラウジング サービスを使ってさまざまな脅威を特定して回避します。

セーフ ブラウジングは、ユーザーの設定によって動作が異なります。特に一般的なのは、Chrome がセーフ ブラウジング サービスのプライバシーに配慮した Update API（アプリケーション プログラミング インターフェース）を使うケースです。この API はユーザーのプライバシーを念頭に置いて開発され、Google は可能な限り最小のユーザーの閲覧履歴しか取得しない仕組みになっています。ユーザーが [保護強化機能]（以前の投稿で取り上げました）や [検索とブラウジングを改善する] をオンにしている場合、Chrome はユーザーの保護を強化することのみを目的として、一部の追加データをセーフ ブラウジングと共有します。

この投稿では、Update API の技術的な実装や詳しいプライバシー配慮の仕組みを適宜示しながら、Chrome の Update API の実装方法について説明します。ここで紹介する内容は、セーフ ブラウジングによってどのように保護されているかをユーザーが理解したり、興味があるデベロッパーが実装を参照したりする際に役立つはずです。保護強化機能に使われる API については、今後の投稿で取り上げたいと思います。

インターネット上の脅威

ユーザーがインターネット上のウェブページを開くと、ブラウザがインターネット上のホストに保存されているオブジェクトを取得します。こういったオブジェクトには、ウェブページの構造（HTML）、スタイル設定（CSS）、ブラウザの動的な動作（Javascript）、イメージ、操作によって始まるダウンロード、メインページに埋め込まれた他のウェブページなどがあります。これらはリソースとも呼ばれ、URL（Uniform Resource Locator）と呼ばれるウェブアドレスが割り当てられています。また、URL が読み込まれると、別の URL にリダイレクトされることもあります。そういったそれぞれの URL に、フィッシング サイト、マルウェア、望まないダウンロード、悪意のあるソフトウェア、不正な課金などの脅威が潜んでいる可能性があります。Chrome でセーフ ブラウジングをオンにすると、URL、リダイレクト、インクルードされるリソースのすべてがチェックされるので、そのような脅威を特定してユーザーを保護できます。

セーフ ブラウジング リスト

セーフ ブラウジングは、脅威からユーザーを守るため、インターネット上の脅威のリストを提供します。Chrome が使う完全なリストは、PC プラットフォームから chrome://safe-browsing/#tab-db-manager にアクセスすると参照できます。

リストには安全でないウェブの完全なアドレス（URL とも呼ばれます）は含まれていません。デバイスの限られたメモリにすべてを保持するのは、あまりに高価すぎて不可能だからです。URL は非常に長くなる可能性があるので、暗号ハッシュ関数（SHA-256）によって URL を固定長の一意な文字列にマッピングします。この固有の固定長文字列はハッシュと呼ばれ、これを使って限られたメモリにリストを効率的に格納します。Update API はハッシュ形式でのみ URL を扱うため、この投稿ではハッシュベース API と呼んでもいいでしょう。

さらに、リストには完全なハッシュが保存されているわけでもありません。この方法でも、メモリを使いすぎてしまうからです。実際には、データを Google と共有しない場合やリストが小さい場合を除き、ハッシュのプレフィックスのみを保持しています。ここでは、オリジナルのハッシュを完全ハッシュ、ハッシュのプレフィックスを部分ハッシュと呼びます。

リストは Update API のリクエスト頻度セクションの内容に従って更新されます。失敗のレスポンスを受け取った場合、Chrome はバックオフ モードにも従います。このアップデートは、サーバーが設定したリスト更新レスポンスの最小待機時間に従って、およそ 30 分ごとに行われます。

関連するソースコードに興味がある方のために、閲覧すべき場所をお知らせします。

ソースコード

1. GetListInfos() には、すべてのリストに加えて、関連する脅威の種類、使われているプラットフォーム、ディスク上のファイル名が含まれます。
2. HashPrefixMap はリストの格納方法とメンテナンス方法を示します。二分探索ベースの高速な検索ができるように、リストはプレフィックス長でグループ化されたうえで連結されます。

ハッシュベースの URL 検索の仕組み

セーフ ブラウジング リストの例として、マルウェア用のリストがあるとします。ここには、マルウェアをホストしている URL の部分ハッシュが含まれています。通常、部分ハッシュの長さは 4 バイトですが、説明のため、ここでは 2 バイトのみを表示します。

['036b', '1a02', 'bac8', 'bb90']

ある URL に移動したときなど、Chrome が Update API でリソースの評判を確認するときは、検索をするためにセーフ ブラウジングに未加工の URL（やその一部）を提示することはありません。Chrome は URL（と URL の組み合わせ）の完全ハッシュを使い、ローカルに保持されているセーフ ブラウジング リストの部分ハッシュを検索します。そして、一致した部分ハッシュのみをセーフ ブラウジング サービスに送信します。このようにすることで、Chrome はプライバシーを尊重しながらユーザーを確実に保護します。このハッシュベースの検索は、以下の 3 ステップで行われます。

ステップ 1: URL の組み合わせと完全ハッシュを生成する

Google は、セーフ ブラウジング リストに登録することで、安全でない可能性があるリソースをホストする URL をブロックします。すると、悪意のある人物は、そのリソースを別の URL にホストするかもしれません。または、さまざまなサブドメインを使い回して新しい URL を作るかもしれません。セーフ ブラウジングはホストのサフィックスを使い、サブドメインにマルウェアをホストしている悪意のあるドメインを特定します。同様に、悪意のある人物はさまざまなサブパスも使い回して新しい URL を作るかもしれません。そこで、セーフ ブラウジングはパスのプレフィックスも使って、さまざまなサブパスにマルウェアをホストするウェブサイトを特定します。これにより、悪意のある人物がサブドメインやパスを使い回して悪意のある URL を新たに作ることを防げるので、確実かつ効率的に脅威を特定できます。

ホストのサフィックスとパスのプレフィックスに対応するため、Chrome はまず URL の完全ハッシュと、URL から算出できるいくつかのパターンを計算します。Chrome は、セーフ ブラウジング API の URL とハッシュの仕様に従い、以下の手順によって URL の組み合わせの完全ハッシュを計算します。

1. まず、Chrome は URL を仕様で定義されている正規形に変換します。
2. 次に、その URL に対して最大 5 つのホストのサフィックス / バリアントを生成します。
3. 次に、その URL に対して最大 6 つのパスのプレフィックス / バリアントを生成します。
4. 次に、その 30 個のホストのサフィックスとパスのプレフィックスの組み合わせのそれぞれについて、完全ハッシュを生成します。

ソースコード

1. V4LocalDatabaseManager::CheckBrowseURL はハッシュベースの検索を行う例です。
2. V4ProtocolManagerUtil::UrlToFullHashes は、ある URL に対してさまざまな URL の組み合わせを作成し、それらの完全ハッシュを計算します。

例

たとえば、ユーザーが https://evil.example.com/blah#frag にアクセスしようとしているとします。正規化した URL は、https://evil.example.com/blah です。試すべきホストのサフィックスは evil.example.com と example.com です。パスのプレフィックスは / と /blah です。4 つの URL の組み合わせは、evil.example.com/、evil.example.com/blah、example.com/、example.com/blah です。

url_combinations = ["evil.example.com/", "evil.example.com/blah","example.com/", "example.com/blah"]
full_hashes = ['1a02…28', 'bb90…9f', '7a9e…67', 'bac8…fa']

ステップ 2: ローカルリストで部分ハッシュを検索する

次に Chrome は、URL の組み合わせの完全ハッシュと、ローカルに保持されているセーフ ブラウジング リストを照合します。このリストには部分ハッシュしか含まれていないので、悪意があると決定的に判定することはできません。しかし、URL に悪意がないと考えられるかどうかはすばやく特定できます。URL の完全ハッシュがローカルのリストのどの部分ハッシュとも一致しなければ、URL は安全であると考えられ、Chrome は読み込み処理に進みます。チェックされる URL の 99% 以上がこの手順に従います。

ソースコード

1. V4LocalDatabaseManager::GetPrefixMatches は、URL とその組み合わせの完全ハッシュに一致する部分ハッシュを取得します。

例

3 つの完全ハッシュ 1a02…28、bb90…9f、bac8…fa が、ローカルの部分ハッシュに一致することがわかります。これはデモ目的であり、実際にここで一致が起きることはほとんどありません。

ステップ 3: 一致する完全ハッシュを取得する

次に Chrome は、セーフ ブラウジング サービスの fullHashes.find メソッドに、一致した部分ハッシュのみを送信します（完全な URL や URL の一部、その完全ハッシュは送信しません）。その応答として、すべての悪意のある URL の完全ハッシュが返されます。この完全ハッシュは、Chrome が送信した部分ハッシュのいずれかで始まるものです。Chrome は、取得した完全ハッシュと、URL の組み合わせから生成した完全ハッシュを照合します。一致する場合、その URL は完全ハッシュに対応したさまざまな脅威や重大度を持つ URL であると特定されます。

ソースコード

1. V4GetHashProtocolManager::GetFullHashes は一致した部分ハッシュに対応する完全ハッシュを検索します。

例

Chrome は一致した部分ハッシュ 1a02、bb90、bac8 を送信し、完全ハッシュを取得します。サーバーは部分ハッシュに一致する完全ハッシュとして、1a02…28, bb90…ce, と bac8…01 を返します。完全ハッシュの 1 つがチェック対象の URL の組み合わせの完全ハッシュと一致するので、Chrome はこの URL がマルウェアをホストする悪意のある URL であると特定します。

まとめ

セーフ ブラウジングは、インターネット上のさまざまな悪意や脅威から Chrome ユーザーを守ります。これらの保護を提供する一方で、Chrome はメモリ容量の制約、ネットワーク帯域幅の使用量、ダイナミックな脅威の状況といった課題に直面します。さらに、ユーザーのプライバシーの選択にも配慮し、Google と共有するデータを可能な限り少なくしています。

今後の投稿では、Chrome が [保護強化機能] をオンにしたユーザーに提供する高度な保護について説明したいと思います。