変更前 : 458 ミリ秒（そのうち 432 ミリ秒が Lock/Unlock/KiPageFault）変更後 : 27 ミリ秒
変更前 : 1 秒あたり 1.32 MB の割り当てが 30 回（30 fps のフレーム 1 つにつき 1 回。さらに高いフレームレートでは割り当てがさらに多くなる）、10 秒間で合計 396 MB変更後 : 0 回
変更前 : 36 ミリ秒変更後 : 0 ミリ秒
Chrome は、新しいパスワードを生成したり、保存されたパスワードの自動入力や同期をしたり、侵害されたパスワードについてユーザーに警告したりすることができます。つまり、ユーザーは自分でパスワードを管理する必要がなくなります。しかし、複数のドメインで同じアカウント管理バックエンドを利用している場合（たとえば、https://www.example.com と https://www.example.co.uk のような複数のトップレベル ドメイン）、Chrome はドメインをまたいで自動入力をしてくれません。その結果、異なるドメインに対して同じパスワードのエントリが 2 つできることになり、同期がとれなくなることもあります。
バージョン 91 以降の Chrome では、Digital Asset Links（DAL）で関連付けられたドメイン間で、保存したパスワードの自動入力が提案されます。DAL は、Android アプリとウェブサイトを関連付けるために、2015 年から利用されています。Chrome 91 では、サイト間で DAL を設定すると、Chrome がサイトをまたいでユーザーのログインをアシストしてくれます。DAL の関連付けをするには、両方のドメインの /.well-known/assetlinks.json に DAL 構文に従った JSON ファイルを配置する必要があります。
DAL の関連付けの詳しい設定方法については、すべての連携サイトで Chrome がログイン認証情報を共有できるようにするをご覧ください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 4 月 22 日の時点で Chrome 91 はベータ版です。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジントライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジントライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジントライアル デベロッパー コンソールをご覧ください。
新しいウェブアプリ マニフェストのメンバーとして、capture_links が追加されます。これを使うと、ユーザーがインストール済みのウェブアプリのスコープ内でページを移動したときの動作をコントロールできます。ユーザーがアプリへのリンクをクリックしたときに自動的に新しい PWA ウィンドウを開いたり、モバイルアプリのようなシングル ウィンドウ モードにしたりすることが可能です。オリジン トライアルに登録すると、オリジントライアル ダッシュボードで詳細を確認できます。
capture_links
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 の試験運用をご覧ください。オリジン トライアルに登録すると、オリジントライアル ダッシュボードで詳細を確認できます。
WebXR アプリケーションで、ユーザーの環境内の平面についてのデータを取得できるようになります。これにより、低い処理能力でも高いユーザー エクスペリエンスを実現できます。この機能なしに平面検出をするには、MediaDevices.getUserMedia() のデータを利用してカスタムのコンピュータ ビジョン アルゴリズムを実行する必要があります。通常、このようなソリューションは、AR エクスペリエンスに求められる質や精度を満たせず、ワールドのスケールもサポートされません。オリジン トライアルに登録すると、ダッシュボードで詳細を確認できます。
MediaDevices.getUserMedia()
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
サイトがユーザー エージェントに対し、ページよりもユーザー エージェントのほうが得意とする方法で電池寿命を節約し、CPU の利用を最適化することを推奨できるようになります。たとえば、フレームレートを落とすことを許可したり、スクリプトの速度を下げることを許可したりできます。詳しくは、解説をご覧ください。
ユーザーがページ内検索をし、ある要素で一致するテキストが見つかると、beforematch イベントが発行されます。これまでは、content-visiblity が hidden に設定されていた場合、このイベントは発行されませんでした。content-visibility: hidden-matchable CSS プロパティは、content-visibility: hidden と同じように動作しますが、ページ内検索で非表示テキストを検索でき、beforematch イベントも発行されます。beforematch イベントと content-visibiliy: hidden-matchable を組み合わせて使うと、ページ内検索に反応して非表示コンテンツを展開するウェブサイトを実現できます。詳しくは、解説をご覧ください。
beforematch
content-visiblity
hidden
content-visibility: hidden-matchable
content-visibility: hidden
content-visibiliy: hidden-matchable
WebAssembly SIMD は、プラットフォームに依存しない方法でハードウェア SIMD 命令を WebAssembly アプリケーションに公開します。これにより、さまざまな種類の圧縮データを表す新しい 128 ビット型や、圧縮データを扱ういくつかのベクトル演算を導入できます。SIMD は、データレベルの並列化を利用してパフォーマンスを大きく向上できることに加え、ネイティブ コードを WebAssembly にコンパイルする場合にも役立ちます。詳しくは、WebAssembly SIMD の V8 機能の解説をご覧ください。
サイト分離の有無に基づいた performance.now() と関連するタイムスタンプの精度を下げる処理が、プラットフォーム間で一貫した動作になりました。これにより、デスクトップ版の分離されていないコンテキストでは、解像度が 5 マイクロ秒から 100 マイクロ秒に下がります。また、Android 版でクロスオリジン分離されているコンテキストでは、解像度が 100 マイクロ秒から 5 マイクロ秒に上がります。
performance.now()
デスクトップ版で、アプリがクリップボードからファイルを読み取ることができるようになります（ただし、クリップボードにファイルを書き込むことはできません）。アプリは、クリップボードのファイルに読み取り専用でアクセスします。
async function onPaste(e) { let file = e.clipboardData.files[0]; let contents = await file.text(); }
リストマーカーや CSS カウンターで CSS の @counter-style ルールを使うと、ウェブ制作者がカスタムのカウンター スタイルを指定できます。これは国際化に役立ちます。この変更は、以下を除くすべての CSS Counter Styles Level 3 機能で実装されます。
@counter-style
speak-as
symbols()
:host() と :host-context() 疑似クラスが、<compound-selector-list> に加えて単一の <compound-selector> を受け取れるようになります。
:host()
:host-context()
<compound-selector-list>
<compound-selector>
フォーム コントロールの外観が刷新され、ユーザー補助機能とタッチのサポートが向上します。これは Microsoft と Google の共同作業です。詳しい情報は、以前の CDS トークや Microsoft のブログ投稿をご覧ください。
今回のリリースでは、すでに他のプラットフォームでリリースしたものと同じフォーム コントロール UX を Android 版にも提供します。新しいフォーム コントロールには、ダークモードでフォーム コントロールやスクロールバーが自動的に暗い色になる機能が含まれています。
ダークモードは、ウェブ制作者がウェブページをダークモードで表示できるようにするユーザー補助機能です。これを有効にすると、ユーザーは Android デバイスでダークモード設定を切り替えることにより、サポートされているウェブサイトをダークモードで表示できます。ダークモードは低光量環境で目にやさしく、電池の消費も少なくなります。
GravitySensor インターフェースは、重力の 3 軸読み取り値を提供します。これまでも、Accelerometer の読み取り値から LinerAccelerometer の読み取り値を除くことで、このインターフェースで提供される値に近い値を算出することができました。
GravitySensor
Accelerometer
LinerAccelerometer
ウェブアプリで File System Access API を使う場合、作成または読み込みをするファイルやディレクトリの名前と場所を提案できるようになります。これにより、ユーザー エクスペリエンスが向上し、ウェブアプリの動作がシステムアプリに近づきます。File System Access API の詳細については、File System Access API: ローカル ファイルへのアクセスを簡単にするをご覧ください。
パーミッション ポリシーで許可されている場合、WebOTP API をクロスオリジン iframe で利用できるようになります。WebOTP API を使うと、プログラムによってそのオリジンが宛先となった特別な形式の SMS メッセージからワンタイム コードを読み取り、ユーザーの手間を減らすことができます。認証を扱う iframe は、多くのサイトに埋め込まれています。
Chrome は、Chromium の WebSockets over HTTP/2（RFC 8441 で規定）をサポートします。これは、すでに HTTP/2 で接続しており、サーバーが仕様で規定されている HTTP/2 の SETTINGS パラメータによって WebSockets over HTTP/2 のサポートをアドバタイズしていて、安全な WebSockets リクエストが行われた場合のみ利用されます。
2015 年より、デベロッパーは Digital Asset Links（DAL）を使って Android アプリとウェブサイトを関連付け、ユーザーのログインをアシストしています。複数のドメインで同じアカウント管理バックエンドを共有している場合は、それらを相互に関連付けることで、Chrome のパスワード マネージャーがすべての連携するウェブサイトで保存した認証情報を提案するようになります。詳しくは、すべての連携サイトで Chrome がログイン認証情報を共有できるようにするをご覧ください。
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.1 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
JavaScript が Service Worker でモジュールをサポートします。コンストラクタの type 属性に 'module' タイプを設定すると、ワーカーのスクリプトが ES モジュールとして読み込まれ、ワーカーのコンテキストで import 文が利用できるようになります。この機能を使うと、組み合わせ可能なプログラムを簡単に書けるようになり、ページやワーカー間でプログラムを共有しやすくなります。
'module'
import
#foo in obj 構文により、オブジェクトでプライベート フィールドの存在チェックをできるようになります。
#foo in obj
このバージョンの Chrome では、デベロッパーに関連するサポートの終了や機能の削除はありません。以前の機能の削除リストは、ChromeStatus.com をご覧ください。
Google Open Source Live イベントシリーズを開催いたします。
第 8 回目の今回のイベントは「Open data lake day」です。
Google に在籍するデータ アナリティクスのエキスパートが、オープンテーブル フォーマットや、イノベーションとクラウドのバリアの克服方法などについてお話しします。
セッション中には質問を投稿できるフォーラムが立ち上がります。Google 社員に直接質問ができるチャンスとなりますのでぜひ、ご活用ください。
また、セッション終了後に Google Meet にてアフターパーティーを開催いたします。他の参加者の方達と交流したり、Google オリジナルグッズが当たるクイズゲームなどをご用意しておりますのでぜひ、ご参加ください。
日本語版のイベントでは、日本語での MC、日本語の字幕付きセッション、そして日本語開催のアフターパーティーとなります。
英語版をご希望の方は太平洋時間の 9:00 am PST、日本語版をご希望の方は日本時間の 9:00 am JST にご参加ください。
事前お申込み受付中 : http://goo.gle/OpenDataLakeDayJP
名 称 『Open data lake day』
日 程 日本語版 : 5 月 7 日（金）9:00 am - 11:00 am JST （日本時間）
英 語 版 : 5 月 6 日（木）9:00 am - 11:00 am PST （太平洋時間）
対 象 開発エンジニア、インフラ エンジニア、運用エンジニア
参加費 無料（事前登録制）
登 録 http://goo.gle/OpenDataLakeDayJP
オープンソースによってイノベーションとクラウドの壁を取り除く
アマー・アワダラ
クラウド・デベロッパー・リレーションズ 担当 副社長 (Google)
バージョン 90 より、Chrome のアドレスバーで https:// がデフォルトとして使われるようになります。これによってプライバシーが向上し、HTTPS をサポートするウェブサイトにアクセスしたときの読み込み速度も上がります。Chrome ユーザーが手動で URL を入力してウェブサイトを開くとき、多くの場合は “http://” や “https://” を含めません。たとえば、アドレスバーに “https://example.com” ではなく “example.com” と入力することがよくあります。このとき、ユーザーが初めてそのウェブサイトを訪れる場合は、これまでの Chrome の動作ではデフォルトのプロトコルとして http:// が選択されていました 1。これは、ウェブの多くが HTTPS をサポートしていなかった過去においては、現実的なデフォルトでした。
今後は、プロトコルを指定せずに入力されたほとんどのナビゲーションで、Chrome のデフォルトが HTTPS になります 2。HTTPS は、安全性が向上しているだけでなく、すべての主要プラットフォームの Chrome で最も広く使われているスキームです。この変更により、セキュリティとプライバシーが明らかに向上することに加え、HTTPS をサポートするサイトの初回読み込み速度も上がります。Chrome が HTTPS エンドポイントに直接接続し、http:// から https:// にリダイレクトする必要がなくなるからです。まだ HTTPS をサポートしていないサイトでは、HTTPS による試行が失敗した後、HTTP にフォールバックします（名前の不一致、信頼できない自己署名証明書などの証明書エラーや、DNS の解決失敗などの接続エラーが発生した場合も含みます）。この変更は、まずバージョン 90 の Chrome デスクトップ版と Android 版にロールアウトされ、その後近いうちに iOS 版の Chrome にもリリースされます。
HTTPS では、ユーザーがウェブサイトに入力した機密情報が攻撃者や盗聴者によって傍受または改ざんされないように、ネットワークに送られるトラフィックを暗号化してユーザーを保護します。Chrome では、HTTPS をウェブのデフォルトのプロトコルにするための取り組みが行われています。今回の変更で、デフォルトで常に安全な接続を使うことに一歩近づきます。
1 主な例外の 1 つは、HSTS プリロード リストに含まれるサイトです。これらのサイトでは、常にデフォルトが HTTPS になります。 2 IP アドレス、シングルラベル ドメイン、test/ や localhost/ などの予約されているホスト名では、引き続き HTTP がデフォルトになります。
2018 年に発売された Pixel 3 には、Titan M と呼ばれる新しい改ざん防止ハードウェア エンクレーブが搭載されました。これは、Pixel のソフトウェアとファームウェアの信頼の基点となるだけでなく、StrongBox を使った Android アプリ用の改ざんできない鍵ストレージも実現しています。StrongBox は、ハードウェアのセキュリティ モジュール内にある Keymaster HAL の実装です。これは Android デバイスにとっての重要なセキュリティ強化策であり、これまで実現できなかった機能を検討する道を開くものです。
StrongBox と改ざん防止ハードウェアは、新たに登場する次のようなユーザー機能の重要な要件になりつつあります。
こういった機能は、すべて改ざん防止ハードウェアで実行する必要があり、アプリケーションの実行ファイルやユーザーのデータ、鍵、財布などの整合性を守ります。現在、ほとんどの最新スマートフォンには、セキュア エレメント（SE）と呼ばれる個別の改ざん防止ハードウェアが含まれています。Google は、この SE こそが、上記のような新しい消費者向けのユースケースを Android に導入するための最善の道であると確信しています。
こういった新しい Android のユースケースの採用を加速するため、Android Ready SE Alliance を設立したことをお知らせします。SE ベンダーと Google は、すぐに使えるオープンソースの検証済み SE アプレットを作成するため、力を合わせています。今日（元記事公開当時）、SE 向け StrongBox の一般提供（GA）版を公開します。このアプレットは、OEM パートナーによって作成、認定されています。現在のところ、Giesecke+Devrient、Kigen、NXP、STMicroelectronics、Thales がこのアプレットを公開しています。
覚えておくべき重要な点は、これらの機能はスマートフォンやタブレットだけのものではないことです。StrongBox は、WearOS、Android Auto Embedded、Android TV でも利用できます。
OEM パートナーがデバイスで Android Ready SE を使うには、以下の作業が必要です。
Google はエコシステムと連携し、以下のアプレットと、対応する Android 機能のリリースを優先して作業を進めています。
いくつかの Android OEM パートナーは、すでにデバイスで Android Ready SE を採用しています。OEM パートナーと連携して、このような次世代の機能をユーザーに提供できることを楽しみにしています。
詳しくは、Android セキュリティとプライバシーのデベロッパー サイトをご覧ください。
