バージョン 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 がデフォルトになります。


Reviewed by Eiji Kitamura - Developer Relations Team

世界中の情報を整理し、強固なセキュリティとプライバシーで保護しつつ広くアクセスできるようにするというミッションにおいて、暗号化は基本的な構成要素です。今から 4 年少し前に、公的に信頼できる認証局(CA)として Google Trust Services を設立したのはそのためです。

公的に信頼される認証局になるまでの道のりは長く、インターネットで特にアクセスの多いサイトの証明書を発行しているなら、なおさらです。

この歩みが始まったときの目標は、5 年以内にルート証明書が十分多くのデバイスに組み込まれ、1 回で長期ルート証明書に移行できるようにすることでした。

現在も、Google のルート証明書の更新が行われていない中古のデバイスがたくさん使われています。

Google Trust Services の証明書を使う際、できる限り多くのクライアントが確実に安全な接続を続けられるようにするには、クロス署名を取得する必要がありました。クロス署名を使うと、すでにデバイスから信頼されている認証局が、そのデバイスの互換性を別の認証局に拡大できます。

パブリック CA の運用における規則では、クロス署名された CA は、クロス署名を提供する側の認証局と厳密に同一の運用、技術、監査の各基準を満たす必要があると規定されています。Google Trust Services は高水準で運用されており、すでに公的に信頼されている CA です。また、すべての主要なブラウザのトラストストアに格納されています。そのため、すでに別の CA からのクロス署名要件を満たしていました。重要な点は、Google の証明書を検証できるようにしたいデバイスで、すでに信頼されている認証局を見つけることでした。そこで、このクロス署名に関して GMO GlobalSign と連携することにしました。現在広く使われているルート証明書の中でも、特に古くから運用されているためです。

なぜここでこのような話をしているかというと、2021 年 12 月 15 日に、現在使用しているプライマリ ルート証明書(Google Trust Services が所有、運用している GlobalSign R2)の有効期限が切れるためです。

Google が発行する証明書を搭載した古いデバイスが問題なく動作を続けられるようにするため、新たな証明書を発行するタイミングで、新しいクロス署名証明書のサービスへの送信を開始します。

ありがたいことに、ユーザーはこの変更に気づくことはないはずです。これは、Google がデプロイしているクロス証明書(GTS Root R1 Cross)は 20 年以上前に作成されたもので、ほとんどのデバイスにおいて信頼されているルート証明書で署名されているからです。

つまり、Google Trust Services の証明書を使用している方やそのお客様は、業界最大級のデバイスの互換性というメリットを引き続き活用できます。

この変更について、質問がある方もいらっしゃるでしょう。特に多く寄せられる質問について、以下に回答を記載します。

デベロッパーまたは ISV として Google API を使用しています。何をする必要がありますか?

認証局は使用するルート CA 証明書を随時変更しています。そのため、Google は現在使用している、または今後使用する可能性がある証明書のリストを常に提供しています。このリストを使っている方は、何も変更する必要はありません。このリストを使っておらず、Google が公開しているガイドに基づく更新をしていない方は、ユーザーが今後の変更にスムーズに対応できるように、これらのルートを使うようにアプリケーションを更新し、定期的にリストを更新する必要があります。

Google Trust Services の証明書を使ってウェブサイトを運用しています。何か変更は必要ですか?

何もありません。Google Trust Services は、多くの Google Cloud のサービスを含む Alphabet のプロダクトやサービスに証明書を提供しています。TLS の設定や管理はこれらのサービスが行ってくれます。

変更が反映されるのはいつですか? 

このクロス証明書を使う証明書チェーンのロールアウトは、2021 年 3 月から始まります。この変更は今年いっぱいをかけてゆっくりとロールアウトし、2021 年 12 月 15 日までに終える予定です。

Google Trust Services を使っているサービスやプロダクトを使用しています。何か変更は必要ですか?ありません。エンドユーザーはこの変更に気づかないはずです。

デバイスがこのクロス署名を使った証明書を信頼していることは、どうすればテストできますか? 

このクロス証明書を使ったテストサイトを作成しています。テストサイトには、こちらからアクセスできます。追加の証明書情報とともに "Google Trust Services Demo Page - Expected Status: good" と表示される場合、そのデバイスで新しい証明書チェーンが正しく動作しています。エラーが表示される場合は、テストしているデバイスの信頼されたルートのリストを更新する必要があります。

このクロス証明書の有効期限はいつですか?また、その有効期限が切れるとどうなりますか? 

クロス証明書の有効期限は、2028 年 1 月 28 日です。今後、クロス証明書がなくても多くのデバイスとの互換性を確保できるようになったと考えられれば、この追加の証明書は不要になるため、証明書要求者への提供を停止する予定です。

クロス署名を信頼しない古いデバイスを使っています。どうすればよいですか? 

多くのデバイスは、セキュリティ パッチ処理の一環としてルート証明書の更新をします。そのようなデバイスを使っている場合は、関連するすべてのセキュリティ アップデートを確実に適用してください。お使いのデバイス向けのセキュリティ アップデートをメーカーがもう提供していない場合もあるかもしれません。その場合は、プロバイダに連絡するか、デバイスを換えることを検討してください。

これは Google Trust Services のルートを使えなくなるということですか?Google Trust Services ルートは今後も使用されます。単にそれがクロス署名されるということです。クロス署名を使う必要がなくなれば、証明書要求者にクロス署名を配布することはなくなります。

詳細は、Google Trust Services をご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team


子供向けスマートフォンの課題

インターネット上のトラブルに十分な知識を持たない子供に高性能なカメラを搭載したスマートフォンの所有がに広がることにより、不適切な自撮りによる被害が発生するようになっています。


