WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
What’s new in privacy

What’s new in privacy

Privacy & Security
观看原视频

Highlight

iOS 16 和 macOS Ventura 收紧设备名、位置、Gatekeeper、登录项和剪贴板访问，同时新增 UIKit paste controls、DeviceDiscoveryExtension、PHPicker、Private Access Tokens、Passkeys 和 Safety Check，帮助开发者减少数据暴露并给用户更明确的控制权。

核心内容

很多隐私问题来自一个细节：App 为了完成一个小功能，拿到了比功能本身更多的数据。

比如，App 只想让用户选择一台投屏设备，却先申请本地网络权限和蓝牙权限；App 只想粘贴一段验证码，却直接读取剪贴板；App 只想在多设备列表里显示当前设备，却拿到了包含用户姓名的设备名。

iOS 16 和 macOS Ventura 的变化，主线就是把这些边界收紧。系统默认少给数据，必要时让用户做明确选择，开发者则使用更小范围的 API 完成功能。

这场 session 可以分成三类内容：平台行为变化、建议采用的新隐私能力、以及面向用户安全场景的 Safety Check。它更像一张迁移清单：哪些旧做法会触发提示或被限制，哪些新 API 能让体验保持顺滑。

详细内容

设备名：UIDevice.name 不再默认暴露用户自定义名称

（03:00）在 iOS 16 之前，UIDevice.name 可以返回用户给设备起的名字。这个名字常常包含用户姓名，例如“某某的 iPhone”。

从 iOS 16 开始，UIDevice.name 默认返回设备型号，而不是用户自定义名称。只有确实需要多设备体验的 App，才可以申请 com.apple.developer.device-information.user-assigned-device-name entitlement。即使获得 entitlement，也不能把设备名分享给云托管服务提供方以外的第三方。

// 概念示例：iOS 16 之后默认拿到设备型号，不应假设这里包含用户姓名。
let displayName = UIDevice.current.name

// 用于界面展示时，把它当作设备标签，而不是用户身份。
deviceLabel.text = displayName

关键点：

  • UIDevice.current.name 是 transcript 中明确提到的 API。
  • iOS 16 后，默认值会更接近设备型号。
  • 如果产品逻辑依赖“用户给设备起的名字”，需要重新评估是否符合 entitlement 的申请条件。
  • 这段代码只能表达读取结果的使用方式，不能绕过系统限制。

Gatekeeper：notarized App 也要保持签名完整

（04:32）macOS Ventura 中，Gatekeeper 会检查所有 notarized apps 的完整性，不再只检查带 quarantine 标记的新下载 App。

这对更新器影响很大。演讲明确说：App 的 executable 和 bundle 都要正确签名；更新后签名也要保持有效。由同一开发团队签名的 App 仍然可以互相更新。如果需要允许另一个团队的进程更新你的 App，可以在 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>

关键点：

  • NSUpdateSecurityPolicy 是 macOS Ventura 中用于声明更新策略的 Info.plist 键。
  • AllowProcesses 是一个字典，key 是 team identifier。
  • 数组中放 signing identifier，用来限制哪些进程可以修改 App。
  • 如果修改行为不属于同一团队，也不在 policy 中，macOS 会阻止修改并通知用户。

登录项：后台启动统一进入用户可见的管理面板

（07:07）macOS Monterey 及更早版本里，App 可以通过 launch agents、daemons、SMLoginItems 等机制在登录时运行。用户经常不知道哪些后台项正在访问数据或传感器。

macOS Ventura 把这些入口合并到 System Settings 的 Login Items 面板里。演讲提到，开发者可以用新的单一 API 启动 App、launch agent 或 daemon。后台项默认可以启动，但用户会收到通知；需要提升权限的 daemon 还需要管理员批准。

// 概念示例：演讲只说明使用 SMAppService API 管理登录启动，未给出完整调用签名。
// 实际项目应以 ServiceManagement 文档为准。
import ServiceManagement

// 在 App 内集中管理登录项，让用户收到系统通知，并在 Settings 中看到来源。
let serviceAPI = "SMAppService"

关键点：

  • SMAppService 是 transcript 中明确提到的新 API 名称。
  • agents 和 daemons 应放在 App bundle 内，演讲指出这样不需要 installer 写入 launch agent，也不需要清理脚本。
  • 调用入口应放在 App 内，便于控制通知出现的时机和 Settings 中显示的 App 图标。
  • 这段是概念示例；演讲没有给出具体 Swift 方法签名，所以不编写可直接复制的注册代码。

剪贴板：直接读 UIPasteboard 会触发意图确认

（09:24）iOS 16 对其他 App 写入的剪贴板内容增加了意图确认。继续用 UIPasteboard 直接读取时，系统会显示 modal prompt。

如果用户是通过 edit menu 或键盘快捷键发起粘贴，系统已经能确认意图。第三种方式是采用 UIKit paste controls。用户点击可见的粘贴按钮后，系统确认这个按钮确实显示并被点击，然后允许粘贴，不需要额外弹窗。

// 概念示例：避免在用户没有表达意图时主动读取剪贴板。
// 旧做法会更容易触发系统确认。
let pastedText = UIPasteboard.general.string

// iOS 16 的推荐方向是使用 UIKit paste controls，
// 让用户通过可见按钮表达粘贴意图。
let recommendedControl = "UIKit paste controls"

关键点：

  • UIPasteboard 是演讲中提到会触发提示的 legacy 访问方式。
  • UIKit paste controls 让粘贴变成用户主动点击按钮的动作。
  • 按钮可以调整圆角、文字颜色、图标颜色和背景色。
  • 按钮不能隐藏在其他元素后面，并且要有足够对比度，否则系统不会认可这次交互。

