Google は、プライバシー技術へのアクセスを拡大し、あらゆる人が利用できるものにしたいと考えています。私たちは、研究者、政府機関、非営利団体、企業などのデベロッパー コミュニティが、差分プライバシーに対応した新しいアプリケーションを作って公開するうえで役立つ無料ツールを作成しています。差分プライバシーは、個人に関する情報を一切明かすことなく、有用な知見やサービスを提供できるようにする技術です。データ プライバシー デーである今日（元記事公開当時）は、その作業に関する最新情報をお知らせします。プライバシーを考慮した設計のプロダクトによって、すべてのインターネット ユーザーにとって安全なエコシステムを作るために、業界を前進させることができれば幸いです。

差分プライバシーを利用できるデベロッパーを増やす

C++、Java、Go によるオープンソース版の基本差分プライバシー ライブラリを公開したのは、2019 年のことでした。そのときの目標は、透明性を実現し、研究者がコードを調査できるようにすることでした。自分たちのアプリケーションでこのライブラリを使いたいというデベロッパーから、大きな関心が寄せられ、その中には、さまざまな医療機関がプライバシーを保護しつつ、医療データから学習できるようにした Arkhn のようなスタートアップ企業もあれば、プライベートであることを証明できるデータを通して科学的発見を加速したオーストラリアのデベロッパーもありました。

その後も、私たちは差分プライバシーを広く利用できるようにするために、さまざまなプロジェクトや新手法に取り組み続けています。今回は、オープンソース デベロッパー団体 OpenMined と連携して 1 年間の開発を行ってきた結果として、差分プライバシー フレームワークの新たなマイルストーンを発表いたします。それは、あらゆる Python デベロッパーが差分プライバシーを用いてデータを処理できるプロダクトです。

これまでの差分プライバシー ライブラリは、3 つのプログラミング言語で利用できました。しかし、Python で利用できるようになった今、世界中のデベロッパーのほぼ半数にお届けできることになります。つまり、膨大な数のデベロッパー、研究者、企業が、業界をリードするプライバシー技術を使ったアプリケーションを作り、個人のプライバシーを保護、尊重しつつ、データセットから知見を得たりトレンドを観測したりできるようになります。

すでにこの新しい Python ライブラリを使い、新たなユースケースの実験を始めている組織もあります。たとえば、匿名で集計し、サイトで最もアクセスされているページを国ごとに表示するユースケースです。このライブラリの特徴は、大規模データ処理エンジンを代表する 2 つのフレームワークである Spark と Beam を使っており、柔軟な利用や実装ができることです。また、新たな差分プライバシー ツールとして、差分プライバシー情報を生成するために使うパラメータの視覚化やチューニングを行えるツールもリリースします。さらに、差分プライバシーをペタバイトとそれ以上のデータセットに効率的にスケールアップする技法をまとめた論文も公開します。

すべてのオープンソース プロジェクトと同じように、技術と成果がどれほどのものになるかはコミュニティ次第です。社内では、モビリティ レポートや Google マップの混雑状況機能を支えるインフラストラクチャなど、差分プライバシー ソリューションを開発するチームのトレーニングを行っています。私たちは目標を実現する一環として、差分プライバシー技術の導入方法を学びたい方を助けるために、OpenMined が Google 外部のエキスパート チームを編成することもサポートしました。

今後に向けて

世界中のデベロッパーの皆さんには、この機会を活用して、統計分析や機械学習などの差分プライバシーのユースケースを試してみることをおすすめします。しかし何よりも、フィードバックをお送りいただけることを願っています。皆さんが開発できるアプリケーションや、その過程で私たちが提供できる機能について、ぜひお知らせください。

私たちは、今後も重要なプライバシー強化技術へのアクセスを拡大する努力を続けるとともに、デベロッパーの皆さんがユーザビリティを向上し対象範囲を拡大する作業に加わっていただけることを願っています。先ほども述べましたが、世界中のすべてのインターネット ユーザーがワールドクラスのプライバシーに値するというのが私たちの考えです。その目標に向かうために、これからも多くの組織と連携を続けてゆきたいと思います。


Reviewed by Eiji Kitamura - Developer Relations Team

AMP にとって、ユーザーのプライバシー保護は非常に重要です。そのため、サイトオーナーが同じことを行えるように、ツールの作成に取り組んでいます。今日は、AMP ページがきめ細かな同意機能をサポートしたことをお知らせします。

ウェブサイトの同意機能によって、ユーザーは、どのようなデータの収集や共有を許可するかを指定できます。このような同意機能には、主に 2 つの形態があります。グローバル同意 では、ユーザーがウェブサイトで一度だけ同意します。たとえば、あるカテゴリの Cookie を許可することに同意するか、ブロックすることをリクエストするかのどちらかです。AMP は以前から、<amp-consent> コンポーネントでグローバル同意をサポートしています。

一方、きめ細かな同意では、ユーザーがウェブサイトで複数の同意項目を選択できます。たとえば、アナリティクスでの使用とパフォーマンス データの収集は許可しても、マーケティング用の Cookie は許可しないユーザーがいらっしゃるかもしれません。

最新の <amp-consent> は、きめ細かな同意とグローバル同意の両方をサポートします。

きめ細かな同意を実装する場合は、パフォーマンス Cookie、マーケティング Cookie、アナリティクスなど、複数の同意の目的を定義し、ユーザーがそれぞれの使用を許可または拒否できるインターフェースを作ります。AMP コンポーネントにラベルを付けることで、ユーザーが指定した目的に同意しない限り、コンポーネントをブロックできます。

<amp-consent> を使うと、独自のソリューションを作成したり、同意管理プロバイダ（CMP）による同意を実装したりすることもできます。

早速今日からお試しください。詳しくは、ドキュメントをご覧ください。こちらの例から始めることもできます。または、以下の動画をご覧ください。

フィードバックや機能リクエストがありましたら、ぜひお知らせください。

投稿者 : AMP Project、デベロッパー アドボケート、Ben Morss


Reviewed by Chiko Shimizu - Developer Relations team

Reviewed by Eiji Kitamura - Developer Relations Team




Android 11 が公開されました！日本時間 9 月 9 日に、ソースを Android オープンソース プロジェクト（AOSP）にプッシュし、Android の最新バージョンを正式にリリースしました。Android 11 は、3 つのテーマ、すなわち人、管理、安全性にフォーカスして開発されています。人中心のコミュニケーションへのアプローチ、ユーザーがすべてのスマート デバイスにすばやくアクセスしてコントロールできる管理、端末のデータの共有方法をより細かく制御できる安全性の 3 つです。詳しくは、こちらのブログ記事をご覧ください。  

デベロッパーにとって、Android 11 は新機能の宝庫です。会話通知、デバイスとメディアのコントロール、「今回のみ」のアクセス許可、強化された 5G サポート、IME の切り替えなどを確認しておきましょう。皆さんの開発作業を高速化するため、互換性の切り替え、ADB の増分インストール、アプリ終了理由 API、データアクセス監査 API、Kotlin NULL 可能性アノテーションなど、たくさんの新しいツールも追加しました。多くのデベロッパーの皆さんがAndroid 11 に対応したアプリを開発されることが楽しみです！ 