この問題は保護者にとって深刻です。問題を避けるために子供にスマートフォンを持たせいないという選択肢もありますが、昨今、子供の日常生活でもスマートフォンが必要とされることも多く、いかに安全なスマートフォンを子供に持たせるかが課題となっています。


TONE e20 はこの問題を技術で解決するために、TensorFlow を活用した画像検知機能を実装しています。

通信せずに不適切な画像を TensorFlow を使用して検知

TONE e20 と TONE e21 にはフリービット株式会社によって開発された特定の画像を AI により自動検知するカメラアプリが標準カメラとしてインストールされています。


この標準カメラは自動で裸などの不適切な画像や映像を検知して規制し、あらかじめ設定された保護者の端末に通知する機能を有しています。




この AI による自動検知は TensorFlow のモバイル向けフレームワークである TensorFlow Lite を使い、端末内で処理されています。


画像の認識には通信機能を使いクラウド上にサーバー側で処理する、という実装方法もありますがセンシティブな内容を含む写真や映像を通信に乗せるコストやリスクを考慮して TONE e20 と TONE e21 では端末内で処理する方式としています。


端末内での処理は AI 専用のチップや GPU を使うことなく、CPU を使用しています。カメラアプリとして快適に利用できるよう処理速度はチューニングされ、画像についてはシャッターを押してからおおよそ 200 ミリ秒 から 1 秒以内、平均で 400 - 600 ミリ秒で処理が完了します。 映像については Android Jetpack の カメラ ライブラリをもとに作成し、一定間隔でキャプチャした画像を検知する仕組みとしてます。


写真、映像ともに不適切な画像を検知した場合は保存させないように規制するとともに保護者の端末に通知する流れとなっています。

モデルは既存のものを活用

TONE e20 と TONE e21 に実装した、不適切な画像を検知する学習モデルは独自に開発したものではありません。

Yahoo が開発していた Caffe をベースとした open nsfw model を TensorFlow Lite のモデルに変換することで利用しています。Caffe はカリフォルニア大学バークレー校が中心となって開発しているオープンソースのディープラーニング ライブラリです。Caffe は TensorFlow のために開発されたモデルではありませんが、さまざまなオープンソースやデベロッパーがブログで公開していたノウハウを活用して変換しています。
  

検知機能への反応と評価

フリービット株式会社は 2013 年からスマートフォン事業をスタートし、2015 年からは トーンモバイル を運営しています。


回線インフラ・ SIM ・サービス・端末を一貫して手掛けることができるのは、トーンモバイルを運営する株式会社ドリーム・トレイン・インターネットを含むフリービットグループで垂直統合しているためです。


トーンモバイルでは単に端末を販売するのではなく、独自の付加価値をもった端末を自社で開発しています。今回ご紹介した AI による不適切な画像の自動検知もその付加価値の一つです。


すでに TONE e20 を購入した保護者の方々からは良い反応を得ています。不適切な自撮り画像の検知だけでなく、AI を活用したいくつかの子供向けの見守り機能が評価されています。安心して子供に渡せるスマートフォンとして評価され、いくつかの自治体では子供向けの推奨スマートフォンとして認証されています。


自撮り画像の検知機能については端末依存の機能ではなく、アプリとして開発されたものです。今後はカメラ機能そのものを向上させるとともに、他の Android スマートフォンや iPhone でも利用できるアプリとしての展開も検討しています。


Posted by Khanh LeViet - Developer Relations Team

関連情報



Reviewed by Eiji Kitamura - Developer Relations Team

広告主(お金を払って広告を出稿するサイト)は、自分のウェブサイトにコードを含めてコホートデータを収集し、アドテック プラットフォーム(広告を配信するソフトウェアやツールを提供する企業)に提供できます。たとえば、アドテック プラットフォームは、オンラインの靴店から、コホート 1101 と 1354 のブラウザはこの店のハイキング グッズに興味があるかもしれないことを把握できます。その他の広告主から、アドテック プラットフォームは各コホートのその他の興味を知ることができます。

次に、広告プラットフォームはこのデータを使って、これらのコホートのいずれかに属するブラウザが広告掲載サイト(ニュースサイトなど)のページをリクエストしたときに、関連性が高い広告(先ほどの靴店のハイキング シューズなど)を選択できます。

Privacy Sandbox は、サードパーティ Cookie などのトラッキング メカニズムを使わずにサードパーティ ユースケースを満たすための一連の提案です。各提案の概要については、Privacy Sandbox の詳細をご覧ください。

この提案について、皆さんからのフィードバックが必要です。コメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。この提案に関連する Chrome の試験運用についてフィードバックがある方は、試験運用の目的に返信する形で投稿してください。

FLoC が必要になる理由

多くの企業は、サイトのトラフィックを増加するために広告を利用しています。そして多くのパブリッシャーのウェブサイトは、広告のインベントリを販売することで、コンテンツの資金を得ています。ユーザーは通常、関連性が高く有用な広告を見ることを好みます。また、広告の関連性が高いほど、広告主に多くのビジネスを、広告をホストしているウェブサイトに多くの収益をもたらします。言い換えれば、関連性の高い広告を表示すれば、広告スペースの価値が上がります。したがって、関連性の高い広告を選ぶことで、広告がサポートするウェブサイトの収益が上がります。つまり、関連性の高い広告は、ユーザーにメリットをもたらすコンテンツを制作するための資金源になります。

しかし、多くのユーザーは、関連性の高い広告が示唆するプライバシーの問題を心配しています。現在、このような広告は、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術を利用しています。これらは、個人の閲覧動作を追跡するために使われる技術です。FLoC の提案は、プライバシーを侵害せずに広告選択の効率を高めることを目指しています。

