プライバシーの強化で信頼を築く

こんにちは WWDCへようこそ

“より強固なプライバシーで信頼を築く” 私はロヒスです 今日は同僚のブランドンも一緒です 今日はプライバシーを強化しながら ユーザと信頼関係を 構築する方法についてお話します プライバシーに対するAppleの アプローチをお話してから 私たちのエコシステムで プライバシーの原則を適用して ユーザトラッキングを緩和する 方法をお話します

ではプライバシーに対する 私たちのアプローチとは何でしょう

Appleではプライバシーについて ４本の基本的な柱があります 私たちが作る製品や機能の指針となるものです オンデバイス処理― データをサーバーに送信せず ローカルで処理します データ最小化 本当に必要なデータだけを要求して使います セキュリティ保護 プラットフォームで プライバシー保護を実施します 透明性と管理― ユーザがデータを理解し管理できるようにします

この４本柱は機能への 強力なプライバシー保護機能を構築し ユーザとの信頼関係を維持に役立ちます

１つずつお話しましょう それぞれが今年行った変更に どのように影響するかお見せします オンデバイス処理からお話します ではユーザのデバイスからリモートサーバーに データを送信せずに データ操作するメリットとは何でしょうか

リモートサーバーにデータを送信すると サーバーにアクセスできるユーザ その後データを共有するユーザ またデータの使用目的を管理する能力が 失われます 侵害や他の脅威に対して 顧客データの安全を確保するには さらに作業が必要になります しかし機械学習モデルの学習のためデータを 集めなければならない場合があります

そのためCore MLを活用し デバイスでモデルを構築し学習させる方法を さらに作りだしています これはこのモデルをXcodeプロジェクトに ドラッグアンドドロップするほど簡単です データをローカルで保持するとデバイスにある 堅牢なセキュリティ保護が自動的に利用されます

すでに多くの機能で オンデバイス学習を活用しています iOS 13以降 プライベートフェデレーテッド学習 またはPFLを利用して 潜在的に機密性のあるデータで 機械学習モデルを構築しています PFLが機能するにはユーザデータを送信せず 違った形でプライベートモデルの更新を デバイスに送信させます こうしてユーザデータにアクセスすることなく サーバーで集中型モデルを構築できます 昨年このテクノロジーを活用して オプトインするユーザから QuickTypeやSiri音声認識のモデルを改善し 製品を向上させました

今年は新しいプライベートフェデレーテッド 学習ユースケースを導入しています チップで強力な ニューラルエンジンを活用しており ユーザデータをAppleまたはサードパーティに 暴露せずに機械学習モデルを改善できます

アプリケーションで 機械学習を利用する点について詳しくは 以下のトピックをご覧ください

さらに多くの言語について デバイスにローカルで口述しました 電話上で口述すると音声データはまさに デバイス上で処理されます 口述を利用するアプリケーションを作成する場合 オンデバイス口述モデルを使うよう指定し この新テクノロジーを利用してください また今年導入したのはHomeKitという 新しい顔認識機能です カメラとビデオの呼び鈴はPhotosで タグしたユーザに基づき またはHomeアプリケーションで 特定される最近の訪問者から そこにいるユーザについて教えてくれます この機能にオプトインすると ホームハブは オンデバイスインテリジェンスを活用して 通りすがりのユーザを認識します オンデバイス処理は今年導入している 多くの新機能にとって不可欠です デバイスがより強力になり続けている中 オンデバイス処理を使い 今ある機能を検討し直す 新しいチャンスを求めてください これはデバイスから送信するデータを 最小限にすることで ユーザとの信頼関係を構築する優れたツールです ではブランドンに交代して 次のプライバシーの柱である データ最小化についてお話してもらいましょう ありがとうロヒス プライバシーはユーザとの 信頼関係を構築することです これを実現する最適な方法として 作業に必要なデータのみ 使うということがあります

これはアプリケーションが アクセスできるデータと 機能の実現のためにアプリケーションが 使用するデータとの バランスを慎重にとるということです

