プライバシーのための設計

(音楽)

(拍手) こんにちは (拍手) ご覧のとおり プライバシーは人々が求め 大事にしているものです 私はプライバシーチームのマーク 同僚のジュリアンと プライバシーのための設計について お話しします

プライバシーとはドアを閉じること そして顧客との信頼を築くために ドアを開けることです

デバイスは自宅での利用や

写真の記録に使われます

健康の管理や― 考えや気持ちのシェアにも データが安全だと思うからです

昨年ティムは言いました “Appleはユーザの個人データを 大切に扱い” “最高のサービスを 提供することができます” “あなたにも できるはずです”と 今日はプライバシーの設計について 話します

Appleは データの最小化を重要視します アプリケーションの機能に 必要なデータと 不要なデータを考えます

魅力的な機能は 機密かつ個人的なデータを使います Appleは これらの機能に デバイス上の知能を付け デバイスが 個人向けになるようにしました Appleはデータを集めません

データを共有する際は顧客に確認します 顧客は常にデータを管理し 何を共有しているか知っています

セキュリティは基礎です デバイスやServer上のデータを 保護するだけでなく―

プライバシー保護と人々の選択を 強固なものにします

データは保護さえすれば 利用してもよいと― 考える企業もあります しかし セキュリティだけでは 不十分です

データ保護の責任はもちろんですが 収集しなければ危険は減ります

プライバシーは透明性と 管理だと言う企業もあります データの扱い方をユーザに知らせ 嫌なら断ってもらいましょう

この事後的プライバシーにより― ユーザはプライバシーか機能を 選ぶことになります ユーザに管理負担を 負わせるべきではありません

プライバシーは基本的人権です 善良な社会には必要不可欠ですし テクノロジーと合わせても 機能すべきことです

だからAppleでは プライバシーを組み入れました 設計の最後に 付け足したのではありません

私たちはプライバシー保護機能を 開発すべく挑戦しています あなたにも できます

今から プライバシーとユーザ体験― フレームワークの新情報について 話します また イノベーションを介した プライバシー保護も紹介します

では４つのユーザ体験を見ていきます

まずはSign In with Appleです ユーザ認証を 保存や管理せずとも プラットフォーム間で共有できます

データ最小化の好例でもあります Appleはアプリケーションが どう使われるか追跡しません

Sign In with Appleで 共有したデータを サインインに必要な量に減らしました 顧客名やEメールアドレスは 必要でしょうか 請求書や郵送に名前が必要なら 後日Apple Payから得られます 追加データを求めなければ ユーザはボタン１つで サインインできます

ユーザと連絡を 取らなければならない時も 簡単な方法があります

人はEメールアドレスを 教えたがりません スパム業者に盗まれたり 悪用される事例を見ているからです ですから 偽のアドレスを 教えるかもしれません サインインで アドレス認証が可能ですが ユーザはアプリケーションから 一旦出ないといけません よい体験ではありません Sign In with Appleなら Apple IDに紐づいたアドレスです

顧客がアドレスを隠したい場合 Appleが管理するアドレスを使います あなたと顧客のやり取りを 私たちが中継し― 伝達後はEメールを廃棄します

このアドレスは デベロッパによって違うので 顧客はやり取りするデベロッパを 管理できます ユーザはEメールを スパムフィルタにかけられるので 誰がこのアドレスを使えるのか 管理できます 両当事者が管理しているので 顧客にとっては最善の Eメール受信方法です

不正利用を防ぐ上での 課題もあるでしょう 画像認証もその１つです しかし これらは面倒で使いにくいです

プライバシーを 侵害するものもあります 例えばユーザを特定できる情報や 指紋認証です

Sign In with Appleなら デバイス上の知能を通じて １ビットでユーザ本人かを判断します

iOSでは アカウント作成時に 使えるフラグです

ユーザのASAuthorizationAppleID Credentialのステータスを確認します 新規ユーザのステータスが 不明の場合もありますが サービスを拒否してはいけません 確認し直す方法を提供しましょう

シングルサインオン･ソリューションの Sign In with Appleは以上です

次は位置情報サービスです 人は居場所を知られたくないものです 住んでいる場所

よく行く場所 生活パターンも分かってしまいます 出かける場所や仲間が 違っても分かります iOS 13では 場所を共有する時 より賢く管理できるようにしました

以前は位置情報の 利用許可を求めていました アプリケーションの位置情報が 初めての場合 ユーザが“許可しない”を 選ぶことがあります すると位置情報サービスの価値を 見逃します