FLoC の利用目的

  • 広告主のサイトに頻繁にアクセスしたコホートや、それに関連するトピックに興味を示したコホートに属するブラウザを使うユーザーに広告を表示する。
  • 機械学習モデルを使用して、ユーザーをコンバージョンできる可能性をコホートに基づいて予測し、広告オークションの入札動作に反映する。
  • ユーザーにコンテンツをお勧めする。たとえば、あるニュースサイトで、スポーツのポッドキャスト ページの人気がコホート 1234 と 7 のユーザーの間で特に高い場合、同じコホートの他のユーザーにもそのコンテンツをお勧めできる。

FLoC の動作の仕組み

下の例は、FLoC を使って広告を選択するうえでのそれぞれの役割について説明しています。

  • この例の広告主(お金を払って広告を出稿する企業)は、次のオンライン靴店です。
    shoestore.example

  • この例のパブリッシャー(広告スペースを販売するサイト)は、次のニュースサイトです。
    dailynews.example

  • アドテック プラットフォーム(広告を配信するソフトウェアやツールを提供する企業)は、次のサイトです。
    adnetwork.example

FLoC を使って広告を選択して配信するうえでのそれぞれの役割について、順を追って説明する図。FLoC サービス、ブラウザ、広告主、パブリッシャー(コホートの観測)、アドテック、パブリッシャー(広告の表示)

この例では、ユーザーを YoshiAlex と呼びます。最初の状態では、どちらのブラウザも同じコホート 1354 に属しています。

ここではユーザーを Yoshi と Alex と呼んでいますが、これは例示のみの目的です。FLoC では、広告主、パブリッシャー、アドテック プラットフォームに名前や個々の ID が明かされることはありません。

コホートをユーザーの集合と考えないでください。そうではなく、コホートは閲覧アクティビティをグループ化したものと考えてください。

1. FLoC サービス

  1. ブラウザによって利用される FLoC サービスは、たくさんの「コホート」を持つ数学的なモデルを作成します。各コホートは、最近の閲覧履歴が似ているたくさんのウェブブラウザに対応しています。この処理については、後ほど詳しく説明します。
  2. それぞれのコホートに番号が付けられます。

2. ブラウザ

  1. Yoshi のブラウザは、FLoC サービスから FLoC モデルの詳細データを取得します。
  2. Yoshi のブラウザは、FLoC モデルのアルゴリズムを使ってどのコホートが自分の閲覧履歴に最も近いかを計算し、自分のコホートを割り出します。この例では、コホート 1354 とします。Yoshi のブラウザは、FLoC サービスに何のデータも送信していない点に注目してください。
  3. 同じように、Alex のブラウザもコホート ID を計算します。Alex の閲覧履歴は Yoshi の履歴とは違いますが、かなり似ているので、どちらのブラウザもコホート 1354 に属すると判断されます。

3. 広告主 : shoestore.example

  1. Yoshi が shoestore.example にアクセスします。
  2. サイトが Yoshi のブラウザにコホートを尋ねます。1354 が返されます。
  3. Yoshi がハイキング シューズのページを閲覧します。
  4. サイトは、コホート 1354 のブラウザがハイキング シューズに興味を示したことを記録します。
  5. サイトは後ほど、コホート 1354 が興味を示した製品についての追加情報も記録します。他のコホートについても同様です。
  6. サイトは、コホートと興味が示された製品についての情報を定期的に集計し、アドテック プラットフォーム adnetwork.example に送信します。

次は Alex です。

4. パブリッシャー : dailynews.example

  1. Alex が dailynews.example にアクセスします。
  2. サイトは Alex のブラウザにコホートを尋ねます。
  3. その後、アドテック プラットフォーム adnetwork.example に広告をリクエストしますが、その際に Alex のブラウザのコホート 1354 を含めます。

5. アドテック プラットフォーム : adnetwork.example

  1. adnetwork.example は、Alex に適した広告を選択できます。その際に、パブリッシャー dailynews.example と 広告主 shoestore.example からの以下のデータを組み合わせて利用します。
    • Alex のブラウザのコホート(1354)。dailynews.example から提供されたもの。
    • コホートと製品に対する興味に関するデータ。shoestore.example から提供されたもの。「コホート 1354 のブラウザはハイキング シューズに興味がある可能性がある」
  2. adnetwork.example は Alex に適した広告を選択します。ハイキング シューズの広告で、shoestore.example によるものが選ばれます。
  3. dailynews.example が広告 🥾 を表示します。

現在の広告選択には、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術が利用されています。これらは、広告主などのサードパーティが個人の閲覧行動を追跡するために使われる技術です。

FLoC では、ブラウザは FLoC サービスにも他の誰にも閲覧履歴を送信しません。ブラウザは、ユーザーのデバイス上でブラウザ自身が属するコホートを割り出します。ユーザーの閲覧履歴がデバイスを離れることは一切ありません。

FLoC モデルを作るバックエンド サービスは誰が運用するのか?

各ブラウザ ベンダーは、それぞれにどのようにコホートを作り出すのかを選択する必要があります。Chrome は独自の FLoC サービスを運用していますが、他のブラウザは異なるクラスタリングアプローチを採った FLoC を実装し、独自のサービスを運用する可能性があります。

FLoC サービスがブラウザにコホートを割り出す方法

  1. ブラウザによって利用される FLoC サービスは、すべての潜在的なウェブ閲覧履歴を表す多次元数学的表現を作成します。このモデルを「コホート空間」と呼びます。
  2. サービスはこの空間をたくさんのセグメントに分割します。各セグメントは、たくさんの類似した閲覧履歴のクラスタを表します。このグループ分けは、実際の閲覧履歴に基づくものではありません。単に「コホート空間」でランダムな中心を選んだり、空間をランダムな線で分割したりしたものです。
  3. それぞれのセグメントにコホート番号が与えられます。
  4. ウェブブラウザは、FLoC サービスから「コホート空間」を示すこのデータを取得します。
  5. ユーザーがウェブを動き回ると、ブラウザはあるアルゴリズムに基づき、「コホート空間」内でのブラウザ自身の閲覧履歴に最も近い領域を定期的に計算します。
