Web OTP API
Web OTP API（旧称 SMS Receiver API）は、Android スマートフォンに特別な SMS メッセージが届いた際、ユーザーが OTP をウェブページに入力するのに役立ちます。
電話番号の所有者を確認する場合、SMS でワンタイム パスワード（OTP）を送り、ユーザーが手動でそれを入力（またはコピーして貼り付け）しなければならないのが一般的です。この手動によるフローでは、ユーザーは SMS アプリを開いてコードを確認してからウェブアプリに戻ってくる必要があります。Web OTP API を使えば、ユーザーがワンタップでコードを入力できるようになります。
詳しくは、
ウェブで Web OTP API を使って電話番号を確認するをご覧ください。
Web Animations
ウェブでのアニメーションは、ユーザーがデジタル空間を移動する、アプリやサイトを記憶する、プロダクトの使用方法についてヒントを提供する、といった場合に役立ちます。このたび、Web Animations API を使ってウェブのアニメーションをさらに細かく制御できるようになりました。
この API の一部はしばらく前から利用できるようになっていましたが、Chrome での新しい実装は開発における 1 つのマイルストーンになっています。仕様への準拠度が向上しているだけでなく、Chrome が効果を組み合わせる方法を制御する複合操作をサポートするようになり、置換可能なイベントを実現するたくさんの新しいフックも提供されています。さらに、この API は Promise もサポートしています。これにより、アニメーションの順序付けや、アニメーションと他のアプリの機能を連動させる方法を細かく制御できるようになっています。
ウェブ アニメーションの詳しい情報や使い方については、
Chromium 84 での Web Animations API の改善をご覧ください。
オリジン トライアル
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、
オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、
ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。
新しいオリジン トライアル
Cookie Store API
Cookie Store API は、
HTTP Cookie を Service Worker に公開するとともに、document.cookie に代わる非同期的な仕組みを提供します。
Idle Detection
Idle Detection API は、ユーザーがアイドルなときをデベロッパーに通知します。これは、キーボード、マウス、画面の操作がない、スクリーンセーバーの起動、画面のロック、別の画面への移動などのタイミングを意味します。デベロッパーが定義したしきい値を超えると、通知がトリガーされます。詳細については、
Idle Detection API でアイドル状態のユーザーを検知するをご覧ください。
Origin Isolation
Origin Isolation は、ウェブ デベロッパーが特定のクロスオリジン同一サイトアクセス機能の放棄をオプトインできるようにします。これは、document.domain による同期スクリプトと
WebAssembly.Module インスタンスの
postMessage() 呼び出しを指します。これにより、ブラウザの実装テクノロジーの自由度が上がります。具体的には、Chrome はこれをヒントとして利用し、オリジンを自身のプロセス内に格納して、リソースやプラットフォームの制限下に置くようになります。
Site Isolation（サイトごとにプロセスを分けること）は、ウェブサイトをお互いに守り合うための最新技術です。古くからある機能の一部が原因で、この保護境界とオリジン境界を合わせることが難しくなっています。Origin Isolation を使うと、デベロッパーはこういった以前の機能を自発的に放棄し、引き替えに分離性を向上させることができます。
WebAssembly SIMD
WebAssembly SIMD は、プラットフォームに依存しない方法で
ハードウェア SIMD 命令を WebAssembly アプリケーションに公開します。SIMD 提案には、パックデータのさまざまな型を表すために用いられる新しい 128 ビット値型と、パックデータを対象とした複数のベクトル演算が導入されています。
SIMD は、データレベルの並列化を利用してパフォーマンスを大きく向上させることができることに加え、ネイティブ コードを WebAssembly にコンパイルする場合にも役立ちます。
完了したオリジン トライアル
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
Content Indexing API
Content Indexing API のオリジン トライアルは終了しました。この機能は、ウェブアプリが既にキャッシュしているコンテンツのメタデータを提供します。具体的には、保存されたメディアを表示する HTML ドキュメントの URL を保存します。この新しい API を使えば、リソースの追加、一覧表示、削除ができます。ブラウザはインデックス内にあるこの情報を使い、オフライン対応コンテンツのリストを表示できます。詳しくは、
Content Indexing API でオフライン対応ページをインデックスに登録するをお読みください。
Promise ベースの Wake Lock API
Wake Lock API が Promise を使うようにアップデートされています。Wake Lock API を使うと、標準的で安全な方法により、画面や CPU サイクルの省電力モードといったいくつかの端末機能を停止できます。このアップデートは、古い API のいくつかの欠点に対処します。古い API は、画面のウェイクロックに制限があり、一部のセキュリティやプライバシーの問題に対処できていませんでした。
今回のリリースに追加されたその他の機能
アプリのショートカット
ユーザーの生産性向上と重要なタスクへの再エンゲージメント促進のため、Android 版の Chrome がアプリのショートカットをサポートするようになりました。これによりウェブ デベロッパーは、ユーザーが頻繁に使う必要がある一般的なアクションへのクイック アクセスを提供できます。既にプログレッシブ ウェブアプリとなっているサイトでは、ウェブアプリ マニフェストに項目を追加するだけでショートカットを作成できます。詳しくは、
アプリのショートカットでものごとをすばやく行うをご覧ください。
イメージ Mixed Contents の自動アップグレード
"Mixed Contents（混合コンテンツ）"とは、HTTPS ページが安全でない HTTP を通してスクリプトやイメージなどのコンテンツを読み込む場合を指します。これまで、混合イメージの読み込みは許可されていましたが、Chrome 80 で鍵アイコンは取り除かれ、それに代わって Not Secure が表示されるようになりました。これはわかりにくく、デベロッパーに対して安全でないコンテンツの読み込みを思いとどまらせるには不十分でした。これは、ユーザーのデータの機密性や整合性への脅威です。Chrome 84 以降では、
混合イメージ コンテンツは https にアップグレードされ、アップグレード後に読み込みに失敗した場合はブロックされます。今後のリリースでは、オーディオと動画の Mixed Contents の自動アップグレードも
予定されています。
安全な（HTTPS）コンテキストからの安全でないダウンロードのブロック
Chrome では、安全なコンテキストから開始される安全でない方法で提供されるダウンロード（「Mixed Contents のダウンロード」）をブロックする予定です。悪意のあるファイルがダウンロードされると、Chrome が適用するすべての保護を迂回できる可能性があります。さらに Chrome では、安全なページで安全でないダウンロードが開始された場合、セキュリティ インジケーターをダウングレードすることによってユーザーに警告することはなく、また、警告できません。その理由は、リクエストが行われるまで、そのアクションが安全でないダウンロードを開始するかどうかを確実に知ることはできないためです。
PC 版の Chrome 84 では、ユーザーに対する警告の表示が開始されます。Chrome 88 では、安全でないダウンロードは完全にブロックされる予定です。Android では、Chrome 85 までは警告は表示されません。詳しくは、
Google Chrome で安全でないダウンロードからユーザーを保護するをご覧ください。
ワーカーの ReportingObserver
Chrome 69 で追加された ReportingObserver API は、サポートの終了やブラウザの介入に応答して呼び出される JavaScript コールバック関数を提供します。このレポートは、保存、サーバーへの送信、任意の JavaScript を使った処理が可能です。この機能は、実際の端末で行われたサイトの操作に関する、より有用な知見をデベロッパーに提供することを目的としています。この API は、Chrome 84 以降でワーカーに公開されます。API の詳細については、
ReportingObserver API でコードの健全性を知るをご覧ください。
Resize Observer のアップデート
Resize Observer API は、最新の仕様に準拠するためにアップデートされました。ResizeObserverEntry には 3 つの新しいプロパティ
contentBoxSize、
borderBoxSize、
devicePixelContentBoxSize があり、監視している DOM 機能についてより詳しい情報を提供します。この情報は
ResizeObserverSize オブジェクトの配列として返されます（これも新たに追加されました）。機能のアップデートなど、この API に関する一般的な情報については
ResizeObserver をご覧ください。要素の
document.onresize のような動作になっています。
revert キーワード
revert キーワードは、
要素のスタイルをブラウザのデフォルトにリセットします。
プレフィックスなしの appearance CSS プロパティ
CSS で、
-webkit-appearance がプレフィックスなしの
appearance として利用できるようになります。
プレフィックスなしの ruby-position CSS プロパティ
Chrome で
ruby-position プロパティがサポート
されるようになりました。これはプレフィックスなしの -webkit-ruby-position で、ルビを付ける位置を制御します。このプロパティには 3 つの値
over、
under、
inter-character がありますが、Chrome は最初の 2 つのみを実装しています。この変更により、機能が Firefox と同等になります。
Web Authenticator API: クロスオリジン iframe のサポート
機能ポリシーで有効化されている場合、
クロスオリジン iframe からの Web Authentication 呼び出しがサポートされます。これにより、Chrome が
Web Authentication Level Two 仕様に準拠することになります。
JavaScript
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.4 が組み込まれます。具体的には、以下の変更点が含まれます。
最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
プライベートなメソッドとアクセッサ
ライブラリ作成者が状態と動作をクラス内に隠蔽すると、明確で安定したインターフェースを提示しつつ、水面下で内部コードを徐々に変更できます。
Chrome 74 で提供されたプライベート クラス フィールドにより、クラスとインスタンスにプライベート フィールドが導入されました。今回の Chrome 84 では、
メソッドとプロパティもプライベートにすることができます。この拡張により、任意の JavaScript クラス要素をプライベートにできるようになります。
Weak References
V8 エンジンが JavaScript オブジェクトへの Weak References をサポートするようになりました。これによりウェブ デベロッパーは、関連オブジェクトを生かし続けることなく、（オプションで）関連オブジェクトがガベージ コレクションされた後に実行されるクリーンアップ ルーチンを定義できるようになります。詳細については、
Weak References とファイナライザをご覧ください。
サポートの終了と機能の削除
このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。
現在サポートが終了している機能および
以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
CSSStyleSheet.replace() の @import ルールの削除
コンストラクタブル スタイルシートの元の仕様では、次のような呼び出しが可能でした。
sheet.replace("@import('some.css');")
このユースケースは削除されます。
replace() の呼び出しで置換されるコンテンツ内に
@import ルールが見つかった場合、例外がスローされるようになりました。
TLS 1.0 と TLS 1.1 の削除
TLS（Transport Layer Security）は HTTPS の安全性を保証するプロトコルで、ほぼ 20 年前に作成された TLS 1.0 や、その前身の SSL までさかのぼることができる長い歴史があります。TLS 1.0 と 1.1 には、どちらもたくさんの脆弱性があります。
- TLS 1.0 と 1.1 は、Finished メッセージのトランスクリプト ハッシュに MD5 と SHA-1 を使っていますが、これらはどちらも弱いハッシュです。
- TLS 1.0 と 1.1 は、サーバー署名に MD5 と SHA-1 を使っています。（注: 証明書の署名ではありません。）
- TLS 1.0 と 1.1 は、RC4 および CBC 暗号化のみをサポートしています。RC4 は、解読可能であることがわかってから削除されています。TLS の CBC モードの構成には欠陥があり、攻撃に対して脆弱です。
- また、TLS 1.0 の CBC 暗号化では、初期化ベクトルが誤って構成されます。
- TLS 1.0 は PCI-DSS 互換ではなくなっています。
以上の問題を回避するには、TLS 1.2 をサポートする必要があります。TLS ワーキング グループは、TLS 1.0 と 1.1 を非推奨としています。現在、Chrome もこれらのプロトコルを非推奨としています。
Reviewed by
Eiji Kitamura - Developer Relations Team
