この記事は Pratyush Sinha による Chromium Blog の記事 "Run on OS Login" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーは、デバイスにログインするときに、メールやチャット、その他のよく使う生産性向上アプリケーションを自動起動したいと考えています。ログイン時にそのようなアプリを自動起動すれば、デバイスにログインしてから手動でアプリを起動する必要がなくなるので、ユーザー エクスペリエンスを効率化できます。

Windows、Mac、Linux のデバイスでは、スタートアップ時に自動起動するようにネイティブ アプリを設定できます。Run on OS Login（OS ログイン時に実行）機能は、Chrome 91 で導入されました。この機能がリリースされたことで、ユーザーが Windows、Mac、Linux のデバイスにログインしたときに、デスクトップ ウェブアプリを自動起動する設定が可能になっています。 インストール済みのアプリは、自身の自動実行を自動的に有効化することはできません。常にユーザーによる手動操作が必要です。
OS ログイン時にアプリを実行するよう設定するには、Chrome ブラウザを開き、chrome://apps に移動するか、ブックマーク バーの [ アプリ ] アイコン（下の例）をクリックします。

ログイン時にアプリを起動するように設定したい場合は、まずそのアプリを右クリックし、コンテキスト メニューから [ ログイン時にアプリを開く ] を選択します。以上で設定は完了で、次にデバイスにログインするとアプリが自動的に起動します。アプリでこの機能を無効にするには、chrome://apps に移動します。アプリを右クリックしてコンテキスト メニューを表示し、[ ログイン時にアプリを開く ] 項目の選択を解除します。

Run on OS Login で起動するアプリは、デバイスが実行されてから起動します。Run on OS Login はブラウザのみの機能であり、アプリ デベロッパーに起動元に関する情報が開示されることはありません。

Google はウェブ プラットフォームを継続的に改善し、日々のタスクを手間をかけずに安全に行える方法をユーザーに提供します。インストール済みのウェブアプリを OS ログイン時に実行できるようにすることは、コンピュータをオンにしたときにチャット、メール、カレンダーなどのクライアント アプリをすぐに使いたいユーザーにとって、スタートアップ ルーチンを簡素化するための小さいながらも重要な一歩です。いつものように、皆さんのフィードバックをお待ちしています。皆さんからのフィードバックは、私たちが今後のステップに優先順位を付けることに役立ちます。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome ブラウザ、プロダクト マネージャー、Yana Yushkina による Chromium Blog の記事 "Searching, browsing, and shutdown Chrome performance improvements" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome では、さまざまなプロジェクトを通じて、パフォーマンスを改善するための長期的な取り組みが行われています。今回の速さと好奇心シリーズの投稿では、スピード、メモリ、意図しないハングに関する改善について紹介します。現在、検索の 6 回に 1 回は一瞬で終わり、PartitionAlloc に関する作業によって Chrome OS でのブラウジングで最大 20% のメモリが削減され、Chrome OS と Windows のシャットダウン操作に関する厄介な問題も解消されています。

アドレスバー

Chrome のアドレスバーを使ってウェブを検索すると、文字を入力するのに合わせて検索語句の候補が表示されることに気づくはずです（Chrome の設定で [ 検索語句や URL をオートコンプリートする ] 機能をオンにしている場合）。これにより、検索語句すべてを入力する必要がなくなるので、情報の検索が迅速かつ簡単になります。求めている検索語句が提案されるまでテキストを入力すれば、すぐにそれを選択できます。




Chrome で検索すれば、さらに高速になります。提案された検索語句が選ばれる可能性が高い場合、検索結果がプリフェッチされるようになったからです。つまり、皆さんが検索語句を選択する前にウェブサーバーから結果を取得するので、検索結果が表示されるまでの時間がさらに短縮されます。実際に実験を行ったところ、検索結果が 500 ミリ秒以内に表示される可能性が 4 倍になったことがわかりました。

現在、この処理が行われるのは、Google 検索がデフォルトの検索エンジンになっている場合だけです。しかし、こちらの記事で説明しているように、提案する検索語句をサーバーから Chrome に送信する際に情報を追加することで、他の検索プロバイダもこの機能をトリガーできます。