FLoC サーバーが作成した「閲覧履歴空間」の図。コホート番号が振られた複数のセグメントが存在する。
FLoC サービスは「コホート空間」をたくさんのセグメントに分割する(ここに示すのは一部のみ)。

このプロセスのどの時点においても、ユーザーの閲覧履歴が FLoC サービスやサードパーティに送信されることはありません。ブラウザのコホートは、ユーザーのデバイス上でブラウザ自身が計算します。FLoC サービスは、ユーザーデータを取得することも、保管することもありません。

ブラウザのコホートは変わることがあるか

はい、ブラウザのコホートはもちろん変わることがあります。毎週同じウェブサイトにアクセスすることはないでしょう。ブラウザのコホートはそれを反映します。

コホートは、ユーザーの集まりではなく、閲覧アクティビティのクラスタを表します。通常、コホートの行動の特徴は時間が経っても一貫性があり、コホートは最近の閲覧行動が似ているグループなので、広告の選択に役立ちます。それぞれのユーザーのブラウザは、閲覧行動の変化とともにコホートを出入りします。まずは、7 日ごとにブラウザがコホートを再計算することを想定しています。

上の例では、Yoshi と Alex のブラウザのコホートはどちらも 1354 でした。将来的に興味が変われば、Yoshi のブラウザと Alex のブラウザが別のコホートに移動する可能性があります。下の例では、Yoshi のブラウザはコホート 1101 に移動し、Alex のブラウザはコホート 1378 に移動します。他のユーザーのブラウザも、閲覧の興味が変わるにつれてコホートを出入りします。

FLoC サーバーが作成した「閲覧履歴空間」の図。コホート番号が振られた複数のセグメントが存在する。時間とともに閲覧の興味が変わるにつれて、ユーザーの Yoshi と Alex に属するブラウザが別のコホートに移動する様子を示した図。
興味が変われば、Yoshi と Alex のブラウザのコホートは変わる可能性がある。

コホートは、ユーザーのグループではなく、閲覧アクティビティのグループを定義します。行動が変わるにつれて、ブラウザはコホートを出入りします。

ブラウザはどのようにしてコホートを割り出すのか

前述のように、ユーザーのブラウザはコホートの数学モデルの詳細データを FLoC サービスから取得します。これは、すべてのユーザーの閲覧アクティビティを表す多次元空間です。その後、ブラウザはあるアルゴリズムを使い、この「コホート空間」のどの領域(すなわち、どのコホート)が最近の自身の閲覧行動に最も近いかを割り出します。

FLoC はどのようにしてコホートの適切なサイズを割り出すのか

各コホートには、たくさんのブラウザが存在することになります。

コホートのサイズが小さい場合、広告のパーソナライズには役立つかもしれませんが、ユーザーのトラッキングをやめることにはなりません。逆もまた同様です。ブラウザをコホートに割り当てるメカニズムには、プライバシーと有用性との間でトレードオフが必要になります。Privacy Sandbox は、ユーザーが「集団の中に隠れる」ことができるように、k-匿名性を利用します。コホートは、少なくとも k 人のユーザーによって共有されれば、k-匿名性があります。k の数が大きくなるほど、コホートのプライバシーは高くなります。

プライベートな分類に基づいてユーザーをグループ化するために FLoC を使えるか

FLoC のコホートモデルを作成するために使うクラスタリング アルゴリズムは、なぜ分類がプライベートなのかは知ることなく、コホートにプライベートな分類と相関関係があるかどうかを評価できるように設計されています。人種、性別、病歴など、プライベートな分類が明らかになる可能性があるコホートはブロックされます。言い換えれば、コホートを割り出すとき、ブラウザはプライベートな分類が明らかにならないようなコホートのみを選択します。

FLoC はオンラインでユーザーを分類するための別の方法にすぎないのか

FLoC では、ユーザーのブラウザは他のたくさんのユーザーのブラウザとともに、たくさんのコホートのうちの 1 つに属します。サードパーティ Cookie やその他のターゲティング メカニズムとは異なり、FLoC はユーザーのブラウザが属するコホートしか明かさず、個々のユーザー ID が明らかになることはありません。そのため、他者がコホート内の個人を特定することはできません。さらに、ブラウザのコホートを割り出すために使われる閲覧アクティビティに関する情報は、ローカルのブラウザやデバイスに留まり続けて、他の場所にアップロードされることはありません。ブラウザは、差分プライバシーなどの他の手法を使ってさらに匿名化することもできます。

ウェブサイトは参加して情報を共有する必要があるのか

ウェブサイトは、FLoC をオプトインすることもオプトアウトすることもできます。そのため、プライベートなトピックを扱うサイトは、そのサイトへのアクセスを FLoC の計算に含めないようにすることもできます。さらなる保護として、FLoC サービスによる分析では、そのコホートがなぜプライベートであるかを知ることなく、コホートによってユーザーに関するプライベートな情報が明らかになる可能性があるかどうかを評価します。あるコホートで、サイトにアクセスしたユーザーのうちプライベートな分類に属するユーザーの数が典型的なユーザーの数を超えている可能性がある場合、そのコホート全体が削除されます。この分析で扱われるプライベートな分類には、負債状況やメンタルヘルスなどが含まれます。