9 月 9 日より、正式版の Android 11 が Pixel 2、3、3a、4、4a 端末から順次配信が開始されていますので、ご期待ください。配信前にダウンロードする方は、Android 11 デベロッパー サイトをご覧ください。  

人、管理、安全性

「人」

Android 11 は「人」を中心とした、高い表現力を持っています。スマートフォンで会話する方法を新たな発想で見直し、皆さんの生活に最も重要な「人」を認識して優先できる OS です。デベロッパーは、Android 11 を使ってさらに深い会話や個人間のやり取りを行うアプリを構築できます。

  • 会話通知がシェード上部の専用のセクションに表示されます。これは人を前面に出したデザインになっており、会話をバブルとして開く、ホーム画面に会話のショートカットを作成する、リマインダーを設定するなどの会話専用アクションも実行できます。


  • バブルを使って会話を表示したままにできるので、端末でマルチタスク作業を行っていても会話にアクセスできます。Android 11 のメッセージ アプリやチャットアプリでこの機能を有効化するには、通知で Bubbles API を使う必要があります。


  • 統合キーボード サジェスチョンを利用すると、自動入力アプリやインプット メソッド エディタ（IME）から、状況に特有なエンティティや文字列を IME のサジェスチョン ストリップ（このような内容を表示するには最も便利な場所です）に直接かつ安全に表示できます。


バブルと会話通知


管理

Android 11 では、ユーザーが端末につながっているすべてのスマート デバイスにすばやくアクセスして、1 か所からコントロールできます。デベロッパーは新しい API を使い、ユーザーによるスマート デバイスの表示やメディアの制御を実現できます。

  • デバイス コントロールを使うと、ネットワークに接続されたスマート端末に今までになく迅速かつ簡単にアクセスして制御できます。電源ボタンを長押しするだけで、すべてのデバイスが即座にデバイス コントロールに表示されるようになりました。新しい API を使うと、アプリを「コントロール」に表示できます。詳しくはこちらをご覧ください。


  • メディア コントロールは、オーディオ コンテンツや動画コンテンツの出力先デバイス（ヘッドフォン、スピーカー、TV など）を即座に切り替えたいときに便利です。詳しくはこちらをご覧ください。

 

デバイス コントロールとメディア コントロール


安全性

Android 11 では、機密性の高いアクセス許可をユーザーが細かく制御できるようにして透明性を向上させ、アップデートを高速化することで端末の安全を保てるようにしています。

 

  • 「今回のみ」のアクセス許可 - ユーザーはアプリに対して、端末のマイクやカメラ、位置情報に対する 1 回限りのアクセス許可を付与できるようになります。アプリは、次に使われたときに再度アクセス許可をリクエストできます。詳しくはこちらをご覧ください。
     


    Android 11 の「今回のみ」アクセス許可ダイアログ


  • バックグラウンド位置情報 - バックグラウンド位置情報を使うには、実行時アクセス許可に加えて、ユーザーから追加の承認を得る必要があります。バックグラウンド位置情報を必要とするアプリでは、システムはまずアプリがフォアグラウンド位置情報を要求することを確認します。その後、個別のアクセス許可リクエストによって、アクセス権をバックグラウンド位置情報に広げます。その際、ユーザーがアクセス許可を付与できるように、システムは [管理] を開きます。 

    なお、不正利用を防ぐため、アプリがバックグラウンドで位置情報にアクセスする場合は承認を得なければならなくなります。デベロッパーの皆さんの対応が間に合うよう、2021 年まで既存アプリへのポリシーの適用を行わないません。詳しくはこちらをご覧ください。

     
  • アクセス許可の自動リセット - ユーザーが長期間アプリを使わなかった場合、Android 11 はアプリに関連付けられたすべての 1 回だけのアクセス許可を「自動リセット」し、ユーザーに通知します。アプリは、次に使われたときに再度アクセス許可をリクエストできます。詳しくはこちらをご覧ください。
     

  • 対象範囲別ストレージ - 外部ストレージにあるアプリのデータとユーザーのデータの保護を強化し、さらにデベロッパーが簡単に移行できるように改善しています。詳しくはこちらをご覧ください。

     
  • Google Play システム アップデート - 昨年リリースされた Google Play システム アップデートは、Android エコシステムの端末に対するコア OS コンポーネントのアップデートを促進する仕組みです。Android 11 では、アップデート可能なモジュールの数が倍以上になっています。この 12 の新しいモジュールは、ユーザーやデベロッパーのプライバシーやセキュリティ、整合性の改善に役立ちます。

     
  • BiometricPrompt API - BiometricPrompt API を使うと、アプリがロック解除や機密部分へのアクセスを行う際に必要とするバイオメトリック認証強度を指定できます。下位互換性を確保するため、この機能は Jetpack Biometric ライブラリにも追加されています。この件については、作業の進捗に応じて最新情報をお知らせします。

     
  • Identity Credential API - これにより、モバイル運転免許証、国民識別番号、デジタル ID などの新しいユースケースが実現します。Android 11 でデジタルファーストな身分証明を提供できるように、さまざまな政府機関や業界パートナーと連携して作業を進めています。

こちらから、Android 11 のすべてのプライバシー機能について確認いただけます。


イノベーション

  • 5G サポートの強化 - Android 11 では、高速かつ低遅延な 5G ネットワークを活用できるように、デベロッパー サポートがアップデートされています。ユーザーが 5G ネットワークに接続したタイミングを検知したり、接続が従量課金かどうかを確認したり、接続の帯域幅を推定したりすることができます。5G 体験の構築に役立つよう、Android Emulator にも 5G サポートを追加しています。Android で 5G を使ってみたい方は、5G デベロッパー ページをご覧ください。


    　　　
    5G は、自宅にとどまることなく、友人から家族、会社に至るまで、まわりの世界とシームレスな繋がりを実現し、「移動中」の体験も高める
     

  • 新しい画面タイプのサポート - Android 対応端末のメーカーは、ホールパンチ スクリーンやウォーターフォール スクリーンなど、新しく画期的な画面の端末を市場に送り出しています。Android 11 では、プラットフォームによるサポートを追加し、アプリを最適化できる API を提供しています。ホールパンチ スクリーンとウォーターフォール スクリーンは、どちらも既存のディスプレイ カットアウト API で扱うことができます。新しいウィンドウ レイアウト属性を設定してウォーターフォール スクリーン全体を使用したり、新しいウォーターフォール インセット API を使ってエッジ付近のインタラクションを制御したりすることができます。 

     
  • 通話スクリーニングのサポート - Android 11 では、通話スクリーニング アプリによるロボコール対策が強化されています。アプリは、通話詳細の一部として着信通話の STIR/SHAKEN ステータス（発信者番号のなりすましに対抗するための標準）を検証できるようになり、通話拒否の理由の報告も可能になります。さらに、システムが提供する通話終了画面をカスタマイズし、通話を迷惑通話としてマークする、連絡先に追加するなどの操作が可能になります。 