Chrome OS の PartitionAlloc

Chrome の新しいメモリ アロケータである PartitionAlloc は、M89 で Android と Windows にロールアウトされました。その結果、メモリ使用量を「最大 22% 節約」でき、パフォーマンスについては「応答性が最大 9% 向上」しました。それ以降も、Linux には M92 で、Chrome OS には M93 で PartitionAlloc を導入しました。うれしいことに、Chrome OS の M93 のフィールド データから、合計メモリ フットプリントが 15%、ブラウザ プロセスのメモリが 20% 減少し、単一タブ、複数タブの両方で Chromebook のブラウジング体験が向上したことがわかりました。

シャットダウン時に最も頻繁に発生するハングを解消

パフォーマンスを改善するため、ソフトウェア エンジニアがシステムにキャッシュを追加するのはよくあることです。しかし、キャッシュの副作用として他の問題（コードの複雑化、安定性、メモリ消費、データの整合性）が発生することも多く、逆にパフォーマンスが悪化する可能性すらあります。今回の事例では、起動時間を短縮するため、数年前に Chrome の履歴システムにローカル キャッシュを追加していました。当時の前提は、Chrome の内部メモリに履歴インデックスをキャッシュする方が、起動のたびに履歴のインデックスを再作成するよりも速いというもので、ラボ環境でのテストでもそれが実証されていたようです。

しかし、クラッシュ データと匿名のパフォーマンス指標から実世界でのパフォーマンスを体系的に調査し続けた結果、このキャッシュによってコードが複雑になり、メモリ使用量が不必要に増加しているだけでなく、シャットダウン時にブラウザがハングする問題の一番の要因にもなっていることがわかりました。その原因は、システムの別の場所で他の I/O が起こり続けている間、バックグラウンド優先スレッドの I/O 枯渇状態が延々と続く OS があることです。さらに、フィールド データの解析結果によれば、パフォーマンス面でユーザーが受けるメリットはほとんどありませんでした。現在は、このキャッシュを削除することで、シャットダウン時に最も頻繁に発生していたハングを解消しています。これは、キャッシュは必ずしも正解ではないという原則を示す好例となりました。

今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ 


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Android、Pixel、および Tensor セキュリティ チーム、 Dave Kleidermacher、Jesse Seed、Brandon Barbello、Stephan Somogyi による Google Online Security Blog の記事 "Pixel 6: Setting a new standard for mobile security" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

リリースされたばかりの 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 M2^TM と連携したりすることが含まれます。

ハードウェアの安全性は、OS が安全であるときにのみ確保されます。Google では、オープンソースの信頼できる実行環境である Trusty を使用しています。Trusty OS は、TrustZone と Google Tensor セキュリティ コアの両方で使用される安全な OS です。

Pixel 6 と Pixel 6 Pro では、Google がすべてを設計して開発した別個のセキュリティ チップである新しい Titan M2^TM によってセキュリティが強化されています。この次世代チップを採用したことにより、Google は社内設計した RISC-V プロセッサに移行し、速度とメモリ容量を向上し、高度な攻撃に対する耐性をさらに強化しています。Titan M2^TM は、独立した認定済みの評価ラボによって、脆弱性評価の最も厳格な標準である 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 スマートフォンにすることができました。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google オープンソース プログラム オフィス、Anne Bertucio による Google Open Source Blog の記事 "Protect your open source project from supply chain attacks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この記事は Chromium Blog の記事 "Chrome 96 Beta: Conditional Focus, Priority Hints, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


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

3 桁のバージョン番号に対する準備

来年には、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 オリジン トライアル デベロッパー コンソールをご覧ください。

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

Conditional Focus

現在、他のウィンドウやタブをキャプチャするアプリケーションには、呼び出し元のアイテムやキャプチャするアイテムにフォーカスするかどうかをコントロールする方法がありません（ビデオ会議アプリのプレゼンテーション機能を思い浮かべてください）。Chrome 96 では、新しい focus() メソッドをサポートする FocusableMediaStreamTrack と呼ばれる MediaStreamTrack のサブクラスを使用して、このコントロールを可能にしました。次のコードをご覧ください。