ウェブサイトは Permissions-Policy ヘッダーに interest-cohort=() を設定すると、FLoC 計算からオプトアウトすることができます。オプトアウトしていないページでは、document.interestCohort() が使われていると、ブラウザの FLoC 計算に含まれることになります。FLoC のオリジントライアル期間中、広告や広告に関連するリソースを読み込むことが検知された場合も、ブラウザの FLoC 計算に含まれることになります(Chrome の広告検知メカニズムの仕組みは、Chromium での広告のタグ付けで説明しています)。イントラネットのサイトなど、プライベートな IP アドレスから提供されているページは、FLoC の計算対象に含まれません。

ウェブ デベロッパーとして FLoC を試すにはどうすればよいか

FLoC API はシンプルで、Promise を返すメソッドが 1 つあるだけです。この Promise は、コホートの idversion を表すオブジェクトに解決されます。

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 API は Chrome 89 以降で利用できますが、オリジン トライアルに参加していない場合は、フラグを設定してコマンドラインから Chrome を実行する必要があります。さまざまなオペレーティング システムで実行する方法は、フラグ付きで Chromium を実行するで説明されています。

  1. 次のフラグを使って Chrome を起動します。

    --enable-blink-features=InterestCohortAPI  
    --enable-features="FederatedLearningOfCohorts:update_interval/10s/minimum_history_domain_size_required/1,FlocIdSortingLshBasedComputation,InterestCohortFeaturePolicy"
  2. サードパーティ Cookie がブロックされていないこと、広告ブロッカーが実行されていないことを確認します。

  3. floc.glitch.me のデモを確認します。

ファーストパーティとサードパーティのそれぞれのコンテキストで FLoC を試す方法は、FLoC のオリジン トライアルに参加する方法で説明しています。

ウェブサイトで FLoC の計算をオプトアウトするにはどうすればよいか

サイトで interest-cohort パーミッション ポリシーを使うと、コホートを計算するためのユーザーのサイト一覧から除外することを宣言できます。このポリシーは、デフォルトで allow となる予定です。interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。メインのフレームに interest-cohort permission がない場合、そのページへのアクセスは興味コホートの計算には使われません。

たとえば、次の HTTP レスポンス ヘッダーを送ると、すべての FLoC コホート計算をオプトアウトできます。

  Permissions-Policy: interest-cohort=()

提案やフィードバックをするにはどうすればよいか

API に関するコメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。

関連情報


Reviewed by Eiji Kitamura - Developer Relations Team




回転寿司はレーンに乗った寿司⽫が客席を回遊し、客は⾷べたい寿司⽫を取るというセルフピックアップ システムの寿司店です。また、客席に備えられたタブレットからも寿司やサイドメニューを注⽂する事ができます。

くら寿司の会計は「回転レーンから取った寿司⽫数」と「オーダーした寿司⽫数」をカウントすることで会計が 決まる仕組みとなっています。

これまでは「回転レーンから取った寿司⽫数」が機械的に取得できず、店員が⼿動かつ⽬視で⽫数の確認を⾏っていましたが、くら寿司では QR コードの識別とTensorFlow を⽤いた画像検知により⾃動で取られた寿司⽫の種類と数をカウントすることで、無⼈で会計確認を⾏う事を実現し、業務コストの削減に成功しました。

システム構成

くら寿司ではレーンを流れる寿司には”抗菌寿司カバー「鮮度くん」”という透明なプラスチックのケースが付い ています。これは寿司の鮮度を保ち、誰も触れないことで清潔さを守るためのケースです。

このケース上部には寿司ネタの種類を記載したQRコードを設置しています。

[QRコードの付いた鮮度くんの写真]

⼀⽅、レーンに沿って配置された各テーブルには、レーンの上流と下流に、レーンの直上となる場所にカメラを設置しています。このカメラは TensorFlow の処理を⾼速化する Coral を搭載したRaspberry Pi に付属したもので す。


[レーンに設置された Raspberry Piの写真]

このカメラでQRコードを識別するとともに、TensorFlow を⽤いて鮮度くんから⽫が取られたかどうかを認識しています。


具体的には上流を通過した時点で鮮度くんが閉まっている事を検知し、下流で開いている場合、そのテーブルで鮮度くんから⽫が取られたと判断することができます。ここでQRコードで識別した寿司の種別をあわせることで、どの寿司がどのテーブルで取られたかを識別することができます。

これらの識別や検知のデータは Raspberry Pi 内で⾼速に⾏われ、原則としてその結果のみが店内に設置された サーバに送信されるため、システム全体としてのデータのやりとりは⼩さなものとなります。

検知デバイスとして Raspberry Pi を選んだ理由はくら寿司が持つ経験に基づいています。ローカルで TensorFlow の⾼速処理を実現するために Coral Edge TPU を⽤いていますが、Coral ⽤に設計された Dev Board を⽤いるのではなく、すでに別の⽤途で店舗で数千台稼働させた経験のある Raspberry Pi に Coral を搭載する形態を採⽤しています。



今後の展開

このように⽇々改善されているこのシステムは 2020 年の時点ですでに200ほどの店舗で稼働しています。くら寿司は⽇本国内に450店舗ほどありますが、来年度には全店舗にこのシステムを展開させ、全ての店舗で TensorFlow を⽤いた⾃動の会計システムを稼働させる予定です。



デジタル カンファレンス 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 事務局

[email protected]

————————————————————



DSC とは

Developer Student Clubs(DSC)プログラムは、Google Developer Technologies に関心のある大学生向けのコミュニティ グループであり、学生の開発・リーダーシップ能力の向上を支援するプログラムです。

デベロッパーとして成長することに関心のあるすべての大学・大学院生の参加を歓迎します。 世界中の学生との交流、Google イベントへの参加、現役エンジニアと出会う機会など、さまざまな活動やワークショップを通じて開発能力とリーダーシップ力の向上を支援します。