品質の向上


  • OS の耐障害性 - Android 11 では、RSS HWM しきい値に基づいてユーザーが気づかないようにプロセスの再起動を強制するなど、メモリ再利用プロセスを微調整することで、OS 全体のダイナミックさと耐障害性を向上させています。 さらに、パフォーマンスとメモリを改善するために、Android 11 に Binder のキャッシュを追加しています。これにより、静的に近いデータを取得する際にキャッシュが活用されるようになり、利用頻度の高いシステム サービス IPC コールが最適化されます。Binder のキャッシュは、電池寿命の向上や CPU 時間の削減にも効果があります。


  • 同期的な IME の切り替え - 新しい API を使うと、アプリのコンテンツと、アニメーションしながら画面に出入りする IME（インプット メソッド エディタ、すなわち画面キーボード）やシステムバーを同期させることができます。これにより、自然で直感的でスムーズな IME の切り替えを簡単に実現できるようになります。新しいWindowInsetsAnimation.Callback API を使うと、フレーム単位の完璧な切り替えが行えます。この API を使うとシステムバーや IME がアニメーションしている間、アプリはインセットに対するフレーム単位の変化について通知を受けることができます。さらに、新しい WindowInsetsAnimationController API を使うと、システムバー、IME、没入モードなどのシステム UI タイプを制御することもできます。詳しくはこちらをご覧ください。 


 

  • HEIF アニメーション ドローアブル - ImageDecoder API を使うと、HEIF ファイルに格納されたイメージ シーケンス アニメーションのデコードとレンダリングを行うことができます。そのため、ネットワーク データや APK サイズへの影響を最低限にとどめつつ、高品質アセットを利用することができます。HEIF イメージ シーケンスを使うと、アニメーション GIF に比べてイメージ シーケンスのファイルサイズを大幅に削減できます。 


  • ネイティブ イメージ デコーダー - 新しい NDK API を使うと、グラフィックや後処理用にネイティブ コードからイメージ（JPEG、PNG、WebP など）のデコードとエンコードを行うことができ、しかも外部ライブラリをバンドルする必要がなくなるため、APK サイズを小さく保つことができます。ネイティブ デコーダーには、継続的にプラットフォームのセキュリティがアップデートがされる Android の処理を活用できるというメリットもあります。この API の使い方の例については、NDK サンプルコードをご覧ください。

     
  • MediaCodec の低遅延動画デコード - Stadia など、リアルタイムに動画ストリーミングを行うアプリやサービスには、低遅延動画が不可欠です。低遅延再生をサポートする動画コーデックは、デコードの開始後、できるだけ早くストリームの最初のフレームを返します。アプリで新しい API を使うと、特定のコーデックの低遅延再生について確認と設定を行えます。

     
  • 可変リフレッシュ レート - アプリやゲームで新しい API を使うと、ウィンドウに好みのフレームレートを設定できるようになります。ほとんどの Android 端末は、60Hz のリフレッシュ レートで画面を更新します。しかし、60Hz に加えて 90Hz をサポートしているなど、複数のリフレッシュ レートに対応し、実行時に切り替えることができるものもあります。このような端末では、システムがアプリに最適なリフレッシュ レートを選択する際に、アプリが設定したフレームレートを使用します。この API は、SDK と NDK の両方で利用できます。詳細については、こちらをご覧ください。

     
  • ダイナミック リソース ローダー - Android 11 には、アプリが実行時に動的にリソースやアセットを読み込む新しいパブリック API が含まれています。リソース ローダー フレームワークを使うと、アプリやゲームにリソースの基本セットを含めておき、実行時に必要に応じて追加リソースを読み込んだり、読み込んだリソースを変更したりすることができます。 

     
  • Neural Networks API（NNAPI）1.3 - Android 端末で機械学習をサポートするため、命令や制御の追加を続けています。一般的なユースケースを最適化するため、NNAPI 1.3 には優先順位とタイムアウト、メモリドメイン、非同期コマンドキューに関する API が追加されています。高度なモデル用の新しい命令には、符号付き整数の非対称量子化、分岐とループ、MobileNetV3 などの次世代オンデバイス ビジョンモデルの高速化に役立つ hard-swish 命令などが含まれています。 


デベロッパーに優しく

  • アプリ互換性ツール - Android 11 の大半の動作の変更点をオプトインできるようにし、アプリの targetSdkVersion を 30 にするまで反映されないようにすることで、アプリに対する互換性の影響を最低限にとどめています。また、Google Play を通して配信している場合は、これらの変更をオプトインするまでに 1 年以上の期間があります。ただし、早めにテストを始めることを推奨します。Android 11 では、テストに役立ててもらうため、多くのオプトイン可能な変更点の有効、無効を切り替えることができるようにしています。詳しくはこちらをご覧ください。


  • アプリの終了理由 - アプリが実行される端末の種類、メモリ構成、ユーザーが行った動作は多岐にわたり、アプリが終了した場合、その理由とその状況を分析することが何より重要となります。Android 11 では、その分析が簡単にできます。搭載された終了理由 API を使うと、アプリの直近の終了について詳細をリクエストできます。

     
  • データアクセス監査 - データアクセス監査はアプリの診断を行う機能で、アプリがユーザーデータにどのようにアクセスするか、どのユーザーフローからアクセスするかについて知ることができます。たとえば、皆さんのコードや使用する SDK で、機密データへの意図しないアクセスを見つける際に役立ちます。詳しくはこちらをご覧ください。 

     
  • ADB Incremental - 開発時に ADB（Android Debug Bridge）で巨大な APK をインストールすると、非常に時間がかかって生産性に影響が出る可能性があります。特に、Android ゲーム関連のデベロッパーではそれが顕著です。Android 11 の ADB Incremental を利用すると、開発用の PC から大きな APK（2GB 以上）を Android 11 端末にインストールする時間が最大で 10 分の 1 になります。詳しくはこちらをご覧ください。

     
  • Kotlin NULL 可能性アノテーション - Android 11 では、パブリック API のさらに多くのメソッドに NULL 可能性アノテーションが追加されています。また、たくさんの既存のアノテーションが警告からエラーにアップグレードされています。これにより、NULL 可能性の問題を実行時ではなくビルド時に発見できるようになります。詳しくはこちらをご覧ください。 


Android 11 リリースに向けたアプリの準備

Android 11 はまもなくユーザーに公開されます。ぜひ、互換性テストを終えてアップデートを早めに公開していただくようお願いします。 


注意すべき大きな動作の変更点のいくつかを紹介します（これらは、アプリの targetSdkVersion によらず適用されます）。

 

  • 「今回のみ」のアクセス許可 - 位置情報と端末のマイクやカメラに対する 1 回限りのアクセス許可を付与できるようになります。詳しくはこちらをご覧ください。


  • 外部ストレージ アクセス - 外部ストレージにある他のアプリのファイルにアクセスできなくなりました。詳しくはこちらをご覧ください。


  • Scudo 強化アロケータ - Scudo がアプリのネイティブ コード用ヒープメモリ アロケータになりました。詳しくはこちらをご覧ください。


  • ファイル記述子サニタイザー - Fdsan がデフォルトで有効化されるようになりました。アプリのネイティブ コードでファイル ディスクリプタ処理の問題を検出します。詳しくはこちらをご覧ください。


