ユーザーはウェブをブラウジングするときに、さまざまな脅威に遭遇します。誤認させるサイトや偽物のサイトにパスワードなどのプライベートな情報を入力するように欺かれる場合があり、これはフィッシングとも呼ばれます。マルウェアと呼ばれる悪意のあるソフトウェアをインストールさせられ、個人データを収集されたり、身代金を要求されたりすることもあります。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 が [保護強化機能] をオンにしたユーザーに提供する高度な保護について説明したいと思います。

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

Custom Highlight API

Custom Highlight API は、疑似要素のハイライトという概念を拡張します。具体的には、ユーザー エージェントで定義される ::selection、::inactive-selection、::spelling-error、::grammar-error に限定されることなく、任意の範囲のテキストのスタイルを設定できるようにします。この仕組みは、独自の選択を実装する編集フレームワーク、仮想ドキュメントのページ内検索、オンライン コラボレーションを表す複数選択、スペルチェック フレームワークなど、さまざまな状況に活用できます。

この機能がない場合、ウェブ デベロッパーやフレームワーク作成者は、ベースとなる DOM ツリー構造を変更しないと希望のレンダリング効果を実現できません。希望するハイライト効果が複数のサブツリーにまたがる場合、このような操作は複雑になり、ハイライトの変化に合わせて DOM を更新しなければならなくなります。Custom Highlight API を使うと、プログラムからハイライトを追加したり削除したりできるようになります。ベースとなる DOM 構造に影響を与えることはなく、範囲オブジェクトに基づいてテキストにスタイルを適用します。

105 では、color と background-color 疑似要素のみがサポートされます。他の項目のサポートは、今後のバージョンで追加される予定です。

コンテナクエリ

コンテナクエリを使うと、コンテナ要素のサイズに応じて要素のスタイルを設定できます。これは、コンポーネントが独自のレスポンシブなスタイル設定ロジックを持てることを意味します。つまり、コンポーネントがページのどこに表示されてもスタイル設定ロジックが付属することになるので、コンポーネントの柔軟性が大きく向上します。

コンテナクエリはメディアクエリに似ていますが、ビューポートのサイズではなく、コンテナのサイズに対して評価されます。既知の問題として、複数列レイアウトでテーブル レイアウトと組み合わせると、コンテナクエリが動作しなくなることが挙げられます。この点は 106 で修正する予定です。詳細については、@container と :has(): 2 つの新レスポンシブ API をご覧ください。今回のリリースのその他の CSS 機能については、以下をご覧ください。

:has() 疑似クラス

:has() 疑似クラスは、引数で渡された相対セレクタに少なくとも 1 つの要素が一致する要素を指定します。他のセレクタとは異なり、:has() 疑似クラスは、特定の要素に先行する要素（兄弟、先祖、先行する兄弟や先祖）にスタイルルールを適用します。たとえば、次のルールは子にイメージタグがあるアンカータグにのみ一致します。

a:has(> img)

詳細については、@container と :has(): 2 つの新レスポンシブ API をご覧ください。今回のリリースのその他の CSS 機能については、以下をご覧ください。

フェッチ アップロード ストリーミング

フェッチ アップロード ストリーミングを使うと、ウェブ デベロッパーは ReadableStream ボディによるフェッチを行えます。これまでは、ボディ全体の準備ができてからでないとリクエストを開始できませんでした。しかし今後は、コンテンツの生成中でもデータの送信を開始できるので、パフォーマンスとメモリ使用量が改善します。

たとえばオンライン フォームでは、ユーザーがテキスト入力フィールドにフォーカスを当てると同時にフェッチを開始できます。ユーザーが Enter をクリックする頃には、fetch() ヘッダーが送られているはずです。この機能を使うと、クライアントでオーディオや動画などのコンテンツを生成すると同時に送信することもできます。詳細については、フェッチ API によるストリーミング リクエストをご覧ください。

インストールした PC ウェブアプリ向けのウィンドウ コントロール オーバーレイ

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

オリジン トライアル

このバージョンの Chrome で開始されるオリジン トライアルはありません。ただし、たくさんのオリジン トライアルが継続されており、その内容は Chrome オリジン トライアル ダッシュボードから確認できます。オリジン トライアルとして新機能を試して、ユーザビリティ、実用性、有効性についてのフィードバックをウェブ標準コミュニティに提供することができます。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

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

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

ワーカーの Media Source Extensions

