Chrome

この記事は Chromium Blog の記事 “Chrome 95 Beta: Secure Payment Confirmation, WebAssembly Exception Handling and More” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

オリジン トライアル

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

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

File System Access API のアクセス ハンドル

私たちの最終的な目的は、File System Access API のオリジン プライベートなファイル システムと Storage Foundation API を統合し、ブラウザからファイルベースのストレージにアクセスする際のエントリ ポイントの数を減らすことです。その目的に向かう最初の一歩となるのが、新たに提案されたアクセス ハンドルです。この新機能は、ファイルのコンテンツに対してインプレースで排他的な書き込みアクセスを提供できる点で、既存の機能とは異なります。この変更は、フラッシュされていない更新を整合性のとれた形で読み取る機能や、専用ワーカーで同期的に同じ処理をする機能とともに、パフォーマンスを大幅に向上し新たなユースケースの可能性を開くものとなります。このオリジン トライアルに参加したい方は、Chrome オリジン トライアルのエントリをご覧ください。アクセス ハンドラの詳細については、File System Access API: ローカル ファイルへのアクセスを簡素化するに追加されている情報をご覧ください。

ユーザー エージェント文字列情報の削減

Chrome では、HTTP リクエストでユーザー エージェント文字列によって公開される情報量の削減を試行しています。navigator.userAgent、navigator.appVersion、navigator.platform についても、同様の削減をします。ユーザー エージェント文字列は、パッシブなユーザー フィンガープリンティングに使われる可能性があります。このオリジン トライアルに参加したい方は、Chrome オリジン トライアルのエントリをご覧ください。

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

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

Secure Payment Confirmation

Secure Payment Confirmation は、Web Authentication API を利用して、ウェブで支払いをする際の認証操作を拡張します。この機能によって、上記の API に新しい ‘payment’ 拡張機能が追加され、銀行などのリライング パーティが PublicKeyCredential の作成にオプトインできるようになります。販売元は、Payment Request API によるオンライン決済の一部として、支払い方法 'secure-payment-confirmation' を使ってこの認証情報を照会できます。

この機能により、プラットフォーム認証機能によるスムーズで一貫性のある認証操作を実現できます。欧州連合をはじめとする多くの地域では、ユーザーの銀行による強力な認証がオンライン決済の要件になりつつあります。この機能提案により、ユーザー エクスペリエンスが向上し、既存のソリューションよりもセキュリティが強化されます。

WebAssembly の例外ハンドリング

WebAssembly が例外ハンドリングをサポートするようになりました。例外ハンドリングを利用すると、コードで例外がスローされたときに制御フローを抜けることができます。例外は、WebAssembly モジュールの既知の例外でも、インポートされて呼び出された関数がスローした未知の例外でも構いません。

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

PerformanceObserver のコールバックに droppedEntriesCount を追加

現在、ウェブ デベロッパーは PerformanceObserver.observe() を呼び出す際に buffered オプションを使って、サイトについての過去や未来のパフォーマンス エントリをリスニングできます。ただし、過去のエントリは保存する必要があり、バッファサイズには限界があります。droppedEntriesCount パラメータを使うと、ストレージが一杯であるため失われたエントリがあるかどうかを知ることができます。

droppedEntriesCount プロパティは、PerformanceObserver コンストラクタに渡されるコールバックの 3 つ目のパラメータとして指定されるオプションのうちの 1 つです。ここから、バッファが一杯になったことで破棄されたエントリの数がわかります。

EyeDropper API

EyeDropper API は、ブラウザによるスポイト機能を提供します。これは、カスタムのカラー選択ツールを作るときに利用できます。ウェブ向けのクリエイティブ アプリケーションでは、画面上のピクセルの色をサンプルとして取得できる機能があれば、その恩恵を受けることができます。この機能は、PowerPoint などの多くの OS のアプリケーションに搭載されていますが、ウェブでは実現できません。

一部のブラウザの <input type=color> 要素にはスポイト機能が組み込まれていましたが、通常、スポイト機能は <input> 要素が呼び出すカスタマイズできないポップアップを通してしか利用できないので、これをウェブ アプリケーションのカスタムのカラー選択ツールに組み込むには制限がありました。

User-Agent Client-Hint 用の Windows における新しい UA Platform Version ソース