Android 11 には、オプトイン可能な動作の変更点も含まれています。これらは、アプリのターゲットを新しいプラットフォームにした時点で反映されます。互換性のあるバージョンのアプリを公開した後、これらの変更点をできる限り早く評価することをお勧めします。互換性テストやツールの詳細については、Android 11 の互換性の週にお伝えしたドキュメントをご覧ください。詳しい技術解説は Android 11 デベロッパー サイトをご覧ください。 


新機能や新 API でアプリを強化する

準備ができたら、Android 11 に移行し、使用できる新しい機能や API について各種ドキュメントでご確認ください。こちらでは最初に着手すべき重要な機能をまとめています。以下の機能はすべてのアプリで対応することをお勧めします。 

  • ダークテーマ（Android 10 以降）- ダークテーマを追加するか Force Dark を有効にして、システム全体でダークテーマを有効にしているユーザーに一貫性のある体験を提供します。

  • ジェスチャー ナビゲーション（Android 10 以降）- アプリを全画面に対応させてジェスチャー ナビゲーションをサポートし、カスタム ジェスチャーがうまく動作するようにしましょう。詳しくはこちらをご覧ください。

  • ショートカットの共有（Android 10 以降）- 共有データを受け取りたいアプリは、ショートカット共有 API を使って共有ターゲットを作成する必要があります。共有データを送りたいアプリは、システム共有シートを使う必要があります。


  • 同期的な IME の切り替え - 新しい WindowInsets API やその関連 API を使うと、ユーザーにシームレスな画面遷移を提供できます。詳しくはこちらをご覧ください。 


  • 新しい画面タイプ - 必要に応じて、ホールパンチ スクリーンやウォーターフォール スクリーンを搭載した端末用にコンテンツをテストし、調整してください。詳しくはこちらをご覧ください。  


該当するアプリでは、以下の項目にも対応することをお勧めします。

  • 会話 - メッセージングやコミュニケーションを行うアプリは、長期ショートカット共有を作成して通知に会話を表示することで、会話エクスペリエンスに参加できます。詳しくはこちらをご覧ください。 


  • バブル - バブルは、会話を表示したままにしてマルチタスク作業中に会話にアクセスできるようにする方法です。これを実現するには、通知で Bubbles API を利用します。 


  • 5G  - アプリやコンテンツで高速かつ低遅延な 5G を活用できる場合は、何ができるかを確認するため、デベロッパー リソースをご覧ください。 


  • デバイス コントロール - アプリで外部スマート デバイスをサポートする場合は、Android 11 の新しいデバイス コントロール エリアからアクセスできるようにしましょう。詳しくはこちらをご覧ください。 


  • メディア コントロール - メディアアプリは、Android 11 メディア コントロールをサポートすることが推奨されます。ユーザーがクイック設定シェードから再生や再開を制御できるようになります。詳しくはこちらをご覧ください。 


Android 11 のすべての機能については、developer.android.com/11 をご覧ください。 


Android 11 をインストールする

Android 11 は、9 月 9 日より、一部の Pixel、OnePlus、Xiaomi、OPPO、realme スマートフォンにロールアウトされます。今後数か月で、さらに多くのパートナーが端末のリリースやアップグレードを行う予定です。今年のベータ版プログラムに登録されている端末も含め、Pixel 2、3、3a、4、4a スマートフォンをお持ちの方には、まもなく OTA（無線）アップデートが届きますので、ご期待ください。  

Pixel 端末向けの Android 11 のファクトリー システム イメージも Android Flash Tool から利用できます。または、こちらからダウンロードできます。いつものように、最新の Android Emulator システム イメージは Android Studio の SDK Manager から取得できます。Treble 対応の端末で幅広くテストしたい場合は、こちらから Generic System Image（GSI）を入手できます。 

Android 11 のソースコードは、Android オープンソース プロジェクト リポジトリの Android 11 ブランチの下にあります。こちらをご覧ください。


今後の予定について

プレビュー版の Issue Tracker はまもなくクローズし、Developer Preview やベータ版ビルドに対して記録されたオープン状態のバグの管理も終了します。しかし、フィードバックは引き続きお待ちしています。Preview の Issue Tracker に記録した問題がまだ解消されていないという方は、AOSP Issue Tracker で Android 11 に対してフィードバックをお寄せください。

 今年のプレビュー プログラムに参加してくださった、たくさんのデベロッパーと先行ユーザーの皆さん、本当にどうもありがとうございました。お寄せくださったフィードバックのおかげで、Android 11 はあらゆる人にとってよりよいプラットフォームになっています。

 Android 11 に対応した皆さんのアプリを拝見できることを楽しみにしています。


Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing, APAC

Share on Twitter Share on Facebook

早くも 8 月になり、Android 11 公式版のリリースが迫っています！

現在、この新しいプラットフォームの最終調整を行っているところですが、2020 年 8 月 6 日（日本時間 8 月 7 日）に最後のベータ版であるAndroid 11 Beta 3 をリリースしました。今年のプレビュー サイクルの最後のアップデートですので、ユーザーへの公式版リリース前の今こそ、デベロッパーの皆さんはぜひご自身のアプリやゲームの準備をお願いいたします。

Android 11 Beta 3 は、Pixel 2、3、3a、4 の各端末で8 月 7 日より利用が可能になっています。また、近日中に Pixel 4a でも利用できます。また、こちらから登録をすると、OTA（無線）アップデートも行えます。既に登録済みの方は、まもなく自動的にアップデートが行われます。これまでフィードバックを提供してくださった皆さん、どうもありがとうございました。ぜひ引き続き、フィードバックをお寄せください。

それでは、いよいよ時期が迫ってきた公式 Android 11 リリースに関する情報をお伝えします。

Android 11 Beta 3 の概要

Android 11 Beta 3 のアップデートには、Pixel 端末と Android Emulator 向けの Android 11 のリリース候補ビルドが含まれています。Beta 2 で Platform Stability に到達しているので、SDK や NDK API、アプリに面するシステムの動作、非 SDK インターフェースの制限など、アプリに面する部分や動作はすべて確定しています。Beta 3 には、これらの機能と最新の修正および最適化が含まれており、テストを終えるために必要なものがすべてそろっています。

Android 11 の公式リリースる作業の中で、この機会を活用して Exposure Notifications System（濃厚接触通知システム）を考慮した Android のアップデートも行っています。Beta 3 以降で、ユーザーは Android 11 で端末の位置情報設定をオンにせずに Exposure Notification アプリを実行できるようになります。これは Exposure Notification System のみで実現できる例外です。これが可能なのは、アプリが Bluetooth スキャンを行っても、端末の位置情報が推定できないように設計されているからです。ユーザーのプライバシー保護のため、他のすべてのアプリでは、端末の位置情報設定がオンになっていてユーザーが位置情報へのアクセスを許可していない限り、Bluetooth スキャンを行うことはできません。この点は以前と変わりません。詳細については、 An update on Exposure Notifications のブログ投稿投稿をお読みください。

公式 Android 11 リリースに向けたアプリの準備