わずかな個人情報しか活用しない機能のため 多くの情報を共有するようユーザに求めることは その機能を使用する心構えより大きな選択を ユーザに迫ります 信頼関係は時間とともに構築されます ユーザのデータに敬意を表し できる限りアクセス要求を 抑えることから始めるのが 優れた第一歩なのです

実際それは必ずしも 単純でないことは知っています 今年は簡単なユーザ体験を通して アプリケーションがアクセスできる情報量の バランスをとりやすくする 新しいツールをご紹介します 今日はiOS 14で新しい方法でアクセスできる ３種類のデータについてお話しましょう Photos Location Contactsです

単純な写真共有アプリケーションで これらを見ていきましょう 共有した写真を選ぶため Photosにアクセスします Locationで共有相手となる友人を見つけます 手作業で共有する友人を選ぶ場合はContactsです iOS 13でどのように 実装されているか見てみましょう

送信する写真を選ぶにはアプリケーションが 写真ライブラリ全体へ アクセスできる権利を求められます その地域にいる友人を見つけるため 位置情報の許可が求められます あるいは特定の友人に写真を送る場合は 友人全員の連絡先へのアクセスを要求し 共有する友人を選ぶことができるようにします

全体の流れを見るとアクセスが多く ユーザ介入も多数あります 写真の共有には３つのプロンプトに回答して そこですべての写真友人の正確な位置 すべての連絡先への アクセス権を与える必要がありました これはプライバシーの面から好ましくありません ユーザは情報の共有を管理しながら 大量の共有に「はい」と言わないと アプリケーションの中核機能を 使うことはできませんでした

使いやすさの面からも好ましくありません もっと上手くやることができます 今年はあなたのアプリケーションで この体験を向上させてくれる テクノロジーをいくつかご紹介します Photosから始めます iOS 14で写真ライブラリにアクセスできる すべてのアプリケーションについて “Limited Photos Library”を導入しています 写真ライブラリ全体ではなく 選んだ写真に限定してアプリケーションに アクセス権を与えることができます “Select Photos”をタップすると アプリケーションで共有したい写真だけ 選ぶことができます 新しいプロンプトは― iOS 14で写真へのアクセスを要求する すべてのアプリケーションに表示されます 互換性についてはアプリケーションを テストしてください 詳しくは“Limited Photos Library” セッションをご覧ください さらにプロンプトが必要ですが もっと上手くやることができます ほとんどのアプリケーションは わずかな数の写真しか使いません この場合のように友人と共有する写真などです PHPickerはUIImagePickerControllerに代わる 新しいフレームワークで もっぱら写真アクセスのプロンプト表示を 回避する場合に利用できます 検索と複数選択の機能を備え 探している写真を見つけることができ Photos Libraryへのアクセス権は不要です

PHPickerはアプリケーションから 独立したプロセスで実行しますが アプリケーション上で提供されています アプリケーションはPickerに直接アクセスできず Pickerのコンテンツの スクリーンショットを撮ります ユーザが実際に選んだ写真だけ アプリケーションに渡されます

どうしてもすべての写真に アクセスしなければならない場合 バックアップサービスを 提供するなどの場合を除き PHPickerを使ってください PHPickerについて詳しくは “Meet the New Photos Picker”セッションを

では実際それが写真共有アプリケーションで 何を意味するのか見ていきます 共有する写真を選ぶ場合 PHPickerが表示されます ここで目的の写真のみを選びます これはプロンプトを通るより ずっと早いユーザ体験で プライバシー面で はるかに優れた結果をもたらします

次にLocationを見てみます iOS 14で追加している機能では ユーザのおおよその位置を アプリケーションと共有できます

Limited Photos Library同様 これはiOS 14で位置を求める すべてのアプリケーションの 新しいアクセスプロンプトです 丸印をタップすると アプリケーションは おおよその 位置の最新情報のみ受信します

