ハイライト
iOS 16 と macOS Ventura は、デバイス名、場所、ゲートキーパー、ログイン項目、クリップボードへのアクセスを強化するとともに、UIKit 貼り付けコントロール、DeviceDiscoveryExtension、PHPicker、プライベート アクセス トークン、パスキー、安全性チェックを追加して、開発者がデータの露出を減らし、ユーザーに明確な制御を提供できるようにします。
主要内容
多くのプライバシー問題は 1 つの詳細から生じています。小さな機能を完了するために、アプリは機能自体よりも多くのデータを取得します。
たとえば、アプリはユーザーに画面キャスト デバイスのみを選択させたいと考えていますが、最初にローカル ネットワークの許可と Bluetooth の許可を適用します。アプリは確認コードを貼り付けるだけですが、クリップボードを直接読み取ります。アプリはマルチデバイス リストに現在のデバイスを表示したいだけですが、ユーザーの名前を含むデバイス名を取得します。
iOS 16 と macOS Ventura の主な変更点は、これらの境界を強化することです。システムがデフォルトで提供するデータは少ないため、ユーザーは必要に応じて明確な選択を行うことができ、開発者は機能を完了するために使用する API の範囲が狭くなります。
このセッションは、プラットフォームの動作の変更、提案された新しいプライバシー機能、ユーザーの安全シナリオの安全性チェックの 3 つのカテゴリに分類できます。これは移行チェックリストに似ています。どの古い慣行がプロンプトをトリガーしたり、制限されたりするのか、どの新しい API がスムーズなエクスペリエンスを維持するのか、ということです。
詳細
デバイス名:UIDevice.nameユーザー定義名はデフォルトでは公開されなくなりました
(03:00) iOS 16 より前は、UIDevice.nameユーザーがデバイスに付けた名前を返すことができます。この名前には、「誰々の iPhone」など、ユーザーの名前が含まれることがよくあります。
iOS16からは、UIDevice.nameデフォルトでは、ユーザー定義名の代わりにデバイス モデルが返されます。マルチデバイスエクスペリエンスを本当に必要とするアプリのみが適用できますcom.apple.developer.device-information.user-assigned-device-name権利。権利を取得した場合でも、デバイス名をクラウド ホスティング プロバイダー以外の第三者と共有することはできません。
// 概念例:iOS 16 以降はデフォルトでデバイスモデルを取得するため、ここにユーザー名が含まれると仮定しないでください。
let displayName = UIDevice.current.name
// UI 表示に使う場合は、ユーザーの身元ではなくデバイスラベルとして扱います。
deviceLabel.text = displayName
キーポイント:
UIDevice.current.nameトランスクリプトで明示的に言及されている API です。- iOS 16 以降、デフォルト値はデバイスのモデルに近くなります。 ・製品ロジックが「ユーザーがデバイスに付けた名前」に依存している場合は、エンタイトルメントの適用条件を満たしているかを再評価する必要があります。
- このコードは読み取り結果の使用方法を表現することしかできず、システムの制限を回避することはできません。
ゲートキーパー: 公証されたアプリは署名をそのまま保持する必要もあります
(04:32) macOS Ventura では、Gatekeeper は、隔離マークが付けられた新しくダウンロードされたアプリだけをチェックするのではなく、公証されたすべてのアプリの整合性をチェックします。
これはアップデーターに大きな影響を与えます。このスピーチでは、アプリの実行可能ファイルとバンドルは正しく署名されなければならないことが明確になりました。署名は更新後も有効なままでなければなりません。同じ開発チームによって署名されたアプリは引き続き相互に更新できます。別のチームのプロセスによるアプリの更新を許可する必要がある場合は、Info.plist で宣言できます。NSUpdateSecurityPolicy。
<!-- 概念例:講演で説明された NSUpdateSecurityPolicy 構造に基づき、許可する updater を表現します。 -->
<key>NSUpdateSecurityPolicy</key>
<dict>
<key>AllowProcesses</key>
<dict>
<key>TEAMID12345</key>
<array>
<string>com.example.pal.about</string>
</array>
</dict>
</dict>
キーポイント:
NSUpdateSecurityPolicymacOS Ventura で更新ポリシーを宣言するために使用される Info.plist キーです。 -AllowProcessesは辞書、キーはチーム識別子です。- 署名識別子を配列に入れて、アプリを変更できるプロセスを制限します。
- 変更が同じチームに属しておらず、ポリシーに含まれていない場合、macOS は変更をブロックし、ユーザーに通知します。
ログイン項目: バックグラウンドを開始し、ユーザーに表示される管理パネルに入ります。
(07:07) macOS Monterey 以前のバージョンでは、アプリは起動エージェント、デーモン、SMLoginItems、およびその他のメカニズムを通じてログイン時に実行できます。ユーザーは多くの場合、どのバックグラウンド項目がデータやセンサーにアクセスしているのかを知りません。
macOS Ventura は、これらのエントリをシステム設定のログイン項目パネルにマージします。講演では、開発者が新しい単一の API を使用してアプリを起動したり、エージェントやデーモンを起動したりできると述べました。バックグラウンド項目はデフォルトで開始できますが、ユーザーは通知を受け取ります。昇格した特権を必要とするデーモンには管理者の承認も必要です。
// 概念例:講演では SMAppService API でログイン起動を管理することだけが説明され、完全な呼び出しシグネチャは示されていません。
// 実際のプロジェクトでは ServiceManagement のドキュメントを基準にしてください。
import ServiceManagement
// アプリ内でログイン項目を一元管理し、ユーザーにシステム通知を表示し、Settings で提供元を確認できるようにします。
let serviceAPI = "SMAppService"
キーポイント:
SMAppServiceトランスクリプトで明示的に言及されている新しい API 名です。- エージェントとデーモンはアプリ バンドルに配置する必要があります。講演では、これにはインストーラーが起動エージェントを作成する必要も、クリーンアップ スクリプトも必要ないことが指摘されました。
- 通知のタイミングと設定に表示されるアプリアイコンの制御を容易にするために、通話入口はアプリ内に配置する必要があります。
- この段落は概念的な例です。スピーチでは特定の Swift メソッドの署名が与えられていないため、直接コピーできる登録コードは記述されません。
クリップボード: 直接読み取りUIPasteboard意図確認をトリガーします
(09:24) iOS 16 では、他のアプリによって書き込まれたクリップボード コンテンツのインテント確認が追加されています。使い続けるUIPasteboard直接読み取る場合、システムはモーダルプロンプトを表示します。
ユーザーが編集メニューまたはキーボード ショートカットを使用して貼り付けを開始した場合、システムはすでにその意図を確認できます。 3 番目の方法は、UIKit ペースト コントロールを使用することです。ユーザーが表示されている貼り付けボタンをクリックすると、システムはそのボタンが実際に表示されてクリックされたことを確認し、追加のポップアップ ウィンドウを表示せずに貼り付けを許可します。
// 概念例:ユーザーが意図を示していないときにクリップボードを能動的に読み取ることを避けます。
// 従来の方法では、システム確認が発生しやすくなります。
let pastedText = UIPasteboard.general.string
// iOS 16 で推奨される方向性は UIKit paste controls を使い、
// ユーザーが表示されているボタンで貼り付け意図を示せるようにすることです。
let recommendedControl = "UIKit paste controls"
キーポイント:
UIPasteboardこれは、講演で言及されたプロンプトをトリガーする従来のアクセス方法です。- UIKit ペースト コントロールは、ユーザーが積極的にボタンをクリックするアクションをペーストします。
- ボタンは角丸、文字色、アイコン色、背景色を調整できます。
- ボタンは他の要素の後ろに隠れることはできず、十分なコントラストがなければなりません。そうしないと、システムはインタラクションを認識できません。
メディア デバイスの検出: アプリはユーザーが選択したデバイスのみを取得します
(11:19) これまで、メディア アプリは、画面キャスト デバイスを検出するためにローカル ネットワークと Bluetooth の許可を申請する必要がよくありました。問題は、デバイスを選択するために、アプリが最初にネットワーク全体のデバイスのリストを参照するため、フィンガープリンティングのリスクが生じることです。
メディア デバイスの検出によりデータ フローが変わります。DeviceDiscoveryExtensionローカル ネットワークと Bluetooth デバイスをスキャンできますが、アプリとは別のサンドボックスで実行され、スキャン結果をアプリに直接送信することはできません。検出されたデバイスが入りますDeviceDiscoveryExtensionフレームワークによって表示されるピッカー。ユーザーがそれを選択すると、システムは選択したデバイスとのみ通信を開始します。
// 概念例:講演で示された統合手順であり、完全なコードではありません。
let extensionPoint = "DeviceDiscoveryExtension"
let routePicker = "AVRoutePickerView"
// Protocol provider: DeviceDiscoveryExtension を作成します。
// App developer: AVRoutePickerView の選択コールバックで、ユーザーが選んだデバイスを処理します。
キーポイント:
DeviceDiscoveryExtensionデバイスの検出を担当しますが、完全なスキャン結果をアプリに渡すことはできません。 -AVRoutePickerView講演の中で言及されたユーザー選択ポータルです。- アプリは、ローカル ネットワークや Bluetooth 環境全体ではなく、ユーザーが選択したデバイスのみを取得します。
- サードパーティのストリーミング プロトコルを使用するアプリの場合、スピーチでは、プロトコル プロバイダーに連絡して、対応する拡張機能を実装することを推奨しています。
PHPicker、プライベート アクセス トークンおよびパスキー: 取得するデータを減らしてコア プロセスを完了する
(13:48) この講演では、PHPicker とメディア デバイスの検出を同一線上に置き、ユーザーが選択したオブジェクトのみを許可します。 PHPicker は macOS Ventura および watchOS 9 で利用でき、Mac および watch アプリはすべての写真に対する許可をリクエストすることなく、ユーザーが選択した写真にアクセスできます。
(14:17) プライベート アクセス トークンは、ブラインド トークンを使用して、サーバーが特定のデバイスの追跡を回避しながら正当なデバイスを識別できるようにします。 Apple は、デバイスがどの Web サイトのトークンを取得したかを知りません。また、サーバーもトークンを送信したデバイスの ID を知りません。これは、Privacy Pass IETF オープン標準に属しており、プライベート リレーのユーザーの信頼性検証に使用されます。
(15:08) パスキーはパスワードを公開キー暗号化に置き換えます。公開鍵はサーバーに保存されており、たとえ漏洩してもログイン可能なシークレットにはなりません。パスキーは対応する Web サイトにバインドされているため、フィッシングに対して耐性があります。
概念フロー:Private Access Tokens
1. Website or API server needs confidence that a request is legitimate.
2. Device obtains a blinded token through the system mechanism.
3. Server receives a token that proves legitimacy.
4. Server does not learn the device identity from that token.
キーポイント:
- これは概念的なフローであり、この話では HTTP フィールドやサーバー側のコードは示されていません。
- 「正当なデバイス」と「デバイス ID を公開しない」は、プライベート アクセス トークンの中核となる境界です。
- さらなる実装では、別のセッションを検討する必要があります。CAPTCHA をプライベート アクセス トークンに置き換えます。
- パスキーの実装の詳細についても、別のセッションで説明します。ここでは、プライバシーとセキュリティに関する動機のみを紹介します。
安全性チェック: ユーザーは人やアプリへのアクセスを一元的に取り消すことができます
(16:18) Safety Check は、家庭内または親密なパートナーの暴力リスク シナリオ向けの iOS 16 プライバシー ツールです。 「現在地を探す」、「写真」、「メモ」、「カレンダー」などの他のユーザーとの共有が停止される場合があります。サードパーティ製アプリのシステムプライバシー権限をリセットすることもできます。
安全検査には入り口が 2 つあります。緊急リセットは危機シナリオで使用され、全員とすべてのアプリのアクセスを迅速にリセットし、他のデバイスが FaceTime や iMessage を受信できないように制限します。共有とアクセスの管理はより詳細で、個人またはアプリごとに共有コンテンツを確認できます。すべてのプロセスにはクイック終了機能があるため、ユーザーはすぐに終了してホーム画面に戻ることができます。
概念リスト:Safety Check が影響するアクセス
- Location sharing in Find My
- Photos, Notes, Calendar sharing
- System privacy permissions for third-party apps
- FaceTime and iMessage on other iCloud devices
- Trusted devices, passwords, emergency contacts
キーポイント:
- 安全性チェックはユーザーレベルのシステム機能であり、音声ではアプリが API にアクセスする必要はありません。
- アプリが位置情報や写真へのアクセスなどの永続的な権限に依存している場合は、ユーザーが一元的にエクスペリエンスを取り消すことができるように準備してください。
- アプリは、権限が永続的であると想定するのではなく、権限が期限切れになったときに明確な回復パスを提供する必要があります。
- Quick Exit では、プライバシーの設計では現実世界のセキュリティのプレッシャーも考慮していると説明しています。
重要ポイント
-
低干渉の検証コード貼り付け入り口を作成: ログイン ページで入力された検証コードを UIKit 貼り付けコントロールと組み合わせます。実行する価値がある理由: iOS 16 では、他のアプリによって書き込まれたクリップボードを直接読み取るための意図確認が行われます。開始方法: クリップボードの自動読み込みを、ユーザーがクリックする貼り付けコントロールに変更し、ボタンの可視性とコントラストをテストします。
-
Mac App アップデーターの署名と更新ポリシー チェックを完了する: 公開する前にすべての実行可能ファイルとバンドルの署名を検証し、チーム間アップデーターの存在を整理します。実行する価値がある理由: macOS Ventura の Gatekeeper は、公証されたアプリの整合性をチェックします。開始方法: App Bundle を変更するすべてのプロセスをリストし、必要に応じて Info.plist に追加します。
NSUpdateSecurityPolicy。 -
バックグラウンド ログイン項目をユーザーに表示される管理モデルに移行: ServiceManagement を使用する
SMAppService方向管理ログインの起動項目。実行する価値がある理由: macOS Ventura では、エージェント、デーモン、SMLoginItem などが [ログイン項目] パネルに表示されます。開始方法: エージェントまたはデーモンをアプリ バンドルに配置し、アプリ内でアクティブ化時間を制御します。 -
メディア キャスト前の許可リクエストを削減: ローカル デバイスを検出する必要があるストリーミング プロトコルの場合は、DeviceDiscoveryExtension を評価します。価値がある理由: アプリは、デバイスを選択するためにローカル ネットワーク全体や Bluetooth 環境を確認する必要がなくなりました。開始方法: プロトコル プロバイダーに拡張機能を実装させ、アプリ側で処理させます。
AVRoutePickerViewユーザーの選択。 -
通常のパスとして権限の取り消しをテスト: 位置情報、写真、カレンダーなどの機密性の高い権限に対して無効化されたインターフェイスを設計します。実行する価値がある理由: セーフティ チェックは、サードパーティ アプリに対するシステムのプライバシー許可を一元的に取り消すことができます。開始方法: テスト プロセス中に権限の取り消しをシミュレートし、アプリが現在の状態を解釈してユーザーを再承認できることを確認します。
関連セッション
- CAPTCHA をプライベート アクセス トークンで置き換える — プライベート アクセス トークンで CAPTCHA を置き換え、デバイス ID をサーバーによる追跡から保護する方法について詳しく説明します。
- アプリとサーバーの DNS セキュリティを向上する - ネットワーク層のプライバシーとセキュリティを補足し、DNSSEC と DDR がドメイン名解決をどのように保護するかを説明します。
- ローカル認証フローの合理化 — LocalAuthentication がアプリ内の機密リソースを保護する方法を拡張し、パスキーや権限制御と併せて理解するのに適しています。
- 管理対象デバイスの証明書の検出 - エンタープライズ デバイスの信頼性の観点から拡張され、サーバーが管理対象デバイスの信頼性を検証する方法について説明します。
コメント
GitHub Issues · utterances