公式 Android 11 リリースに向かう今、Android のアプリやゲームのすべてのデベロッパーの皆さんに、早めに互換性テストを終えてアップデートを公開するようにお願いしています。SDK、ライブラリ、ツール、ゲームエンジンのデベロッパーの皆さんは、互換性のあるバージョンをすぐにリリースすることが一層重要です。皆さんのライブラリなどを利用しているデベロッパーの方は、皆さんからのアップデートを受け取るまで作業できないかもしれません。互換性アップデートを公開したら、関係するデベロッパーに向けてアナウンスをお願いします。



Android 11 Beta 2 リリースの際に詳しく説明しましたが、Android 11 で互換性テストを行う方法は以下のとおりです。


現在のアプリをテストするには、すべてのアプリの動作の変更点についてのドキュメントを確認し、プラットフォームの変更によってアプリが影響を受ける可能性がある部分を特定します。注意すべき大きな変更点のいくつかを紹介します（これらは、アプリの targetSdkVersion によらず適用されます）。





アプリのライブラリや SDK の互換性テストも忘れずに行ってください。問題を見つけた場合は、最新バージョンの SDK にアップデートするか、デベロッパーに連絡してサポートを受けるようお願いします。


互換性テストやツールの詳細については、Android 11 の互換性のブログ記事でお知らせした関連情報をご覧ください。詳しい技術解説は Android 11 デベロッパー サイトをご覧ください。


新しい機能と API を試してみる



人、管理、安全性に関する新たな体験を構築できるように、Android 11 にはたくさんの新機能が搭載されています。ぜひ、デベロッパー機能についてまとめた #Android11 ベータ版に関する投稿をご覧ください。また、Android 11 Beta のウェブページでは、Android チームが新機能についてご説明している動画をご覧いただけます。Android 11 向けの機能や API の詳細についても、Android 11 Beta のウェブページをご覧ください。

また、Android Studio の Android 11 機能もお試しください。大きな APK のインストールを高速化する ADB Incremental、プラットフォーム API への Null 可能性アノテーションの追加などにより、生産性やワークフローを改善できます。最新の Android Studio ベータ版または Canary 版をダウンロードすると、これらの機能を試してみることができます。Android Studio を Android 11 用に設定する手順はこちらです。

Android 11 Beta 3 の入手方法

Android 11 Beta 3 は、Pixel 2、3、3a、4 の各端末で 8 月 7 日より利用が可能になっています。また、近日中に Pixel 4a でも利用できます。また、こちらから登録をすると、OTA（無線）アップデートも行えます。既に登録済みの方は、まもなく自動的にアップデートが行われます。オンデマンドでアップデートしたい方は、Android Flash Tool をお試しください。手動で書き込みたい方のために、ダウンロード可能なシステム イメージも公開されています。

Pixel 端末をお持ちでない方は、Android Studio で Android Emulator を使うか、サポートされている Treble 対応端末で GSI イメージを使うと、Android 11 を実行できます。

公式 Android 11 リリースに向けて

数週間後に予定されている公式 Android 11 リリースにご期待ください！それまでにテストを終え、できる限り早く互換性アップデートを公開することをお勧めします。ぜひ遠慮なくフィードバックをお寄せください。プラットフォームの問題（プライバシーや動作の変更点も含む）、アプリの互換性の問題、サードパーティ SDK の問題の送信には、ホットリストを使うことができます。


先日、Android 11 AMA と Android Studio AMA が Reddit の r/anddroiddev で開催されました。参加してくださったデベロッパー コミュニティの皆さん、本当にありがとうございました！お役に立てたことがありましたら幸いです。




Reviewed by Yuichi Araki - Developer Relations Team


Share on Twitter Share on Facebook

モバイル セキュリティのイラスト


プライバシーとセキュリティは Android の設計の中核であり、リリースを重ねる度にこの分野に注力してきました。Android 11 でも、重要な取り組みを進めています。 今回は、Android のプライバシーとセキュリティに関するさまざまなアップデートやリソースについて解説します。Android 11 では、ユーザーのプライバシーを守り、プラットフォームの安全性を高めるために、いくつかの重要な変更を行いました。まずはその内容を簡単に紹介します。