自分の地域の友人を見つける この写真共有アプリケーションのように 現在多くのアプリケーションがおおよその位置に 自然に調和する機能を備えています 位置の認証を求める場合に デフォルトでおおよその位置を要求できます Info.plistで NSLocationDefaultAccuracyReducedキーを 設定して行います 進路変更ごとのナビゲーションなど 現実的に正確な位置を 必要とする機能がアプリケーションにある場合 正確な位置に 一時的にアップグレードするよう要求できます この写真共有アプリケーションでは それは不要です おおよその位置を要求するだけです

アプリケーションがおおよその位置に どのように反応するのか 注意して見てください 可能な限り多くの機能が欲しいという ユーザの意思を尊重し 必要に応じておおよその位置のみを 求めるよう考慮しています

Core Location APIの変更点については “What's New in Core Location”をご覧ください おおよその位置を利用するためApple Mapsが 行った設計面の選択をじっくり見るには “Design for Location Privacy”をご覧ください 最後にiOS 14でContactsへのアクセスを どのようにシンプルにできるか見てみましょう

今年はプロアクティブキーボードが さらにインテリジェントになりました QuickTypeが連絡先の詳細情報を オンデバイス連絡先データベースから提示します “Enter name”フィールドで 名前を入力していくと 自動的にその名前の正しい情報が 埋まっていきます

どのタイプの連絡先情報を提示するか キーボードにヒントを与えるため テキストフィールドに 注釈を付けることができます この写真アプリケーションのようにほとんどの アプリケーションで素晴らしい体験ができます 電話番号かメールフィールドに 入力するだけのために ユーザの連絡先 すべてへのアクセスを求める必要はありません この仕組みについては“Autofill Everywhere” セッションをご覧ください

では始まりから思い出してみましょう 写真の共有には３つのプロンプトに回答して 多くのアクセス権を与える必要がありました プライバシー面で好ましくなく 使いやすいわけでもありません

ところがiOS 14でアプリケーションが利用できる 新しいツールを使って 体験を著しく向上させることができます ユーザは必要な写真だけをシームレスに共有し 正確な位置を共有しなくても その地域の友人を簡単に見つけることができ すべての連絡先へのアクセスを許可せずに 友人の名前を入力するだけです プライバシー面で優れ 使いやすさも向上しています

この新しいAPIで アプリケーションが選択できる設計は それぞれあるものの その背後にある原則を 覚えておくことが大切です

データ最小化は必要なデータを必要な時に要求し データを可能な限り最小限に抑え 新しいツールで優れた機能を構築することです これはアプリケーションを 使い始める最初の瞬間から ユーザとの信頼関係を構築する優れた方法です ロヒスに戻って次のプライバシーの 原則セキュリティについて話してもらいましょう

ありがとうブランドン セキュリティはエコシステムで プライバシーの基礎となり それを強化する もう1つの基本的な柱です

今年はセキュリティを活用して インターネットプロトコルの サーバー名のトラッキングの問に 対処しています

DNSクエリを使って サーバー名を公開するという方法があります

デバイスがウェブサイトにアクセスすると DNSクエリが送信され その名前をIPアドレスに変換します デバイスで使われるDNSサーバーは通常 インターネットプロバイダ ワイヤレス通信事業者　企業 他のネットワーク通信事業者により 自動的に構成されています DNSクエリは機密性や確実性にも 対応していないため クエリやサーバーのアドレスは サードパーティやネットワーク通信事業者により 読み取られたり 変更さえされる可能性があります デバイスから送信されるDNSクエリの タイプに関する情報を 収集し監視し保持して共有できます

しかし接続が暗号化されていれば サードパーティは DNSクエリを監視できなくなります

今年からAppleプラットフォームは ２つの標準暗号化DNSプロトコルに ネイティブで対応しています

対応している標準暗号化DNSプロトコルは サーバー名の機密性と確実性の両方を保護します これは企業のVPNやMDMの 構成プロファイルと共存します