stream = await navigator.mediaDevices.getDisplayMedia();
let [track] = stream.getVideoTracks();

このコードでは、以前は getVideoTracks() が MediaStreamTrack オブジェクトの配列を返していましたが、FocusableMediaStreamTrack オブジェクトを返すようになります（Chrome 97 では、返されるオブジェクトが BrowserCaptureMediaStreamTrack に変更される予定です。本記事の執筆時点で、Canary 版ではすでに新しいオブジェクトが返されるようになっています）。

フォーカスするディスプレイ メディアを決定するには、このコードの次の行で "focus-captured-surface" を指定して track.focus() を呼び出し、新しくキャプチャするウィンドウやタブにフォーカスするか、"no-focus-change" を指定してこのメソッドを呼び出し、呼び出し元のウィンドウにフォーカスし続けます。Chrome 96 以降では、デモコードを試して、この機能の動作を確認できます。

Priority Hints

Priority Hints では、デベロッパーが設定する "importance" 属性が導入され、計算されるリソースの優先度を変更することができます。サポートされる importance 属性の値は、"auto"、"low"、と "high" です。Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールできるようにします。ブラウザでは、リソースのタイプ、可視性、プリロードのステータスなど、多くの要素がリソースの優先度に影響を及ぼします。

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

プリフライトなしに単純な Range ヘッダー値を許可

プリフライト リクエストなしに、単純な Range ヘッダーを指定してリクエストを送信できるようになりました。CORS リクエストでは、プリフライト リクエストをトリガーせずに、Range ヘッダーを限定的な方法（1 つの有効な範囲のみ）で使用できます。

デスクトップのバックフォワード キャッシュ

バックフォワード キャッシュにページが格納され、クロスサイト ナビゲーションをした後でも、以前にアクセスしたページへの即時ナビゲーションが可能になります。

Cross-Origin-Embedder-Policy: credentialless

Cross-Origin-Embedder-Policy には、クロスオリジン no-cors リクエストで認証情報（Cookie やクライアント証明書など）を省略できるようにする新しい credentialless オプションが追加されます。COEP:require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。COEP: require-corp を使用して、クロスオリジン分離のオプトインを大規模に導入することは難しく、すべてのサブリソースで明示的にオプトインしなければならなくなります。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、ソーシャル メディア全般、フォーラムなど）では、依存関係の問題が発生します。

CSS

:autofill 疑似クラス

新しい autofill 疑似クラスを使用すると、自動入力されるフォーム要素のスタイルを設定できます。これは、:-webkit-autofill 疑似クラスの標準化として導入されており、WebKit ではすでにサポートされています。Firefox は、この標準バージョンをサポートします。

封じ込めが適用される場合に body スタイルからビューポートへの伝播を無効化

writing-mode、direction、background など、一部のプロパティは、body からビューポートに伝播されます。CSS コンテナクエリの無限ループを防ぐために、仕様と実装が変更され、HTML または BODY にレイアウトの封じ込めが適用される際にこれらのプロパティが伝播されなくなりました。

font-synthesis プロパティ

font-synthesis CSS プロパティは、フォント ファミリーにフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。

EME MediaKeySession が閉じられた理由

MediaKeySession.closed プロパティは、enum を使用して、MediaKeySession オブジェクトが閉じられた理由を示すようになります。この closed プロパティは、セッションが閉じたときに解決される Promise を返します。以前は Promise が解決されるだけでしたが、文字列として解決されるようになり、閉じられた理由を示します。返される文字列は、"internal-error"、"closed-by-application"、"release-acknowledged"、"hardware-context-reset"、"resource-evicted" のいずれかです。

HTTPS DNS レコードでの HTTP から HTTPS へのリダイレクト

Chrome では、DNS（ドメイン名サービス）から HTTPS レコードが利用できる場合は、常に HTTPS 経由でウェブサイトに接続します。

EventTiming の interactionID