All things privacy in Android 11 の動画でもお話しているように、ユーザーが機密性の高いアクセス許可を制御できる範囲を増やしています。今回のリリースの開発期間を通して、デベロッパー コミュニティと何度も深い議論を行いました。それぞれの機能は、ユーザーのプライバシーを強化しつつデベロッパーへの影響を最小限に抑えられるように、バランスを考慮して設計しています。では、いくつかの機能を見ていきましょう。

  • 1 回だけのアクセス許可: Android 10 で、細かい位置情報のアクセス許可を導入しました。これにより、ユーザーはアプリが使用中（フォアグラウンド）の場合にのみ、位置情報への限定的なアクセスを許可できます。

    新しいランタイム アクセス許可オプションを提示されたとき、ユーザーの 50% 以上がフォアグラウンドのみの位置情報を選択しました。この結果から、ユーザーはアクセス許可の細かい制御を望んでいたことがわかりました。そこで Android 11 に1 回だけのアクセス許可を導入しました。これにより、アプリが端末のマイクやカメラ、位置情報に 1 回だけアクセスすることを許可できるようになります。

    アプリのデベロッパーは、ワンタイム アクセス許可に対応するために何かを変更する必要はありません。アプリは、次回使われたときに再度アクセス許可をリクエストできます。新しい変更点を組み込み、プライバシーを尊重するアプリを構築する方法については、こちらの動画をご覧ください。
  • バックグラウンド位置情報: Android 10 では、アプリがバックグラウンド位置情報を定期的に利用している場合、ユーザーがこの機密データの利用方法を把握できるように、リマインダーを追加しました。このリマインダーが表示されたユーザーの 75% 以上は、位置情報のアクセス許可をダウングレードまたは拒否しました。さらに、広範なリサーチの結果、バックグラウンドで位置情報へのアクセスを要求するアプリには、正当なユースケースはとても少ないことがわかりました。

    Android 11 のバックグラウンド位置情報は、ユーザーが実行時に手っ取り早く付与できるアクセス許可ではなくなり、さらに慎重なアクションを要するものとなっています。バックグラウンド位置情報を必要とするアプリでは、システムはまずアプリがフォアグラウンド位置情報を要求することを確認します。その後、アプリは個別のアクセス許可リクエストによってアクセス範囲を広げることで、バックグラウンド位置情報を利用できるようにします。この操作では、アクセス許可を付与するために [Settings] が開きます。

    不正利用を防ぐため、アプリがバックグラウンドで位置情報にアクセスする場合は承認を得なければならなくなるようポリシーの変更を行うと、2 月にお知らせしました。しかし、ポリシーを遵守するために相当な作業が必要になるデベロッパーの方がいらっしゃることをふまえ、2021 年まで既存アプリへのポリシーの強制を行わないこととしました。コードでバックグラウンド位置情報を利用できるケースについては、こちらの動画をご覧ください。
  • アクセス許可の自動リセット: ほとんどのユーザーは、端末に 60 以上のアプリをダウンロードしてインストールしていますが、定期的に使うのはそのうちわずか 3 分の 1 程度です。Android 11 をターゲットにしたアプリでは、ユーザーが長期間アプリを使わなかった場合、システムがユーザーがアプリに付与した機密情報に関わる権限を自動的にリセットし、ユーザーに通知します。アプリは、次に使われたときに再度アクセス許可をリクエストできます。アクセス許可を維持する正当なニーズがあるアプリでは、[Settings] からこの機能を OFF にするようにユーザーに案内することができます。
  • データアクセス監査 API: Android では、機密データへのアクセスを制限することをデベロッパーに推奨しています。この点は、アクセス許可が与えられていたとしても変わりません。Android 11 のデベロッパーは、保護された個人データをアプリがどのように利用しているかを透過的に把握できる新しい API にアクセスできます。この API を使うと、アプリによるプライベートなユーザーデータへのアクセス記録をアプリからトラッキングできます。
  • 対象範囲別ストレージ: Android 10 で対象範囲別ストレージを導入し、外部ストレージをフィルタしたビューを提供できるようにしました。アプリは、これを通してアプリ固有のファイルやメディア コレクションにアクセスできます。この変更により、さまざまな方法で共有ストレージへの幅広いアクセスを制限し、ユーザーのプライバシーを保護できるようになりました。たとえば、ストレージのアクセス許可を変更して写真や動画、音楽への読み込みアクセスのみを許可する、アプリのストレージ属性を改善する、などが想定されます。

    Android 10 以降も、デベロッパーの皆さんに対象範囲別ストレージを採用していただけるよう、フィードバックや多くの改善を取り入れてきました。たとえば、アクセス許可 UI のアップデートによるユーザー エクスペリエンスの改善、既存ライブラリとの互換性を向上させるためのファイルパスによる直接メディア アクセス、メディアの変更を可能にする API のアップデート、ファイルに幅広くアクセスする必要があるユースケースでの Manage External Storage アクセス許可、外部アプリ ディレクトリの保護などです。Android 11 では、API レベル 30 をターゲットとするすべてのアプリで、対象範囲別ストレージが必須となります。詳細については、こちらの動画またはデベロッパー ドキュメントをご覧ください。
  • Google Play システム アップデート: Google Play システム アップデートは、Project Mainline の一環として Android 10 で導入されました。主なメリットとして、Android 内のプラットフォーム サブシステムのモジュール性と粒度の向上があげられます。そのため、スマートフォン メーカーの完全な OTA アップデートを行わなくても、コア OS コンポーネントをアップデートできます。

    今年は Project Mainline のおかげで、メディア デコード サブシステムの重大な脆弱性をすばやく修正することができました。Android 11 には新しいモジュールを追加して、既存モジュールのセキュリティ特性も維持しています。たとえば、暗号プリミティブを提供する Conscrypt は、Android 11 の FIPS 検証も維持しています。
  • BiometricPrompt API: BiometricPrompt API を使うと、アプリがロック解除や機密部分へのアクセスを行う際に必要とするバイオメトリック認証強度を指定できます。下位互換性を持たせるために、これを Jetpack Biometric ライブラリに追加する予定です。この件については、作業の進捗に応じて最新情報をお知らせします。
  • Identity Credential API: この API によって、モバイル運転免許証、国民識別番号、デジタル ID などの新しいユースケースが実現できます。この機能は Google のセキュリティ チームが開発しており、セキュリティ ハードウェアを使ってデータへのアクセスを保護および制御し、情報を安全に格納します。この方法では、従来の物理的な文書よりもユーザーのプライバシーが強化されます。Android 11 でデジタルファーストな身分証明を提供できるように、さまざまな政府機関や業界パートナーと連携して作業を進めています。

プライバシーを重視した安全なプラットフォームを構築するにあたり、皆さんの柔軟な対応とフィードバックに感謝いたします。その他の機能は、Android 11 Beta デベロッパー サイトで確認できます。プライバシーやセキュリティに関する一般的なベスト プラクティスについても学ぶことができます。

Twitter や Youtube で Android Developers をフォローし、この分野に役立つコンテンツや資料を見逃さないようにしましょう。

関連情報


#11WeeksOfAndroid 動画コンテンツの全プレイリストはこちらから、それぞれの週の詳しい内容はこちらからご覧いただけます。毎週新しい分野を取り上げますのでご期待ください。Twitter や YouTube のフォローもお願いします。ご覧いただき、ありがとうございました！


Reviewed by Yuichi Araki - Developer Relations Team and Nori Fujii - Google Play Developer Marketing APAC
Share on Twitter Share on Facebook



数週間前、人、管理、安全性にフォーカスした Android 11 Beta 1 をリリースしました。#Android11Beta Launch でも取り上げましたが、この OS の開発では、スマートフォンで会話する方法を新たな発想で見直し、皆さんの生活に最も重要な「人」を優先しています。Beta 1 ではより人間中心になり、表現力が豊かになりました。スマート端末は操作しやすくなり、機密性の高いアクセス許可も細かく制御できるようになりました。また、会話通知、バブル、クイック アクセス デバイス コントロール、メディア コントロールなどの API を使用して、「人」を優先したエクスペリエンスをアプリに組み込むことができるようになりました。

そして 2020 年 7 月 8 日（日本時間 7 月 9 日）、Android 11 Beta 2 をリリースしました。今回のリリースで Platform Stability に到達し、Android 11 の API と動作がこれで確定しました。デベロッパーの皆さんは早急にご自分のアプリの互換性アップデートに着手し、2020 年第 3 四半期に予定している Android 11 公式リリースまでに完了、公開していただけるようお願いします。

#11 Weeks of Android の第 4 週目のテーマは、Android 11 の互換性です。この週を通して、役立つコンテンツや資料を公開します。#11 Weeks of Android のページにアクセスするか、Twitter や Youtube で Android Developers をフォローしてください。

Pixel 2、3、3a、4 の各端末は、こちらから登録してすぐに無線（OTA）アップデートで Beta 2 を入手でき、ダウンロードも可能です。既に Beta 1 をインストールしている端末は、自動的に無線アップデートが行われます。ぜひ感想をお聞かせください。これまでにフィードバックをお寄せくださった皆様、ありがとうございました！

Platform Stability


今回公開した Beta 2 で、Android 11 は Platform Stability となりました。このマイルストーンは、フィードバックに基づいて、デベロッパーの皆さんのために今年新たに追加されました。

Platform Stability は、Android 11 のアプリに関わる部分とその動作がすべて確定版になったことを意味します。SDK と NDK API が確定するだけでなく、アプリに影響する可能性がある非 SDK インターフェースについてのシステム動作や制限も確定します。Beta 2 以降はプラットフォームが変わることはないので、安心して互換性アップデートを公開できます。スケジュールの詳細はこちらをご覧ください。




プラットフォームが安定版になったのですべてのアプリやゲームのデベロッパーの皆さんは、最終の互換性テストを開始し、最終リリース前にアップデート版のアプリを公開することをおすすめします。

すべての SDK、ライブラリ、ツール、ゲームエンジン デベロッパーの皆さんは、今すぐテストを開始し、できる限り早く互換性アップデートを公開することが非常に重要です。皆さんのライブラリなどを利用しているデベロッパーの方は、皆さんからのアップデートを受け取るまで作業できないかもしれません。互換性アップデートを公開したら、関係するデベロッパーに向けてアナウンスをお願いします。




アプリの互換性が重要である理由


