アプリでアクション ボタンが提供されていない場合、URL を共有するデフォルトのアクション ボタンがトップバーに追加される
CustomTabsIntent.Builder
setShareState()
val customTabsIntent = CustomTabsIntent.Builder()
.setShareState(CustomTabsIntent.SHARE_STATE_OFF)
.build();
addDefaultShareMenuItem()
setDefaultShareMenuItemEnabled()
プライバシー サンドボックスの取り組みは、一連のプライバシー保護 API を提案することで、サードパーティ Cookie などのトラッキング メカニズムのないオープンウェブに貢献するビジネスモデルをサポートします。この取り組みは 2019 年に始まり、Chrome では昨年の 1 月と 10 月に最新の進捗状況を共有しました。
1 年間のインキュベーション期間を経た 2021 年はテストの 1 年間となり、ウェブのエコシステムが関与する機会が継続的に発生するでしょう。この投稿では、Privacy Sandbox API とその提案の状況について、最新情報をお届けします。
サイト運営者や広告主は、広告を含め、関連性が高くユーザーが興味を持つコンテンツを提供したいと考えています。現在のウェブでは、どのようなサイトやページにアクセスしたかを観察することでユーザーの興味を測ることが多く、これにはサードパーティ Cookie やデバイスのフィンガープリンティングなど、透過性が低く好ましくない仕組みが使われます。
3 月の Chrome リリース 89 で、Federated Learning of Cohorts API（FLoC）のオリジン トライアルを開始する予定です。FLoC は、同じような閲覧パターンを持つ人々を大きな集団に分類し、「大勢」の中の個人やブラウザの閲覧履歴を隠すことで、関連性の高いコンテンツや広告をユーザーに届ける新しい仕組みを提案します。現在 Google 広告は、FLoC アルゴリズムのテストから得た最新情報を共有しています。このテストによって、関連性の高い興味ベースの広告を提供するという点で、提案された API がサードパーティ Cookie と同様の効果を持つ可能性があることが示されました。
標準化コミュニティで盛んな議論を呼んだユースケースの 1 つが、どうすれば企業はオーディエンスを形成できるか、そしてどうすれば再マーケティングによって以前のユーザーをウェブサイトに呼び戻せるか、ということでした。昨年には、このユースケースに対応しつつ、他の提案と同じプライバシー保護を提供できる TURTLEDOVE が Chrome に導入されました。ウェブサイトは、入札や広告表示に関する情報を含む Interest Group を保存するようブラウザに依頼します。そして、この Interest Group に基づいて広告購入候補者によるオンデバイス入札が行われることになります。
Chrome の新しい FLEDGE（First "Locally-Executed Decision over Groups" Experiment）提案は、寄せられた多くの提案に含まれる新しいコンセプトを組み込んで TURTLEDOVE を拡張したものです。FLEDGE には、オンデバイス入札アルゴリズムで追加情報を利用する仕組みが含まれています。この追加情報は、この目的に限定して設計された、新しい信頼できるサーバーから提供されます。新しい信頼できるサーバーが利用できるようになる前に初期段階の実験をサポートするため、私たちは "Bring Your Own Server" モデルを提案しています。また、この最初の実験は、2021 年中に行いたいと考えています。
マーケティング担当者が広告キャンペーンを行う場合、各広告を見たユーザー数と、それによって購入や登録などの行動に結びついたのかを理解することが重要です。
2020 年 9 月に、パブリック Chrome オリジン トライアルでテストを行うために、Event Conversion Measurement API を公開しました。これを使うと、マーケティング担当者はサードパーティ Cookie を使わずにコンバージョンを測定できます。ブラウザは、クリックとコンバージョンを記録し、匿名レポートを共有します。このテクノロジーは、将来的に「ビュースルー コンバージョン」（ユーザーが広告を見た後、時間をおいて行動する場合）もサポートする予定です。
マーケティング担当者が特定の広告キャンペーンの対象範囲を理解できるように、2020 年 4 月に Aggregate Measurement API を公開しました。この API は、複数のサイトにわたってユニーク ユーザーが広告を見た回数を測定する場合に役立ちます。ここでも、個人の特定に利用される可能性があるデータが公開されることはありません。この仕組みは、ある集計しきい値を超えた場合に一度だけデータを報告することで実現します。Aggregate Measurement API は、今年の前半に公開してパブリック オリジン トライアルとしてテストすることを計画しています。
サイトやサイト運営者は、実際のユーザーと、スパム作成者や詐欺師、ボットを確実に見分けられなければなりません。昨年 7 月には、Trust Tokens API をテスト用に公開しました。この機能は、詐欺に対抗するため、ユーザーの身元を特定することなくユーザーの正当性を評価します。Chrome 89 では、新しいタイプの Trust Token 発行者をサポートするために、オリジン トライアルを導入します。これにより、ユーザーのプライバシーを守りつつ、モバイル デバイスによる詐欺の検出機能を向上させることができます。
2020 年には、現在のウェブ テクノロジーの安全性も向上しました。Chrome と Edge が SameSite Cookie ポリシーを採用し、近日中に Firefox も採用する予定です。このポリシーにより、デベロッパーがサイト間アクセスを必要とすることを明示しない限り、Cookie はファーストパーティとして扱われます。これは Android の Webview にも導入されており、Android S 以降をターゲットとしたアプリでは、"SameSite=Lax" がデフォルトの扱いとなる予定です。
今月の Chrome 88 リリースの新機能として、このポリシーを強化します。具体的には、接続の安全性のダウングレードを含むいくつかの形態のクロスサイト攻撃を防ぐため、SameSite の定義を変更します。これにより、同じホストのドメインの安全なバージョンと安全でないバージョン（https://site.example と http://site.example など）は、お互いにサードパーティと見なされるようになります。
実際のウェブサイトが複数のドメインや国コードドメイン（.com、co.uk、.de など）にまたがる場合があることは認識しています。Chrome 89 では、オリジン トライアルとして First Party Sets を導入する予定です。これにより、ドメイン所有者は関連するウェブドメインのグループが同じ組織に所属するものであることを明示的に宣言できるようになります。この宣言を行うと、対象のドメインはお互いに「同じパーティ」として扱われます。そのため、たとえばショッピング サイトが複数のドメインをまたぐ場合でも、ユーザーはログイン状態を維持できるようになります。トライアルへの登録はこちらから行ってください。
さらに、既存の迷惑なトラッキング技術を防ぎ、問題にならない回避策を提供するため、Chrome の変更も進めています。
今後数週間のうちに、新しい User-Agent Client Hints（UA-CH）API の Chrome 安定版ロールアウトを終える予定です。これは、デフォルトでユーザーのブラウザに関する情報をすべて取得するのではなく、デベロッパーが特定の情報をリクエストできるようにするものです。将来的に Chrome は従来の User-Agent 文字列で提供する情報を制限する予定なので、デベロッパーには UA-CH API への移行を始めることを推奨します。現在の User-Agent 情報は、フィンガープリンティングに使われる可能性があります。
先週、Gnatcatcher を導入しました。これは、ユーザーのグループが同じプライベート化サーバーを通してトラフィックを送信できるようにする提案で、サイトのホストから IP アドレスを効果的に隠蔽します。また、Gnatcatcher は、不正利用の防止などの正当な目的で IP アドレスへのアクセスが必要なサイトには、認証や監査を行った上で、アクセスを保証します。
昨年 10 月にお知らせしたように、ユーザーがキャッシュの仕組みを使ってアクセスしたサイトを別のサイトから確認できる機能は、近日中にクローズする予定です。これによって元のリクエストを行ったサイトのみがキャッシュされたリソースにアクセスできることが保証され、クロスサイト トラッキングや検索攻撃などのセキュリティ攻撃のリスクを減らすことができます。この変更は、3 月の Chrome 89 からすべての Chrome ユーザーにロールアウトされる予定です。
biddingFunctions
BidRequest
Floc
User
message Floc { // The value of a cohort ID – a string identifier that is common to a large // cohort of users with similar browsing habits. optional string id = 1; // The type of the FLoC. See // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf. enum FlocType { // Default value that should not be used. FLOC_TYPE_UNKNOWN = 0; // FLoC simulated using affinity hierarchical clustering with centroids // and feature extraction based on Topic categories as described in the // whitepaper. SIMULATED_AFFINITY_CLUSTERING_CENTROID_VERTICAL = 2; // FLoC simulated using SortingLSH clustering algorithm and Domain One-hot // encoding feature extraction as described in the whitepaper. SIMULATED_SIMHASH_SORTING_LSH_DOMAIN_ONE_HOT = 3; // FLoC simulated using a k Random Centers locality-sensitive hash // function as described in // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/k-random-centers.md // with Domain TF-IDF feature extraction as described in the whitepaper. KCENTER_DOM_FILTERED_TFDIF = 4; } optional FlocType type = 2; }
google_user_id
hosted_match_data
FlocType
BidResponse
FrequencyCap
Bid
message FrequencyCap { // An ID that can represent a bidder's use-case for frequency capping; for // example, it could represent their campaign, ad, line item, etc. It should // not contain any user-specific information or identifiers. optional string fcap_id = 1; // The time units for which frequency caps can be enforced. enum TimeUnit { UNKNOWN_TIME_UNIT = 0; MINUTE = 1; DAY = 2; WEEK = 3; MONTH = 4; // When INDEFINITE is used, time_range will be ignored. INDEFINITE means // the frequency cap will be applied for a long period of time, (longer // than a month) but not necessarily forever. INDEFINITE = 5; } // The unit of time used to specify the time window for which a frequency // cap applies. optional TimeUnit time_unit = 2; // The length of the time window, in units specified by time_unit, for which // the frequency cap applies. For instance, if time_unit=WEEK and // time_range=3, then capping is applied for a three week period. If the // time_unit=INDEFINITE, this will be ignored. optional int32 time_range = 3 [default = 1]; // The maximum number of impressions allowed to be shown to a user for // the provided frequency_cap_id within the time window described by // time_unit and time_range. optional int32 max_imp = 4; }
WorkManager は、非同期タスクのスケジュールを簡単に設定するための一連の API を提供します。これにより、アプリが閉じられた場合やデバイスが再起動した場合にも実行されることが期待されるタスクを即時実行または遅延実行できます。また、WorkManager は Kotlin ユーザーに最大級のコルーチンのサポートを提供します。この投稿では、WorkManager Codelab の内容に基づいて、WorkManager とコルーチンの基本について説明します。では早速始めましょう。
ユーザーが特定の画面から離れたり、アプリがバックグラウンド状態になったり、デバイスが再起動したりしても実行を続ける必要があるタスクには、WorkManager ライブラリを使うことが推奨されています。一般的には、以下のようなタスクが考えられます。
ユーザーが画面などの特定のスコープを離れたときに即時実行したタスクが終了する可能性がある場合は、直接 Kotlin コルーチンを使うことを推奨します。
WorkManager Codelab では、画像をぼかしてその結果をディスクに保存します。これを実現するために必要なことを確認しましょう。
まず、work-runtime-ktx 依存性を追加しました。
implementation "androidx.work:work-runtime-ktx:$work_version"
そして、独自の Worker クラスを実装します。ここに、バックグラウンドで実行する実際の作業に必要なコードを含めます。Worker クラスを拡張し、doWork() メソッドをオーバーライドします。これは一番重要なクラスなので、のちほど詳しく説明します。最初の実装は次のようになります。
次に、作業のリクエストを作成します。今回の場合は、作業を一度だけ行いたいので、OneTimeWorkRequest.Builder を使います。入力として、ぼかしたい画像の Uri を設定します。
Kotlin のヒント: 入力データを作成するために、workDataOf 関数を使うことができます。この関数は、データビルダーを作成し、キーと値のペアを格納してデータを作成します。
作業のスケジュールを設定して実行するには、WorkManager クラスを使います。その際に、実行するタスクと、タスクへの制約を指定できます。
Worker を使うと、WorkManager は自動的にバックグラウンド スレッドで Worker.doWork() を呼び出します。doWork() から返される Result は、WorkManager サービスに作業が成功したかどうかと、失敗した場合には作業を再試行すべきかどうかを通知します。
Worker.doWork() は同期呼び出しです。バックグラウンドの作業全体をブロックありで実行し、メソッドが終了するときには完了していることになります。doWork() で非同期 API を呼び出して Result を返すと、コールバックが正しく動作しない場合があります。
もう少し複雑な例として、ぼかしをかけたすべてのファイルの Uri をデータベースに保存する場合を考えてみましょう。
これを実現するために、以下を作成しました。
実装はこちらをご覧ください。
Kotlin でデータベースへのデータの保存やネットワーク リクエストなどの非同期作業を行う必要がある場合は、CoroutineWorker の利用を推奨します。
CoroutineWorker を使うと、Kotlin コルーチンを使って非同期作業を行えます。
doWork() メソッドは suspend メソッドです。つまり、中断を伴う dao を簡単に呼び出すことができます。
デフォルトで、doWork() は Dispatchers.Default を使います。この動作は必要な Dispatcher でオーバーライドできます。今回は、既に Room が挿入作業を別の Dispatcher に移動させているので、これを行う必要はありません。詳しくは、Room Kotlin API の投稿をご覧ください。
ぜひ CoroutineWorker を使って、ユーザーがアプリを閉じても完了しなければならない非同期作業を実行してみてください。
WorkManager についてもっと詳しく知りたい方は、今後のシリーズで詳しく解説しますので、ご期待ください。それまでの間は、Codelab やドキュメントをご覧ください。
この記事は Miguel Guevara による Android Developers Blog の記事 "How we’re helping developers with differential privacy" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google は、イノベーションとプライバシーは車の両輪だと考えています。その一環として2021 年 1 月、オンラインのユーザーの安全を確保するための私たちの取り組みについてブログでお知らせしました。その中では、差分プライバシー（ディファレンシャル・プライバシー / differential privacy ）などの先進的なプライバシー技術に言及しておりました。
毎年 1 月 28 日は、データ プライバシーの日です。そこで、それに合わせて、Google のプロダクトに差分プライバシー技術を適用し、この技術を世界のデベロッパーや企業に広めていこうという新しい取り組みをここに詳しく紹介させていただきます。この取り組みにより、個人情報を確実に保護しつつ、データや知見に広くアクセスできるようになります。
差分プライバシーは高度な匿名化技術で、初めて Chrome に導入されたのは 7 年ほど前になります。そして現在では、Google マップや Google アシスタントなどのプロダクトに日々活用されています。昨年、世界が COVID-19 と闘う中、COVID-19 コミュニティ モビリティ レポート（英語）を公開しました。差分プライバシーを使っているこのレポートは、世界の公衆衛生当局、エコノミスト、政策立案者がコミュニティにとって重要な決定をする際に活用していますが、いかなる時点においても、個人を特定できる情報は利用できないことが保証されています。
Google Play Console では、今年中に差分プライバシーの手法を用いたアプリの新たな指標やベンチマークをデベロッパー向けに提供する予定です。この機能がリリースされると、デベロッパーは個人が特定または再特定できないことが保証される方法で、日々のアクティブ ユーザー数、アクティブ ユーザーあたりの収益など、アプリがどのくらいユーザーを惹きつけているかを表す指標に簡単にアクセスできるようになります。
このようなアプリの新たな指標に差分プライバシーを加えることで、デベロッパーに有用な知見を提供し、アプリの改善に役立ててもらうことができます。その一方で、ユーザーのプライバシーやデベロッパーの機密性が損なわれることはありません。今後は、差分プライバシーを使った指標を増やすことを計画しています。
Google のプロダクトにおけるプライバシー保護技術は進化を続けていますが、デベロッパーがこの技術を利用できるようにすることも重要です。そこで、2019 年に差分プライバシー ライブラリをオープンソース化し、世界中のデベロッパーが自由にアクセスして簡単にデプロイして活用できるようになりました。それ以降、たくさんのデベロッパーや研究者、団体が Google の差分プライバシー アルゴリズムを利用して、プライバシーが保護される方法で責任をもってデータを使い、新しい問題の解決に取り組んでいます。そのような企業の 1 つに、フランスの新興医療企業 Arkhn があります。Arkhn は、差分プライバシーによって複数の部門にまたがる病院のデータを安全な方法で収集、照会、分析できるようになり、それを活用して人工知能で医療業界に革命を起こすというミッションを掲げています。
Arkhn のようなデベロッパーのチームに、高度な差分プライバシー ライブラリを広く提供するため、 2021 年 1 月 29 日（現地時間 1 月 28 日）、OpenMined との新たなパートナーシップを結びましたのでお知らせします。
OpenMined は、プライバシー保護技術を研究し、その活用法を世界中に広めることに注力しているオープンソース デベロッパー グループです。Google は、今後 OpenMined と協力し、差分プライバシー ライブラリの Python デベロッパー専用のバージョンを開発する予定です。Python デベロッパーは、Google の差分プライバシー対応インフラストラクチャと同じ仕組みを活用することで、ワールドクラスのプライバシーを備えた他にはない新しい方法でデータを扱うことができます。
昨年と同様、デベロッパーが既存の差分プライバシー ライブラリをさらに簡単に使えるようにする作業も継続します。たとえば今月には、Google で日々何千件ものクエリに利用されている、新しい差分プライバシーに対応した SQL データベース クエリ言語拡張機能をオープンソース化しました。アナリストがこのようなクエリを活用すれば、ビジネスに関する知見を得たりプロダクトのトレンドを確認したりできます。これは、プライバシーが守られたデータ分析を広め、世界中のデータ サイエンティストが個人のプライバシーを保護および尊重しつつ、強力な洞察を得られるようにするための一歩です。
2 年前、TensorFlow Privacy（GitHub）をローンチしました。TensorFlow Privacy はオープンソース ライブラリです。これを使うと、デベロッパーがプライバシーに配慮した機械学習モデルを簡単にトレーニングでき、研究者は TensorFlow Privacy を使ってより安全なプライバシーを保証し、機械学習の水準を高めることができます。
昨年は、このライブラリを拡張して TensorFlow 2 をサポートするとともに、Keras モデル インターフェースと TensorFlow の既製 Estimator の両方をサポートしました。また、ウォータールー大学の研究者と連携してパフォーマンスを向上させています。これにより、新しいリリースでは一般的なワークロードのトレーニングが 4 倍以上高速になりました。
さらに、プライバシーを考慮した機械学習のトレーニングはコストが高くなってしまい、現実的ではない可能性があることがわかっています。そこで、機械学習モデルはどの程度プライベートなのかを理解するための調査を開始し、昨年、それに役立つ仮想攻撃ライブラリをオープンソース化しました。このライブラリを使うと、機械学習モデルの全体的なプライバシーの保護状況を確認できます。
その後は、プリンストン大学やシンガポール国立大学の研究者と連携。ライブラリのスコープを拡張して生成モデルや非ニューラル ネットワーク モデルをテストする新機能を追加しています。
先日、スタンフォード大学医学部の研究者がこの機能をいくつかのモデルで試しました。そのテストから、モデルの中でのプライバシーに関する動作が明らかになりました。その中には、それ以前はできなかったことも含まれています。
また、差分プライバシーと堅牢性のトレードオフに関する新しい研究を発表しました。これは、AI 倫理の中核にあるもう 1 つの特性である、プライバシーと安全性に関わることです。
健全なオープンソース エコシステムを育み、広げていく一方で、Google 製品を使うユーザーをアルゴリズムによって保護するために、Google は高度なプライバシー保護を行う取り組みに投資をしております。私たちは、世界中のあらゆる人がトップレベルなプライバシー保護を享受すべきだと強く確信しています。そのためにさまざまな組織と協力してそのミッションを果たしてまいります。
Google Cloud Japan は 2 月 3 日 （水）、2 月 10 日 （水）、3 月 17 日 （水）の 3 週にわたって Google Cloud App Modernization OnAir を開催いたします。
Google Cloud App Modernization OnAir では、Google Cloud のエンジニアが、モダンなアプリケーション開発で利用可能な Google Cloud のサービスや、コンテナ、Kubernetes を利用した開発手法、マイクロサービス アーキテクチャの採用、CI/CD パイプラインの構築、DevOps の実践方法、SRE の考え方、アプリケーション セキュリティ、デザインパターンなどをご紹介いたします。 既に Google Cloud についてご存知のお客様、これから利用を検討しているお客様、ぜひご視聴ください。
この Google Cloud App Modernization OnAir は、一度ご登録いただくと、3 週間分のセッションを追加登録なしでご視聴いただけます。配信当日はライブでの Q&A も行いますので、ぜひご参加ください。
また、今回 App Modernization OnAir 放送開始キャンペーンを実施しております。
参加ご登録者の中から抽選で 10 名様に Kubernetes パーカーをプレゼントいたします。
（全配信終了後に送付いたします）
事前お申込み受付中：http://goo.gle/devrelblog
名 称 『App Modernization OnAir』
日 程 毎週 水曜日（3 連続開催） 2021 年 2 月 3 日（水）、2 月 10 日 （水）、2 月 17 日 （水）
対 象 開発エンジニア、インフラエンジニア、運用エンジニア
参加費 無料（事前登録制）
登 録 http://goo.gle/devrelblog
