12 月 1 日（米国時間）、Maps SDK for iOS と Places SDK for iOS の新しいバージョンをリリースいたしました。バージョン 6.0 では、サポート対象の iOS のバージョンが iOS 12 からとなり、Apple M1 マシン上で iOS 14 以降のシミュレータを使用して開発する際に必要なバイナリを含む XCFramework のプレビュー サポートを提供し、デベロッパーの開発速度向上を実現します。また、このバージョンには、デベロッパーの皆様からのリクエストに基づいて、マーカーを地図に追加した際のアニメーション動作に関する新機能も追加しています。
バージョン 6.0 では、マーカーをマップに追加した際の表示をアニメーション化できるように、kGMSMarkerAnimationFadeIn という新しい GMSMarkerAnimation タイプが導入されました。
これを使用するには、マーカーをマップに追加する前に、マーカーの appearAnimation プロパティを設定します。 Swift
let position = CLLocationCoordinate2D(latitude: -33.86, longitude: 151.2)
let marker = GMSMarker(position: position)
marker.appearAnimation = .fadeIn
Objective-C
CLLocationCoordinate2D position = CLLocationCoordinate2DMake(-33.86, 151.2);
GMSMarker *marker = [GMSMarker markerwithPosition:position];
marker.appearAnimation = kGMSMarkerAnimationFadeIn;
従来、Maps SDK for iOS と Places SDK for iOS は、アプリの開発とリリースに必要なアーキテクチャを含む単一の .framework ファイルとして配布されていました。しかし、Apple M1 マシンを使用する場合、新しいバリアントである arm64 シミュレータに対応させるため、SDK を新しい XCFramework 形式に再パッケージ化する必要がありました。
Apple M1 マシンで以前のバージョンの SDK の使用を試みたことがある方は、以下のエラーに見覚えがあるはずです。
ld: building for iOS Simulator, but linking in object file built for iOS, file '[...]/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps for architecture arm64
Maps SDK for iOS と Places SDK for iOS のバージョン 6.0 のリリースでは、XCFramework のプレビュー サポートを提供し、Apple M1 マシンで発生していた上記のエラーを解消しています。プレビュー サポートの使用方法について詳しくは、Maps と Places のスタートガイドをご覧ください。
Maps SDK と Places SDK の XCFramework バージョンはベータ版のため、これらのバージョンは開発目的でのみ使用し、アプリをリリースする際には .framework バージョンを使用することをおすすめします。今後の SDK では、XCFramework のサポートを一般提供する予定です。
CocoaPods や Carthage を使用して Maps SDK for iOS と Places SDK for iOS のバージョン 6.0 をインストールできるようになりました。SDK の XCFramework プレビュー版をインストールする場合は、[Installing the XCFramework] タブをご覧ください。サポートする iOS バージョンは iOS 12 からとなるため、バージョン 6.0 を使用して開発するには Xcode 12 以降を使用する必要があります。iOS 11 のサポートは現在中止していますが、Maps SDK for iOS と Places SDK for iOS の古いバージョンを指定することで、引き続きご利用いただけます。
Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。
旧 : このページは削除予定。ウェブ関連のストレージの管理は、chrome://settings/content/all から行う。
新 : こちらの chrome://settings/content/all で、ユーザーがウェブ関連のストレージを削除できる。
詳細な Cookie の管理は引き続き DevTools で実行可能
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。
来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。詳細については、Chrome の User-Agent 文字列のメジャー バージョンを強制的に 100 にするをご覧ください。
chrome://flags/#force-major-version-to-100
details
閉じられた details 要素に対する検索やリンクができるようになります。また、こういった非表示の要素は、find-in-page や ScrollToTextFragment のタイミング、あるいは要素のフラグメント ナビゲーションが使われたときに、自動的に展開されます。
find-in-page
ScrollToTextFragment
専用ワーカーが Content Security Policy の影響を受けるようになります。これまで、Chrome は、オーナーのドキュメントの Content Security Policy を誤って適用していました。
font-synthesis CSS プロパティは、フォント ファミリーに斜体、太字、小型英大文字のフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。font-synthesis プロパティがない場合、必要なバリエーションのフォント ファミリーがないウェブページで、不自然な形状のフォントになる可能性があります。
font-synthesis
perspective() 関数の引数として、値 'none' がサポートされます。その場合、関数は無限大の引数を渡された場合のように動作します。これにより、perspective() 関数が関係しているアニメーションのエンドポイントの片方が単位行列であるアニメーションが簡単になります（場合によっては、実現可能になります）。
perspective()
'none'
Chrome は、Feature Policy の許可リストで新しく keyboard-map 値をサポートします。Keyboard.getLayoutMap() を使うと、英語やフランス語など、異なるキーボード レイアウトで押されたキーを特定できます。このメソッドは、iframe 要素では利用できません。また、Keyboard API を利用できなかった一部のウェブアプリ（Excel、Word、PowerPoint）のアーキテクチャで、このメソッドが利用できるようになります。
keyboard-map
Keyboard.getLayoutMap()
HTMLScriptElement.supports() メソッドは、script 要素を利用する新機能を統一的な方法で検出します。現在のところ、HTMLScriptElement の type 属性で利用できる種類を簡単に判定する方法はありません。
HTMLScriptElement.supports()
HTMLScriptElement
フォーム エントリの改行が Gecko や WebKit と同じように正規化されるようになります。これにより、Gecko と WebKit は改行を遅い段階で正規化するにもかかわらず、Chrome は早い段階で正規化するという、長期にわたって存在していた相互運用性の問題が解決します。Chrome 97 以降では、早い段階での正規化が削除され、遅い段階での正規化がすべてのエンコーディング タイプに拡張されます。
Chrome 97 は、Sec-CH- プレフィックスを付けて Client Hint 名を標準化します。影響を受ける Client Hint は、dpr、width、viewport-width、device-memory、rtt、downlink、ect です。Chrome では、以上のヒントの既存バージョンのサポートも継続されます。しかし、ウェブ デベロッパーは、今後のサポートの終了や削除に向けた準備をする必要があります。
Sec-CH-
dpr
width
viewport-width
device-memory
rtt
downlink
ect
WebTransport は、ウェブのセキュリティ モデルの制約を受けるクライアントがリモート サーバーと通信する際に、安全な多重化転送を可能にするプロトコル フレームワークです。
現在、ウェブ アプリケーション デベロッパーがリモート サーバーと双方向通信をする場合、WebSockets と RTCDataChannel という 2 つの API を使うことができます。WebSockets は TCP ベースなので、すべての TCP の欠点（ヘッドオブライン ブロッキング、信頼できないデータ転送の未サポート）を引き継ぐことになり、レイテンシが重要なアプリケーションには適しません。RTCDataChannel は Stream Control Transmission Protocol（SCTP）ベースなので、そのような欠点はありません。しかし、ピアツーピアで使うことを念頭に置いて設計されているので、クライアントサーバー設定で使われることはほとんどありません。WebTransport は、信頼できないデータと信頼できるデータの両方の双方向通信をサポートするクライアントサーバー API で、UDP 的なデータグラムによるキャンセル可能なストリームを利用します。WebTransport の呼び出しは DevTools の [Network] パネルで確認できます。[Type] 列を見ると、このプロトコルが使われていることがわかります。
WebSockets
RTCDataChannel
WebTransport
詳しくは、WebTransport の試験運用をご覧ください。
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン x.x が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Array と TypedArray が findLast() と fileLastIndex() 静的メソッドをサポートします。この 2 つの関数は find() と findIndex() と同じですが、配列の最初からではなく最後から検索します。
Array
TypedArray
findLast()
fileLastIndex()
find()
findIndex()
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
2013 年以降、WebRTC の SDES 鍵交換メカニズムは、関連する IETF 標準で使用禁止と宣言されています。IETF は、SDES 仕様を過去のものと宣言しています。近年では、Chrome での使用も大幅に減少しました。そのため、Chrome 97 で削除されます。
サードパーティ コンテキストでの WebSQL が削除されます。Web SQL Database 標準が最初に提案されたのは 2009 年 4 月で、2010 年 11 月に検討が中止されました。Gecko はこの機能を実装しておらず、WebKit では 2019 年に非推奨となりました。W3C は、代替手段として Web Storage や Indexed Database を推奨しています。
WebRTC でセッションを確立するために使われる Session Description Protocol（SDP）は、Chromium では 2 種類の方言 Unified Plan と Plan B によって実装されています。Plan B はクロスブラウザの互換性がないため、削除されます。
Windows、Mac、Linux のデバイスでは、スタートアップ時に自動起動するようにネイティブ アプリを設定できます。Run on OS Login（OS ログイン時に実行）機能は、Chrome 91 で導入されました。この機能がリリースされたことで、ユーザーが Windows、Mac、Linux のデバイスにログインしたときに、デスクトップ ウェブアプリを自動起動する設定が可能になっています。 インストール済みのアプリは、自身の自動実行を自動的に有効化することはできません。常にユーザーによる手動操作が必要です。 OS ログイン時にアプリを実行するよう設定するには、Chrome ブラウザを開き、chrome://apps に移動するか、ブックマーク バーの [ アプリ ] アイコン（下の例）をクリックします。
chrome://apps
リリースされたばかりの Pixel 6 と Pixel 6 Pro は最も安全な Pixel スマートフォンであり、5 年間にわたるセキュリティ アップデートが適用されるほか、最もレイヤー数の多いハードウェア セキュリティを備えています。これらの新しい Pixel スマートフォンでは、レイヤー化されたセキュリティ アプローチを採用しており、Google Tensor SoC（System on a Chip）ハードウェアから Pixel で先行利用できる Android オペレーティング システムの新機能に至るまでのイノベーションを活用して、チップからデータセンターまでを網羅する Google セキュリティが適用された最初の Pixel スマートフォンを実現しました。また、複数の専属のセキュリティ チームが開発を担当して、透明性と外部検証を通じて Pixel のセキュリティを証明しています。
コアにセキュリティを提供
Google は、Google Tensor を使用して、ハードウェア セキュリティの最重要部にユーザーデータの保護と透明性を提供しています。Google Tensor のメイン プロセッサは Arm ベースであり、TrustZone™ テクノロジーを活用しています。TrustZone は、一般的な処理を安全に行うセキュリティ アーキテクチャの重要な要素ですが、Google Tensor に含まれているセキュリティ強化は、TrustZone の一歩先を進んでいます。
Google Tensor セキュリティ コアは、ユーザー プライバシーの保護に特化したカスタム設計のセキュリティ サブシステムです。このサブシステムは、アプリケーション プロセッサとは論理的かつ物理的に異なり、専用 CPU、ROM、OTP（1 回しか書き込めない）メモリ、暗号化エンジン、内部 SRAM、保護された DRAM で構成されます。Pixel 6 と Pixel 6 Pro の場合、セキュリティ コアの主要なユースケースには、実行時にユーザーデータ キーを保護したり、セキュアブートを強化したり、Titan M2TM と連携したりすることが含まれます。
ハードウェアの安全性は、OS が安全であるときにのみ確保されます。Google では、オープンソースの信頼できる実行環境である Trusty を使用しています。Trusty OS は、TrustZone と Google Tensor セキュリティ コアの両方で使用される安全な OS です。
Pixel 6 と Pixel 6 Pro では、Google がすべてを設計して開発した別個のセキュリティ チップである新しい Titan M2TM によってセキュリティが強化されています。この次世代チップを採用したことにより、Google は社内設計した RISC-V プロセッサに移行し、速度とメモリ容量を向上し、高度な攻撃に対する耐性をさらに強化しています。Titan M2TM は、独立した認定済みの評価ラボによって、脆弱性評価の最も厳格な標準である AVA_VAN.5 に照らしてテストされています。Titan M2™ は Android StrongBox をサポートします。Android StrongBox は、PIN とパスワードの保護に使用されるキーを安全に生成して格納し、Google Tensor セキュリティ コアと連携して、SoC で使用中のユーザーデータ キーを保護します。
システムが改善された Pixel 6 と Pixel 6 Pro は、Android 12 と、Pixel で先行利用や限定利用ができるたくさんの機能が搭載された状態で出荷されます。
強化されたコントロール
Google は、Android のリリースのたびに、データをコントロールしてデバイスを管理するより適切な方法をユーザーに提供することを目指しています。Pixel で使用される Android 12 以降では、新しいセキュリティ ハブを使用して、すべてのセキュリティ設定を 1 か所で管理することができます。つまり、デバイスの現在の構成を一元的に表示することにより、スマートフォン、アプリ、Google アカウント、パスワードを保護できるようにしています。また、セキュリティ ハブは、セキュリティを改善するための推奨事項を提供するため、ニーズに最適な設定を判定できるようになります。
Google はプライバシーのためにプライバシー ダッシュボードをリリースし、過去 24 時間以内に位置情報、マイク、カメラにアクセスしたアプリをシンプルで明確なタイムライン形式で表示できるようにしています。予想よりも多くのデータにアクセスしているアプリに気付いた場合、ダッシュボードには、それらのアプリのパーミッションをすぐに変更できるコントロールへのパスが表示されます。
さらに透明性を向上するため、アプリがカメラやマイクにアクセスしていることが、Pixel のステータスバーにある新しいインジケーターでわかるようになっています。アクセスを無効にしたい場合、プライバシーの新しい切り替え機能により、1 回タップするだけで、スマートフォンのアプリによるカメラやマイクへのアクセスをいつでもオフにすることができます。
Pixel 6 と Pixel 6 Pro には、セキュリティが低い 2G ネットワークにアクセスするデバイスの機能を削除する切り替え機能も含まれています。一部の状況では 2G ネットワークへのアクセスが必要になりますが、さらなる攻撃ベクトルが発生する可能性があります。この切り替え機能は、2G 接続が不要なときに、そのリスクを軽減することに役立ちます。
組み込みのセキュリティ
Google はすべてのプロダクトをデフォルトで安全にするために、オンラインの安全を維持することに他の誰よりも取り組んでいます。また、Pixel 6 と Pixel 6 Pro では、デフォルトで組み込まれている保護機能を強化しています。
画面に埋め込まれた光学指紋認証センサーは、バイオメトリック情報の安全を確保し、デバイスの外に流出することを防ぎます。Google の継続的なセキュリティ開発ライフサイクルの一環として、Pixel 6 と Pixel 6 Pro の指紋認証によるロック解除は、外部のセキュリティ エキスパートによって、Android 12 互換性定義ドキュメント（Compatibility Definition Document、CDD）で定義されているクラス 3 強度要件を満たす安全な生体認証ロック解除メカニズムとして検証されています。
フィッシングは強大な攻撃ベクトルであり続け、さまざまなデバイスを使用しているすべての人に影響を及ぼしています。
Pixel 6 と Pixel 6 Pro では、新しいフィッシング対策保護機能が導入されています。組み込みの保護機能は、通話、テキスト メッセージ、メール、アプリを通じて送信されるリンクからの潜在的な脅威を自動的にスキャンし、潜在的な問題がある場合は、ユーザーに通知します。
また、ユーザーは、Google Play プロテクト内のオンデバイス検出機能に加えられた機能強化により、悪意のあるアプリからより強固に保護されています。Google Play プロテクトは 2017 年にリリースされて以来、デバイスがオフラインのときでも、悪意のあるアプリを検出できるようにしてきました。Pixel 6 と Pixel 6 では、Google Play プロテクトでのマルウェア検出を強化する新しい機械学習モデルを使用しています。この検出機能は Pixel で実行され、フェデレーション アナリティクスと呼ばれるプライバシー保護テクノロジーを使用して、一般的に実行される悪意のあるアプリを検出します。これにより、すでに 1,000 億個のアプリを毎日分析して脅威を検出している Google Play プロテクトが改善され、30 億人を超えるユーザーにさらに強固な保護を提供します。
Pixel の多くのプライバシー保護機能は、残りのオペレーティング システムやアプリから分離されたオープンソースのサンドボックスである Private Compute Core 内で実行されます。Google のオープンソースの Private Compute Services は、これらの機能のネットワーク通信を管理し、プライバシーを保護すると同時に、フェデレーション ラーニング、フェデレーション アナリティクス、個人情報の取得を通じて機能を改善します。Private Compute Core ですでに実行されているいくつかの機能には、自動字幕起こし、この曲なに？、スマート リプライの提案などが含まれます。
Google Binary Transparency（GBT）は、Google のオープンで検証可能なセキュリティ インフラストラクチャに追加された最新機能であり、デバイスのソフトウェア整合性に新しいレイヤーを追加します。証明書の透過性によって導かれる原則を基に構築された GBT は、Pixel で実行できるソフトウェアを、認定された OS ソフトウェアのみに限定します。GBT は、システム イメージのハッシュを署名し、追加専用のログに格納することで機能します。このログは公開され、公開されたハッシュとデバイスにあるハッシュが同じであることを検証するために使用できます。これにより、ユーザーと研究者は初めて、OS の整合性を独立して検証できるようになりました。
スマートフォン以外への拡張
多層防御は、ハードウェアとソフトウェアのレイヤーだけの問題ではありません。セキュリティは厳密なプロセスです。Pixel 6 と Pixel 6 Pro では、設計やアーキテクチャの詳細なレビュー、セキュリティ上重要なコードのメモリ安全な書き換え、静的分析、ソースコードの公式検証、重要なコンポーネントのファジング、デバイスに侵入テストする外部のセキュリティ ラボなどが含まれたレッドチームを活用しています。また、Pixel は Android 脆弱性報奨金プログラムに含まれています。昨年、このプログラムでは 175 万ドルが支払われ、Google とセキュリティ リサーチ コミュニティの間に有益なフィードバック ループを構築したほか、最も重要であるユーザーの安全を引き続き確保できるようにしています。
ハードウェアとソフトウェアが組み合わされた、このセキュリティ システムを締めくくるのは Titan Backup Architecture です。このアーキテクチャにより、クラウドでの Pixel の安全な土台が確保されます。Android のバックアップ サービスと Google Cloud の Titan テクノロジーの組み合わせは 2018 年に発表され、クライアント以外は Google を含め誰もが知らないランダムに生成されたキーのみによって、バックアップされたアプリケーション データを復号化できるようにします。このエンドツーエンドのサービスはサードパーティのセキュリティ ラボによって別個に監査され、パスコードを明確に知らない限り、ユーザーのバックアップされたアプリケーション データに誰もアクセスできないことが検証されました。
ハードウェアやソフトウェアからデータセンターに至るまでのこのエンドツーエンドのセキュリティに加え、Pixel 6 と Pixel 6 Pro デバイスでは、米国で発表されてから 5 年以上の Android セキュリティ アップデートが保証されています。これは、業界にとって重要な取り組みであり、他のスマートフォン メーカーもこの取り組みを推進することを望んでいます。
Google は安全なチップセット、ソフトウェア、プロセスを連携させることにより、Pixel 6 と Pixel 6 Pro を最も安全な Pixel スマートフォンにすることができました。
理由と解説 : 悪意のある人物がデベロッパー アカウントにアクセスできる場合、既知の貢献者になりすまして悪意のあるコードを送信する可能性があります。貢献者には、commit を送るプラットフォームだけでなく、メールなどの貢献に関連するアカウントに対して、多要素認証（MFA）を使うことを推奨しましょう。可能であれば、MFA の方式でお勧めなのはセキュリティ キーです。
理由と解説 : セルフマージ（一方的な変更とも呼ばれます）には、1）貢献者のアカウントを乗っ取った攻撃者がプロジェクトに悪意のあるコードを注入する可能性がある、2）善意の貢献者が意図しないセキュリティ リスクを含む commit をマージする可能性がある、という 2 つのリスクがあります。悪意のあるコードの送信や意図しない脆弱性を回避するために役立つのが、身元が明らかで信頼できる別の人の目です。可能であれば、GitHub のブランチ保護設定などを使い、自動要件として設定しましょう。Allstar などのツールも、この要件の適用に役立ちます。これは、SLSA レベル 4 に対応します。
理由と解説 : 「多層防御」というセキュリティの考え方は、複数の異なる防御レイヤーを設けてシステムやシークレット * などの機密データを守ることを指します。シークレット マネージャー ツール（GCP ユーザーの Secret Manager や、HashiCorp Vault、CyberArk Conjur、Keywhiz など）を使うと、ソースコードにシークレットをハードコードする必要はなくなり、集中管理や機能の監査を実現できます。また、シークレットの漏洩を防ぐ認可レイヤーを導入することにもなります。
* 機密データを CI システムに保存する場合は、それが CI/CD のためだけに使われることや、パスワードや ID マネージャーに格納するほうが適したデータではないことを確認してください。
理由と解説 : デフォルトでプロジェクト リポジトリに対して「必要最低限のアクセス」を付与することで、意図しないアクセスと不正利用の両方から CI/CD システムを守ることができます。テストを行うことは重要ですが、デフォルトですべての commit と pull リクエストに対してレビュー前にテストを実行すると、CI/CD システムのコンピューティング リソースの意図しない不正利用につながる可能性があります。
理由と解説 : 手動でビルド手順を実行すると、意図しない構成ミスが紛れ込む可能性があります。しかし、ビルド スクリプト（ビルドやビルドの手順を定義した build.yaml などのファイル）を使えば、手動でビルドする必要はなくなります。加えて、悪意のある人物がビルドを改ざんしたり、レビューされていない変更を紛れ込ませたりする機会を減らすことにもなります。これは、SLSA レベル 1～4 に対応します。
理由と解説 : 1 つの決定的な手法でパッケージが「良い」か「悪い」かを判断することはできません。セキュリティ プロファイルや許容できるリスクは、プロジェクトごとに異なります。プロジェクトにとって依存関係が「安全」であるかどうかを判断するうえで役立つのは、依存関係やどのような変更が推移的に取り込まれるかの情報を集めることです。Open Source Insights（deps.dev）などのツールは、最初のレイヤーと推移的依存関係をマッピングしてくれます。一方の Scorecards は、セキュリティ ポリシー、MFA、ブランチ保護の使用有無など、複数のリスク評価指標に基づいてパッケージのスコアを算出します。
使っている依存関係を把握できたら、定期的に Open Source Vulnerabilities などの脆弱性スキャンツールを実行します。そうすることで、常に最新のリリースやパッチについての情報を得ることができます。多くの脆弱性スキャンツールは、アップグレードの自動適用にも対応しています。
理由と解説 : ビルドの出所（ビルドの来歴）とアーティファクトを表示すると、ビルドが改ざんされていないことや、正しいものであることをユーザーに示すことができます。来歴にはさまざまな要素があります。こういった要素を実現する 1 つの方法は、来歴を表示するために必要なデータを生成と認証するビルドサービスを利用することです。これは、SLSA レベル 2～4 に対応します。
理由と解説 : 来歴の生成やビルドの署名は、自分のプロジェクトで行うべきことであるだけでなく（SLSA レベル 2～4）、他者のアーティファクトを使うときも、同じ証明を求めるべきです。ロゴなどのブランドに基づく認定形態は偽造可能で、タイポスクワッティングによって正当性を偽装できます。署名などの偽造できない証明を求めるようにしてください。たとえば Sigstore は、OSS プロジェクトでビルドに署名したり、他者のビルドを検証したりする際に役立ちます。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 10 月 21 日の時点で Chrome 96 はベータ版です。
来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
現在、他のウィンドウやタブをキャプチャするアプリケーションには、呼び出し元のアイテムやキャプチャするアイテムにフォーカスするかどうかをコントロールする方法がありません（ビデオ会議アプリのプレゼンテーション機能を思い浮かべてください）。Chrome 96 では、新しい focus() メソッドをサポートする FocusableMediaStreamTrack と呼ばれる MediaStreamTrack のサブクラスを使用して、このコントロールを可能にしました。次のコードをご覧ください。
focus()
FocusableMediaStreamTrack
MediaStreamTrack
stream = await navigator.mediaDevices.getDisplayMedia(); let [track] = stream.getVideoTracks();
このコードでは、以前は getVideoTracks() が MediaStreamTrack オブジェクトの配列を返していましたが、FocusableMediaStreamTrack オブジェクトを返すようになります（Chrome 97 では、返されるオブジェクトが BrowserCaptureMediaStreamTrack に変更される予定です。本記事の執筆時点で、Canary 版ではすでに新しいオブジェクトが返されるようになっています）。
getVideoTracks()
BrowserCaptureMediaStreamTrack
フォーカスするディスプレイ メディアを決定するには、このコードの次の行で "focus-captured-surface" を指定して track.focus() を呼び出し、新しくキャプチャするウィンドウやタブにフォーカスするか、"no-focus-change" を指定してこのメソッドを呼び出し、呼び出し元のウィンドウにフォーカスし続けます。Chrome 96 以降では、デモコードを試して、この機能の動作を確認できます。
"focus-captured-surface"
track.focus()
"no-focus-change"
Priority Hints では、デベロッパーが設定する "importance" 属性が導入され、計算されるリソースの優先度を変更することができます。サポートされる importance 属性の値は、"auto"、"low"、と "high" です。Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールできるようにします。ブラウザでは、リソースのタイプ、可視性、プリロードのステータスなど、多くの要素がリソースの優先度に影響を及ぼします。
"importance"
"auto"
"low"
"high"
プリフライト リクエストなしに、単純な Range ヘッダーを指定してリクエストを送信できるようになりました。CORS リクエストでは、プリフライト リクエストをトリガーせずに、Range ヘッダーを限定的な方法（1 つの有効な範囲のみ）で使用できます。
バックフォワード キャッシュにページが格納され、クロスサイト ナビゲーションをした後でも、以前にアクセスしたページへの即時ナビゲーションが可能になります。
Cross-Origin-Embedder-Policy には、クロスオリジン no-cors リクエストで認証情報（Cookie やクライアント証明書など）を省略できるようにする新しい credentialless オプションが追加されます。COEP:require-corp と同じように、クロスオリジン分離も有効化できます。
Cross-Origin-Embedder-Policy
no-cors
credentialless
COEP:require-corp
SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。COEP: require-corp を使用して、クロスオリジン分離のオプトインを大規模に導入することは難しく、すべてのサブリソースで明示的にオプトインしなければならなくなります。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、ソーシャル メディア全般、フォーラムなど）では、依存関係の問題が発生します。
COEP: require-corp
新しい autofill 疑似クラスを使用すると、自動入力されるフォーム要素のスタイルを設定できます。これは、:-webkit-autofill 疑似クラスの標準化として導入されており、WebKit ではすでにサポートされています。Firefox は、この標準バージョンをサポートします。
autofill
:-webkit-autofill
writing-mode、direction、background など、一部のプロパティは、body からビューポートに伝播されます。CSS コンテナクエリの無限ループを防ぐために、仕様と実装が変更され、HTML または BODY にレイアウトの封じ込めが適用される際にこれらのプロパティが伝播されなくなりました。
font-synthesis CSS プロパティは、フォント ファミリーにフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。
MediaKeySession.closed プロパティは、enum を使用して、MediaKeySession オブジェクトが閉じられた理由を示すようになります。この closed プロパティは、セッションが閉じたときに解決される Promise を返します。以前は Promise が解決されるだけでしたが、文字列として解決されるようになり、閉じられた理由を示します。返される文字列は、"internal-error"、"closed-by-application"、"release-acknowledged"、"hardware-context-reset"、"resource-evicted" のいずれかです。
MediaKeySession.closed
MediaKeySession
"internal-error"
"closed-by-application"
"release-acknowledged"
"hardware-context-reset"
"resource-evicted"
Chrome では、DNS（ドメイン名サービス）から HTTPS レコードが利用できる場合は、常に HTTPS 経由でウェブサイトに接続します。
PerformanceEventTiming インターフェースに interactiveID と呼ばれる属性が含まれるようになりました。これは、ブラウザが生成する ID であり、複数の PerformanceEventTiming エントリが同じユーザー操作に対応する場合、これらのエントリをリンクできるようにします。現在、デベロッパーは Event Timing API を使用して、関心のあるイベントのパフォーマンス データを収集できます。ただし、同じユーザー操作に対応するイベントをリンクすることは困難です。たとえば、ユーザーがタップしたときなら、pointerdown、mousedown、pointerup、mouseup、click など、多くのイベントが生成されます。
PerformanceEventTiming
interactiveID
pointerdown
mousedown
pointerup
mouseup
click
Chrome は、 'prefers-contrast' と呼ばれる新しいメディアクエリをサポートします。そのため、ウェブ制作者は、オペレーティング システムで設定されたユーザーのコントラスト設定（具体的には、macOS のコントラストを強調したモードと Windows のハイ コントラスト モード）にウェブ コンテンツを合わせることができます。有効な選択肢は、'more'、'less'、'custom'、または 'no-preference' です。
'prefers-contrast'
'more'
'less'
'custom'
'no-preference'
ウェブアプリ マニフェストで任意の id フィールドがサポートされ、ウェブアプリをグローバルに特定できるようになりました。id フィールドがない場合、PWA は start_url にフォールバックします。現時点で、このフィールドはデスクトップのみでサポートされます。
id
start_url
ウェブ アプリケーションがインストール マニフェストを使用して、カスタム URL プロトコル / スキームのハンドラとして自身を登録できるようにします。多くの場合、オペレーティング システム アプリケーションは自身をプロトコル ハンドラとして登録して、見つけやすさと使用率を向上します。ウェブサイトは、すでに registerProtocolHandler() を介してスキームを処理するように登録できます。この新機能はもう一歩踏み込んで、カスタム スキーム リンクが呼び出されたときに、ウェブアプリを直接起動できるようにします。
registerProtocolHandler()
Chrome のコンテンツ セキュリティ ポリシーが強化され、WebAssembly との相互運用性が向上しています。wasm-unsafe-eval は、WebAssembly の実行をコントロールします（JavaScript の実行には影響しません）。また、script-src ポリシーに WebAssembly が含まれるようになりました。
wasm-unsafe-eval
script-src
WebAssembly モジュールで JavaScript オブジェクトや DOM オブジェクトへの参照を保持できるようになりました。具体的には、これらの参照は、引数として渡したり、ローカル変数やグローバル変数に格納したり、WebAssembly.Table オブジェクトに格納したりできます。
PaymentRequest API では、"basic-card" 支払い方法が非推奨となっています。その使用率は低いうえ、低下し続けています。この支払い方法の購入手続きまでの時間や購入完了率は、他の支払い方法を下回っています。デベロッパーは、代わりとして他の支払い方法に切り替えることができます。たとえば、Google Pay、Apple Pay、Samsung Pay などの支払い方法です。 削除までのタイムライン :
Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。そのため、Google では、Google for Startups Accelerator というスタートアップを支援するアクセラレータプログラムを日本でも継続的に行っております。
この度、Google for Startups Accelerator のプログラムにおいて、参加するスタートアップに対して技術的メンタリングを提供してくださるメンターを募集いたします。メンターの方にはスタートアップへのメンタリングを通じて、 テクノロジーを活用した社会、経済、環境といったさまざまな分野の問題解決への取り組みをともに解決し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることへの貢献を一緒に行っていければと考えています。
メンターとして参画してくださる方、ぜひこちらのフォームよりご応募ください。
canMakePayment()
false