iOS 14は自動DoHサーバー検出にも対応しており デバイスは暗号化されたDNSプロトコルを 自動的に使うことができます ウェブコンテンツをホストしている場合 サーバーを使って 安全にDNSクエリを解決するよう デバイスに指示できます Appleサーバー名はAppleのDoHサーバーを使って 自動的にDNSクエリを解決します これらのプロトコルの有効化について詳しくは “Enable Encrypted DNS”の トピックをご覧ください 閲覧中にサーバー名を公開するもう１つの方法は TLSセッションエスタブリッシュメント ハンドシェイクを通して行います TLSはウェブでトラフィックを 暗号化する場合に使うプロトコルです 暗号化DNSを有効にして より人目につかないように名前解決をしても TLSセッションエスタブリッシュメントには 標準文字のServer Name Indication つまりSNIがあります DNSクエリのように SNIはネットワーク上のサードパーティにより 監視されることがあり 接続しているサーバーの名前を教えます

私たちはサードパーティが トラフィックを探ることができないよう TLSハンドシェイクの暗号化をさらに 強化するための方法を 標準化すべくIETFとともに取り組んでいます このアップデートを盛り込んだ暗号化により ネットワーク通信事業者とサードパーティは ウェブ上の活動をトラッキングできなくなります これは我々のシステムでセキュリティが プライバシー保護を強化する 多くの方法の１つです ユーザはデータの安全確保において アプリケーションに依存しています iOS 14でアプリケーションの安全を確保して ユーザの信頼性を維持する方法については 次のトピックをご覧ください プライバシーに関する３つの柱である オンデバイス処理データ最小化 セキュリティ保護についてお話しました 必要なデータだけに アクセス要求する優れた方法を 開発者に与えるだけでなく アプリケーションがどのデータにアクセスするか ユーザが理解するための透明性も加味しています 今年はウェブ上で アプリケーションが収集するデータを より深く理解できるアップデートがあります

App Storeから始めます

現在すべてのアプリケーションで プライバリーポリシーが必要です 今年はもう一歩進めて情報を追加して 最も大切な詳細情報を 簡単に選べるようにしています

2020年秋からアプリケーションを App Storeに提示する場合 アプリケーションによるユーザデータの使い方を アンケートに記入する必要があります 提供する情報はStoreページで ユーザに直接表示されます 自分に関連付けられたデータ これによりアプリケーションを ダウンロードする前に アプリケーションが実行する内容を確認できます 収集するのは少量のデータか大量のデータか またそのデータでユーザをトラッキングするか 確認できるようになります

詳細情報を必ずユーザに提供して プライバシーポリシーやウェブサイト上などでの データ利用率を説明する必要があります この情報はApp Store製品ページで 簡単に入手できます

またあらゆるプラットフォームで App Storesのアプリケーションに表示されます

サードパーティのコードを インストールしている場合 分析や広告関連のSDKなどですが 収集するデータとその使い方を 宣言する必要もあります SDKは仕掛中のアプリケーションで動作するため アプリケーションと同じ権限に アクセスできる点を覚えておいてください 開発者はアプリケーションのユーザデータの 信頼性と扱いに対する責任があります 自分が組み込むコードなどです 次のステップ SDKの開発者にとり これは資料を更新する良いチャンスで SDKが行うことを 開発者が理解できるようにします 開発者の資料とアンケートは後で入手できます その一方でSDKの開発者に働きかけて データの収集方法と使い方を理解してください ウェブではIntelligent Tracking Prevention つまりITPによる― ユーザの保護方法を確認できるよう 変更をしています ITPはiOS 11とSafari 11以降 ユーザを保護しています ブロック対象となる既知のトラッカーを Safariのツールバーから 確認できるようになりました 過去30日間のすべての閲覧から Safariがブロックした トラッキングの詳細レポートを 詳しく調べ確認することもできます

またアプリケーション内の透明性を 向上させています ユーザはパスワード 写真 クレジットカード番号など 多くの機密情報をコピーアンドペーストできます ペーストボード この情報にアクセスできるのは クリップボードのデータを アプリケーションと共有したい場合のみです 組み込まれたコードがボードに アクセスしていることさえ認識できません