米国を始め、ヨーロッパ、オーストラリア、東南アジア、アフリカ、インド、中東・北アフリカ、ラテンアメリカ地域などなど、合わせて 106 カ国以上、1265 拠点から世界中の学生たちが活動している DSC プログラム。今年、日本にも展開します。



このような方の参加をお待ちしています。

  • 世界を変えていく・インパクトを作ることに情熱がある方
  • コンピュータ プログラミングやソフトウェア エンジニアリングに技術的な理解をお持ちの方
  • チームを引っ張ってみた経験、リーダーシップのある方
※ 必須条件 : 卒業まで 2 学期(1 年)以上残っている現役大学生・大学院生(休学中の学生含む)の方が応募可能なプログラムです。


DSC を通してできること

  • Google のトレーニング コンテンツを使用して、デベロッパーとしてのスキルを高める
  • 自分のプロジェクトのスケールを拡大するため、チームの仲間を率いるリーダーシップスキルを身につける
  • 地域別の問題解決に向けたプロトタイプとソリューションの構築を学ぶ
  • グローバルなデベロッパー コンテストに参加する
  • Google の一部イベントや会議にアクセスする



2020~2021 学年度のオンライン申請が開始しました

  • オンライン申請期間 : 2021 年 4 月 7 日(水)~ 6 月 15 日(火)
  • インタビュー : 2021 年 6 月 14 日(月)~ 7 月 21 日(水)
  • 最終 DSC Lead 発表 : 2021 年 7 月 23 日(金)

※各ステップの結果は、個別通知し、上記の日程は変更になる場合がございます。



詳しくはこちら


Posted by Reisa Matsuda- Developer Relations Team



この記事は Google Maps Platform デベロッパー アドボケイト Angela Yu による Google Cloud Blog の記事 "Reduce Deprecation Stress: Understand SDK Dependencies in Google Maps Platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Maps Platform における機能を向上させ、デベロッパーやエンドユーザーの皆様に一層ご活用いただくために、時に既存の機能を非推奨にしなくてはならないことがあります。たとえば、2020 年は COVID-19(新型コロナウィルス感染症)の感染拡大を抑えるために、数多くの施設が一時的に閉鎖される状況となりました。Google Maps Platform はこれを受けて、business_statusフィールドを導入して営業のステータスを 3 つの値で表現できるようにするとともに、臨時休業している店舗を正確に表現できないことから permanently_closed フィールドを非推奨にしました。

本番環境のコードの変更は慎重に行う必要がありますので、Google Maps Platform チームとしても、機能を非推奨にすることは最小限に抑えるよう努めています。本稿では、プロジェクトに影響を与える可能性がある機能の非推奨に関する連絡を受け取った場合に、Google Maps Platform における機能の非推奨の仕組みをご理解頂き、適切なタイミングで対処頂けるよう解説したものです。


非推奨と廃止の違い


まず、ソフトウェアに関する議論でよく混同される 2 つの用語の定義を見てみましょう。
  • 非推奨 : 使用をやめることをおすすめするものです。この理由として、他の良い代替方法や計画的な廃止などが挙げられます。
  • 廃止 : 以前は使用できたものが今後使用できない、またはサポートされないことを表します。廃止されたソフトウェアを呼び出すと、予期しない動作や無効なレスポンスが発生する可能性があります。

SDK における非推奨 : API の非推奨との違い


SDK には、2 つのレベルの非推奨があります。バージョンの非推奨と、機能の非推奨です。SDK のあるバージョンが非推奨になると、そのバージョンは間もなく廃止になります。廃止されたバージョンの SDK の依存関係を使用して構築すると、エラーやクラッシュが発生する可能性があります。そのため、SDK のあるバージョンが非推奨になったというお知らせを確認しましたら、新しいバージョン(理想的には、利用可能な最新のバージョン)に移行する時間を確保するようにしましょう。

次の 2 つの図は、機能の非推奨の 2 つの段階を示しています。最初に、非推奨の機能を含まない新しいメジャー バージョンを導入します。依存関係に古いバージョンを指定することで、非推奨の機能を続けて使用することができます。ただし、コードから非推奨の機能の使用を削除し、依存関係を新しいバージョンに更新するまでは、新しいバージョンでのみ利用できる機能は使用できません。



SDK で機能 B を非推奨にする例。v3.0 には機能 B が含まれていないため、機能 B をサポートしている最後のバージョンは v2 となります。機能 B の使用を続けるには、v2 の指定が必要となります。v3.0 にアップグレードするには、コードから機能 B の使用の削除が必要です。

非推奨の機能をサポートする最後のバージョンが廃止されると、その機能をサポートするバージョンはなくなり、機能の継続的な使用は保証されませんので、ご注意ください。




SDK でのバージョンの廃止の例。v2 は機能 B をサポートする最後のバージョンであり、サポートが終了しているため、機能 B を今後使用することはできません。SDK に依存するアプリケーションを新しく構築するには、サポートされているバージョンにアップグレードする必要があるため、機能 B の使用をやめる必要があります。

API や SDK における非推奨の微妙な違いについては、非推奨に関するドキュメントをご覧ください。現在非推奨となっているすべての機能を記載しています。


SDK の依存関係の管理方法


Google Maps Platform のモバイル向けの SDK(Maps SDK for Android、Places SDK for Android、Maps SDK for iOS、Places SDK for iOS)をお使いのデベロッパーは、依存関係のバージョンを管理することで、期限前に慌てて修正するのではなく、定期的なバージョン アップなどアプリの開発サイクルに合わせて非推奨の機能を移行するスケジュールを立てられます。