Media Source Extensions（MSE）API は、DedicatedWorker コンテキストから利用できるようになっています。これにより、メイン Window コンテキストで HTMLMediaElement が再生用にメディアをバッファリングする操作のパフォーマンスが向上しています。アプリケーションが DedicatedWorker で MediaSource オブジェクトを作成すると、そこから MediaSourceHandle を取得し、postMessage() を呼び出してメインスレッドに転送し、HTMLMediaElement にアタッチできます。すると、MediaSource オブジェクトを作成したコンテキストからメディアをバッファリングできます。

Viewport-Height クライアント ヒント

Chrome が新しい Sec-CH-Viewport-Height クライアント ヒントをサポートします。これは、以前に Chrome に導入された Sec-CH-Viewport-Width と対になる機能です。これらを合わせると、ビューポートのサイズ情報をオリジンに伝えることができます。このヒントを使うには、Accept-CH ヘッダーに Sec-CH-Viewport-Height または Sec-CH-Viewport-Width を渡します。

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

マルチスクリーン ウィンドウ配置用の正確な画面ラベル

今回のリリースでは、Multi-Screen Window Placement API が提供する画面ラベル文字列が拡張されています。具体的には、ScreenDetailed.label プロパティが改善され、以前のプレースホルダがデバイスの Extended Display Identification Data（EDID）または高水準のオペレーティング システム API からの情報に置き換えられています。たとえば、ラベル プロパティで "External Display 1" ではなく、"HP z27n" や "Built-in Retina Display" などが返されるようになります。こういった正確なラベルは、オペレーティング システムのディスプレイ設定ダイアログ ボックスに表示される内容と一致します。このラベルは、ユーザーが "window-placement" パーミッションを与えたサイトのみに公開されます。

CSS: 固定要素のオーバースクロール効果の防止

要素の position CSS プロパティを fixed に設定すると（その要素を包含するブロックがルートである場合を除きます）、overscroll-behavior で指定された効果が無効になります。特に、fixed-position 要素がオーバースクロール効果によって移動することはなくなります。

DisplayMediaStreamConstraints.systemAudio

MediaDevices.getDisplayMedia() に、ユーザーにシステム オーディオを提供するかどうかを示す新しい制約が追加されます。ユーザー エージェントが、動画と合わせてオーディオのキャプチャを提供する場合もあります。しかし、すべてのオーディオが同じように作成されるわけではありません。ビデオ会議アプリケーションについて考えてみてください。タブのオーディオは便利な機能であり、リモート参加者と共有することがよくあります。しかし、システム オーディオには参加者自身のオーディオが含まれており、共有するのは適切でないかもしれません。この新しい制約を使うには、制約として systemAudio を渡します。次に例を示します。

const stream = await navigator.mediaDevices.getDisplayMedia({
  video: true,
  audio: true,
  systemAudio: "exclude"  // or "include"
});

この機能はパソコン版でのみサポートされます。

TransformStreamDefaultController の公開

仕様に準拠するため、TransformStreamDefaultController クラスがグローバル スコープで利用できるようになります。このクラスはすでに存在しており、次のようなコードでアクセスできます。

let TransformStreamDefaultController;
new TransformStream({ start(c) { TransformStreamDefaultController = c.constructor; } });

今回の変更により、TransformStreamDefaultController がグローバル スコープから利用できるようになるので、上記のようなコードは不要になります。このクラスは、モンキーパッチによって TransformStreamDefaultController.prototype にプロパティを追加したり、その既存プロパティの機能テストを簡単にしたりするために利用できます。このクラスを作成することはできません。つまり、次のコードはエラーをスローします。

new TransformStreamDefaultController()

HTML Sanitizer API

HTML Sanitizer API は、便利で安全な方法によって、任意のユーザー提供コンテンツから実行可能コードを削除します。この API の目的は、クロスサイト スクリプティング脆弱性のないウェブ アプリケーションを簡単に作れるようにし、そのようなアプリのメンテナンス負荷の一部をプラットフォームに移すことです。

今回のリリースでは、基本機能の Element.setHTML() のみがサポートされます。Sanitize インターフェースは、今後の段階で追加される予定です。サポートされるのは HTML のみで、名前空間付きコンテンツ（SVG + MathML）はまだサポートされません。この API の詳細は、HTML Sanitizer API - Web APIs をご覧ください。

import.meta.resolve()

import.meta.resolve() メソッド は、現在のスクリプトのコンテキストで渡された指定子が解決される URL を返します。つまり、import() を呼び出した場合にインポートされる URL を返します。指定子とは、有効なスキームまたは /、./、../ のいずれかで始まる URL です。サンプルは HTML 仕様をご覧ください。