PerformanceEventTiming インターフェースに interactiveID と呼ばれる属性が含まれるようになりました。これは、ブラウザが生成する ID であり、複数の PerformanceEventTiming エントリが同じユーザー操作に対応する場合、これらのエントリをリンクできるようにします。現在、デベロッパーは Event Timing API を使用して、関心のあるイベントのパフォーマンス データを収集できます。ただし、同じユーザー操作に対応するイベントをリンクすることは困難です。たとえば、ユーザーがタップしたときなら、pointerdown、mousedown、pointerup、mouseup、click など、多くのイベントが生成されます。

新しいメディアクエリ : prefers-contrast

Chrome は、 'prefers-contrast' と呼ばれる新しいメディアクエリをサポートします。そのため、ウェブ制作者は、オペレーティング システムで設定されたユーザーのコントラスト設定（具体的には、macOS のコントラストを強調したモードと Windows のハイ コントラスト モード）にウェブ コンテンツを合わせることができます。有効な選択肢は、'more'、'less'、'custom'、または 'no-preference' です。

デスクトップ PWA の一意の ID

ウェブアプリ マニフェストで任意の id フィールドがサポートされ、ウェブアプリをグローバルに特定できるようになりました。id フィールドがない場合、PWA は start_url にフォールバックします。現時点で、このフィールドはデスクトップのみでサポートされます。

PWA の URL プロトコル ハンドラ登録

ウェブ アプリケーションがインストール マニフェストを使用して、カスタム URL プロトコル / スキームのハンドラとして自身を登録できるようにします。多くの場合、オペレーティング システム アプリケーションは自身をプロトコル ハンドラとして登録して、見つけやすさと使用率を向上します。ウェブサイトは、すでに registerProtocolHandler() を介してスキームを処理するように登録できます。この新機能はもう一歩踏み込んで、カスタム スキーム リンクが呼び出されたときに、ウェブアプリを直接起動できるようにします。

WebAssembly

コンテンツ セキュリティ ポリシー

Chrome のコンテンツ セキュリティ ポリシーが強化され、WebAssembly との相互運用性が向上しています。wasm-unsafe-eval は、WebAssembly の実行をコントロールします（JavaScript の実行には影響しません）。また、script-src ポリシーに WebAssembly が含まれるようになりました。

参照型

WebAssembly モジュールで JavaScript オブジェクトや DOM オブジェクトへの参照を保持できるようになりました。具体的には、これらの参照は、引数として渡したり、ローカル変数やグローバル変数に格納したり、WebAssembly.Table オブジェクトに格納したりできます。

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

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

PaymentRequest API の "basic-card" 支払い方法

PaymentRequest API では、"basic-card" 支払い方法が非推奨となっています。その使用率は低いうえ、低下し続けています。この支払い方法の購入手続きまでの時間や購入完了率は、他の支払い方法を下回っています。デベロッパーは、代わりとして他の支払い方法に切り替えることができます。たとえば、Google Pay、Apple Pay、Samsung Pay などの支払い方法です。

削除までのタイムライン :

• Chrome 96: "basic-card" 支払い方法は、レポーティング API で非推奨となります。
• Chrome 100: "basic-card" 支払い方法は削除される予定です。

Reviewed by Eiji Kitamura - Developer Relations Team

Google for Startups Accelerator のメンターを募集します。

Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。そのため、Google では、Google for Startups Accelerator というスタートアップを支援するアクセラレータプログラムを日本でも継続的に行っております。

この度、Google for Startups Accelerator のプログラムにおいて、参加するスタートアップに対して技術的メンタリングを提供してくださるメンターを募集いたします。メンターの方にはスタートアップへのメンタリングを通じて、 テクノロジーを活用した社会、経済、環境といったさまざまな分野の問題解決への取り組みをともに解決し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることへの貢献を一緒に行っていければと考えています。

メンターとして参画してくださる方、ぜひこちらのフォームよりご応募ください。

Posted by Takuo Suzuki - Developer Relations Team

この記事は Chrome チーム、デベロッパー アドボケート、Eiji Kitamura による Chromium Blog の記事 "Sunsetting the 'basic-card' payment method in the Payment Request API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。