これらの SDK の場合、アプリの依存関係に正確なバージョン番号を指定することをおすすめします。Maps SDK for AndroidPlaces SDK for AndroidMaps SDK for iOSPlaces SDK for iOS で、SDK の依存関係を管理する方法をドキュメントに記述しているのでご確認ください。

なお、Maps JavaScript API はモバイル向けの SDK とは異なります。バージョンは四半期ごとのスケジュールでリリースされたり廃止されたりするため、常に最新バージョンをデフォルト(v=weekly)で読み込むことをおすすめします。Maps JavaScript API の定期的な更新に備える方法について、詳しくはこちらをご覧ください。


コードを更新するタイミングの選択


最後のステップは、開発サイクルでの定期的なコード保守のスケジュールです。これにより、技術的な負担を最小限に抑えると同時に、SDK の最新の改善点を使用できます。リリースノートやサービスに関する必須のお知らせでは、コードの更新作業に必要となる労力を最小限に抑えるために、移行ガイドを提示したり、非推奨の機能を使用しないよう回避策を提案したりします。

前述の手順を踏むことで、次に非推奨の機能やバージョンに関する通知を受け取った場合に、安心してコードを更新し、最新の SDK のバージョンを導入するタイミングを選択することができます。安定した SDK のバージョンに照らしてモバイルアプリの構築が予測可能となり、ウェブサイトに影響を及ぼす可能性がある変更についての JavaScript リリースノートを受け取った際に何をすべきか(以前のバージョンを指定)が理解できます。前述のヒントにより、コードの更新を事前に計画し、非推奨の通知によるストレスをなくすことができれば幸いです。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer


メモリ管理の改善

Windows 版の Chrome M89 では、ブラウザ プロセスで最大 22%、レンダラで 8%、GPU で 3% と、大幅なメモリの節約を実現しました。さらに、ブラウザの応答性が最大 9% 改善しています。これは、Google の高度なメモリ アロケータである PartitionAlloc を使って実現しました。このアロケータは、割り当ての低遅延性、空間効率、セキュリティの面で最適化されています。PartitionAlloc は、これまでにも、Google のレンダラ コードベースである Blink の内部で広く使われています。M89 より、Android 版と 64 ビット Windows 版の Chrome をアップグレードし、(malloc をインターセプトして)すべての場所で PartitionAlloc を使うようにしました。

現在の Chrome は、メモリの割り当て方法が改善されただけでなく、メモリの使用(と破棄)についてもさらにスマートになりました。現在の Chrome は、画面外の大きなイメージなど、フォアグラウンド タブが使っていないメモリを破棄することで、タブ 1 つにつき最大 100 MiB を回収します。人気サイトの 20% 以上がこのようなサイトに該当します。macOS 版の Chrome では、バックグラウンド タブのメモリ フットプリントも縮小しています。これは、他のプラットフォームでしばらく前から行っていることです。これにより、最大 8%、場合によっては 1 GiB 以上のメモリを節約できます。

さらに、タブ スロットリングに関する実データが集まるにつれて、バックグラウンドのタブの Apple Energy Impact スコアが最大 65% 改善しています。つまり、Mac は熱くならず、ファンも静かになっています。


ビルド、パッケージング、ランタイムの改善

Chrome for Android に特化して、あらゆる種類の Android デバイスにとって快適なブラウザを作るという、他にはない挑戦をしています。今回のリリースでは、パッケージングとランタイムの最適化を適用し、ポケットの中の Chrome のパフォーマンスを向上させています。


新しい Play 機能や Android 機能を使うと、Android で Chrome を再パッケージングできます。これにより、リソースの枯渇によるクラッシュが減少し、メモリ使用量は 5%、スタートアップ時間は 7.5%、ページ読み込みは最大 2% 改善しました。Android App Bundle を使うと、各ユーザーのデバイス構成に合わせて最適化した APK を Play ストアで生成できます。コードやリソースを分割 APK にパッケージングして、ベース APK とともにインストールすることもできます。また、Android O の機能である isolatedSplits を使うと、これらの分割機能をオンデマンドで読み込むことで、Chrome 全般のスタートアップ コストを削減できます。

最新の Android デバイス(Android Q 以降かつ 8 GB 以上の RAM)をお使いの方のために、Chrome を 64 ビットバイナリとして再ビルドしました。これにより、ページの読み込みが最大 8.5% 速く、スクロールや入力のレイテンシが 28% 少なくなり、さらに安定した Chrome を提供できるようになっています。

加えて、Android で Chrome の起動が 13% 速くなる機能、フリーズドライ タブを組み込んでいます。この機能により、軽量版のタブが保存されるようになり、このタブのサイズはスクリーンショットと同じくらいでありながら、スクロール、ズーム、リンクのタップをサポートします。スタートアップ時には、実際のタブがバックグラウンドで読み込まれるまでの間、このフリーズドライ タブを利用してページにすばやくアクセスできます。以下の動作例をご覧ください。



Google のチームは、あらゆるデバイスに最速、最強のブラウザをお届けするために、常に懸命に作業を進めています。ここでお知らせしたパフォーマンスの改善を提供できることをうれしく思います。今後もさらに改善を続けますので、ご期待ください。

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


Reviewed by Eiji Kitamura - Developer Relations Team

モバイル デバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証(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)

悪意や欠陥のあるアプリケーション - モバイル デバイスに読み込まれたアプリケーションに、悪意のあるコードや悪用可能なコードが含まれる可能性がある 

通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル

認可と認証 - ネットワークやバックエンドの安全な認証(Authentication)

モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能

モバイル デバイスの整合性 - ソフトウェア、ハードウェアの両方における重要な機能のデバイスの整合性

エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供

恒常的な存在 - 攻撃者がデバイスに恒常的に存在する場合、デバイスは整合性を失い、それを取り戻せないことを意味する 

