特に記載のない限り、下記の変更は 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 の仕様変更に従ったもので、プラットフォームにも影響します。

この記事は Google マップ、Google Maps Platform プロダクト マネージャー Alicia Sullivan による Google Cloud Blog の記事 " New Cloud-based maps styling features provide more options, control, and flexibility to enhance your user experience" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年の Google I/O にて、Google は Maps JavaScript API 向けクラウドベースのマップスタイル設定の一般提供を発表しました。この度 Google は、クラウドベースのマップスタイル設定の新機能を発表いたします。この新機能は選択肢の幅を広げ、制御性を高め、ユーザーに優れたエクスペリエンスを提供します。その新機能とは、ランドマークとビルディング フットプリント（建物の外形情報）の 2 つです。ウェブ版とアプリ版の一般向け Google マップをご利用の方はこれらの機能をすでにご存知かもしれません。また、業界別に最適化された地図スタイルの新バージョンもリリースします。新しいバージョンではより細やかな設定が設定できるようになると同時に柔軟性が向上し、優れたエクスペリエンスを実現します。それでは詳細を見てみましょう。

ランドマークの表示によりすばやく現在地を把握することが可能に

ウェブ版とアプリ版の一般向け Google マップをご利用の方は、主要なスポットが強調表示されていることにお気づきかもしれません。このランドマークは、ユーザーが自身の現在地を確認し、探索中または訪問中の都市でどのように移動すればよいかを決定するための目印として役立ちます。

サンパウロ（左）とローマ（右）のランドマーク

このたび、クラウドベースのマップスタイル設定を使用して地図を作成することで、一般向け Google マップと同じエクスペリエンスをユーザーに提供できるようになりました。この機能は、ニューヨーク、ドバイ、パリ、ムンバイ、シンガポールなど、世界中の 100 の都市で利用可能です。地図にランドマークを表示するには、Cloud Console にログインし、スタイル エディタで [Points of interest] の機能タイプに移動して、[Marker Style] で [Illustrated] を選択します。

ビルディング フットプリントへの切り替えで地図機能をシンプルに

場合によっては、シンプルな地図のほうが便利なときもあります。高い建物が密集している都市では、高い建物を 3D で表示するとユーザーにはわかりづらくなる場合があります。そのため、建物の 3D 表示の他に、スタイル エディタのオプションとしてビルディング フットプリント機能を追加しました。ビルディング フットプリントにより、基本的な地図のバランスや構成が大きく変更されるため、建物が 3D 表示された複雑な地図を必要としないユースケースにも対応できます。

ビルディング フットプリント

スタイル エディタのメニューで [Landscape] から [Human-made] を選択し、ビルディング フットプリントを有効にした地図。

業界別に最適化された地図のスタイルでは、ランドマークとビルディング フットプリントに加えて詳細なストリート マップも使用可能

Google は今年の 1 月、旅行、不動産、小売、ロジスティクス業界向けに最適化された地図のスタイルの提供を開始しました。これによりお客様は、クラウドベースのマップスタイル設定を通じて、事前設定されたスタイル付き地図が利用できるようになりました。ランドマークは業界別に最適化されたすべてのスタイル付き地図で使用でき、ビルディング フットプリントは旅行業界向けのスタイル付き地図のみで使用できます。業界別に最適化されたスタイル付き地図をすでに利用している場合、それらの新機能は地図に自動で適用されるため、追加操作は不要です。この変更を無効にしたい場合は、スタイル エディタで機能をオフにします。

また、業界別に最適化された地図のスタイルに限定されますが、詳細なストリート マップが利用可能になります。この機能は、2020 年 8 月に Google I/O で発表したウェブ版とアプリ版の一般向け Google マップの新しい機能ですでにご覧になっているかもしれません。詳細なストリート マップは、現在サンフランシスコ、ニューヨーク、ロンドン、東京で使用できますが、2021 年の終わりまでに新たに 50 都市をサポートをする予定です。

詳細なストリート マップは、業界別に最適化された地図の全スタイルでデフォルトで有効になります。この表示設定は、新たに作成された設定メニューから必要に応じて変更できます。将来的に、すべてのクラウドベースのマップスタイル設定に、詳細なストリート マップ機能を完全導入できるようこの取り組みを続けています。

ランドマークとビルディング フットプリントおよび業界別に最適化された地図のスタイルの新バージョンは、Google Cloud Console 内のクラウドベースのマップスタイル設定からご利用いただけます。利用料金は Google Maps Platform の料金に含まれています。ランドマーク、ビルディング フットプリント、業界別に最適化された地図スタイルの使用方法については、開発者ドキュメントをご参照ください。また、クラウドベースのマップスタイル設定を開始するには、JavaScript のドキュメントをご覧ください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

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 から手動でサイト分離をオプトインすることもできます。これにより、すべてのウェブサイトが分離されるようになりますが、メモリの消費量は増加します。

この記事は Product Manager, Google Maps Platform の Yaron Fidler と Product Manager, Google Maps Transportation の Johann Lau による Google Maps Platform Blog の記事 "Elevate customer and driver experiences with improved accuracy, reliability, and travel modes" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年、Google は新たにオンデマンド配車および配達ソリューションをリリースしました。このサービスは、企業のオペレーション改善を助けることに加え、予約から配車・配達までのカスタマージャーニーを、ドライバーとお客様双方にとって変革することを目的としています。オンデマンド配車と配達において、時間はきわめて重要です。ユーザーが配車の予約やフード デリバリーの注文をする際には、シームレスなエクスペリエンスとリアルタイムの情報更新が求められます。現在 Google は、位置情報、時刻、距離の精度、並びにバイクルートのデータ品質の改善に注力しています。

フィッシング検知

効率の改善

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

高速化の成果