iOS 14では別のアプリケーションから ペーストボード項目にアクセスするタイミングを 開発者とユーザに分かるように説明しています これにはプログラムによるアクセスだけでなく キーボードメニュー項目吹き出しバーを使って 手作業でペーストするタイミングも含まれます

これにより項目をペーストし ペーストボード情報に 過剰にアクセスしている可能性がある アプリケーションについて警告する場合に ユーザによる確認を行います

またカメラやマイクへの透明性を 向上させています

アプリケーションでカメラやマイクが起動すると ステータスバーにインジケータが表示されます これで いつアプリケーションが録音しているか 常にわかります さらにControl Centerは どのアプリケーションが現在 カメラやマイクを使っているか またはどのアプリケーションが 最近使ったかを示します この透明性はウェブサイトによる カメラやマイクの利用許可にも当てはまります アプリケーションによる ペーストボードや録音の使い方を理解し 機能が必要としユーザが求めている場合のみ アプリケーションがアクセスされるようにします これにはペーストボードマイクカメラを ウォームアップして アプリケーションの即応性を アップさせることも含まれます アプリケーションが起動して 突然 録音を開始したら びっくりするでしょう

いつなぜアプリケーションが ペーストボードにアクセスするまたは 録音を開始するか明確にする UIによるヒントを組み込んでください

SDKはアプリケーションの一部であることも 覚えておいてください あなたはアプリケーションのコードや エンドユーザとの関係に対する責任があります アプリケーションのSDKが ペーストボードマイクカメラを使っている場合 エンドユーザにはアプリケーションが 使っているように見えます 透明性を維持するとユーザがアプリケーションや ユーザデータの利用に持つ信頼性が強化されます

アプリケーションと共有するデータ管理は 透明性と連携します では今年導入している次の最新情報を お話していきましょう ネットワークからお話します

ローカルネットワークのデバイスは ネットワーク活動に関する情報を監視し 収集でき アプリケーションは ユーザが利用しているネットワークから ユーザに関する情報を収集できます

あらゆるネットワークは独自であり ユーザの周囲環境を表しています アプリケーションや他の監視プログラムは まるで自宅で自分の周囲の人のように 情報を取得できるということです TVや他のアクセサリなど 接続されたデバイスに基づいて プロフィールを作成することもできます

今年はローカルネットワークへの アクセス管理を追加しています アプリケーションが BonjourやmDNSスキャンなどで ローカルネットワークにアクセスしようとすると アクセス権の提供を求められます Info.plistにアプリケーションが要求している Bonjourサービスを宣言してください システムはどのサービスから 情報を提供するか認識します 以前のように使用法メッセージを提供して アクセスが必要な理由を説明し 突然要求されたのではないことを示す UIのヒントを用意してください

iOS 14のローカルネットワークについて詳しくは “Support Local Network Privacy in Your App”のトピックをご覧ください

MACアドレスはネットワークの特定デバイスを アドレス指定する場合に使うIDですが デバイスをトラッキングするために 作成されたわけではありません iOS 8ではMACアドレスの ランダム化を導入しました これによりWi-Fiに接続されていない場合 MACアドレスから ユーザはトラッキングされません

しかしネットワークに接続していると 物理Wi-Fi MACアドレスは接続の痕跡を残します アドレスは変わらないためです あるネットワークから 別のネットワークに移動しながら ネットワーク通信事業者は Wi-Fi MACアドレスからのデータを組み合わせて より完ぺきなユーザプロファイルを作成できます ここにはユーザが閲覧した場所 そのネットワーク活動の詳細が含まれています 今年はプライベートWi-Fiアドレスを 導入しています ネットワークに参加するとiOS 14は 自動的にWi-Fi MACアドレスを管理します こうすればMACアドレスはユーザIDに 関連付けられず あるネットワークから次のネットワークへの トラッキングに使うことはできません また新しいMACが 24時間ごとにネットワークに生成され ネットワークを離れて再度参加すると 新しいプライベートアドレスが使われます ユーザは常にこの機能を管理し Wi-Fi設定で調整できます プライベートWi-Fiアドレスを使って ユーザはIDに関連付けられていない 日々生成されたネットワークごとの アドレスを取得します ユーザは常に管理できます