Windows の Chrome で Sec-CH-UA-Platform-Version の値を更新し、サイトが有意義な Windows プラットフォームの変更を識別できる程度の情報を提供します。これにより、サイトは、オペレーティング システムのバージョンに固有のバイナリ実行ファイルやヘルプ コンテンツを提供できます。現在のユーザー エージェント文字列と既存の Sec-CH-UA-Platform-Version 実装では、Windows コンポーネントのメジャー バージョンとマイナー バージョンが提供されています。しかし、Windows 10 時点で、重要なリリースが行われても通常はどちらの数値も増加しないようになっています。なお、Windows 11 ではどちらの数値も増加しません。数値と Windows リリースとの対応表は、UA Client-Hint のリポジトリの Issue 220 で確認できます。

self.reportError()

この関数は、ウィンドウとワーカーで利用できます。デベロッパーがこの関数を使うと、キャッチされない JavaScript 例外と同じように、コンソールやグローバルの「error」イベント ハンドラにエラーを報告できます。これは主に、カスタムのイベント ディスパッチ ライブラリやコールバック操作ライブラリで便利です。
この機能により、ライブラリ デベロッパーはブラウザと同じように例外を報告できるようになります。これは、コールバックの実行をカスタム制御する必要がある場合に便利です。

URLPattern

URLPattern は新しいウェブ API で、与えられたパターン文字列と URL をマッチングする機能をオペレーティング システムでサポートします。JavaScript で直接使うことも、サービス ワーカーのスコープなどの別のウェブ プラットフォーム API にパターンを渡して使うこともできます。URL とのマッチングは、ウェブプラットフォーム機能と JavaScript アプリケーションの両方で頻繁に必要になります。利用例として、ウェブ プラットフォームのサービス ワーカーのスコープや、JavaScript フレームワークでの URL ルーティングなどが挙げられます。これまでのウェブ プラットフォーム機能では、それぞれが独自の URL マッチング メカニズムを作成していました。JavaScript では、path-to-regexp などのライブラリを利用していました。

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

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

FTP サポートの削除

Chrome で、FTP URL のサポートを削除します。ブラウザからの FTP の利用率は低く、既存の FTP クライアント機能の改善に注力するのは現実的ではありません。また、影響するすべてのプラットフォームで、機能の豊富な FTP クライアントが利用できます。

Google Chrome 72 以降では、FTP によるドキュメント サブリソースのフェッチと、トップレベル FTP リソースのレンダリングのサポートが削除されています。現在、FTP URL を開くと、リソースの種類によって、ディレクトリ一覧またはダウンロードが表示されます。Google Chrome 74 以降のバグにより、HTTP プロキシを経由した FTP URL へのアクセスがサポートされなくなっています。FTP のプロキシ サポートは、Google Chrome 76 で完全に削除されました。Chrome 86 では、FTP のサポートがプレリリース チャンネル（カナリア版とベータ版）で無効になり、安定版のユーザーの 1% でも試験的に無効化されましたが、コマンドラインから再有効化できました。Chrome 87 では 50% のユーザーで無効になりましたが、ここでもコマンドラインから有効化できました。Chrome 88 以降ではデプリケーション トライアルでのみ利用でき、現在は無効になっています。

数値で終了する IPv4 以外のホスト名の URL のサポート

数値で終了し、有効な IPv4 アドレスではないホスト名のほとんどは、有効なホスト名として扱われ、DNS のルックアップが行われます（たとえば、http://foo.127.1/ など）。Public Suffix List 仕様によると、この URL のホスト名の eTLD+1 は 127.1 です。これが URL として指定されると、http://127.1/ は URL 仕様によって http://127.0.0.1/ にマッピングされます。これは潜在的に危険です。127.0.0.0.1 も、ユーザーを混乱させるために使われる可能性があります。今後、こういったホスト名を含む URL は、拒否されるようになります。

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

Chrome では、エージェント クラスタが長期的にオリジンにスコープできるように、クロスオリジンでありながら同一サイト環境であるサイト間での WebAssembly モジュールの共有が非推奨となります。

U2F API（Cryptotoken）のサポート終了

セキュリティ キーを操作するための Chrome の以前の U2F API が非推奨となり、Chrome 95 でデプリケーション トライアル（オリジンを指定してサポートの終了を延期できるオプトイン機能）が開始されます。この API はデフォルトで有効なまま残されますが、トライアルに参加したサイトでは、トライアル トークンによって鍵が無効化されます。U2F セキュリティ鍵自体は非推奨ではなく、今後も動作し続けます。

影響を受けるサイトは、Web Authentication API に移行する必要があります。もともと U2F API で登録された認証情報は、Web Authentication 経由でチャレンジできます。U2F API でサポートされる USB セキュリティ キーも、Web Authentication API のサポート対象です。

