特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2020 年 10 月 15 日の時点で Chrome 87 はベータ版です。
Web Authentication のテストは、コードをテストするデバイスが必要なので長らく困難でした。Chrome 87 より、DevTools の新しいパネルを使って認証のエミュレートやデバッグができるようになります。この DevTools のパネルは、[More options]、[More tools]、[WebAuthn] の順に選択すると表示されます。詳しい使用方法は、DevTools の新機能（Chrome 87）の WebAuthn のセクションをご覧ください。
部屋単位のビデオ会議ソリューションでは、ソフトウェアがカメラでミーティングの参加者を映せるよう、カメラをパン、チルト、ズームする機能が搭載されます。Chrome 87 より、MediaDevices.getUserMedia() と MediaStreamTrack.applyConstraints() のメディア トラック制約を使って、ウェブサイトからカメラのパン、チルト、ズーム機能にアクセスできるようになります。
MediaDevices.getUserMedia()
MediaStreamTrack.applyConstraints()
この機能は、ユーザーが明示的にアクセス許可を与えた場合にのみ操作できます。新機能の詳しい使い方やデモは、カメラのパン、チルト、ズームを制御するをご覧ください。
物理プロパティを論理プロパティで補完するというのが、長年にわたる CSS のトレンドになっています。中国語の縦書きテキストやアラビア語など、ヨーロッパ式以外のテキストでは、左から右や上から下に読むことを想定した言語のプロパティは動作しません。最新の CSS では、テキストの軸（方向）を扱うルールは、start や end のように flow-relative（テキストの方向に相対的）な語句を使って提供されています。
Chrome でこれを最初に実装したのは、CSS Logical Properties and Values 仕様によるおおまかな flow-relative 機能の実装でした。Chrome 87 では、この省略形が導入され、 このような論理プロパティと値が少しばかり書きやすくなります。具体的には、これまで複数の CSS ルールで書いていたことを 1 つのルールで書けるようになります。たとえば、margin-block-start と margin-block-end という別々のルールを、1 つの margin-block プロパティを使って書けるようになりました。
margin-block-start
margin-block-end
margin-block
現在 Chrome でサポートされているすべての flow-relative の省略形の一覧や、その使い方の説明については、flow-relative の省略形による論理レイアウトの拡張をご覧ください。その他の CSS 関連のアップデートについては、下の CSS のセクションをご覧ください。
オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
Cookie Store API は、HTTP Cookie を Service Worker に公開するとともに、document.cookie に代わる非同期的な仕組みを提供します。
document.cookie
Chrome 87 では、Cross-Origin Isolation に関する多数の変更が行われています。Chrome は、Cross-Origin Isolation エージェント クラスタのエージェント クラスタキーとして、サイトではなくオリジンを使うようになります。Cross-Origin Isolation エージェント クラスタでは、document.domain の変更はサポートされなくなります。この変更と合わせて、window.crossOriginIsolated も導入されます。これは、Cross-Origin Isolation が必要な API の使用が許可されているかどうかを示すブール値です。サポートされる API は以下になります。
document.domain
window.crossOriginIsolated
SharedArrayBuffer
performance.measureMemory()
詳しくは、Making your website "cross-origin isolated" using COOP and COEP をご覧ください。
disallowdocumentaccess プロパティを追加し、同じ親ドキュメント内の Same-Origin から iframe 間のクロスドキュメント スクリプティングを許可しないようにします。これにより、Same-Origin の iframe を別々のイベントループに入れるようにもなります。
disallowdocumentaccess
長時間実行されるスクリプトによって、ユーザーの入力がブロックされることがあります。アプリでユーザーのアクションとレスポンスの間にタイムラグが発生すると、ユーザー エクスペリエンスが悪化します。これに対処するため、Chrome に isInputPending() というメソッドが追加されました。このメソッドには、長時間実行するオペレーションから navigator.scheduling を通して呼び出すことでアクセスできます。メソッドの使用例は、ドラフト版の仕様に掲載されています。
isInputPending()
navigator.scheduling
ここ数年の間に主要なブラウザで利用できるようになった HTTP 範囲リクエストを使うと、サーバーがクライアントにリクエストされた範囲のデータをチャンク形式で送信できます。この機能は、大きなメディア ファイルで特に有効です。スムーズな再生を実現し、一時停止や再開の機能を改善できるので、ユーザー エクスペリエンスを向上できます。
従来、範囲リクエストと Service Worker はうまく連携できませんでした。そのため、デベロッパーは回避策を構築せざるを得ませんでした。Chrome 87 より、Service Worker からネットワークに範囲リクエストを渡しても、通常どおり動作するようになります。
範囲リクエストに関する問題の説明や、Chrome 87 の変更点については、Service Worker で範囲リクエストを扱うをご覧ください。
Transferrable Streams で、postMessage() の引数に ReadableStream、WritableStream、TransformStream オブジェクトを渡せるようになります。Stream API では、データ ストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。ストリームは、Web Worker に渡して使うのが一般的です。この流れるようなプリミティブにより、作業を別のスレッドにオフロードできます。
postMessage()
ReadableStream
WritableStream
TransformStream
ワーカーに作業をオフロードすることは、スムーズなユーザー エクスペリエンスを提供する上で重要なことですが、人間工学的に不自然になる可能性があります。Transferrable Streams は、このストリームの問題を解消します。ストリーム自体を転送すると、データは透過的にバックグラウンドにクローンされます。
ontransitionrun、ontransitionstart、ontransitioncancel イベント ハンドラ属性を利用すると、要素、Document オブジェクト、Window オブジェクトに 'transitionrun'、'transitionstart'、'transitioncancel' イベントに対応するイベント リスナーを追加できます。
ontransitionrun
ontransitionstart
ontransitioncancel
'transitionrun'
'transitionstart'
'transitioncancel'
WakeLockSentinel オブジェクトに released という新しいプロパティが追加されます。このプロパティは、sentinel が既にリリースされているかどうかを示します。デフォルトは false で、release イベントがディスパッチされると true になります。この新しい属性によって、ウェブ デベロッパーはロックのリリース タイミングを確認できるようになり、手動でトラッキングする必要はなくなります。
WakeLockSentinel
released
新しい @font-face 記述子が ascent-override、descent-override、line-gap-override に追加され、フォントのメトリックをオーバーライドできるようになりました。これにより、ブラウザやオペレーティング システム間の相互運用性が改善され、OS やブラウザによらず同じサイトで同じフォントが常に同じ外見になります。また、別のグリフで同時に提示される 2 つのウェブフォント間のメトリックを合わせます。さらに、フォールバック フォント用にフォントのメトリックをオーバーライドしてウェブフォントをエミュレートし、Cumulative Layout Shift（ページのレイアウトのずれ）を最小限に抑えます。
@font-face
ascent-override
descent-override
line-gap-override
Chrome でいくつかの新しいテキスト修飾と下線プロパティがサポートされます。これらのプロパティを使うと、下線がテキストのベースラインに近すぎる場合や、下線が途切れる位置が早すぎる場合に対処できます。これは、text-decoration-skip-ink プロパティが導入されたことで起こるようになった問題を解決するものです。新しいプロパティは、text-underline-position の text-decoration-thickness、text-underline-offset、from-font キーワードです。
text-decoration-skip-ink
text-underline-position
text-decoration-thickness
text-underline-offset
from-font
CSS2 では、ブラウザが quotes プロパティのデフォルト値を定義することが許可されていました。これまで、Chrome はそれに従っていました。Chrome 87 は CSS Generated Content Module Level 3 に従い、'auto' キーワードがデフォルト値になります。この仕様では、要素や親要素のコンテンツ言語に基づいてタイポグラフ的に適切な値を引用符に使用する必要があります。
'auto'
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.7 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Chrome は、Atomics.wait() の非同期版である Atomics.waitAsync() をサポートします。プログラマーが Atomics.waitAsync() を使うと、Atomics.wait() と同じように SharedArrayBuffer の位置で待機できますが、返されるのは Promise になります。
Atomics.wait()
Atomics.waitAsync()
Atomics.wait() はスレッドをブロックするので、ブロックが許可されていないウェブブラウザのメインスレッドでは使用できません。この仕組みは、SharedArrayBuffers を通してメインスレッドとワーカー スレッド間の調整を行うことで、人間にとって使いやすい形を実現します。
SharedArrayBuffers
このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
<iframe> タグのアクセス許可ポリシー宣言で、アイテム間の区切り文字としてコンマを利用できなくなります。代わりにセミコロンを使うようにしてください。
<iframe>
Blink は、ほとんど使われていない -webkit-font-size-delta プロパティをサポートしなくなります。フォントサイズを調整したい場合は、代わりに font-size を使うようにしてください。
-webkit-font-size-delta
font-size
Chrome では、FTP URL のサポートを終了して削除する作業が進んでいます。Google Chrome の現在の FTP 実装は、暗号化接続（FTPS）やプロキシをサポートしていません。ブラウザからの FTP の利用率はかなり低く、既存の FTP クライアント機能の改善に注力するのは現実的ではありません。また、影響するすべてのプラットフォームで、機能の豊富な FTP クライアントが利用できます。 Google Chrome 72 以降では、FTP によるドキュメント サブリソースのフェッチと、トップレベル FTP リソースのレンダリングのサポートが削除されています。現在、FTP URL を開くと、リソースの種類によって、ディレクトリ一覧またはダウンロードが表示されます。Google Chrome 74 以降のバグにより、HTTP プロキシを経由した FTP URL へのアクセスがサポートされなくなっています。FTP のプロキシ サポートは、Google Chrome 76 で完全に削除されました。Chrome 86 では、FTP がプレリリース チャンネル（Canary 版とベータ版）で無効になり、安定版のユーザーの 1% でも試験的に無効化されました。 Google Chrome の FTP 実装に残された機能は、暗号化されていない接続でのディレクトリ一覧の表示とリソースのダウンロードのみとなっています。
なお、サポート終了のスケジュールは以下のようになっています。
デフォルトで、FTP サポートは 50% のユーザーに対して無効化されますが、フラグを使うと有効化できます。
FTP サポートが無効化されます。
Chrome はユーザーのパスワードの侵害状況を確認するため、暗号化を施した特別な形式でユーザー名とパスワードを Google に送信します。Google はその情報を使って、侵害が判明している認証情報のリストと突き合わせますが、暗号化した情報からユーザー名とパスワードを取得することはできません。
ウェブサイトのパスワードが侵害されていた場合はユーザーに通知しますが、パスワードを変更する関連フォームを見つけるのは時間がかかることがあります。そこで、".well-known/change-password" URL をサポートします。これにより、Chrome でパスワードの侵害のアラートが表示されると、ユーザーは適切な「パスワード変更」フォームを直接開けるようになります。
この改善に加えて、モバイル版の Chrome にも安全確認を提供します。次のリリースでは、iOS と Android の Chrome に安全確認を導入し、侵害されたパスワードの確認に加え、セーフ ブラウジングが有効になっているかどうか、現在実行している Chrome のバージョンが最新のセキュリティ保護でアップデートされているかどうかの通知を行います。また、iOS 版の Chrome に保存したログイン情報は、他のアプリやブラウザでも自動入力できるようになります。
Chrome 86 では、ユーザーのセキュリティを向上させるたくさんの追加機能もリリースされる予定です。詳しくは、以下の説明をご覧ください。
Android のセーフ ブラウジング保護強化機能
今年、PC 向けにセーフ ブラウジング保護強化機能をリリースしました。これにより、Chrome ユーザーはさらに高度なセキュリティ保護を受けることもできます。
セーフ ブラウジング保護強化機能をオンにすると、Chrome は Google のセーフ ブラウジング サービスとリアルタイムにデータを共有し、先回りでフィッシングやマルウェア、その他の危険なサイトから保護します。ウェブサイトやダウンロードのリアルタイム チェックを有効にすると、予測フィッシング保護によって、フィッシング サイトにパスワードを入力してしまうユーザーは約 20% 減少します。
iOS でのパスワード自動入力の改善
先日、フィッシング攻撃に対する保護として、タッチしてパスワードを自動入力する機能を Android 向けにリリースしました。iOS でもセキュリティを強化するため、パスワードを自動入力する前に生体認証の手続きを追加します。iOS では、Face ID、Touch ID、スマートフォンのパスコードのいずれかを使って認証できます。さらに、[Settings] で Chrome の自動入力を有効にしている場合は、Chrome Password Manager を使って iOS のアプリやブラウザに保存済みのパスワードを自動入力できます。
更新（2020/10/07）: 当初、混合フォームの警告は Chrome 86 でリリースされる予定でしたが、遅延して Chrome 87 になる見込みです。
安全な HTTPS ページの中にも、安全でない機能が含まれる場合があります。今年より Chrome では、安全なページに安全でないコンテンツが含まれる "Mixed Contents" をブロックする保護が行われるようになりました。しかし、HTTPS ページには、その他にもユーザーのセキュリティ リスクとなるものがあります。たとえば、安全でないリンクからのダウンロードの提供、安全でない形でデータを送信するフォームの使用などです。
このような脅威に対するユーザー保護を強化するため、PC と Android の Chrome 86 に混合フォームの警告を導入し、HTTPS ページに埋め込まれた安全でないフォームを送信する前にユーザーに警告します。
さらに、Chrome 86 では、安全なページで安全でないダウンロードを始めると、ブロックされたり警告されたりすることがあります。現時点では、この変更はよく悪用されるファイル形式に対してのみ行われます。しかし将来的には、安全なページでは形式によらず安全なダウンロードのみを開始できるようになる予定です。詳しくは、混合ダウンロードを段階的にブロックする Chrome の計画をご覧ください。
デベロッパーの皆さんは、ユーザーの安全とプライバシーを守るため、安全な接続を使うようにフォームやダウンロードをアップデートしてください。
スペインのマドリードで Firebase Summit 2019 を開催し、Firebase の最新情報をお伝えしたり、プロダクトに関するフィードバックに耳を傾けたりしてから 1 年が経ちました。その後、私たちが知る世界は変わってしまいましたが、Firebase のミッションは変わりません。そのミッションとは、モバイルアプリやウェブアプリの構築や運用を容易にして、デベロッパーの皆さんの成功をサポートすることです。
私たちは、アプリ開発の高速化、ユーザーの分析機能の提供、そしてスケーリングに役立つツールを構築するため、作業を続けています。今年はバーチャルで開催される Firebase Summit で、そのようなアップデートについてお知らせできることを楽しみにしています。太平洋標準時の 10 月 27-28 日、両日とも午前 9 時 30 分（日本時間の翌日午前 2 時 30 分）から開催されます。モバイル端末やノートパソコンを準備して firebase.google.com/summit を開くだけで、どこからでも視聴できます。
直接皆さんとお会いできないのは残念ですが、今年は今まで以上に多くのデベロッパーが参加してくれることを楽しみにしています。
次に、この 2 日間で期待できることをご紹介します。
10 月 27 日午前 9 時 30 分（太平洋標準時）の基調講演では、アプリの構築や運用に Firebase がどう役立つかについてお話しします。基調講演後にはチャットで質問を受け付け、#AskFirebase で Firebase チームがライブで回答します。
最新リリースのモニタリング、ユーザー エンゲージメントの向上、アプリの収益最適化などのトピックを扱う 11 のテクニカル セッションにもご期待ください。各セッションは 2 日間にわたってライブ配信されるので、視聴しながら他のデベロッパーや Firebase チームとチャットできます。さらに、都合のいい時間にオンデマンドで視聴することも可能です。
ハンズオンの学習体験として、Flutter と Firebase を使ってアプリをゼロからコーディングする様子をライブでお見せします。また、新しいデモの他、チュートリアル動画や詳しい手順が付いた Codelab を試して、Firebase を使ったウェブアプリの構築方法などの人気トピックについて学ぶこともできます。
Firebase Summit の詳細については、これから数週間でさらに詳しくお知らせする予定です。それまでの間、最新情報を受け取るためにイベントのページに登録し、Firebase YouTube チャンネルも登録しておきましょう。また、Twitter をフォローして会話に参加してください。
ロック画面と認証の改善点について詳しく説明する前に、いくつかの背景情報をお伝えします。この情報は、今回の改善点における相互の関連性を把握するために役立ちます。今回の変更は、階層化認証モデルのフレームワークに当てはめてみるとイメージしやすいはずです。階層化認証モデルとは、Android に搭載されているすべての認証方式を概念的に分類し、相互の関連性や、この分類に基づく制約をまとめたものです。
信頼できる場所や信頼できるデバイス（そして一般的な第 3 の方式）を使うと、便利な方法でデバイスの内容にアクセスできます。しかし、これらに共通する根本的な問題は、最終的にユーザーの身元確認機能の精度の低さに集約されます。たとえば、信頼できる場所を使っているスマートフォンのロックは、ユーザーの自宅のそばを通り過ぎるだけで解除できるかもしれません。また、既製のソフトウェア無線と多少のスクリプトを使えば、比較的簡単に GPS シグナルを偽装することもできます。信頼できるデバイスも同様で、許可リストに登録された Bluetooth デバイスにアクセスできれば、ユーザーのスマートフォン内のすべてのデータにアクセスできることになります。
そこで、Android 10 の環境階層に大幅な改善が加えられ、第 3 階層は積極的にロックを解除する仕組みからロック解除を延長する仕組みに変わっています。この新しいモードでは、第 3 階層でデバイスのロックを解除できなくなりました。その代わり、最初に第 1 の方式か第 2 の方式を使ってデバイスのロックを解除している場合、最大 4 時間にわたってロック解除状態を継続します。
生体認証の実装には、幅広いセキュリティ特性があります。そこで、次にあげる 2 つの重要な要素を利用して特定の実装のセキュリティを判定しています。
各クラスには、一連の制約が紐付いています。この制約は、それぞれの使いやすさとセキュリティのレベルのバランスをとることを目指したものです。
制約は、生体認証が第 1 階層の認証にフォールバックするまでの時間と、許可されているアプリ統合で表されています。たとえば、クラス 3 の生体認証はタイムアウトまでの時間が最も長く、すべてのアプリ統合オプションを利用できます。一方、クラス 1 の生体認証はタイムアウトまでの時間が最も短く、アプリ統合オプションは提供されません。概要を下の表に示します。完全版を確認したい方は Android Compatibility Definition Document（CDD）をご覧ください。
1 App Integration（アプリ統合）とは、API をアプリに公開すること（例: BiometricPrompt/BiometricManager、androidx.biometric、FIDO2 API などの統合によって）を意味します。
2 Keystore Ingegration（キーストア統合）とは、キーストアを組み込むこと（例: アプリの認証バインドキーをリリースするなど）を意味します。
生体認証を利用すると、高レベルのセキュリティを維持しつつ、ユーザーに利便性を提供できます。ユーザーは生体認証を利用するために第 1 の認証方式を設定する必要があるので、ロック画面の採用が促進されます（生体認証を提供しているデバイスは、そうでないデバイスに比べてロック画面の採用が平均 20% 高くなっています）。これにより、ロック画面が提供するセキュリティ機能のメリットを活用できるユーザーが増えます。具体的には、ユーザーの機密データへの認証されていないアクセスを防ぐことができ、暗号化バックアップなどの第 1 の認証方式によるその他のメリットも受けることができます。さらに、生体認証は、肩越しにのぞき見るショルダー サーフィン攻撃によって PIN やパターン、パスワードを入力するのを見た攻撃者が認証情報を再現しようとする試みを減らすうえでも役立ちます。
ただし、生体認証を使うことによるトレードオフ（発生し得るリスク）をユーザーが理解することが重要です。特に大切なのは、完璧な生体認証システムはないということです。これは Android だけでなく、すべてのオペレーティング システム、フォームファクタ、テクノロジーに対して言えることです。たとえば顔を使った生体認証の実装なら、ユーザーに似た家族やユーザーの 3D マスクでロックが解除できてしまうかもしれません。指紋を使った生体認証の実装なら、ユーザーの潜在指紋を使ってなりすませるかもしれません。このようななりすまし攻撃を緩和するため、なりすまし対策や Presentation Attack Detection（PAD）テクノロジーの開発が進められていますが、これらは緩和策であり、予防策ではありません。
生体認証の利用による潜在的なリスクを緩和するための Android の取り組みとして、Android P で導入されたロックダウン モードがあります。必要な場合、Android ユーザーはこの機能を使って一時的に生体認証や Smart Lock（信頼できる場所や信頼できるデバイスなど）、ロック画面の通知を無効化できます。
ロックダウン モードを使うには、まず第 1 の認証方式を設定し、その後に設定でロックダウン モードを有効化する必要があります。ロックダウン モードを有効化するための厳密な設定はデバイスのモデルによって異なりますが、Google Pixel 4 デバイスでは [Settings] > [Display] > [Lock screen] > [Show lockdown option] にあります。これを有効化すると、ユーザーは電源ボタンを押して電源ボタン メニューのロックダウン アイコンをクリックすることで、ロックダウン モードを起動できます。ロックダウン モードのデバイスは、第 1 の認証方式（PIN、パターン、パスワードなど）を使ってデバイスのロックを解除すると、ロックダウン解除状態に戻ります。
BiometricPrompt API を使用すると、さまざまなメリットが得られます。最も重要なことは、この API を使うと、アプリのデベロッパーが方式を意識せずに、さまざまな Android デバイスで生体認証を利用できることです（つまり、BiometricPrompt は、デバイスでサポートされているさまざまな生体認証方式の単一統合ポイントとして利用できます）。一方で、認証が提供する必要があるセキュリティ保証（フォールバックとしてのデバイス認証情報と合わせてクラス 3 またはクラス 2 の生体認証を必須とするなど）を制御することもできます。これにより、（ロック画面の他に）防御の第 2 階層でアプリデータを保護できることに加え、ユーザーの機密データを尊重することにもつながります。さらに、さまざまな Android デバイスのさまざまな方式の生体認証で一貫したユーザー エクスペリエンスを提供するため、BiometricPrompt は永続的な UI を提供しています。一部の情報（タイトルや説明など）をカスタマイズするオプションも存在します。
次のアーキテクチャ図に示すように、フレームワーク API やサポート ライブラリ（下位互換性を確保するための androidx.bitmetric）のどちらかを通して、Android デバイスのアプリに生体認証を組み込むことができます。注意すべき点は、FingerprintManager が非推奨になっていることです。デベロッパーには、方式を意識しない認証としてBiometricPrompt に移行することが推奨されています。
Android 11 では、BiometricManager.Authenticators インターフェースなどの新機能が導入されています。これを使うと、デベロッパーはアプリで受け入れる認証タイプを指定したり、BiometricPrompt クラスで利用ごとの認証キーをサポートしたりできます。
詳しくは、Android 11 プレビューと Android 生体認証システムのドキュメントをご覧ください。BiometricPrompt API の詳しい使用方法については、ブログ記事 Using BiometricPrompt with CryptoObject: how and why や、Codelab Login with Biometrics on Android をご覧ください。
ConversionActionCategoryEnum
ConversionTracker.Category
LEAD
PURCHASE
SIGNUP
DOWNLOAD
PAGE_VIEW
DEFAULT
ConversionCategoryName