今年はNearby Interactionフレームワークも 導入しています これによりU1チップで導入された 超広帯域を活用できます Nearby Interactionは対話型ゲームや 近くにある電話を探していることを確認するなど 他のピアツーピアのユースケースについて 距離と方向の情報を取得する優れた方法です

このフレームワークを使う場合Bluetoothや ネットワークアクセスを求める必要はありません セッションをベースにした アクセスが求められます そのためデータは アプリケーションがフォアグラウンドで 使われている最中に使用できます いつユーザに許可を求めるのか 必ずはっきりと説明を入れて 事情があってアプリケーションが 許可を求めている場合に指示してください 詳しくは“Meet Nearby Interaction”の トピックをご覧ください

iOS 14の新機能App clipは アプリケーションでの体験を ユーザに紹介する優れた方法です App clipは最初から 非公開になるよう設計されました そのためユーザは気楽に試すことができます App clipをフルアプリケーションに アップグレードしない場合 iOSは未使用のApp clipを 消去するため痕跡は何も残りません 特にApp clipの独自のユースケースに向け データ最小化を実践できるよう プライバシーを重視した位置アクセスも 新しく設計されました タグが移動していないこと また正しいレストランの待ちリストに 載っていることを確認できます 位置情報は位置にフルアクセスすることなく この達成に必要十分な情報を公開します ユーザはApp clipカードでこれを管理できます App clipが特定の位置で起動されたか システムに尋ねても 余分なプロンプトはありません しかし確認に失敗してもユーザが 近くにいないわけではありません ユーザが単に位置サービスをオフにしているか 位置の確認を許可しないように していた可能性があります 確認を追加するなどしてユーザによる対処方法を 提供してください 詳しくは“Streamline Your App Clip”と “Design Great App clips”のトピックを ご覧ください

Safari 14の新機能Safari Web Extensionでは 拡張機能とデータの利用を ユーザが直接管理できます ユーザはSafari Web Extensionが アクセスするウェブサイトを選び ニーズに応じて カスタマイズできるようになります 必要最小限の権限を要求するよう 拡張機能を構成してください たとえばactiveTab権限では 現在のウェブページでスクリプトを実行する前に ユーザを追加確認せずに ユーザが拡張機能を起動します Safari Web Extensionとプライバシーについて 詳しくは “Meet Safari Web Extensions”のトピックを ご覧ください

今年のMacはiOSでなじみの多くのテクノロジーや プライバシー保護機能をmacOSに 組み込んでいます Core Bluetoothを使うmacOSアプリケーションの Bluetoothアクセスを管理可能になりました

Catalystでアプリケーションを構築する場合 Limited Photos Libraryを 利用することができます iOSと同じ認証モデルで利用できる HomeKitを活用し Media and Apple Musicにアクセスし CNCopyCurrentNetworkInfoに アクセスできます iOSの場合のように目的文字列を指定して ユーザデータが必要な理由を 理解できるようにする必要があります

今年はアプリケーションで 透明性と管理を実践するため 優れた新ツールを作成しました ユーザデータの使われ方をユーザに説明して示し ユーザが常にデータを管理することが大切です この４つのプライバシーの柱により ユーザはそのデータとデバイスを任されます それぞれアプリケーションを使い始める 最初の瞬間から ユーザとの信頼関係を構築し続けます ブランドンに戻って ユーザトラッキングを防ぐため このプライバシーの柱が どのように連携しているかお話します Safariの初期以降トラッキング防止機能を内蔵し ウェブ閲覧中のユーザを保護していました デフォルトでの サードパーティクッキーのブロックから Intelligent Tracking Preventionの 今年の新しい透明性まで これらの保護機能を常に更新するため 懸命に取り組んできました 今年はこの同じトラッキング保護の考え方を アプリケーションにもたらしています トラッキングは常に透明性があり ユーザに管理されていると考えるものです 前に進みますがApp Storeポリシーでは 他社所有のアプリケーションやウェブサイトの ユーザをトラッキングする前に確認が必要です アプリケーションはこのプロンプトを表示し “Allow Tracking”をタップした場合のみ 他社所有のアプリケーションや ウェブサイトのユーザをトラッキングします これにはターゲット広告 広告効果測定 データブロッカーとの共有などがあります 実際会社間のトラッキングとは 何なのか詳しく見ていきましょう