位置情報サービスの使用法を 説明をするより 実際に使ってもらいましょう iOS 13の新しいオプションは １回だけ許可できる設定です ユーザは決断前にアプリケーションで 位置情報サービスを試せます

ユーザが“１回だけ”許可したとします この時 位置情報の利用は― アプリケーションの使用中に限ります 次の起動時に再び選択します 毎回 選択したくなければ “このAppの使用中のみ許可”を 選びます

“常に許可”はどうでしょう いつでも位置が分かるのは 強力な機能です 位置情報サービスの価値の実証前に 選択をせまられたら？ 位置情報がアプリケーションに なぜ必要なのかと思うでしょう

位置情報の選択は 今後 “１回だけ”か“使用中”のみとなり

“常に許可”を求めても 表示は “１回だけ”か“使用中”だけです

ユーザが“使用中”を選んだら “常に許可”が認可されたと判断します iOSは引き続き“常に許可”の 位置情報イベントを生成します

“常に許可”の位置情報イベントを 提供する前に “使用中”から“常に許可”に 変更するようユーザに促します ユーザが許可した場合のみ 位置情報イベントを得ます

ホーム画面にいる時だけに 質問しますので すぐには実行されないでしょう

透明性の提供のため 常に位置情報を得ていることを ユーザに伝えます さらに ユーザが iOS 13にアップグレードしたら “常に許可”設定の 既存アプリケーションを再度通知します

互換性を破るAPIの変更はありません しかしアプリケーションが うまく対応できるか “１回だけ”や“常に許可”の 動作テストは必要です “常に許可”のデータを使うなら その使用価値を明確にしましょう

コンテクストプロンプトは ユーザの情報に基づく選択に役立ちます 質問があればラボへどうぞ What's New in Core Locationの セッション動画を見たり Core Locationラボへ来てください

３つ目のユーザ体験は Bluetoothです 以前はperipheralManager APIで 情報を共有する際は ユーザの同意のみ必要でした

iOS 13ではどのCore Bluetooth APIでも 同意が必要です これは古いSDKにリンクされた アプリケーションにも適用されます

Info.PlistでNSBluetoothAlways UsageDescriptionとします ユーザはBluetoothの 必要性を理解した上で 妥当な選択ができます これはiOS 13以降にリンクされる 全アプリケーションに必要になり 入力しないとクラッシュします 使用目的の書き方は 昨年の講演をご参考に

導入は簡単です ユーザが許可していない場合 CBPeripheralかCentralManagerの インスタンスが生成されます iOSはユーザに Bluetooth APIへの アクセス許可を求めます そこでCentralまたは PeripheralManagerで 現時点での許可状況を 確認できます

詳細はWhat's New in Core Bluetoothの セッションをどうぞ

最後はmacOS Catalinaです ユーザの同意を求める機能を 増やしました

macOS Mojaveでは ファイルシステムのリソースを保護し ユーザにアクセス許可を求めました 今年はデスクトップや書類 ダウンロードなど こちらに挙げたフォルダの保護を 追加しています

macOS Mojaveのカメラやマイクや macOS Catalinaの スクリーンレコーディングなどもです

Synthetic Input Eventsなどの ユーザコントロールもです 詳細はAdvances in macOS Securityの セッションや― 彼らのラボへどうぞ

次は新しいフレームワークを ３つ紹介します

その前にデベロッパの方に朗報です

２年前 ITPつまりIntelligent Tracking Preventionを発表しました クロスサイトトラッキングを 防ぐためです これはSafariに大きな影響を与えました 他のブラウザも同様のテクニックを使い クロストラッキング対策をしています

しかしトラッキングしないWebに 広告がないとは限りません 昨年のプライバシー重視の インストール検証付き広告インフラで 広告からインストールへの コンバージョン率が測れました 今年は Webに対応

Privacy Preserving Ad Click Attributionです 広告主と業者が ユーザを追跡せず 広告キャンペーンの成功を判断する 新しい方法です

SneakerNetでランニングシューズを 売るとしましょう

search.exampleで 広告を購入し 閲覧数や購入に 効果があるかを見ます

以前はクロスサイトトラッキングで 行いましたが 今はITPがブロックします

ここでPrivacy Preserving Ad Click Attributionです Safariが広告のクリックと―

業者をつなげます

そして属性を広告主に報告します 仕組みを見ていきます

ユーザがSneakerNetの広告を クリックすると Safariはそれを７日間記憶します

