プライバシーの新機能

♪心地良いヒップホップ♪ ♪ こんにちは！ Privacy EngineeringのMichaelです 「プライバシーの新機能」の セッションにようこそ Appleでは プライバシーは 基本的人権だと考えます それを尊重し保護するのは 全員が共有する責任です そのため Appleが新機能や 機能改善をデザインする時は プライバシー保護は主要な要素となります 多くのプロダクトやサービスが 私たちの生活の中において 欠かせない存在となるなか デベロッパも人々を守る上で 重要なパートナーです アプリが優れたプライバシー体験を提供し どのデータがアクセスされて その目的は何なのかを 人々が理解し管理できれば アプリへの信用を得られます 個人的にセンシティブな内容については とりわけそうだと言えるでしょう みなさんがアプリでの プライバシー保護を確立するうえで プライバシーの柱が 素晴らしいガイドになります 以前に聞いたことがあるかもしれませんが これらはAppleでの 4つの中心的考え方で プロダクトやサービスのプライバシーを 考える時に使われます 最初の柱はデータの最小化で 機能を構築するのに 必要なデータのみ使うことです これは アプリの開発過程 全体を通して適用され アクセスされるデータ機能の量から アプリケーションサーバと 共有されるデータ そしてサードパーティと共有される 可能性のあるデータに適用されます 2番目は オンデバイス処理です デバイスの力を活用して データ処理はローカルで行い サーバとの共有を避けます 3つ目は 透明性とコントロールです データへのアクセスや処理が起こる前に 何がどうして いつどこで起こるのか 人々が理解できるように確認し 適切なコントロールを提供します そして あとからでも変更できるよう オプションを提供します 最後の柱は セキュリティ保護で ほかの柱を強化するための 強力なテクノロジーで エンドツーエンド暗号化などがあります アプリにプライバシーの柱を 取り込みやすくなるように プライバシーを中心にデザインされた 導入しやすい新ツールについて話し そのあとに プライバシーのための プラットフォームの 重要な変更についての 最新アップデートを提供し 最後に Appleの最新プラットフォームの 空間入力モデルが いかにプライバシー保護のために デザインされたかを話します 優れたプライバシーを備えた 素晴らしいアプリの制作に役立つ プライバシー強化のテクノロジーが Appleのプラットフォームで 利用可能になります ここに含まれる一連の新しいAPIにより アプリはコンテンツに シームレスにアクセスでき 一方 ユーザーは共有に関して 詳細の管理ができ サーバやユーザー間の通信を より強力に保護する APIも含まれています まず「写真ピッカー」に 加えられた改善点についてお話しします これは写真へのアクセスへの 障壁をなくすようデザインされました 時間の経過とともに 写真ライブラリも膨大になり そこにキャプチャされた 貴重な瞬間がどんどん増えていき 恥ずかしい子どもの頃の写真から 最近のハイキングの写真まで入っています それゆえに アプリへの信頼を 得るための基本的な方法は いつ どのデータを アプリと共有するのかという 細かい決定を行う力を ユーザーに提供することです もし 誰かが 最近の旅行での 絶景の写真を共有するために あるアプリを使いたいのなら アプリにすべての写真へのアクセスを 許可しなくてもいいはずです これを可能にするのが 「写真ピッカー」です このAPIで アプリは写真ライブラリ 全体へのアクセス許可を リクエストしなくても 選択された写真や動画にアクセスできます iOS 17とmacOS Sonomaでは アプリにピッカーを完全に埋め込めるので シームレスな体験が可能になります 写真はアプリの一部になったように 見えたとしても システムによりレンダーされたものが 選択された時に共有されただけなので ユーザーの写真は常に ユーザーのコントロールにあります 新しいカスタマイズのオプションで ピッカーの表示方法が選べ クローム無しだと このようで あるいは 単列の写真だけで 横にスクロールできるものや あるいは インライン型の フルピッカーで 新しいオプションメニューで 写真のキャプションや 位置情報などの写真のメタデータの共有を コントロールできるようになっています 写真ピッカーは写真を すばやく取得する素晴らしい方法で ライブラリ全体へのアクセス許可を 取得する必要もなく 写真選びのフローをデザインして 実行する必要もありません ライブラリへのフルアクセスを リクエストする代わりに ピッカーを利用して 個別の写真にアクセスしましょう ピッカーの新機能についての 詳細な説明は 「Embed the Photos picker in your app」の動画をご覧ください もしも写真ライブラリへの フルアクセスが必要になるような アプリを開発している場合には iOS 17には再デザインされた 許可ダイアログがあり その中には写真の数と 共有可能なもののサンプルが 含まれています これにより ユーザーが 何を共有するかを 判断しやすくなります 時間とともにユーザーが好む設定が 変わることもあるため システムは定期的に アプリが写真ライブラリに フルアクセスを持つかどうか ユーザーに確認します 次に、Screen Captureピッカーは macOS用ScreenCaptureKitの 新しいAPIで スクリーンが共有されている時 アプリが必要とする ウインドウかスクリーンのみを 共有できるようになり より優れた体験を提供します macOS Sonoma以前はオンラインの ビデオ会議でプレゼンテーションを ユーザーが共有したいと思った場合 設定アプリ経由で 会議アプリに フルスクリーンの録画を 許可しなければならず その結果 共有過多のリスクがある 残念な体験になりかねません 新しい SCContentSharingPicker APIで macOS Sonomaはアプリに代わって ウインドウピッカーを表示し ユーザーは共有したい画面コンテンツを 選ぶことができます macOSは ウインドウや画面が 選ばれるとすぐ 確実に 選ばれた部分のみをシェアします 画面を録画するという 明確なアクションのため アプリはスクリーンキャプチャ セッションの間だけ 選ばれたコンテンツの録画を 許可されます つまり アプリは画面をキャプチャするのに 別途に許可を取る必要もなく 独自の画面コンテンツピッカーを 作成する必要もありません SCContentSharingPickerが すべてやってくれます 常にユーザーが気づけるように macOS Sonomaには新しい画面共有 メニューバーアイテムがあり アプリが画面を録画していることを 知らせる役割を果たしています これで録画したい時だけに 画面コンテンツを録画しているのが わかります クリックすると メニューが拡大され 共有するコンテンツの プレビューを表示します これにより キャプチャセッションに 画面コンテンツを素早く追加したり 削除したり あるいは 全部を終わらせられます SCContentSharingPickerは カスタマイズの オプションも提供していて 好みの選択モードや アプリケーションなどの アプリのニーズに基づいて 調整できるようになっています 詳細については 「What's new in ScreenCaptureKit」をご覧ください カレンダーもアプリの シームレスな体験を可能にしてくれる もう1つのエリアで 特に新イベントを作成するだけの アプリには嬉しい改善です カレンダーでは人々の生活の 詳しい情報が対象になります 例えば 病院の予約や フライト情報などがあるので アプリからアクセス要求が来ると ユーザーは驚いたり 拒否したりすることもあります カレンダーのイベントを 書き込むためのアクセスを 要求しているだけのアプリにとって これではイベント追加に失敗し フラストレーションが溜まり ユーザーがコンサートや 友人の誕生日パーティに行き損ねる こともあるかも知れません このような問題を避けるため カレンダーへのアクセスに関して Appleのプラットフォームに 2つの重要な変更点があります まず アプリが新しいカレンダー イベントを作成するだけなら 嬉しいお知らせです EventKitUIを使えば アプリは何も許可が要りません アプリの外側にEventKitUIビュー コントローラをレンダリングすることで これが可能になり APIや機能性に何も変更はありません 2番目に イベントの作成に 独自のUIを提供したい場合は 新しい追加専用のカレンダー許可があり アプリはカレンダーの他のイベントに アクセスせずにイベントが追加できます これでアプリがカレンダーのコンテンツを 取得するのではないかと ユーザーに心配させずに アプリのイベントを ユーザーの予定に統合することができます もしもアプリがあとになってカレンダーへの フルアクセスが必要になったら アップグレードを一度要求できます このリクエストはユーザーの意図に 結びつけて行いましょう 予期しない時間に聞いたり 予期しない理由で聞いたりすれば 拒否される可能性が生じ アプリの体験を低下させかねません 有意義な目的の記述で なぜアクセスが必要なのか ユーザーに理解してもらいましょう すべてのアプリに書き込み専用の アクセスによる利点を 提供したいなら 2つの重要なポイントを覚えておきましょう アプリがカレンダーのアクセスを 以前に許可されていた場合 iOS 17やmacOS Sonomaへの アップグレードで 書き込み専用許可が デフォルトになります 同様に EventKitの 古いバージョンにリンクしていて アプリがカレンダーへのアクセスを 要求した場合 システムは書き込み専用の アクセスのみを促します この場合 アプリがカレンダーの イベントをフェッチしようとすれば システムは自動的に フルアクセスのための アップグレードをアプリに要求します EventKitやEventKitUIを アプリに統合する方法に関する 詳細情報を知りたい場合は 「Discover Calendar and EventKit」をどうぞ 次は 新しいOblivious HTTPのAPIで クライアントIPアドレスを サーバから隠したり 潜在的にセンシティブな 使用パターンを 通信事業者から隠すのに役立ちます いつ どのアプリを日常的に 使っているかという情報は 人々の生活への深い洞察を提供します データ通信やWi-Fiの通信事業者は 誰がどのサーバに 接続しているのかを観察でき 人々の個人的なアプリの使用状況や 生活のパターンを観察できます 通信業者の中にはその立場を利用して 人々がどのようにみなさんのアプリを 使っているのか知ろうとする 業者がいるかもしれません デートアプリや特定の健康状態に 関するアプリの場合は特に センシティブなケースです IPアドレスはインターネット通信において 重要な要素です ですが IPアドレスを不正利用して 誰かの位置情報やIDを 突き止めることもあります クライアント分析のような アプリに匿名性を保証した機能を- 実装したい場合には IPアドレスが見えてしまうと 負担が増える可能性があります Appleのプラットフォームでは Oblivious HTTP 略してOHTTPをサポートするようになり 「誰」と「何」を切り離すことで デベロッパがユーザーのアプリの 使用状況とIPアドレスを守るのに 大きく役立つようになりました OHTTP は標準化された インターネットプロトコルで 軽いデザインになっていて アプリケーションレイヤーで 暗号化メッセージの代理をし トランザクションサーバの 速いインタラクションを可能にします OHTTPを使うと 通信事業者が観察できるのは リレープロバイダへの接続のみで アプリケーションサーバは見えません このアーキテクチャの土台はリレーで リレーはクライアントのIPアドレスや 宛先サーバ名を知っていますが 暗号化されたコンテンツは何も知りません リレーは常にアプリケーションサーバへの 接続が見えると推測され リレーが取得できる有意義な情報は クライアントIPだけということになります アプリケーションサーバへの 最終的な接続は リレーによって行われます リレーがサードパーティによって 操作される時は どの主体も 送信元IPや宛先IPや コンテンツを フルに見ることはできません これによって 匿名分析のような ユーザーを特定したり追跡したり したくない機能に対して テクニカルな保証を加えることが できるようにもなります OHTTPのサポートで 人々に有意義な影響を与える インターネットでの 強化されたプライバシー保護を 構築するチャンスができました iCloud Private Relayのような サービスは既に OHTTPを活用して 素晴らしいパフォーマンスと 堅固なプライバシー保護を実現しています 例えば Private RelayはOHTTPを すべてのDNSクエリの保護に使っています OHTTPの導入の詳細は ネットワークリレーに関する ビデオをご覧ください OHTTPを採用する際 システムアーキテクチャにおける IPアドレスをどのように置き換えるか 考える必要があります 例えば リアルユーザーを検出する 場合などです プライバシー保護の代替策で IPレピュテーションシステムを 置き換える方法については WWDC22の「Replace CAPTCHAs with Private Access Tokens」を 参照してください DNSクエリの暗号化は アプリの使用状況をネットワークから 守るために必要不可欠な もう一つの点です その方法はWWDC20の「Enable Encrypted DNS」をご覧ください 最後の新ツールは 「コミュニケーションの安全性」と 新しい「センシティブなコンテンツの 分析」フレームワークで オンデバイス処理を活用して アプリを利用する子どもを保護します Appleプラットフォームと みなさんが開発するアプリが 多くの家族にとって 重要な役割を果たすようになりました 子どもたちが製品やサービスを使って デジタル世界を探検し家族や友達と 通信するようになったためです コミュニケーションの安全性は 子どもがヌードを含みそうな写真を 受信したり共有しようとした場合などに 警告を表示し 有用なリソースを提供して 子どもの安全を守るよう 家族を手伝います これらの保護が Appleプラットフォーム全体と みなさんのアプリで適用されるのは 非常に重要なことです この目的のために コミュニケーションの安全性は メッセージ以外にも拡大され センシティブなコンテンツの検出は AirDropでの共有や FaceTimeでのメッセージの送信 電話アプリで連絡先ポスターを 共有する時 そして写真ピッカーでも行われます これらの機能は すべての人に利用可能になっていて 年齢に関係なく センシティブな コンテンツの警告が出されます そして 新しいセンシティブなコンテンツの 分析フレームワークで みなさんもアプリ内のセンシティブな コンテンツを検出できます 同じオンデバイステクノロジーを システム提供のMLモデルと一緒に 活用しているので コンテンツをサーバと 共有する必要はありません このフレームワークを使えば 膨大なMLモデルをトレーニングして アプリに詰め込む面倒もなく センシティブなコンテンツの検出が アプリでも可能になります アプリへの統合は わずか数行のコードで可能です まず最初に SCSensitivityAnalyzerの インスタンスを作成します analysisPolicyの属性をチェックして 分析が必要かどうかや 画像や動画にヌードが 含まれている場合は どのような介入が 示されるべきかを決定します そして 分析したい写真のURLやCGImageで analyzeImageメソッドを呼び出します 動画の分析には 代わりに videoAnalysisメソッドを呼び出します これでハンドラが返されるので 進捗を追跡して 必要ならば分析をキャンセルできます 分析結果を取得するには ハンドラに hasSensitiveContentを呼び出します isSensitiveがtrueであれば 画像もしくは動画は おそらくヌードを含んでいます このような場合は アプリ自体が 介入を提供するべきで 画像や動画のぼかしや 不明瞭にするほかの方法で 介入を行い コンテンツを見るオプションも提供します また 分析ポリシーをチェックして コミュニケーションの安全性か センシティブなコンテンツの警告が 有効になっているかどうかに合わせて 介入を作成しましょう 介入のデザインガイドラインに ついての詳細は Appleのデベロッパ向けの ドキュメントをご確認ください これらが アプリに優れた プライバシー保護を取り込める 新しいAPIです それに加え Appleプラットフォームの 既存の機能にも いくつかのプライバシーの変更があります その中には アプリにあるデータを 保護する新しい方法や Safariや SafariでのApp Extensionの プライバシーの改善点があります まずは macOSのための 新しいプライバシー保護で みなさんのアプリにあるデータを 同じデバイス内にある ほかのアプリから守るために デザインされています デスクトップやドキュメントや ダウンロードフォルダのような ディスクのロケーションには システム管理の許可があります これにより プライベートなデータへの アプリのアクセスをいつ許可するかは 確実に人々が決定します このモデルは人々が直接 取り扱うようなファイルに有効で 例えばプロジェクトの発表や 家計簿のスプレッドシートなどです アプリケーションによっては プライベートなデータを 別のロケーションに保管していて 例えばメッセージアプリは 送受信したメッセージの データベースがありますし 休暇の計画を書き込んだ メモアプリもそうです これらのファイルはしばしば ライブラリフォルダのような 場所に保管されていて Sandbox内のアプリの場合は アプリのデータコンテナに 保管されています macOS Sonomaはユーザーに 誰がデータにアクセスできるかに関して 追加のコントロールを与えます 特にmacOSは 異なるデベロッパの アプリケーションデータコンテナ内の データにアプリがアクセスする前に 必ずユーザーからの 許可が下りることを確認します これはみなさんのアプリに ２つの影響を与えます 1つ目は みなさんのアプリの データの保管場所が システムの管理する データ保管場所の外にある場合 App Sandboxを導入して この新しい保護機能を ユーザーのデータに拡大してください そうすればアプリによって作成された すべてのファイルが保護されます App Sandboxを既に使っているアプリは この新しい保護を自動的に受けます 2つ目は みなさんのアプリが ほかのアプリからのデータにアクセスする場合 許可を求める方法がいくつかあります みなさん側では何の変更もせずに みなさんのアプリが ほかのアプリのデータコンテナのファイルに アクセスする時は macOS Sonomaが許可を求めます アプリが開いている限り その許可は有効のままですが アプリを終了すると許可はリセットされます ほかのアプリのファイルを読もうとするのは 予期されている時のみにしましょう 催促のタイミングが 相手を驚かすような場合や 目的が不明な場合は アプリのアクセスは 拒否されるかもしれません 目的を有意義に説明して なぜアプリがアクセスを求めるのか 理解しやすくしましょう ほかのアプリのファイルへのアクセスに 明示的な許可を得られる 代わりの方法がいくつかあります 個人のファイルやフォルダへの シームレスなアクセスには NSOpenPanelを使いましょう こちらは みなさんのプロセスの 外にあるmacOSファイルピッカーで ユーザーが選択内容を確認すれば みなさんのアプリは 選択したリソースを読んだり 書いたりできます NSOpenPanelは ピッカーで デフォルトとして示される パスを特定させてくれるので 選択するのが一段と簡単になります バックアップユーティリティや ディスク管理ツールは 既にフルディスクアクセスを認められていて アクセス時にさらにプロンプトを 提示することはなく 人々が これらのアプリに すべてのファイルへのアクセスを 許可すると既に選択しているからです それに加え みなさんのチームIDで 署名されたすべてのアプリは チームのほかのアプリコンテナのデータに デフォルトでアクセスでき 許可プロンプトは不要です ですから アプリの前のバージョンから データをインポートするような 新しいアプリをリリースするなら シームレスに行えます ですが もっと厳しいポリシーを 定義すべき インスタンスがあるかもしれません 例えば エディタやブラウザ あるいはシェルのような コードインタープリタを作成するのであれば 自分が開発したメッセージアプリのデータに このアプリがアクセスするための許可を macOSから要求するようにした方が いいかも知れません そうするには アプリのInfo.plistで NSDataAccessSecurityPolicyを特定し デフォルトの同チームポリシーを 明示的なAllowListで置き換えましょう 特定されると リストにあるプロセスや インストーラパッケージは 追加の同意が無くても アプリのデータにアクセスできますが ほかのアプリは引き続き許可が必要となります 「高度なデータ保護」は ユーザーのデータを保護する もう一つの素晴らしい方法です 高度なデータ保護の機能は2022年に追加され iCloudに保管されるデータの大部分に対して エンドツーエンドの暗号化を 有効化する方法を提供しています CloudKitを利用すれば 高度なデータ保護を有効化するたびに アプリによってCloudKitに保管されたデータを エンドツーエンドで 暗号化することができます デベロッパ側では何の変更も不要で 暗号化キーや暗号化操作や 複雑でリスキーなリカバリーフローを 管理できます 高度なデータ保護のプライバシーの利点を ユーザーに提供するには わずかなステップを踏むだけです まず CloudKitスキーマの 全てのフィールドにおいて 必ず暗号化された データタイプを使いましょう その中には デフォルトで CKAssetフィールドがあり CloudKitのほとんどのデータタイプには EncryptedStringのような 暗号化されたバリアントがあります そして encryptedValues APIを使って CloudKitの記録にある データの取得や保管ができます すべての暗号化や復号化の操作は このAPIによって抽象化されるため デベロッパにとって便利です その結果 アプリのデータは 誰かがこの機能を有効にするたびに 高度なデータ保護が提供する セキュリティ侵害防止と プライバシー保護の あらゆる恩恵が受けることになります CloudKitの導入方法については コードサンプルも含めて WWDC21の「What's New in CloudKit」をご覧ください 次は Safariの「プライベートブラウズ」 モードにおける 新しいフィンガープリンティングと トラッキングの防止機能についてです Safariはプライバシーを中心にして デザインされています プライベートブラウズモードは Safariに更なるプライバシー保護を 加えるもので 例えば タブを閉じた時には 閲覧したページや 検索履歴や あるいは オートフィルの情報の記録を 確実にSafariから削除します Safari 17での プライベートブラウズモードは トラッキングとフィンガープリンティング の高度な防止機能を加え Webサイト間での トラッキングを防止する 2つの新しい保護機能が含まれています まず Safariは既知の トラッキングリソースや フィンガープリンティングリソースが ロードされるのを防止します Webサイトデザイナーの方は プライベートブラウズモードでの Webサイトの機能性を 必ずテストしてください ログインのフローや Webサイトからの クロスサイトナビゲーション 画面や音声やグラフィックに関連する ブラウザAPIの使用が テストの焦点です 高度なトラッキング及びフィンガー プリンティング防止機能を使わずに 再読み込みを行なって Webサイトの挙動の変化が 新しい保護機能によるものか どうかを確認してください その方法は macOSの更新ボタンを 右クリックするか iOSのページ設定ボタンを使うか 通常のブラウズモードで Safariをテストするかです あるいはWebインスペクタを開いて JavaScriptコンソールへの 出力を検査することもできます 既知のトラッカーとの接触の結果 ブロックされたネットワークリクエストには 以下で始まるメッセージが表示されます 「Blocked connection to known tracker」 クロスWebサイトトラッキングの もう一つの一般的手法は URLに埋め込まれた特有の識別子で 例えば クエリパラメータの中に 埋め込まれています どこでトラッキングされるかの コントロールをユーザーに与えるための もう一つの新しい保護機能が トラッキングパラメータの削除で ブラウザナビゲーションの一部として リンクをコピーした時に行われます トラッキングパラメータが検出されると SafariはURLの ID識別コンポーネントを剥ぎ取って 識別に関係ない部分はそのまま残します なお 広告のアトリビューションは Webサイト中において 個人のIDを識別しなくても可能です 例えば Private Click Measurementは 広告のアトリビューションのために トラッキングパラメータを使わず プライバシーを保護しています これは プライベートブラウズモードでの ダイレクトレスポンス広告にも 利用可能になり ディスクには何のデータも書き込まれず アトリビューションも単一タブに基づいた 単一のブラウズコンテキストに 制限されています これはプライベートブラウズにおける 一時的なブラウジングやタブの分離という Safariの厳しい 既存モデルに従っています この詳細についてはWWDC21の動画 「Meet privacy-preserving ad attribution」をご確認ください プラットフォームの最後の変更は SafariでのApp Extensionのための 新しい許可モデルです Safari 17で Appleが開拓した Webの機能拡張のための許可モデルが App Extensionにも使えるようになります これでユーザーは みなさんのExtensionが どのWebページにアクセス可能か サイトごとに選ぶことが できるようになります また プライベートブラウズモードで どのExtensionが実行できるかについても ユーザーがコントロールできます このようなExtensionへの変更や Extensionへの許可がどのように サイトごとに許可されるのか その詳細についての動画 「What's new in Safari extensions」を見てください デベロッパ用の新しいツールや プラットフォームの変更の裏にある プライバシー原則は Appleが構築する すべての機能に拡張され 新しい空間コンピューティング プラットフォームの 入力モデルもその中に含まれています このシステムの利用はいたって簡単です 周りを見回して インタラクトしたい物を決めて タップします 新しい許可もなければ デベロッパが余分な作業をする必要もなく アプリが自分の見ている場所を トラッキングする心配もありません その結果 優れたプライバシーを持った 素晴らしいプロダクトになっています 目と手によるコントロールを開発した プライバシーエンジニアリングの アプローチを見てみましょう まず 入力モデルが達成すべき 高レベルなゴールがあります 入力体験は速くて流動的に UI要素を自然に操作できなければ なりません 人々が何を見ているのか リアルタイムのフィードバックを行い あらゆる種類やサイズのUI要素を 自信を持って操作できるようにする 必要があります それに加え 既存のiPhoneや iPadのアプリもそのまま 使えなければなりません 最後に 基本的な入力を アプリが受け取るためだけなら 新しいアプリの許可は 不要でなければなりません 次は 入力モデルのための プライバシーの目標です 健康状態などを含む 目に関するセンシティブな詳細を アプリが学習しないようにするために 関連するシステムコンポーネントだけが アイカメラへのアクセスを 許されるべきです 許可不要のアクセスを有効にするためには アプリは人々の目や手について 詳細を学習せずに 機能できなければなりません 見ている物から人々の考えを 推測できてしまうため 人々が見ている物ではなく 操作対象物のみから学んで アプリが機能できるようにすることが 重要です これらの目標を達成して Appleが作り上げたシステムを 見てみましょう 入力システムのために目と手を測る 内部と外部のカメラデータは 孤立したシステムプロセスで処理されます これで 目と手の位置の測定が 目とピンチジェスチャの 検出システムへと送られ 複雑なカメラプロセスを完全に抽象化し みなさんのアプリを含む ほかのあらゆるシステムから切り離します ホバーフィードバックシステムが スクリーン上にある物と 目の位置を組み合わせて ユーザーが何を見ているのか決定します 見ているのがUI要素の場合は システムはレンダー中に 強調レイヤーを追加します これを行うのは アプリのプロセス外にある レンダリングエンジンで デバイスを使用している人にだけ見えるため アプリに何の情報も開示せずに 見ている物を理解できます ピンチジェスチャが検出されると直ぐに システムは 強調された UI要素のための 通常のタップイベントをアプリに送ります このシステムアーキテクチャで カメラデータを入力イベントに 変換するという複雑な作業が オペレーティングシステムによって 行われます つまり この新プラットフォームでは 入力を受けるのに 何も変更が必要ないということです デフォルトのシステム動作に加え UIKitやSwiftUIやRealityKitで アプリのデザインに適したエフェクトに 調整しやすくなり 同時にシステムが提供するUI要素と同じ プライバシー保護を提供できます タイプや形状 そして どの要素にホバーエフェクトを 適用したいのかについて 変更することもできます その導入についての詳細は 「Meet SwiftUI for spatial computing」と 「Elevate your windowed app for spatial computing」をご覧ください この空間入力モデルが実現したのは プライバシーの柱を実行したからです システムの各コンポーネントが アクセスする必要のあるデータ量を システムが最小化します プロセスはすべてデバイス上で行われます 意図的なインタラクションのみが アプリと共有されるので コントロールは人々が行います OSのカーネルが強制する プロセスの分離を使用するため 見ている場所は保護されています プライバシーをデザインにおける 中核の目標にすることで 素晴らしい機能と 優れたプライバシーは 同時に実現できるのです Appleプラットフォームにおける 新しいプライバシー変更が みなさんの参考になれば幸いです 素晴らしいプライバシーを通して 信頼を築くことが 一層 容易になりました シームレスなユーザーコントロールを 提供するコンテンツピッキングAPIで アプリがアクセスするデータ量を 最小化しましょう オンデバイス処理と一緒に センシティブなコンテンツの 分析フレームワークを アプリに導入して子どもたちを守りましょう アプリ内のユーザーのデータ保護のために macOSでのApp Sandboxのような セキュリティ保護を導入して 必ずCloudKitのデータを暗号化しましょう ご視聴ありがとうございました 今後のみなさんの制作を楽しみにしています ♪