たとえば私はベーグルが好きで ブドウが嫌いと アプリケーションが知っていたとします これを私が宇宙飛行士になりたいことを 知っているデータブローカーと共有すると これはトラッキングと見なされます 大切なのは直接 私の名前と紐付けられていなくても ユーザID 広告向けID デバイスID指紋IDやプロファイルなど 特定のユーザに関するIDと紐付けられている場合 トラッキングと見なされます いくつか特定の条件下では トラッキングAPIを呼び出す必要はありません たとえばユーザのデバイスでのみ 関連付けがされている場合です データはそのユーザ またはデバイスを特定するようなやり方で デバイスから送信できないことを意味します あるいはデータを データブローカーと不正の検出や防止 またはセキュリティ目的でのみ 共有している場合です にもかかわらずデータブローカーの目的ではなく 自分のためだけに利用しなければなりません ユーザをトラッキングする許可を求めるには AppTrackingTransparencyフレームワークを 呼び出します このようなプロンプトが表示されます

このフレームワークではInfo.plistに記述する NSUserTrackingUsageDescriptionキーが 必要です

ユーザのトラッキングを要求する理由を 明確に説明する必要があります

IDFAはIDの1つで 新しいトラッキング権限で管理されます ユーザをトラッキングする許可を求めるには AppTrackingTransparencyフレームワークを 呼び出します “Ask App Not to Track”を選ぶと IDFA APIはすべてゼロを返します AppTrackingTransparencyフレームワークは iOS 14 SDKでのみ入手できます つまりiOS 14に対してアプリケーションを 構築していない場合は IDFAは入手できず APIはすべてゼロを返すということです

アプリケーションがトラッキング許可を 求めないようにすることもできます Limit Ad Trackingはこのスイッチに移行しており アップグレードしているユーザの期待通り Limit Ad Tracking対応とは iOS 14のアプリケーションが 引き続きIDFAをゼロと読み取り Request to Trackスイッチが オフになるということです Limit Ad Tracking同様スイッチはオフになり 未成年のアカウント共有されている iPadsに対して完全に無効になり MDMプロファイルでオフにし無効にできます

最後に覚えておいてほしいことがあります ユーザはいつでもトラッキング権限を 許可しないようにできるということです AppTrackingTransparencyフレームワークは IDFAを使う前に アプリケーションを起動するたびに 呼び出されます 今の場合のようにIDFAをキャッシュに入れたり 保存したりしないでください またトラッキングがオフの場合に ユーザのトラッキングを停止するため どのような変更を行うか考えてください 私たちはプライバシーが 変革のチャンスと考えています トラッキングの作用に対する この大きな変化により 通常トラッキングに関する 主要な疑問に答えるため イノベーションソリューションをまとめました 広告属性です