期間中ユーザがSneakerNetで 商品を買うと 業者や広告主は コンバージョンとして特定します

Safariはそれと クリックした広告を結び付け search.exampleからSneakerNetへの コンバージョンを記録します

そしてこのコンバージョンを search.exampleへ報告します

導入は簡単です 広告主はadDestinationなどの 新しい属性を リンクアンカータグに付けるだけです つまり SneakerNet.exampleと―

adCampaignIDです search.exampleは複数の キャンペーンをしているかもしれません CampaignIDで それらを別々に比較できます

業者サイトを変更せず 既存のトラッキングピクセルで コンバージョンを検出できます

検索サービスプロバイダは ConversionIDを認識するURLに Serverを向け直します コンバージョンとは カートに商品を入れたり アカウントを作成することです 業者はConversionIDにより コンバージョンを区別できます

ユーザのプライバシー保護のため SafariはCampaignIDと ConversionIDの上限値を64としています よって広告主と業者間の コンバージョンは 最大で4000分の１にリンクされます

この属性の報告まで Safariは24～48時間待ちます クリックとコンバージョンを集計し ユーザアクティビティの 相互関係を防ぐためです

また この属性は一時的なセッションで 報告されます プライベートブラウズでは 記録されません

Privacy Preserving Ad Click Attributionは Safari Technology Preview 83で 試用できます これはiOS 13やmacOS Catalinaの 初期設定です Web基準になるようW3Cにも提案中です 詳細はwebkit.org/blogでどうぞ

次にSpeech Recognizer フレームワークは 音声表記を可能にします ローカライズを望む声がありました これは医療現場などで特に役立ちます

iOS 13ではオフラインの音声表記を 導入しています 情報を発信せず オフラインでも 音声表記ができるのです

導入するにはisAvailableForLocal Recognitionを確認し― requiresLocalRecognitionを “true”と設定します

次はTestFlightに フィードバックする方法です ユーザが抱える問題をデベロッパが― 理解することは大切です ただ テストユーザの プライバシー保護も大切です

iOS 13ではTestFlightユーザが Screenshot UIから スクリーンショットを提供できます クラッシュも報告できますので 彼らがクラッシュに直面した時の 行動が分かります

ユーザはデータ共有も管理しています iOS 13のTestFlight 2.3で 利用可能です App Store Connectで フィードバックを送れます 詳細はWhat's New in App Store Connectを確認してください

次の項目はジュリアンが説明します (拍手) ありがとう

既存APIのプライバシー強化について お話しします

今日紹介するアップデートは５つです １つ目はCNCopyCurrentNetworkInfoです CNCopyCurrentNetworkInfo APIは デバイスが接続された― Wi-Fiアクセスポイントの 名前とMACアドレスを返します ユーザの居場所が分かるため プライバシーに影響を及ぼします

iOS 13では CNCopyは特定カテゴリの Appのみ有効です CNCopy エンタイトルメントを 宣言するAppと 仮想プライベートネットワークを 構成するAppです またはNEHotspotConfiguration APIを 使うAppか ユーザから位置情報の 許可を得るAppです もうCNCopyに アクセスできない場合があるのです 詳細は画面のセッションで 確認してください

２つ目は連絡先へのアクセスです iOS 13ではユーザが連絡先への アクセスを許可したAppは メモ欄にアクセスできなくなります 連絡先のメモ欄には 上司の悪口などの 機密情報が含まれます Appにこのデータは不要です 必要だと思う場合は こちらのURLから エンタイトルメント申請を ３つ目はCustom URL Schemeです AppをCustom URL Schemeで 起動した場合 オープンURLのオプションで 起動したAppを特定できます これでインストールされたAppが 分かります iOS 13以降 ソースAppは 同じデベロッパのAppにしか 明かされません ４つ目はGame Centerです プライバシー保護のため Game Centerは新たに ２つのAPIを導入しています teamPlayerIDは チーム中心のプレイヤーの識別子 gamePlayerIDは ゲーム中心のプレイヤーの識別子です 既存のplayerID識別子は廃止されます これによりゲームAppで使う識別子が 変わります 詳細はGame Centerの動画を 確認してください ５つ目はコンテクスト情報です iOSはAppが一番 ユーザの役に立つ時を知りません よって主に２つのAPIを使い Appへのコンテクスト情報を提供します NSUserActivityは 検索結果でAppを目立たせます SiriKit INInteractionは デバイス上の知能で Appを宣伝します 例えばマップやショートカット 今年の共有シートです Appを宣伝するならフェアでいましょう Appから削除した内容は消します そうすればSiri ショートカットに 提案されません 相当する削除APIを使いましょう 以上が既存APIの アップデートについてです 次は そこから少し離れます プライバシー保護への挑戦は どう革新につながるのでしょう プライバシーは 全プロダクト設計の基本です プライバシーチームは エンジニアと協力して プライバシー強化に努めています