このメソッドを使うと、厳密なロケーションやウェブ アプリケーションのモジュール設定にこだわらないスクリプトの記述が簡単になります。この機能のいくつかは現在でも利用できますが、new URL() と既存の import.meta.url() メソッドを組み合わせるという長い形式が必要です。しかし、インポート マップとの統合により、インポート マップの影響を受ける URL を解決できるようになります。

Navigation API の改善

Chrome 105 では、Navigation API（102 で導入）の NavigateEvent に 2 つの新しいメソッドが導入され、実用性に問題があったメソッドが改善されます。intercept() は、ナビゲーションに続く状態をデベロッパーが制御できるようにするもので、使うのが難しかった transitionWhile() の代わりとなります。scroll() メソッドは、URL で指定されたアンカーにスクロールするもので、すべてのナビゲーションの種類には対応していなかった restoreScroll() の代わりになります。既存のメソッドの問題の説明や、新しいメソッドの使用例については、NavigateEvent の変更点をご覧ください。

transitionWhile() メソッドと restoreScroll() メソッドはこのリリースで非推奨になり、108 で削除される予定です。以下に記載されている今回のリリースでのその他のサポート終了と機能の削除をご覧ください。

onbeforeinput グローバル イベント ハンドラのコンテンツ属性

Chrome で onbeforeinput グローバル コンテンツ属性がサポートされます。beforeinput 形式は、すでに addEventListener() で利用できるようになっています。Chrome では、document.documentElement.onbeforeinput を確認することで、この機能を検出できます。

Opaque Response Blocking v0.1

Opaque Response Blocking（ORB）は、Cross-Origin Read Blocking（CORB）に代わるものです。CORB と ORB は、どちらも "no-cors" サブリソースのクロスオリジン開示を防ぐためのヒューリスティックです。

Picture-in-Picture API が Android に対応

Picture-in-Picture API を使うと、ウェブサイトでフローティング動画ウィンドウを作成できます。これは常に他のウィンドウの上部に表示されるので、ユーザーはデバイスで他のサイトやアプリケーションを操作しながら、メディアを視聴し続けることができます。この機能は、パソコンでは Chrome 70 以降で利用可能ですが、現在、Android 11 以降で実行される Chrome でも利用できるようになっています。今回の変更は、<video> 要素にのみ適用されます。Picture-in-Picture API の詳しい使い方は、ピクチャー イン ピクチャーで動画を視聴するをご覧ください。

Response.json()

Response() コンストラクタを使うとさまざまな種類のレスポンス本体を作成できますが、既存の response.json() インスタンス メソッドでは直接 JSON オブジェクトを作ることはできません。この点に対応するのが、Response.json() 静的メソッドです。

Response.json() は、2 つの引数を受け取り、新しい Response オブジェクトを返します。最初の引数は、JSON に変換する文字列です。2 つ目の引数は初期化オブジェクトで、省略可能です。

マークアップ ベースのクライアント ヒント委譲の構文変更

Chrome 100 のユーザー エージェントの削減によって取得できなくなったクライアント情報を必要とするサードパーティ コンテンツへのクライアント ヒント委譲の構文が変更されます。

以前の構文 :
<meta name="accept-ch" value="sec-ch-dpr=(https://foo.bar https://baz.qux), sec-ch-width=(https://foo.bar)">

新しい構文 :
<meta http-equiv="delegate-ch" value="sec-ch-dpr https://foo.bar https://baz.qux; sec-ch-width https://foo.bar">

File System Access API での書き込み可能なディレクトリ プロンプト

Chromium では、File System Access API の 1 回のプロンプトで、読み取りと書き込みの両方のパーミッションを持つディレクトリを返すことができるようになります。これまで、Window.showDirectoryPicker() は読み取りアクセスのプロンプトを表示した後、読み取り専用のディレクトリを返していたので、書き込みアクセスを取得するために 2 つ目のプロンプトが必要でした。このような 2 重のプロンプトはユーザー エクスペリエンスが低く、ユーザーの混乱やパーミッション疲労の原因になります。

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

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

安全でないコンテキストでの WebSQL の削除

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

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

CSS のカスタム識別子で default キーワードの利用を禁止

CSS キーワード 'default' が CSS カスタム識別子として使用できなくなります。カスタム識別子は、CSS でさまざまな種類のユーザー定義名に使われます（@keyframes ルールで作られる名前、カウンタ、@container 名、カスタムのレイアウトやペイントの名前など）。これにより、カスタム識別子での利用が制限される名前のリスト（'inherit'、'initial'、'unset'、'revert'、'revert-layer'）に 'default' が追加されます。

Navigation API でのサポートの終了

