バージョン 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 セキュリティとプライバシーのデベロッパー サイトをご覧ください。
Federated Learning of Cohorts（FLoC）は、プライバシーを保護しつつ、興味ベースで広告を選択するメカニズムです。ユーザーがウェブを動き回ると、ブラウザは FLoC アルゴリズムを使って「興味コホート」を割り出します。これは、直近の閲覧履歴が似ているたくさんのブラウザで共通するものです。ユーザーのブラウザは一度に 1 つの興味コホートと関連付けられますが、コホートはユーザーのデバイスで定期的（今回の最初のオリジン トライアルの時点では、7 日ごと）に再計算されます。個々の閲覧データがブラウザ ベンダーなどの他者と共有されることはありません。
FLoC の詳細については、Federated Learning of Cohorts（FLoC）の概要をご覧ください。
トライアルは、サードパーティ オリジン トライアルとして Chrome 89 で始まる予定です（元記事公開当時。すでに開始されています）。FLoC オリジン トライアル トークンを取得するには、登録する必要があります。
自分のサイトで興味コホートのデータにアクセスするには、以下の方法のどちらかを使ってウェブページにオリジン トライアル トークンを追加します。
各ページの <head> 内のメタタグに次を含める :
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
HTTP ヘッダーに次を含める :
Origin-Trial: TOKEN_GOES_HERE
これをすると、ファーストパーティ コンテキストで FLoC を試すことができます。たとえば、サイトにアクセスしたユーザーのコホートを確認できます。
サードパーティのサイトで自分のコードから FLoC API をテストするには、メタタグにオリジン トライアル トークンを注入する必要があります。具体的な方法は、ウェブ デベロッパー向けオリジン トライアル ガイドで説明されています。
Chrome のオリジン トライアル サイトから行ってください。このフィードバックは公開されず、Chrome チームの一部のグループのみが利用します。トークンの有効期限が切れると、メールで更新リンクが送られます。トークンを更新する前に、フィードバックの送信を促すメッセージが表示されます。
FLoC API はシンプルで、Promise を返すメソッドが 1 つあるだけです。この Promise は、コホートの id と version を表すオブジェクトに解決されます。
id
version
document.interestCohort()
利用できるようになったコホートのデータは、次のように見えます。
{ "id": "14159", "version": "chrome.1.0" }
FLoC API は Chrome 89 以降で利用できますが、オリジン トライアルに参加していない場合は、フラグを設定してコマンドラインから Chrome を実行する必要があります。さまざまなオペレーティング システムで実行する方法は、フラグ付きで Chromium を実行するで説明されています。
次のフラグを使って Chrome を起動します。
--enable-blink-features=InterestCohortAPI --enable-features="FederatedLearningOfCohorts:update_interval/10s/minimum_history_domain_size_required/1,FlocIdSortingLshBasedComputation,InterestCohortFeaturePolicy"
サードパーティ Cookie がブロックされていないこと、広告ブロッカーが実行されていないことを確認します。
floc.glitch.me のデモを確認します。
FLoC API の説明でユースケースが提示されていますが、API の使用方法は定義されていません。FLoC を使って関連するコンテンツや広告を提供する場合、サイトやサービスによって制約や要件が異なります。
独自の技術によってお勧めコンテンツ、広告、マーケティングのサービスを提供している場合は、FLoC の知見を適用することで、特定のコホートに対して最適なコンテンツやマーケティング メッセージを提供できます。これらのサービスを提供するサードパーティ企業を利用している場合は、その企業がオリジン トライアルに参加し、皆さんのサイトや他のサイトを含めた実験をする方がよいかもしれません。
たとえば、関連コンテンツを選択する方法を探しているパブリッシャーがオリジン トライアルの期間中に FLoC を試すプロセスは、次のようになります。
サイトで宣言をすると、コホートを計算するためのユーザーのサイト一覧からそのサイトが除外されるようにする必要があります。新しい interest-cohort パーミッション ポリシーによって、これが可能になります。このポリシーは、デフォルトで allow となる予定です。
interest-cohort
allow
interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() を呼び出したときに返される Promise はリジェクトされます。メインのフレームに interest-cohort パーミッションがない場合、そのページへのアクセスは興味コホートの計算には使われません。
たとえば、次の HTTP レスポンス ヘッダーを送ると、すべての FLoC コホート計算をオプトアウトできます。
Permissions-Policy: interest-cohort=()
FLoC のオリジン トライアルの期間中、オプトアウトしていないウェブサイトは、そのサイトが広告関連のリソースを読み込んだことが Chrome によって検知されると、FLoC の計算に含まれます。
Chrome で広告検出メカニズムが動作する仕組みについては、Chromium での広告タグ付けで説明されています。
FLoC は、プライバシーを保護しつつ、興味ベースで広告を選択するメカニズムです。
ユーザーがウェブを動き回ると、ブラウザは FLoC アルゴリズムを使って、直近の閲覧履歴が似ているたくさんのブラウザで共通する「興味コホート」を割り出します。コホートはユーザーのデバイスで定期的に再計算されますが、個々の閲覧データがブラウザ ベンダーなどの他者と共有されることはありません。
FLoC は現在 Chrome オリジントライアルの最中です。詳しくは FLoC のオリジン トライアルに参加する方法をご覧ください。
現在の FLoC オリジントライアルでは、以下のいずれかの要因によりブラウザの FLoC 計算に取り込まれます:
他のクラスタリングアルゴリズムでは、今回のトライアルでは異なる取り込み基準で実験を行う可能性があります。これはオリジントライアルの実験手順の一部です。
広告主（お金を払って広告を出稿するサイト）は、自分のウェブサイトにコードを含めてコホートデータを収集し、アドテック プラットフォーム（広告を配信するソフトウェアやツールを提供する企業）に提供できます。たとえば、アドテック プラットフォームは、オンラインの靴店から、コホート 1101 と 1354 のブラウザはこの店のハイキング グッズに興味があるかもしれないことを把握できます。その他の広告主から、アドテック プラットフォームは各コホートのその他の興味を知ることができます。
次に、広告プラットフォームはこのデータを使って、これらのコホートのいずれかに属するブラウザが広告掲載サイト（ニュースサイトなど）のページをリクエストしたときに、関連性が高い広告（先ほどの靴店のハイキング シューズなど）を選択できます。
Privacy Sandbox は、サードパーティ Cookie などのトラッキング メカニズムを使わずにサードパーティ ユースケースを満たすための一連の提案です。各提案の概要については、Privacy Sandbox の詳細をご覧ください。
この提案について、皆さんからのフィードバックが必要です。コメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。この提案に関連する Chrome の試験運用についてフィードバックがある方は、試験運用の目的に返信する形で投稿してください。
多くの企業は、サイトのトラフィックを増加するために広告を利用しています。そして多くのパブリッシャーのウェブサイトは、広告のインベントリを販売することで、コンテンツの資金を得ています。ユーザーは通常、関連性が高く有用な広告を見ることを好みます。また、広告の関連性が高いほど、広告主に多くのビジネスを、広告をホストしているウェブサイトに多くの収益をもたらします。言い換えれば、関連性の高い広告を表示すれば、広告スペースの価値が上がります。したがって、関連性の高い広告を選ぶことで、広告がサポートするウェブサイトの収益が上がります。つまり、関連性の高い広告は、ユーザーにメリットをもたらすコンテンツを制作するための資金源になります。
しかし、多くのユーザーは、関連性の高い広告が示唆するプライバシーの問題を心配しています。現在、このような広告は、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術を利用しています。これらは、個人の閲覧動作を追跡するために使われる技術です。FLoC の提案は、プライバシーを侵害せずに広告選択の効率を高めることを目指しています。
下の例は、FLoC を使って広告を選択するうえでのそれぞれの役割について説明しています。
この例の広告主（お金を払って広告を出稿する企業）は、次のオンライン靴店です。shoestore.example
この例のパブリッシャー（広告スペースを販売するサイト）は、次のニュースサイトです。dailynews.example
アドテック プラットフォーム（広告を配信するソフトウェアやツールを提供する企業）は、次のサイトです。adnetwork.example
この例では、ユーザーを Yoshi と Alex と呼びます。最初の状態では、どちらのブラウザも同じコホート 1354 に属しています。
ここではユーザーを Yoshi と Alex と呼んでいますが、これは例示のみの目的です。FLoC では、広告主、パブリッシャー、アドテック プラットフォームに名前や個々の ID が明かされることはありません。
コホートをユーザーの集合と考えないでください。そうではなく、コホートは閲覧アクティビティをグループ化したものと考えてください。
次は Alex です。
現在の広告選択には、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術が利用されています。これらは、広告主などのサードパーティが個人の閲覧行動を追跡するために使われる技術です。
FLoC では、ブラウザは FLoC サービスにも他の誰にも閲覧履歴を送信しません。ブラウザは、ユーザーのデバイス上でブラウザ自身が属するコホートを割り出します。ユーザーの閲覧履歴がデバイスを離れることは一切ありません。
各ブラウザ ベンダーは、それぞれにどのようにコホートを作り出すのかを選択する必要があります。Chrome は独自の FLoC サービスを運用していますが、他のブラウザは異なるクラスタリングアプローチを採った FLoC を実装し、独自のサービスを運用する可能性があります。
このプロセスのどの時点においても、ユーザーの閲覧履歴が FLoC サービスやサードパーティに送信されることはありません。ブラウザのコホートは、ユーザーのデバイス上でブラウザ自身が計算します。FLoC サービスは、ユーザーデータを取得することも、保管することもありません。
はい、ブラウザのコホートはもちろん変わることがあります。毎週同じウェブサイトにアクセスすることはないでしょう。ブラウザのコホートはそれを反映します。
コホートは、ユーザーの集まりではなく、閲覧アクティビティのクラスタを表します。通常、コホートの行動の特徴は時間が経っても一貫性があり、コホートは最近の閲覧行動が似ているグループなので、広告の選択に役立ちます。それぞれのユーザーのブラウザは、閲覧行動の変化とともにコホートを出入りします。まずは、7 日ごとにブラウザがコホートを再計算することを想定しています。
上の例では、Yoshi と Alex のブラウザのコホートはどちらも 1354 でした。将来的に興味が変われば、Yoshi のブラウザと Alex のブラウザが別のコホートに移動する可能性があります。下の例では、Yoshi のブラウザはコホート 1101 に移動し、Alex のブラウザはコホート 1378 に移動します。他のユーザーのブラウザも、閲覧の興味が変わるにつれてコホートを出入りします。
コホートは、ユーザーのグループではなく、閲覧アクティビティのグループを定義します。行動が変わるにつれて、ブラウザはコホートを出入りします。
前述のように、ユーザーのブラウザはコホートの数学モデルの詳細データを FLoC サービスから取得します。これは、すべてのユーザーの閲覧アクティビティを表す多次元空間です。その後、ブラウザはあるアルゴリズムを使い、この「コホート空間」のどの領域（すなわち、どのコホート）が最近の自身の閲覧行動に最も近いかを割り出します。
各コホートには、たくさんのブラウザが存在することになります。
コホートのサイズが小さい場合、広告のパーソナライズには役立つかもしれませんが、ユーザーのトラッキングをやめることにはなりません。逆もまた同様です。ブラウザをコホートに割り当てるメカニズムには、プライバシーと有用性との間でトレードオフが必要になります。Privacy Sandbox は、ユーザーが「集団の中に隠れる」ことができるように、k-匿名性を利用します。コホートは、少なくとも k 人のユーザーによって共有されれば、k-匿名性があります。k の数が大きくなるほど、コホートのプライバシーは高くなります。
FLoC のコホートモデルを作成するために使うクラスタリング アルゴリズムは、なぜ分類がプライベートなのかは知ることなく、コホートにプライベートな分類と相関関係があるかどうかを評価できるように設計されています。人種、性別、病歴など、プライベートな分類が明らかになる可能性があるコホートはブロックされます。言い換えれば、コホートを割り出すとき、ブラウザはプライベートな分類が明らかにならないようなコホートのみを選択します。
FLoC では、ユーザーのブラウザは他のたくさんのユーザーのブラウザとともに、たくさんのコホートのうちの 1 つに属します。サードパーティ Cookie やその他のターゲティング メカニズムとは異なり、FLoC はユーザーのブラウザが属するコホートしか明かさず、個々のユーザー ID が明らかになることはありません。そのため、他者がコホート内の個人を特定することはできません。さらに、ブラウザのコホートを割り出すために使われる閲覧アクティビティに関する情報は、ローカルのブラウザやデバイスに留まり続けて、他の場所にアップロードされることはありません。ブラウザは、差分プライバシーなどの他の手法を使ってさらに匿名化することもできます。
ウェブサイトは、FLoC をオプトインすることもオプトアウトすることもできます。そのため、プライベートなトピックを扱うサイトは、そのサイトへのアクセスを FLoC の計算に含めないようにすることもできます。さらなる保護として、FLoC サービスによる分析では、そのコホートがなぜプライベートであるかを知ることなく、コホートによってユーザーに関するプライベートな情報が明らかになる可能性があるかどうかを評価します。あるコホートで、サイトにアクセスしたユーザーのうちプライベートな分類に属するユーザーの数が典型的なユーザーの数を超えている可能性がある場合、そのコホート全体が削除されます。この分析で扱われるプライベートな分類には、負債状況やメンタルヘルスなどが含まれます。
ウェブサイトは Permissions-Policy ヘッダーに interest-cohort=() を設定すると、FLoC 計算からオプトアウトすることができます。オプトアウトしていないページでは、document.interestCohort() が使われていると、ブラウザの FLoC 計算に含まれることになります。FLoC のオリジントライアル期間中、広告や広告に関連するリソースを読み込むことが検知された場合も、ブラウザの FLoC 計算に含まれることになります（Chrome の広告検知メカニズムの仕組みは、Chromium での広告のタグ付けで説明しています）。イントラネットのサイトなど、プライベートな IP アドレスから提供されているページは、FLoC の計算対象に含まれません。
interest-cohort=()
const { id, version } = await document.interestCohort(); console.log('FLoC ID:', id); console.log('FLoC version:', version);
{ "id": "14159", "version": "chrome.1.0"}
FLoC を使うサイトは、version の値を使って、コホート ID が参照するブラウザと FLoC モデルを知ることができます。以下の説明のとおり、interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。
ファーストパーティとサードパーティのそれぞれのコンテキストで FLoC を試す方法は、FLoC のオリジン トライアルに参加する方法で説明しています。
サイトで interest-cohort パーミッション ポリシーを使うと、コホートを計算するためのユーザーのサイト一覧から除外することを宣言できます。このポリシーは、デフォルトで allow となる予定です。interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。メインのフレームに interest-cohort permission がない場合、そのページへのアクセスは興味コホートの計算には使われません。
interest-cohort permission
API に関するコメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。
デジタル カンファレンス Google Cloud Day: Digital ’21 開催まで、あと 1 か月半となりました。セッション情報が公開されましたので、気になるセッションをぜひこちらからチェックしてみてください。
今回は、初日の「基調講演」と、翌週に開催される「ハンズオン祭」をご紹介します。
今年の基調講演は、昨年よりさらにパワーアップして、二部構成でお送りします。
前半（10:00-10:45）は「Data-powered innovation」をテーマに、データの利活用や働き方改革を Google Cloud を導入して進めている企業のリーダーに、ご登壇いただきます。また、Google Cloud からは最新のクラウド ソリューションをご提案します。
後半（11:00-11:45）は「Open Cloud leading transformation」をテーマに、システムのモダナイゼーションと、従来システムとのハイブリッド クラウド環境によってトランスフォーメーションを実現している企業から、その体験をご紹介いただきます。そして、Google Cloud からは、パートナーエコシステムをより強化している中で Anthos のソリューションをご紹介します。
登壇企業（敬称略）:
株式会社 ファーストリテイリング、LIXIL 株式会社、京都大学、ウーブン・プラネット・ホールディングス株式会社、エムスリー株式会社、株式会社エヌ・ティ・ティ・データ、日本ヒューレット・パッカード株式会社
基調講演、ブレイクアウト セッションでの学びを、翌週 6 月 01 日 (火) - 03 日 (木) に開催される「ハンズオン祭」で実践しましょう。
はじめて Google Cloud を利用される方は「はじめてみよう Google Cloud」で、製品の概要や各種機能を、実際に手を動かして体験いただけます。
「Study Jam」では、Qwiklabs（30 日間無料特典つき） を使って Google Cloud を体験でき、Google エンジニアへの質問も可能です。
ハンズオン祭のいずれかのセッションに出席された方の中から、抽選で 50 名様に Google Cloud 特製手ぬぐいをプレゼントします。
※ハンズオン祭への参加は、Google Cloud Day: Digital '21 とは別にお申し込みが必要となります。以下のリンクからご興味のあるセッションへ、それぞれお申し込みください。
☁ 6 月 1 日（火）
10:00 - 13:00 Study Jam Cloud Developer 編 https://goo.gle/2QS4Ymx
14:00 - 17:00 はじめてみよう Google Cloud Cloud Run 編 https://goo.gle/31BKHDT
☁ 6 月 2 日（水）
10:00 - 13:00 Study Jam Cloud DevOps 編 https://goo.gle/2QVjWs6
14:00 - 17:00 はじめてみよう Google Cloud Kaggle (BQ, BQML) 編 https://goo.gle/39yMC0l
☁ 6 月 3 日（木）
10:00 - 13:00 Study Jam Machine Learning 編 https://goo.gle/3dmMZfM
14:00 - 17:00 はじめてみよう Google Cloud Dialogflow CX 編 https://goo.gle/2Oe4hmI
日程 :
2021 年 5 月 25 日 ( 火 ) - 27 日 ( 木 ) : 基調講演、ブレイクアウト セッション
2021 年 6 月 01 日 ( 火 ) - 03 日 ( 木 ) : ハンズオン祭
対象 : 開発者、ビジネスの意思決定者やリーダー
ハッシュタグ : #GoogleCloudDay
お問い合わせ先 : Google Cloud Day: Digital 事務局
google-cloudday-tokyo-office@google.com
————————————————————
Developer Student Clubs（DSC）プログラムは、Google Developer Technologies に関心のある大学生向けのコミュニティ グループであり、学生の開発・リーダーシップ能力の向上を支援するプログラムです。
米国を始め、ヨーロッパ、オーストラリア、東南アジア、アフリカ、インド、中東・北アフリカ、ラテンアメリカ地域などなど、合わせて 106 カ国以上、1265 拠点から世界中の学生たちが活動している DSC プログラム。今年、日本にも展開します。
非推奨の機能をサポートする最後のバージョンが廃止されると、その機能をサポートするバージョンはなくなり、機能の継続的な使用は保証されませんので、ご注意ください。
API や SDK における非推奨の微妙な違いについては、非推奨に関するドキュメントをご覧ください。現在非推奨となっているすべての機能を記載しています。
なお、Maps JavaScript API はモバイル向けの SDK とは異なります。バージョンは四半期ごとのスケジュールでリリースされたり廃止されたりするため、常に最新バージョンをデフォルト（v=weekly）で読み込むことをおすすめします。Maps JavaScript API の定期的な更新に備える方法について、詳しくはこちらをご覧ください。
Chrome for Android に特化して、あらゆる種類の Android デバイスにとって快適なブラウザを作るという、他にはない挑戦をしています。今回のリリースでは、パッケージングとランタイムの最適化を適用し、ポケットの中の Chrome のパフォーマンスを向上させています。
モバイル デバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証（Certification）によるものである必要があります。スマートフォンの場合、特に確実なエンドツーエンドの認証（Certification）に Common Criteria（CC）Mobile Device Fundamentals（MDF）Protection Profile があります。Common Criteria は、31 か国に広がる大規模なセキュア IT プロダクトの相互認証（mutual recognition）を確立する原動力です。ここ数年間、すべての OS のバージョンで継続的に認証（Certification）を受けているスマートフォン メーカーは、Google、Samsung、Apple の 3 社のみです。2 月初頭には、現在サポート対象で、Android 11 を実行する Pixel スマートフォンのすべての認証（Certification）が完了しました。Google は、最新の OS バージョンで認証（Certification）を受けた最初のメーカーです。
この認証（Certification）は、コンシューマや企業が直面する現実の脅威に対するデバイスの防御力を評価するために設計されています。次の表は、CC MDF 保護プロファイルに示されている脅威と対策の概要です。
脅威
対策
ネットワークの盗聴 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する
ネットワーク攻撃 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する
通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル
認可と認証 - ネットワークやバックエンドの安全な認証（Authentication）
モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能
物理アクセス - 物理アクセス可能な攻撃者は、モバイル デバイスから認証情報を含むユーザーデータの取得を試みる可能性がある
ストレージの保護 - デバイスに含まれるデータを安全に保存（すなわち、保存データの暗号化）
認可と認証 - パスワード、PIN、指紋、顔認証など、既知のロック解除要素を利用した安全なデバイス認証（Authentication）
エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供
この認証（Certification）が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。
概念的には、評価対象（TOE）はデバイスのハードウェア（システム オン チップ）とオペレーティング システム（Android）の組み合わせです。上記の脅威に対する対策を検証するため、ラボは以下のセキュリティ機能を確認します。
これが企業にとって重要な理由
Pixel のセキュリティが企業のニーズを確実にサポートできることは、非常に重要です。規制が厳しい業界の多くでは、機密データが考えられる限り最も強固な保護を受けられるように、Common Criteria 認証（Certified）デバイスの利用が義務付けられています。Android Enterprise 管理フレームワークでは、企業がデバイスの管理などをし、エンドユーザーが実行できる操作を制限したり、デバイスを監査してすべてのソフトウェアが適切に設定されていることを保証したりできます。たとえば、企業の IT 管理者は、カメラ、位置情報サービス、アプリのインストール プロセスなどの機能に対するポリシーを強制できます。
これがコンシューマにとって重要な理由
セキュリティは企業だけが心配することではありません。Common Criteria 認証（Certification）で検証している多くの保護は、コンシューマにも適用されます。たとえば、Wi-Fi に接続するとき、ウェブのブラウズを誰にも盗聴されないことを確認したいと思うでしょう。デバイスの紛失や盗難の際は、ロック画面によって他人が個人情報にアクセスする可能性が減ると確信したいはずです。
Google は、すべてのユーザーにセキュリティとプライバシーをお届けしたいと考えています。Pixel デバイスがこの認証（Certification）基準以上を確実に満たせるようにしたいと考えているのはそのためです。今後もこの基準を満たすために注力しますので、どうぞご安心ください。Pixel スマートフォンでは、スイッチを入れた瞬間から充実したセキュリティを利用できます。
これが Android エコシステムにとって重要な理由
認証（Certification）はサードパーティによる検証として有用な形態ですが、以下の、Google が 3 C と呼ぶものに該当することがよくあります。
ここ 3 年間は、OEM パートナーを対象に、この複雑さを軽減するための作業をしてきました。その結果、必要なセキュリティ要件を満たすために要求される機能が Android オープンソース プロジェクトに直接組み込まれることをお知らせします。さらに、すべての管理要件と監査要件を Android Enterprise Management フレームワークに追加しました。昨年は、このために開発したツールを GitHub に公開しました。他の Android OEM が認証（Certification）を受ける際に、この作業のメリットを活用できるようにするためです。
新しい Android OS バージョンでの Pixel スマートフォンの認証（Certification）は継続しますが、Google はその他の Android OEM も、この認証（Certification）や、以下のその他の認証（Certification）を取得できるように取り組んでいます。
今後も、企業とコンシューマの両方を対象にしたセキュリティ対策に注力してまいります。業界の皆さんがこの作業に加わってくれることを歓迎いたします。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 3 月 11 日時点で、Chrome 90 はベータ版です。
デスクトップ版の Chrome に AV1 エンコーダが搭載されます。このエンコーダは、組み込みの WebRTC を利用したテレビ会議に特に最適化されています。AV1 には、以下のようなメリットがあります。
WebRTC は最近正式に W3C と IETF の標準になったので、この追加は特に重要です。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
mediaDevices.getCurrentBrowsingContextMedia() メソッドを使うと、getDisplayMedia() と同様に、現在のタブの動画（可能な場合は音声も）から MediaStream をキャプチャできます。getDisplayMedia() とは異なり、この新しいメソッドを呼び出すと、許可するか拒否するかを選択する単純なダイアログ ボックスが表示されます。ユーザーが許可した場合は、現在のタブがキャプチャされます。getCurrentBrowsingContextMedia() のその他の動作は、すべて getDisplayMedia() と同じです。このオリジン トライアルは、Chrome 92 まで行われる予定です。
カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力など、MediaStreamTrack のローメディアを操作する API です。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams API が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。次のようなユースケースをサポートすることを想定しています。
このオリジン トライアルは、Chrome 92 まで行われる予定です。
WebAssembly が例外ハンドリングをサポートするようになりました。例外ハンドリングを利用すると、コードで例外がスローされたときに制御フローを抜けることができます。例外は、WebAssembly モジュールの既知の例外でも、インポートされて呼び出された関数がスローした未知の例外でも構いません。このオリジン トライアルは、Chrome 94 まで行われる予定です。
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
ライティング推定を利用すると、サイトから WebXR セッション内の環境光条件の推定値を照会できます。これにより、環境光を表す球面調和関数と、「反射」を表すキューブマップ テクスチャの両方を取得できます。ライティング推定を追加すると、モデルが自然になってユーザーの環境への「適合度」が上がる可能性があります。
aspect-ratio プロパティを使うと、ある要素の横か縦のサイズだけが指定された場合に、もう片方のサイズを自動計算できます。もともとこのプロパティは、アニメーション時に補完されない（つまり、ターゲット値にスナップする）ものとして導入されました。この機能により、あるアスペクト比から別のアスペクト比に変化するときに、スムーズな補完が行われるようになります。
aspect-ratio
カスタム要素が、状態を表す CSS 疑似クラスを介してカスタム要素の状態を公開するようになります。ビルトイン要素には状態が存在します。これは、ユーザーのインタラクションなどによって時間とともに変化する場合があり、疑似クラスを通してウェブ制作者に公開されます。たとえば、フォームのコントロールの中には、"invalid" 状態を持つものがあり、これが :invalid 疑似クラスで公開されています。カスタム要素も状態を持つので、ビルトイン要素と同じように状態を公開できるのは妥当です。
以下のフォーム コントロールの CSS プロパティ appearance と -webkit-appearance のデフォルト値が、'auto' に変更されます。
appearance
-webkit-appearance
'auto'
<input type=color>
<select>
<input type=date>
<input type=datetime-local>
<input type=month>
<input type=time>
<input type=week>
これらのコントロールのデフォルトのレンダリングは変更されません。
overflow に clip 値を指定すると、ボックスのコンテンツがボックスのオーバーフロー クリップエッジでクリップされます。さらに、スクロール インターフェースは提供されず、ユーザーやプログラムはコンテンツをスクロールできなくなります。また、ボックスはスクロール コンテナとは見なされず、新しいフォーマッティング コンテキストは開始されません。そのため、この値を使うと、overflow: hidden を使う場合よりもパフォーマンスが向上します。
overflow
clip
overflow: hidden
overflow-clip-margin プロパティを使うと、要素が境界のどのくらい外側まで描画できるかを指定できます（その範囲を超えるとクリップされます）。デベロッパーは、このプロパティを使ってクリップ境界を拡張することもできます。これは、インク オーバーフローを表示したい場合に特に便利です。
overflow-clip-margin
Permissions-Policy HTTP ヘッダーは、アクセス許可や機能の委譲を制御する既存の Feature-Policy ヘッダーを置き換えます。このヘッダーを使うと、どのオリジンに機能へのアクセスを許可するかをサイトで厳密に制限できます。
Permissions-Policy
Feature-Policy
Chrome 74 で導入された Feature Policy API は、最近 "Permissions Policy" という名前に変わり、それに伴って HTTP ヘッダーの名前も変更されました。同時に、コミュニティは HTTP の構造化フィールド値に基づいた新しい構文を決定しています。
Cross-Origin-Read-Blocking が利用する盗聴されない MIME タイプのリストに application/x-protobuffer を追加し、これを投機的実行攻撃から守ります。application/x-protobuf は、すでに盗聴されない MIME タイプとして保護されています。application/x-protobuffer もよく使われている MIME タイプで、protobuf ライブラリによって "ALT_CONTENT_TYPE" として定義されています。
Cross-Origin-Read-Blocking
application/x-protobuffer
application/x-protobuf
"ALT_CONTENT_TYPE"
FileSystemWritableFileStream.write() にファイルの末尾を超えるデータを渡した場合、0x00（NUL）を書き込んでファイルを拡張します。これにより、疎なファイルを作成できるので、書き込むデータが順不同で届く場合に、コンテンツをファイルに保存する処理を大幅に簡略化できます。 この機能がないと、ファイルのコンテンツを順不同で受け取るアプリケーション（たとえば、BitTorrent のダウンロード）は、事前に、または書き込み中にファイルのサイズ変更が必要になった場合に、手動でそれを行う必要があります。
FileSystemWritableFileStream.write()
0x00
NUL
現在、ウェブ制作者が作成できる範囲型は Range のみです。しかし、Range オブジェクトは「ライブ」であり、これをメンテナンスするのはコストがかかる場合があります。ツリーが変更されるたびに、影響を受けるすべての Range オブジェクトの更新が必要です。新しい StaticRange オブジェクトは、ライブではない軽量の範囲型を表すので、Range と同じようなメンテナンス コストはかかりません。StaticRange を作成可能にすることで、ウェブ制作者は DOM ツリーの変更に応じて更新する必要がない範囲にこれを利用できます。
Range
StaticRange
<picture> 要素内で <source> 要素を使う場合、width と height プロパティがサポートされます。これにより、Chrome が <picture> 要素のアスペクト比を計算できるようになります。これは、<img>、<canvas>、<video> の各要素の動作と一致します。
<picture>
<source>
width
height
<img>
<canvas>
<video>
新しい OscillatorNode オブジェクトを作成するときに、periodicWave に null を設定できなくなります。この値は、OscillatorNode() コンストラクタに渡される options オブジェクトに設定されます。WebAudio 仕様では、この値に null を設定することは許可されていません。これにより、Chrome の動作が仕様と Firefox に一致します。
OscillatorNode
OscillatorNode()
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.0 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Array、String、TypedArray が at() メソッドをサポートします。このメソッドは、負の数による相対インデックスをサポートします。たとえば、次のコードは指定された配列の最後の項目を返します。
at()
let arr = [1,2,3,4]; arr.at(-1);
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
'plugin-types' ディレクティブを使うと、<embed> または <object> html 要素で読み込めるプラグインの種類をデベロッパーが制限できます。これにより、デベロッパーはページ内の Flash をブロックできます。Flash のサポートは終了したので、このポリシー ディレクティブは不要になりました。
<embed>
<object>
Chrome では、WebRTC の非標準である RTP データ チャンネルのサポートを削除しました。ユーザーは、標準の SCTP ベースのデータ チャンネルを使用する必要があります。
Chrome は navigator.plugins と navigator.mimeTypes に対して空を返します。Flash が削除されたことで、これらのプロパティから何かを返す必要はなくなりました。
navigator.plugins
navigator.mimeTypes