時々 大変難しい問題に直面します 世に出したい機能があっても プライバシーを守る方法が分かりません

こんな時は自分に課題を与えます 私たちの目標は 最高の機能を開発することです プライバシーの原則に従い 解決策を見つけて革新します 皆さんにも そうしてほしいのです 次はユーザ体験の３つの重要点 機械学習 Find Myそしてホームです まずは機械学習です

このAppを作る方法は 多数あります 通常 モデルを訓練し評価をします 機械学習での プライバシー保護への挑戦は モデルをどう訓練するかです ユーザの機密データは収集しません 各ユーザ向けにモデルを変えて ユーザ体験を大幅に改善します 通常 データから始めますが その量は膨大です 探すだけで一苦労です オプションを見ましょう １つ目はユーザからデータをもらうこと プライバシー保護のため ベストプラクティスを適用します 例えば識別子のランダム化などです しかし ユーザの顔写真など 機密度の高いデータもあります ２つ目はユーザスタディの実施です 厳選したユーザにテストしてもらい データを集めます Face IDの訓練は この方法でした

最後はユーザの外部データ 公開されているものもありますが それ以外は他の企業との 入念な協力が必要です プライバシーに関する課題も 出るでしょう データを入手したら― モデルを訓練できます 例えばCreate MLが使えます モデルは大抵のユーザに適していますが ユーザはそれぞれ違います 各自ニーズがあります 特定のユーザ向けに モデル調整が必要な場合は？ 今年は更新可能なCore MLモデルを 導入します デバイスに更新可能なモデルを送ります モデルはユーザの訓練データを取り入れ 新しい個別モデルを作ります Face IDでも実施済みです Face IDは人の顔を自動で特定します ひげを伸ばしたり長髪にしても あなたを認識します デバイスでも同じことが起きます

訓練ではリソースを使いますし ユーザ体験に影響する場合もあります 新しいBackgroundTasks APIは バックグラウンドで機械学習の 予定を決めます 期間は１週間以内にしましょう

先すぎると iOSが 予定を組まないかもしれません BackgroundTasks APIの詳細は セッションで確認してください １人以上のユーザデータが 必要な場合もあります 様々なユーザのデータが必要です 今日は私たちが開発中の― 新しいテクニックを披露します これは機械学習のために プライバシーを革新した例です Federated Learningは 機械学習を加速する新しい手法です Private Federated Learningは Federated Learningとプライバシーを 組み合わせたものです アイデアはシンプルです ユーザデータは集めませんが Private Federated Learningで モデルの更新情報を集めます つまり こうです デバイスがServerに モデルをどのように更新するか 伝えるのです 例を見てみましょう Serverがデバイスに オリジナルモデルを与えます 今は白です デバイスはモデルを訓練し 新しいモデルを得ます 色がつきましたね 新モデルとオリジナルモデルの 違いを計算し その更新情報を Apple Serverへ戻します

Serverは情報を集積し 新しい機械学習モデルを作ります グラデーションのところです この時ユーザデータは そのまま送られませんし ユーザまたはデバイス識別子は不要です

Serverは新モデルを使い デバイスを更新します このサイクルはデバイスとServer間で 繰り返されます プライバシーの観点から 機密データが含まれないか 分析する必要があります 更新情報は ユーザデータそのものとは違います 残念なケースもあります Serverが モデルの更新情報を元に データを再構築しかねません この城の更新モデルを ユーザが送ったとします そのServerはその情報から 城の画像を再構成するでしょう これを防ぐため デバイスやServer上で使う― 更新情報を保護しています SeparatedとCentral Differential Privacyを使ってです Differential Privacyは 更新モデルにノイズを加えます これによりServerは 画像を再構成できません Separated Differential Privacyの 使い方は この資料をご覧ください

Private Federated Learningは デバイス上の知能の 改善に使われます これは研究実験ではありません この技術をiOS 13で使っています QuickTypeキーボードやHey Siriなど 様々な使用例があります