U2F は Chrome オリジナルのセキュリティ キー API で、フィッシングに強い 2 要素認証システムを構築するため、サイトから USB セキュリティ キーに公開鍵認証情報を登録し、チャレンジできるようにします。U2F はオープンなウェブ標準になることはなく、Web Authentication API（Chrome 67 でリリース）に取り込まれました。Chrome は FIDO U2F JavaScript API を直接サポートすることはありませんでしたが、同等の機能を持つ chrome.runtime.sendMessage() メソッドを提供する Cryptotoken と呼ばれるコンポーネント拡張機能を公開しました。U2F と Cryptotoken はメンテナンス モードに入っており、サイトにはここ 2 年間にわたって Web Authentication API への移行が推奨されてきました。

以下のスケジュールは、現時点でのサポート終了と削除の予定です。

Chrome 93

2021 年 8 月 31 日の時点で安定版です。googleLegacyAppIdSupport 拡張機能のサポートが追加されました。

Chrome 95

2021 年 9 月 23 日の時点でベータ版です。次の変更が実装されました。

• ユーザー許可プロンプトによって U2F API リクエストへのアクセスを制限
• リクエストのたびに DevTools コンソールにサポート終了の通知を記録

Chrome 98

2022 年 1 月初旬にベータ版、2 月に安定版となる予定です。デプリケーション トライアルは継続しますが、動作は逆転します。すなわち、デフォルトで API が無効化されますが、トライアル参加者は継続利用することもできます。

Chrome 103

Chrome 104

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

headless 曰く、Googleは 23 日、Chrome 拡張機能プラットフォームの Manifest V2 終息と Manifest V3 移行タイムラインを公開した (Chrome Developers のブログ記事、 Manifest V2 support timeline、 9to5Google の記事)。

Manifest V3 は Chrome 拡張の信頼性向上を目指して 2018 年に発表された。コンテンツブロッカーの動作が制限されるとして反対の声も出ていたが、その後制限はある…

“2021 Is the Year of Linux on the Desktop,” writes PC Magazine. “No, really…”

Walk into any school now, and you’ll see millions of Linux machines. They’re called Chromebooks. For a free project launched 30 years ago today by one man in his spare tim…

headless 曰く、Google は 14 日、Chrome の User Agent (UA) 文字列情報削減に向け、より具体的なスケジュールとオリジントライアルの詳細を発表した (Chromium Blog の記事、 Chrome Developers のブログ記事)。

Google が昨年 1 月に発表した UA 文字列情報削減計画は COVID-19 の影響で 2021 年以降に先送りされていた。Google は 5 月に再開を発表し、7 段階に分けて計画を進める計画を示したが、Chr…

この記事は Chromium Blog の記事 “Chrome 94 Beta: WebCodecs, WebGPU, Scheduling, and More” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

WebCodecs

既存のメディア API（HTMLMediaElement、Media Source Extensions、WebAudio、MediaRecorder、WebRTC）は高レベルで、特定の用途に特化しています。低レベルのコーデック API は、遅延の影響を受けやすいゲームのストリーミング、クライアント側のエフェクトやコード変換、ポリフィル対応のメディア コンテナのサポートなど、新たな用途に適しています。JavaScript や WebAssembly によるコーデック実装のように、ネットワークや CPU のコストが増加することはありません。

WebCodecs API は、すでにブラウザに組み込まれているメディア コンポーネントをプログラマーが利用できるようにすることで、このような不足を解消します。具体的には、次のような内容です。

• 動画やオーディオのデコーダ
• 動画やオーディオのエンコーダ
• 未加工動画フレーム
• イメージ デコーダ

この機能は Chrome 93 でオリジン トライアルを終えており、現在はデフォルトで有効です。詳しくは、WebCodecs による動画処理をご覧ください。

WebGPU

WebGPU API は、ウェブ用の WebGL と WebGL2 グラフィックス API の後継です。「GPU コンピュート」などの最新機能や、GPU ハードウェアへの低オーバヘッド アクセス、パフォーマンスや予測可能性の向上などが導入されています。既存の WebGL インターフェースはイメージの描画用に設計されたもので、かなりの労力をかけなければ他の用途の計算は行えませんでしたが、その点が改善されています。

WebGPU は、Direct3D 12、Metal、Vulkan といった最新のコンピュータ グラフィックス機能を公開し、グラフィックス プロセッシング ユニット（GPU）で行われるレンダリングや計算の操作をします。以前のテクノロジーと比べた場合の WebGPU の利点は以下のとおりです。

• リソース管理、作業準備、GPU への送信を分割
• OS の API と同じように動作するパイプライン状態
• グラフィックス ドライバがレンダリング前に必要な準備をするためのバインディング グループ