Android におけるアプリの互換性 とは、特定のバージョンのプラットフォーム（通常は最新版）でアプリが問題なく動作することを意味します。互換性は、Android 11 を実行している端末またはエミュレータに本番向けのアプリをインストールすれば、すぐにチェックできます。すべてのユーザーフローや機能をテストして、アプリの見栄えと動作が問題ないことを確認できれば、互換性を確保できたことになります。

こう聞くと簡単そうですが、それだけでは不十分かもしれません。リリースのたびにプライバシーとセキュリティの改善に必要な変更が行われ、OS 全体のユーザー エクスペリエンスを進化させる変更も実装されています。場合によっては、アプリに影響が生じる可能性もあります。そのため、動作の変更点を確認してテストし、ユーザーに互換性アップデートを公開することが必要です。これは基本的なことですが、品質基準としてなくてはならない工程です。

アプリの互換性は、ユーザーが最新バージョンの Android にアップデートする際に重要になります。この点は、新しい端末を購入した場合でも現在の端末にアップデートをインストールした場合でも変わりません。ユーザーは最新バージョンの Android OS を使うことを楽しみにしており、そこでお気に入りのアプリを使いたいと考えています。アプリがきちんと動作しなければ、ユーザーにとっても、私たち全員にとっても大問題になります。

Android 11 Beta 2 で利用できる新しい API や機能はたくさんあり、アプリのターゲットを変更する際に考慮すべき変更点も多くありますが、まずは現在のアプリをテストし、互換性アップデートをリリースするところから始めましょう。

Pixel などの端末では、Android 11 が Android オープンソース プロジェクト（AOSP）に最終リリースされ次第、アップデートが始まります。このタイミングは、2020年第 3 四半期を予定しています。複数のパートナーの端末でも、互換性テストをサポートするために積極的なパブリック プレビューを実施中です。


アプリの互換性を確保しやすくなった Android 11


私たちはリリースのたびに、アプリの準備に必要な作業を減らすよう努めています。Android 11 では、プラットフォームのアップデートによる影響を最低限にとどめ、簡単にアプリの互換性を維持できるようにするため、新しいプロセスやデベロッパー ツール、リリース マイルストーンを追加しました。






Android 11 リリースに向けたアプリの準備



Android 11 が安定版になったので、できるだけ早くアプリの互換性を確保してください。そのための方法を以下に示します。






現在のアプリのテストは、すべてのアプリが対象となる動作の変更点から始めましょう。ここから、影響がありそうな変更点を確認できます。次に示すのは、特に重要な変更点です（これらはアプリの targetSdkVersion に関係なく適用されます）。





アプリのライブラリや SDK の互換性テストも忘れずに行ってください。問題を見つけた場合は、最新バージョンの SDK にアップデートするか、デベロッパーに連絡してサポートを求めます。


互換性を確認したアプリを公開した後は、アプリの targetSdkVersion をアップデートする作業に着手します。Android 11 アプリに関する動作の変更点を確認し、互換性フレームワークを試して影響を確認します。次に示すのは、テストする際に特に重要な変更点です（targetSdkVersion 30 以上にのみ適用されます）。






テストでは、制限されている非 SDK インターフェースが使用されていないかを確認し、存在する場合は同等のパブリック SDK に移行します。制限されている API については、こちらをご覧ください。


新しい機能と API を試してみる



準備ができたら、早速 Android 11 を試して、構築できる新しいエクスペリエンスについて学びましょう。#Android11 ベータ版についてのブログ記事に、デベロッパー向けの新機能がまとめられています。また、Beta Launch ページにアクセスして、Android チームのトークや各分野の新機能を確認することもできます。


Android Studio にも Android 11 向けに、大きな APK のインストールを高速化する ADB Incremental（adb 増分 APK インストール）、プラットフォーム API への追加の NULL 可能性アノテーションなど、生産性やワークフローを改善するための新機能が搭載されました。最新の Android Studio ベータ版または Canary 版をダウンロードすると、これらの機能を試してみることができます。Android Studio を Android 11 用に設定する手順はこちらです。

Android 11 向けの機能や API の詳細については、Android 11 デベロッパー サイトをご覧ください。


Android 11 Beta 2 の入手方法



簡単です！こちらから登録すると、Pixel 2、3、3a、4 の各端末で Android 11 ベータ版の無線アップデートを受け取ることができます。または、簡単にオンデマンドでアップデートしたい方は、Android Flash Tool をお試しください。ダウンロード可能なシステム イメージも公開されています。Pixel 端末をお持ちでない方は、Android Studio で Android Emulator を使うか、サポートされている Treble 対応端末で GSI イメージを使うと、Android 11 を実行できます。

皆さんからのフィードバックを活用して、さらに改善を続けていきます。ぜひお気づきの点はぜひこちらからフィードバックをお寄せください。プラットフォームの問題（プライバシーや動作の変更点も含む）、アプリの互換性の問題、サードパーティ SDK の問題の送信には、ホットリストを使うことができます。これまですばらしいフィードバックを共有してくださった皆さん、どうもありがとうございました。


Android 11 互換性の関連情報



#11 Weeks of Android の第 4 週のテーマは、Android 11 の互換性です。プラットフォームが安定版になった今、すべてのデベロッパーにとって重要な内容が含まれています。

互換性テストに便利な情報をこちらで共有しています。また、Twitter や Youtube で Android Developers をフォローすると、この 1 週間を通してこの分野に役立つコンテンツや資料を入手できます。

太平洋夏時間の 7 月 9 日午後 12 時（日本時間 7 月 10 日午前 4 時）に、Android エンジニアチームが r/androiddev で Reddit AMA を開催し、Android 11 についての技術的な質問にお答えしました。詳細は Reddit のスレッドをご覧ください。


Reviewed by Yuichi Araki - Developer Relations Team and Nori Fujii - Google Play Developer Marketing APAC
Share on Twitter Share on Facebook


 4 月に SameSite Cookie のラベル付け強制を一時的にロールバックしました。これは、COVID-19 対応の重要な初期ステージにおいて、生活に必要なサービスを提供しているウェブサイトの安定性を確保するためでした。このロールアウトは、夏の間に再開させる計画です。

4 月以降、私たちはエコシステム全体の準備状況の監視を続けるとともに、SameSite ラベル付けポリシーの準備が確実に整うように、ウェブサイトやサービスに働きかけてきました。SameSite Cookie の強制は 7 月 14 日の Chrome 84 安定版リリースに合わせて再開される予定です。強制は Chrome 80 以降で有効になります。

以前のロールアウトと同じように、強制は徐々に適用されます。スケジュールや変更される可能性がある点は、Chromium.org の SameSite アップデート ページでお知らせを続けます。デベロッパー向けの全般的なガイドは変更されていません。詳しい情報や、フィードバックを提供するためのリソースやチャンネルは、以前の Chromium の投稿や web.dev をご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

ウェブページの外部リソースがサイトのドメインに一致しない Cookie にアクセスする場合、クロスサイトすなわち「サードパーティ」コンテキストとなる。