モデルを訓練したら使いましょう 機械学習における ２つ目の課題点です ユーザデータを集めず 短時間で どうモデルを評価すればいいのでしょう まず浮かんだのは ユーザデータをServerに送り モデルを評価して推論値を得る方法 しかし多くのデータが必要です それよりも デバイス上の知能です デバイスが送られてきたモデルを 評価します これには利点があります 送るデータは少量で済み Core MLを使えば速くできます Core MLは iOSデバイス上で使うには最適です 既存モデルをCore MLモデルに 変えるのも簡単です 今年はモデルアーキテクチャの数も 増やしました Core MLセッションで 詳細を確認してください

デバイス上の知能は プライバシー保護に強いです プライバシーの保証という形で ユーザにその利点を伝えましょう プライバシーの保証の文言は とてもシンプルです これは法律用語ではありません

例えばFace IDですが “Face IDのデータは デバイスにとどまります” これは私たちのプライバシーへの 取り組みを明示しています ユーザにも分かりやすいでしょう

以上が機械学習です 次はFind Myです

今年は新作を発表しました 「iPhoneを探す」と「友達を探す」を 融合したものです 楽しみな機能の１つが オフラインでの検索機能です これは注目していた課題でした ユーザが図書館に MacBookを忘れたとします Find My Appを起動し MacBookを探します しかしMacBookは インターネットに接続されていません

プライバシー保護の挑戦は MacやiPhoneなどの デバイスを探すことです つまり インターネットに 接続していなくても 紛失したデバイスのプライバシーは 守られます また 発見者のプライバシーも 守られます この時Appleは何の情報も得ません バッテリー寿命への影響もわずかです 課題が多いためクラウドソーシングに 頼ることにしました Bluetoothを使って MacBookを見つけやすくし Apple Serverに報告するのです しかし静的識別子 ブロードキャストには頼れません 静的識別子を使うと 誰でもデバイスを追跡できます それではダメです その代わりが MacBookが発信する― 一時的な公開暗号キーです このキーは時間と共に変わります

近くの電話は Bluetoothを通して暗号キーを受信し 自身の居場所を計算して暗号化します このデータはApple Serverに送られます 暗号化された居場所は Appleでは分かりません 紛失物を見つけてくれた 電話の情報もありません MacBookの所有者が 暗号データをAppleに要求し 暗号を解読して 紛失物を見つけるのです こうすれば こんなプライバシー保証が 可能です “Appleはオフラインデバイスや 発見者の場所は分かりません” これは大きな成果です 業界最高のすばらしい機能を 設計する方法を見つけました

続いてホームです

自宅は安全で大切な場所です 仕事やWWDCの長い講演が終わったら 帰る場所です スマートホームの人気が高まるにつれ 新たなプライバシーの脅威も現れます スマートホームのアクセサリも 不安ですし― 防犯カメラ以上に 機密事項を持つものはありません ここでのプライバシー保護の挑戦は いつでも防犯カメラの確認が できることです Appleを含め 他の人に 動画を見られることなく Smart Camera体験を 可能にするのです 私たちは２つのことに取り組みました １つ目 デバイス上の知能に頼り 住人のデバイスで 画像を扱うことです HomePodかApple TV iPadでもいいです Cloudではなく家で直接 人や物を検知します

２つ目はカメラの記録を 暗号化して保存することです つまり内容を見られるのは 住人だけです 次のプライバシーの保証の宣言もします “あなただけがカメラの映像を 見られます” 短くて簡単ですね 終わりに近づいてきました プライバシー保護の挑戦と 解決策を紹介しました 今回はAPIアップデートと プライバシーの新機能も解説しました

毎年 新しいプロダクトが リリースされます ユーザ情報を提供しなくて済むような 最高の機能を開発していきます プライバシーは 全プロダクト設計の基本ですので プライバシーの保証を ユーザと共有します

プライバシーを守る決意を シンプルな文章で伝えます

３つのことを覚えて帰ってください １つ目 新規プロジェクトに取り組む時 自問してください “ユーザデータをどう守る？”と 何をすべきかを自分に尋ねてください プライバシーが保護されていると 分かりやすくして ユーザの信頼を得ましょう

２つ目 プライバシーの問題に直面したら 全力で解決策を見つけましょう プライバシーは革新のチャンスです ユーザデータを提供しなくても済む 機能を届けましょう

３つ目 プライバシーはユーザと 関われるいい機会です

プライバシーとは人です プライバシーポリシーに 固執してはいけません ユーザとプライバシー保証を 共有しましょう

質問がある方は プライバシーラボへどうぞ プライバシーチームを代表して お礼を言います (拍手)