transitionWhile() メソッドと restoreScroll() メソッドは今回のリリースで非推奨となり、108 で削除される予定です。この機能が必要なデベロッパーは、新しい intercept() メソッドと scroll() メソッドを利用してください。既存のメソッドの問題の説明や、新しいメソッドの使用例については、NavigateEvent の変更点をご覧ください。

Cookie のドメイン属性での非 ASCII 文字のサポート終了

最新の仕様（RFC 6265bis）に準拠するため、Chromium は非 ASCII 文字（Domain=éxample.com など）を含む Domain 属性を持つ Cookie を拒否するようになります。
Cookie の IDN ドメイン属性のサポートは長いこと規定されておらず、Chromium、Safari、Firefox のすべてで動作が異なります。今回の変更により、非 ASCII ドメイン属性を持つ Cookie を拒否するという Firefox の動作が標準になります。

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

105 以降では、コンソールに警告が表示されます。削除は 106 で行われる予定です。

ジェスチャー スクロール DOM イベントを削除

ジェスチャー スクロール DOM イベント（gesturescrollstart、gesturescrollupdate、gesturescrollend）が Chrome から削除されます。これらは非標準 API であり、プラグインで使うために Blink に追加されましたが、ウェブにも公開されていました。

多くの Google Maps Platform のデベロッパーにとって、地図はユーザー エクスペリエンスの中核と言えますが、これには正しい地図描画と適切な情報量とのちょうどよいバランスが必要となります。例えば、旅行アプリのデベロッパーは、旅行者に関連の薄いスポットよりも、レストランやランドマークなどを表示したいと考えるでしょう。しかし、どのくらいの比率がユーザー エクスペリエンスにとってちょうどよいかを判断するのには、テストが必要です。多くのケースでは、最適なカスタマイズ セットを見いだす最良の方法は、テストを繰り返し行うことです。

この度 Google は、スタイルのプロトタイピングとテストを容易にする、クラウドベースのマップスタイル設定のための変更履歴機能を追加リリースします。この新しい機能は、すべてのデベロッパーが [ 設定 ] メニューの地図のスタイル エディタからご利用頂けます。

変更履歴とは

変更履歴を使ってマップ スタイル エディタで地図のスタイルを保存または公開すると、作業の新しいバージョンが自動的に作成されます。

つまり、問題が発生した場合には 1 つ前のバージョンに戻り、ボタンをクリックするだけでそのバージョンを復元できるので、安心して地図のスタイルを変更できるようになります。また、以前のバージョンはどれでも新しい地図のスタイルに複製できるので、古いバージョンと新しいバージョンの両方を用意して、アプリやウェブサイトで A / B テストを行うこともできます。

変更履歴の使用

変更履歴を使うには、Cloud コンソールで地図のスタイル エディタに移動し、地図のスタイルを開きます。その後、数百種類から選べるカスタマイズを使用して更新し、[ 保存 ] ボタンをクリックして新しいドラフトを作成するか、[ 公開 ] ボタンをクリックして新しい公開バージョンを作成します。新しいバージョンは、地図の右側の [ 変更履歴 ] に表示されます。

バージョンを切り替えるには、切り替えたいバージョンをリストから選択して、[ 復元 ] ボタンをクリックします。その後、[ 公開 ] ボタンをクリックすると、その地図のスタイルに関連付けられたマップ ID を使っているウェブアプリやモバイルアプリに変更が自動的に反映されます。各バージョンをスタート ポイントとして利用し、さらなるカスタマイズを加えた新しいバージョンを作成することもできます。

本機能のリリース以降に行われたすべての地図のスタイルの変更に対して、変更履歴が作成されます。ただし、リリース以前に加えられた変更には、変更履歴は利用できません。

優れたカスタム マップ エクスペリエンスの創出

昨年、Google は クラウドベースのマップスタイル設定機能を一般公開しました。これは、ユーザーのニーズに合わせて地図をカスタマイズするだけでなく、コードなしの地図のデザインを実現するものです。Cloud コンソールで地図をデザインし、[ 公開 ] ボタンをクリックするだけでアプリに設定情報がすべて反映されます。

この機能を公開してからは、デベロッパーはクラウドベースのアプローチを活用して、より魅力的なマップ エクスペリエンスのプロトタイプの作成と本番環境でのテストを行い、ユーザー エンゲージメントとコンバージョンの大幅な向上に成功しています。長期休暇のためのホテルを探すときや、車を手配したり店舗を検索したりするときも、テーマにマッチした適切なデザインの地図が、より早く、より簡単に作成できるので、目的達成をサポートします。

変更履歴機能を使うことで、これまで以上に、試行的な設定情報の更新とそのテストが繰り返し行えるので、ユーザーに喜ばれるエクスペリエンスの創造を容易にコントロールできるようになりました。

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