一方、Cookie のドメインがユーザーのアドレスバーに表示されているウェブサイトのドメインと一致する場合は、同一サイト（すなわち「ファースト パーティ」）コンテキストによる Cookie アクセスとなります。同一サイトの Cookie は、個々のウェブサイトでログイン状態を維持する、ユーザー設定を保存する、サイトのアナリティクスを行う、といった目的でよく使用されています。

 
ウェブページ上のリソースがアクセスする Cookie が、ユーザーの訪問先サイトと一致する場合、同一サイトすなわち「ファースト パーティ」コンテキストとなる

Cookie のセキュリティと透過性を実現するための新しいモデル

現在のところ、Cookie がファースト パーティ コンテキストからのみアクセスできるようにする場合、デベロッパーは 2 つの設定（SameSite=Lax または SameSite=Strict）のいずれかを選んで外部アクセスを防ぐことができます。しかし、この推奨手法に従っているデベロッパーはほとんどおらず、大多数の同一サイト Cookie はクロスサイト リクエスト フォージェリ攻撃などの脅威に不要にさらされています。

そこで、ウェブサイトとユーザーを保護するため、デフォルトで安全な状態にする新しいモデルでは、明示的な指定がない限り、すべての Cookie を外部アクセスからの保護対象と見なします。デベロッパーは新しい Cookie 設定 SameSite=None を使い、Cookie をクロスサイト アクセスの対象として指定する必要があります。SameSite=None 属性が存在する場合は、クロスサイト Cookie に HTTPS 接続のみでアクセスできるように、Secure 属性も追加する必要があります。これでクロスサイト アクセスに関連するすべてのリスクが緩和されるわけではありませんが、ネットワーク攻撃に対する保護は実現できます。

このようにクロスサイト Cookie を明示的に宣言すると、すぐにセキュリティを向上できるだけでなく、透過性が高まり、ユーザーの選択肢も増えます。たとえば、1 つのサイトからアクセスされる Cookie と複数のサイトからアクセスされる Cookie を分けて管理するなど、ブラウザで Cookie の細やかな制御を行えるようになります。

Chrome は 2020 年 2 月より新しいモデルを適用

2 月の Chrome 80 以降、SameSite 値が宣言されていない Cookie は SameSite=Lax として扱われます。外部アクセスは、SameSite=None; Secure 設定のある Cookie のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。Chrome プラットフォームの SameSite=None と Secure の Status Tracker は、最新のリリース情報に基づいて今後もアップデートが継続されます。

Mozilla は、Firefox でクロスサイト Cookie の SameSite=None; Secure 要件を実装する予定で、新しい Cookie 分類モデルのサポートを確約しています。Microsoft は先日、Microsoft Edge 80 より試験運用版としてこのモデルの実装を開始する計画を発表しました。

準備方法と既知の複雑なケース

クロスサイト Cookie を管理している方は、Cookie に SameSite=None; Secure 設定を適用する必要があります。ほとんどのデベロッパーは簡単な実装で済むはずです。しかし、以下のような複雑なケースや特殊なケースを判別するため、すぐにテストを開始することを強くお勧めします。
SameSite Cookie の説明には、前述の状況についての具体的なガイダンスや、問題や質問を送信できるチャンネルが記載されています。

管理しているサイトや Cookie に対する Chrome の新しい動作の影響をテストしたい場合は、Chrome 76 以降で chrome://flags を開き、試験運用版機能である [SameSite by default cookies] と [Cookies without SameSite must be secure] を有効にします。また、一部の Chrome 79 ベータ版ユーザーは、これらの試験運用版機能が自動的に有効になります。試験運用版機能を有効にしたベータ版ユーザーによっては、新しいモデルをまだサポートしていないサービスによって互換性に関する問題が起きることがあります。ユーザーは、chrome://flags に移動してベータ版の試験運用を無効にすることで、対象の機能をオプトアウトできます。

同一サイト コンテキストのみでアクセスされる Cookie（同一サイト Cookie）を管理している場合、何もする必要はありません。SameSite 属性がない、または値が設定されていない場合でも、Chrome は外部エンティティからこれらの Cookie へのアクセスを自動的にブロックします。ただし、すべてのブラウザがデフォルトで同一サイト Cookie を保護するとは限らないため、適切な SameSite 値（Lax または Strict）を設定し、デフォルトのブラウザの動作に依存しないことを強くお勧めします。

最後に、皆さんのウェブサイトにサービスを提供しているベンダーなどの対応を懸念している方へお伝えします。必要な設定が行われていないクロスサイト Cookie がページに含まれる場合、Chrome 77 以降のデベロッパー ツールのコンソールに次の警告が表示されます。この警告を確認してください。



 2 月の Chrome 80 のリリースまでの数か月間で必要な変更を実装するプロバイダ（一部の Google 製サービスを含む）もあります。対応状況を確認するために、パートナーに連絡してみるのもよいでしょう。


Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook


不正の防止

現在、ほとんどのサイト運営者には、不正行為を検知して防止したいというニーズがあります。不正行為の例として、不正取引や、広告主やサイト運営者から金銭をだまし取ろうとする嘘の広告活動があげられます。Google を含む多くの企業は、不正の検知と防止に取り組んでいます。広告会社や広告詐欺については、特にそれが言えます。

現在、合法的に詐欺と戦っているツールの中には、プライバシー セーフな仕組みの恩恵を受けた技術を活用したものがあります。その一例が CloudFlare が Tor ユーザーのために導入した PrivacyPass トークンです。現在、この技術は標準化の過程にあります。

サンドボックスの境界を保護

ウェブからある機能を削除すれば、デベロッパーは正規の道を選ぶのではなく、現在のシステムを動作させ続けるために回避策を見つけようとします。このことは、既に経験から明らかになっており、最近でも、他のブラウザが Cookie をブロックするために行った措置に対してこのような反応が見られました。そのようにして登場したのが、フィンガープリントのように、ユーザーにとって透過的でない新しい技術です。

フィンガープリントを使うと、ユーザーごとに異なるごくわずかな情報を知ることができます。たとえば、ユーザーがどんな端末をもっているか、どんなフォントをインストールしているかなどです。こういった小さなデータを組み合わせることで一意な識別子を生成でき、それを使えばウェブサイト間でユーザーを照合することも可能です。Cookie と違い、フィンガープリントはユーザーがクリアすることはできません。つまり、特定されることを嫌うユーザーでも、デベロッパーによるユーザーの特定を避けることはできません。私たちは、このような形でユーザーから選択肢を奪うのは間違いだと考えています。

5 月の I/O でも触れましたが、私たちはフィンガープリントを防止する対策を積極的に行っており、プライバシー予算と呼ぶものを実現することを提案しています。プライバシー予算の考え方によると、ウェブサイトはユーザー情報を得る API を呼び出すことができますが、ユーザーが匿名を維持できる十分な大きさのグループに絞り込まれた情報までに限られます。その後、さらに詳しい情報を得ようとして API を呼び出そうとすると、ブラウザが介入して呼び出しをブロックします。

プライバシー サンドボックス構築のための初期提案にも目を通していただけるとありがたく思います。これは壮大な計画であることは承知しています。他のブラウザやサイト運営者を含め、業界全体で連携した結果として改良、改善していくことが重要です。この点は、どんなに誇張しても誇張しすぎるということはありません。ぜひ皆さんの意見もお聞かせください。

Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

Share on Twitter Share on Facebook