この機能は、Chrome 99 での導入を目指して、Chrome 94 からオリジン トライアルが始まります。詳しくは、WebGPU で最新の GPU 機能にアクセスするをご覧ください。

Scheduling API: scheduler.postTask() による優先順位付け

ユーザーの操作に的確に応答し、時間が経っても応答性が低下しないウェブアプリを構築するのは困難です。応答性を阻害する主な原因の 1 つがスクリプトです。インクリメンタル サーチ機能について考えてみてください。この機能を搭載したアプリは、ユーザーの入力に追いつきつつ、結果をフェッチして表示する必要があります。その際、アニメーションなど、ページで起きていることは考慮されませんが、アニメーションはスムーズにレンダリングする必要があります。

通常この問題には、メインスレッドの作業を分割してスケジュールすることで対処できます。具体的には、適切なタイミングで作業を非同期的に実行します。しかし、このアプローチ自体にも問題があります。たとえば、デベロッパーがどのように優先度を設定しようと、メインスレッドでは時間の奪い合いが生じています。メインスレッドはデベロッパーが設定した優先度を認識しないだけでなく、fetch() 操作やガベージ コレクションといったブラウザのタスクも行っているからです。

scheduler.postTask() メソッドを使うと、デベロッパーが OS のブラウザのスケジューラで 3 段階の優先度（user-blocking、user-visible、background）を指定してタスク（JavaScript のコールバック）をスケジュールできるようになるので、このスケジュールのジレンマを解消できます。また、動的にタスクをキャンセルしたり、優先度を変更したりできる TaskController インターフェースも公開されます。

この機能は Chrome 93 でオリジン トライアルを終えており、現在の Chrome ではデフォルトで有効です。その他の新しいオリジン トライアルや完了したオリジン トライアルの一覧については、以下のオリジン トライアルのセクションをご覧ください。

オリジン トライアル

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

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

ナビゲーションの Early Hints

Chrome では、新しい HTTP ステータス コードである 103 Early Hints のテストが行われています。これは、早い段階でサブリソースをプリロードするためのものです。
<link rel=preload> などの link ヘッダーを含む 103 レスポンスを受け取ると、Chromium は最終的なレスポンスを受け取る前に、指定されたリソースのプリロード（またはプリコネクトやプリフェッチ、あるいはそのすべて）を試みます。ウェブ デベロッパーはこの方法を使って、アプリやサイト、ページを最適化できます。

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

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

描画キャンバスのカラー マネジメント

このアップデートにより、CanvasRenderingContext2D オブジェクトと ImageData オブジェクトのデフォルトのカラースペースが sRGB であることが正式に明文化されます。そのため、CanvasRenderingContext2D インターフェースが完全にカラー マネジメントされる（すべての入力が描画キャンバスのカラースペースに変換される）ことが明確になります。これまでは、上記の動作は慣習上のものであり、明文化はされていませんでした。今回のアップデートで、以下の点が変更されます。

• CanvasRenderingContext2D オブジェクトや ImageData オブジェクトを作成する際に、sRGB 以外のカラースペースを指定するパラメータが追加されます。
• そのパラメータで利用できる Display P3 カラースペースのサポートが追加されます。

現在、CanvasRenderingContext2D で表示されるコンテンツは、sRGB カラースペースに限定されていますが、このカラースペースには最新のディスプレイやカメラほどの機能はありません。今回の機能で、Display P3 カラースペースを使用する CanvasRenderingContext2D オブジェクトを作成できるようになります。さらに、CanvasRenderingContext2D の色の動作に関して、いくつかの曖昧だった点が明確になります。

VirtualKeyboard API

VirtualKeyboard インターフェースには、仮想キーボードの表示や非表示のタイミングをコントロールするメソッドやプロパティが含まれています。また、仮想キーボードがページのコンテンツを遮ると、仮想キーボードのサイズを含むイベントが発行されます。仮想キーボードは画面に表示されるキーボードで、ハードウェア キーボードが利用できない場合の入力に使います。

ハードウェア キーボードとは異なり、仮想キーボードは想定される入力に合わせて形状を変えることができます。デベロッパーは、inputmode 属性によって仮想キーボードの表示形状をコントロールできますが、仮想キーボードの表示や非表示のタイミングのコントロールには制限がありました。

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

CSS

transform-style: preserve-3d と perspective プロパティが仕様に準拠