媒体设备发现：App 只拿到用户选择的设备

（11:19）过去，媒体 App 为了发现投屏设备，常常要申请本地网络和蓝牙权限。问题在于，App 为了选择一个设备，先看到了整个网络中的设备列表，这会带来 fingerprinting 风险。

Media device discovery 改变了数据流。DeviceDiscoveryExtension 可以扫描本地网络和蓝牙设备，但它与 App 分开沙盒运行，不能把扫描结果直接回传给 App。发现的设备进入 DeviceDiscoveryExtension framework 展示的 picker。用户选择之后，系统只打开与被选设备的通信。

// 概念示例：演讲给出的集成步骤，而不是完整代码。
let extensionPoint = "DeviceDiscoveryExtension"
let routePicker = "AVRoutePickerView"

// Protocol provider: 创建 DeviceDiscoveryExtension。
// App developer: 在 AVRoutePickerView 的选择回调中处理用户选中的设备。

关键点：

  • DeviceDiscoveryExtension 负责发现设备，但不能把完整扫描结果交给 App。
  • AVRoutePickerView 是演讲提到的用户选择入口。
  • App 只获得用户选中的设备，而不是整个本地网络和蓝牙环境。
  • 对于使用第三方 streaming protocol 的 App，演讲建议联系 protocol provider 实现对应扩展。

PHPicker、Private Access Tokens 和 Passkeys：少拿数据，也能完成核心流程

（13:48）演讲把 PHPicker 和媒体设备发现放在同一条线上：只授予用户选择的对象。PHPicker 在 macOS Ventura 和 watchOS 9 上可用，Mac 和 watch App 可以访问用户选择的照片，而不必申请所有照片权限。

（14:17）Private Access Tokens 用 blinded tokens 帮服务器识别合法设备，同时避免追踪具体设备。Apple 不知道设备为哪些网站获取 token，服务器也不知道发送 token 的设备身份。它属于 Privacy Pass IETF open standard，并用于 Private Relay 用户真实性验证。

（15:08）Passkeys 用公钥密码学替代密码。服务器保存的是公钥，泄露后也不会变成可登录的秘密。Passkeys 绑定到对应网站，所以能抵抗 phishing。

概念流程：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 字段或服务端代码。
  • “legitimate device”和“不暴露设备身份”是 Private Access Tokens 的核心边界。
  • 进一步实现应看单独的 session：Replace CAPTCHAs with Private Access Tokens。
  • Passkeys 的实现细节也在单独 session 中展开，这里只介绍隐私与安全动机。

Safety Check：用户可以集中撤销人和 App 的访问

（16:18）Safety Check 是 iOS 16 面向家庭或亲密伴侣暴力风险场景的隐私工具。它可以停止与人的共享，例如 Find My 位置共享、Photos、Notes 和 Calendar；也可以重置第三方 App 的系统隐私权限。

Safety Check 有两个入口。Emergency Reset 用于危机场景，快速跨所有人和所有 App 重置访问，并限制其他设备接收 FaceTime 和 iMessage。Manage Sharing & Access 更细，可以按人或按 App 检查共享内容。所有流程都有 Quick Exit，用户可以快速离开并回到主屏幕。

概念清单：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

关键点：

  • Safety Check 是用户级系统功能，演讲没有要求 App 接入某个 API。
  • 如果 App 依赖持续权限，例如位置或照片访问，要准备好权限被用户集中撤销后的体验。
  • App 应在权限失效时提供清晰恢复路径，而不是假设授权会永久存在。
  • Quick Exit 说明隐私设计还要考虑真实世界中的安全压力。

核心启发

  • 做一个低干扰验证码粘贴入口：把登录页的验证码输入和 UIKit paste controls 配合起来。为什么值得做：iOS 16 会对直接读取其他 App 写入的剪贴板做意图确认。怎么开始：把自动读取剪贴板改成用户点击的粘贴控件，并测试按钮可见性和对比度。

  • 为 Mac App 更新器补齐签名和更新策略检查：在发布前验证所有 executable 和 bundle 的签名，并梳理是否存在跨团队 updater。为什么值得做：macOS Ventura 的 Gatekeeper 会检查 notarized apps 的完整性。怎么开始：列出所有修改 App bundle 的进程，必要时在 Info.plist 中添加 NSUpdateSecurityPolicy。

  • 把后台登录项迁移到用户可见的管理模型：用 ServiceManagement 的 SMAppService 方向管理登录启动项。为什么值得做：macOS Ventura 会把 agents、daemons、SMLoginItems 等集中显示在 Login Items 面板。怎么开始：把 agent 或 daemon 放进 App bundle，并在 App 内控制启用时机。

  • 减少媒体投屏前的权限请求：对需要发现本地设备的 streaming protocol，评估 DeviceDiscoveryExtension。为什么值得做：App 不再需要为了选择一台设备而看到整个本地网络或蓝牙环境。怎么开始：让 protocol provider 实现扩展，并在 App 侧处理 AVRoutePickerView 的用户选择。

  • 把权限撤销当作常规路径测试：为位置、照片、日历等敏感权限设计失效后的界面。为什么值得做：Safety Check 可以集中撤销第三方 App 的系统隐私权限。怎么开始：在测试流程中模拟权限被撤销，确认 App 能解释当前状态并引导用户重新授权。

关联 Session

评论

GitHub Issues · utterances