多くの開発者にとってトラッキングは 業務上の疑問に答えようとする場合の副作用です “最も効果的な広告キャンペーンはどれか？” といった疑問です AppleのSearch Ads属性システムは 現在会社間でユーザをトラッキングしませんが 他の属性システムではどうでしょうか 今年はSKAdNetworkに 大きな改善を発表しています プライバシーを重視したやり方で 広告実績に関する疑問に答える フレームワークです SKAdNetworkはプライバシーを核にして 設計されています オンデバイスインテリジェンスと アグリゲーションを使って ユーザをトラッキングせずに 変換測定を行っています ユーザをトラッキングしないように 設計されているため トラッキング許可を求める必要はありません 属性は次のように機能します アプリケーションの広告を 有料でニュースアプリケーションに表示します ユーザがその広告をクリックすると App Storeにそのアプリケーションが表示されます ダウンロードして起動します そのアプリケーションの 新規ユーザとなるわけです SKAdNetworkで “アプリケーションを多くインストールするのに つながった広告は？”などの質問に答えられます オレンジ色の背景の広告が最も効果があるようで キャンペーン１を増やし キャンペーン２を少なくするのが良いでしょう また広告を表示しているどのアプリケーションが アプリケーションの新規ユーザ獲得に つながったのか理解するのに役立ちます キャンペーンをスポーツアプリケーションで 多く行うことが重要だとわかるでしょう では現在これはどのように機能するでしょうか ユーザが広告をクリックすると 広告SDKはキャンペーンIDとIDFAのような ユーザに関連付けられたIDとともに 広告ネットワークにメッセージを送信します 次にアプリケーションを インストールして起動すると そのアプリケーションの広告SDKは 同じIDを送信し 広告ネットワークに知らせます 広告ネットワークはこれらの情報をまとめ 広告を購入した開発者に ニュースアプリケーションのキャンペーン89の 変換が成功したことを知らせます では広告ネットワークは 何を学習するのでしょうか 多くのことを学習します このユーザはニュースアプリケーションと あなたのアプリケーションをインストールしたこと この広告をクリックしたこと 変換が成功したことなどです

ではトラッキングせずに これがどのようになるか見てみましょう

ユーザがトラッキングを許可しないと このユーザIDはなくなります 広告ネットワークは変換について 何も学習できません これは従来の方法での変換測定の問題です しかし広告ネットワークは 変換を測定しようとしているだけで それにユーザ固有の情報は含まれていません SKAdNetworkは具体的なユーザ情報がない 変換情報のみ学習できるよう構築されました これが表面下でどのように 機能するのか見てみましょう 広告ネットワークを直接呼び出す 広告SDKのかわりに デバイスでStoreKitフレームワークを呼び出して キャンペーンIDを渡してみましょう この情報はApp Storeクライアントにより 保存されます これはアプリケーションのダウンロードも 記録します アプリケーションを起動すると アプリケーション内の広告ネットワークは StoreKitにアプリケーションが 正常に起動したことを知らせます 今度はそれをApp Storeクライアントに知らせます

送信元アプリケーションと 宛先アプリケーションの一意の組み合わせで ユーザが特定されないよう 変換データはAppleに送られ 十分な数の他のユーザが同じ変換を したかどうか検査します 検査に合格すると デバイスが通知され 変換データを広告ネットワークに送信でき 変換の成功をニュースアプリケーションから あなたのアプリケーションへ 実行したキャンペーン経由で報告します またこの情報の完全性を確保するため 終始暗号署名が使われます

では広告ネットワークがここで学習する 内容を見てみましょう キャンペーン89が― ニュースアプリケーションからあなたの アプリケーションへユーザを誘導したことだけです これがユーザが始めから 測定しようとしていたことです SKAdNetworkはプライバシー設計技法を適用し 創造的な技術ソリューションを構築して 機能とプライバシーのギャップを埋める好例です 開発者の数グループがSKAdNetwork導入へと 歩みを進めることができます アプリケーションに広告がある場合や アプリケーションの広告を 別のアプリケーションで行っている場合 SKAdNetworkに対応した 広告ネットワークを選びます そうすればトラッキングの 許可を求める必要がなく ユーザトラッキングの選択に関係なく 変換データを取得します 広告ネットワーク事業者は developer.apple.comで SKAdNetworkの導入方法について調べてください “What's New with In App Purchases” セッションで SKAdNetworkと導入について詳しくご覧ください

まとめますがAppleで製品を判断する指針となる プライバシーに関する 主要な４つの柱についてお話しし 新しいトラッキング保護機能など 今年の新機能に それをどのように適用するのか説明しました これがプライバシーを変革のチャンスと捉え 今日お話ししたツールを使い プライバシーを大いに守り ユーザとの信頼関係を構築する きっかけとなれば幸いです ありがとうございました