transform-style: preserve-3d と perspective プロパティが仕様に準拠します。preserve-3d プロパティを使うと、子要素を親の 3D シーンに追加できます。また、perspective プロパティは子要素に透視変換を適用します。この変更が行われる前の Chromium は、両方の効果を DOM ツリーではなく内包するブロック階層に基づいて適用し、変換関連のプロパティがない要素にも効果を拡張できるようになっていました。

flex-basis がキーワード ‘content’ と ‘min/max/fit-content’ を反映

Chrome は、flex-basis プロパティと flex 省略記法の値として、キーワード content、min-content、max-content、fit-content をサポートします。content キーワードを使うと、flex-basis と優先されるサイズ プロパティ（width または height）の両方が auto である場合のように、flex のベースサイズがデフォルトのサイズ計算ルールを使用します。flex-basis が auto の場合、メインの軸の長さとして指定された width や height は、すべて無視されます。その他のキーワードは通常と同じで、flex のベースサイズを細かく指定できます。

これまでは、レスポンシブ レイアウトでコンテナに対して display:flex を追加または削除する場合、個々の項目で値を追加または削除しなければならない場合がありました。content の導入により、それが不要になることもあります。

scrollbar-gutter

scrollbar-gutter プロパティは、スクロールバーのガター（スクロールバーを表示するために予約されている領域）の有無をコントロールします。これにより、コンテンツが増加した場合にレイアウトが変わることを防ぎつつ、スクロールが不要な場合に余分な領域が表示されないようにすることができます。

スクロールバーの有無自体は、overflow プロパティによって決まる点に注意してください。従来型のスクロールバーを使うかオーバーレイ スクロールバーを使うかを決めるのは、ユーザー エージェントです。デベロッパーは、このプロパティを使うことで、ブラウザが提供するスクロールバーとレイアウトとの相互作用を細かくコントロールできます。

MediaStreamTrack Insertable Streams（別名 Breakout Box）

この API を使うと、MediaStreamTracks によってローメディアを操作できます。操作できるのは、カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力などです。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。サンプルのユースケースとして、おかしな帽子、物体のリアルタイム検出や注釈付けがあります。

navigator.plugins と navigator.mimeTypes が固定のリストを返却

Flash が削除されたことで、navigator.plugins と navigator.mimeTypes から何かを返す必要はなくなりました。この API は、主に以下の目的で使われていました。

• Flash プレイヤー サポートの確認
• フィンガープリンティング

この API を使って PDF ビューアのサポートを確認しているサイトもあります。今回の変更により、この配列は PDF ビューア プラグインの標準リストを含む固定のリストを返すようになります。

これによって API が削除または変更されることはありません。2 つの既存 API で固定の配列が返されるようになるだけです。

JavaScript

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

Self Profiling API

Chrome がウェブ公開サンプリング プロファイラをサポートし、クライアント JavaScript の実行時間を計測できるようになります。実際のユーザーから JavaScript のプロファイルを収集すると、パフォーマンスの低下が観測された場合のデバッグに役立てることができます。面倒な手動インストルメンテーションをする必要はありません。

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

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

サードパーティ コンテキストでの WebSQL のサポート終了と削除

サードパーティ コンテキストでの WebSQL が非推奨となります。この機能の削除は、Chrome 97 で行われる予定です。Web SQL Database 標準が最初に提案されたのは 2009 年 4 月で、2010 年 11 月に検討が中止されました。Gecko はこの機能を実装しておらず、WebKit では 2019 年に非推奨となりました。W3C は、代替手段として Web Storage や Indexed Database を推奨しています。

デベロッパーは、WebSQL 自体が非推奨であり、利用率が十分低くなった際に削除される予定であることを想定する必要があります。

サブリソースのプライベート ネットワーク リクエストをセキュア コンテキストに制限

サブリソースのプライベート ネットワーク リクエストは、セキュア コンテキストからのみ開始できます。プライベート ネットワーク リクエストとは、パブリック ネットワークで開始され、プライベート ネットワークを対象とするリクエストです。これには、インターネットから イントラネット へのリクエストや、イントラネット ループバックなどが含まれます。

今回の対応は、プライベート ネットワーク アクセスの完全実装に向けた最初の一歩です。ローカル ネットワーク内やユーザーのデバイス上で実行されているサーバーは、ウェブに充実した機能を公開しますが、これは危険な場合もあります。プライベート ネットワーク アクセスで提唱されている一連の変更は、サーバーに外部エンティティとの通信をオプトインさせることで、このようなサーバーへのリクエストによる影響を制限します。

このオプトインが意味を持つためには、クライアントのオリジンが認証されていることをサーバーが確認できなければなりません。これを実現するため、セキュア コンテキストのみに外部リクエストの実行を許可します。

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