モバイル デバイスの整合性 - ソフトウェア、ハードウェア両方における重要な機能の整合性を保証するためのデバイスの整合性が保たれている

エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供


この認証(Certification)が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。

  1. すべての対策があらかじめ定義された標準や基準を満たしている。
  2. すべての対策が公表されているとおりに機能する。

概念的には、評価対象(TOE)はデバイスのハードウェア(システム オン チップ)とオペレーティング システム(Android)の組み合わせです。上記の脅威に対する対策を検証するため、ラボは以下のセキュリティ機能を確認します。

これが企業にとって重要な理由

Pixel のセキュリティが企業のニーズを確実にサポートできることは、非常に重要です。規制が厳しい業界の多くでは、機密データが考えられる限り最も強固な保護を受けられるように、Common Criteria 認証(Certified)デバイスの利用が義務付けられています。Android Enterprise 管理フレームワークでは、企業がデバイスの管理などをし、エンドユーザーが実行できる操作を制限したり、デバイスを監査してすべてのソフトウェアが適切に設定されていることを保証したりできます。たとえば、企業の IT 管理者は、カメラ、位置情報サービス、アプリのインストール プロセスなどの機能に対するポリシーを強制できます。

これがコンシューマにとって重要な理由

セキュリティは企業だけが心配することではありません。Common Criteria 認証(Certification)で検証している多くの保護は、コンシューマにも適用されます。たとえば、Wi-Fi に接続するとき、ウェブのブラウズを誰にも盗聴されないことを確認したいと思うでしょう。デバイスの紛失や盗難の際は、ロック画面によって他人が個人情報にアクセスする可能性が減ると確信したいはずです。

Google は、すべてのユーザーにセキュリティとプライバシーをお届けしたいと考えています。Pixel デバイスがこの認証(Certification)基準以上を確実に満たせるようにしたいと考えているのはそのためです。今後もこの基準を満たすために注力しますので、どうぞご安心ください。Pixel スマートフォンでは、スイッチを入れた瞬間から充実したセキュリティを利用できます。

これが Android エコシステムにとって重要な理由

認証(Certification)はサードパーティによる検証として有用な形態ですが、以下の、Google が 3 C と呼ぶものに該当することがよくあります。

  • Complex(複雑) - デバイスのハードウェア、オペレーティング システム、その間にあるものすべてを含む評価スコープであるため。
  • Costly(高価) - すべての形式とモデルの組み合わせ(SoC + OS)について、認定を受けたラボで実際に評価作業をする必要があり、個々のテストは数百件にのぼるため。
  • Cumbersome(厄介) - かなり長い評価手続きで、初回は最長で 18 か月を要するため。

ここ 3 年間は、OEM パートナーを対象に、この複雑さを軽減するための作業をしてきました。その結果、必要なセキュリティ要件を満たすために要求される機能が Android オープンソース プロジェクトに直接組み込まれることをお知らせします。さらに、すべての管理要件と監査要件を Android Enterprise Management フレームワークに追加しました。昨年は、このために開発したツールを GitHub に公開しました。他の Android OEM が認証(Certification)を受ける際に、この作業のメリットを活用できるようにするためです。

新しい Android OS バージョンでの Pixel スマートフォンの認証(Certification)は継続しますが、Google はその他の Android OEM も、この認証(Certification)や、以下のその他の認証(Certification)を取得できるように取り組んでいます。

  • アメリカ国立標準技術研究所の Cryptographic Algorithm と Module Validation Programs。これは暗号アルゴリズムとモジュールの評価で、アメリカの公共部門やその他多くの規制のある業界で求められています。Android 11 では、Conscrypt の主要モジュールである BoringSSL がこの検証を終えています(認定番号 3753)。
  • アメリカ国防総省の Security Technical Implementation Guide(略称 STIG)。アメリカ国防総省のネットワークに技術を導入する方法をまとめたガイドラインです。かつては Android OEM に独自の実装や制御があったので、それによって異なる STIG が存在していましたが、Google の作業の成果によって、現在は 1 つの Android STIG テンプレートに統合されています。そのため、Android OEM は、さまざまな要件を満たすために独自の制御を作成する手間をかけずに済みます。

今後も、企業とコンシューマの両方を対象にしたセキュリティ対策に注力してまいります。業界の皆さんがこの作業に加わってくれることを歓迎いたします。


Reviewed by Eiji Kitamura - Developer Relations Team


さらに、8 週間ごとにマイルストーンがアップデートされる Extended Stable オプションを新しく追加します。Extended Stable は、エンタープライズの管理者や Chromium を埋め込みで利用しているユーザーで、アップデートの管理に追加の時間が必要な方が利用できます。Extended Stable では、重要な問題を修正するセキュリティ アップデートは 2 週間ごとにリリースされますが、このアップデートには、4 週間ごとのオプションで提供される新機能やセキュリティの修正は含まれません。 

Chrome OS ユーザーの皆さんにも、複数の安定版リリース オプションを提供する予定です。Chrome OS の管理者には、今後の数か月間で、管理対象のデバイスに対するマイルストーンのアップデート オプションについてさらに詳しくお伝えします。

新しいリリース スケジュールに関するドキュメントは、最新の状態に更新しています。また、[email protected] で Chromium のコントリビューターの皆さんからのフィードバックをお待ちしています。新しいリリース スケジュールの導入に向けて、リリース カレンダーにも仮のアップデートをしています。このカレンダーは、常に最新の状態に更新します。

今後も Chrome の進化が続き、セキュリティ、安定性、スピード、シンプルさをこれまで以上に早くユーザーの皆さんにお届けできることを楽しみにしています。

Reviewed by Eiji Kitamura - Developer Relations Team