隐私保护与您的 App

隐私安全和App

大家好 我是姬蒂·斯金纳 今天下午我将要和傑森·諾瓦克 一起谈论一下 关于你们app中隐私安全的问题

我们都是苹果产品 安全及隐私团队中的成员

这意味着我们需要 和苹果公司里所有的团队打交道 来在我们的app 和服务中实现隐私安全

在工作中和我联系最紧密的团队包括 Apple Pay,Siri,Proactive Assistant,Health

以及我们最新发布的操作系统 watch OS

首先我想讲一点关于隐私安全的 意义以及我们是如何看待它的

在苹果我们把隐私 视作人的一项基本权利 这也是我们每天工作的首要原则 当我们在设计app 服务以及发行新版本 也就是IOS, OSX, watch OS的时候 我们会牢记这一点

用户希望当他们使用我们的产品时 他们的隐私得到尊重而对所有的开发者 在座的每一个人来说 这是我们的共同责任

所以当你们在开发app时 要留心对用户隐私的保护 并将其在你们的app中实现

在苹果我们不仅致力于做出伟大的产品 也致力于做出伟大的工具 面向开发团队为你们提供更多的便利 让你们尊重用户隐私并在 你们的app和服务中实现隐私安全

到目前为止我们所有的成功 都依赖于我们和用户之间的良好关系

而信任是维系这段关系的关键

我们都看过一些 关于违背隐私安全 泄露用户信息的新闻 在座的各位都不想看到这种事情发生 不希望苹果成为下一个此类新闻的焦点

我们提供了这样一个平台 让用户为新的体验感到兴奋 兴奋于下载新的app

这些使得我们的app 生态系统得以运转 并且繁荣而用户对 你们的信赖是其中重要的一环

所以我们要值得让用户信赖

如今用户因信任而提供了许多敏感数据

我们要成为优秀的数据管家 隐私安全的构建是个好的入手点

现在所有的数据都需要一份保存策略 你们对此有什么好的想法吗？ 我们可以从如何使用这些数据入手

对于一些你们再也用不到的数据 不会再用它们来为用户提供服务 那就应该把它们删掉

对于你存储的所有数据而言 你存储的数据越多 你对攻击者就越具有吸引力 就越有价值

所以要做到只保存你们需要的数据

我认为我们收集到的 所有数据都具有风险

所以你需要在为用户提供的价值 和收集与存储数据本身存 在的风险之间做出权衡

现在你可以通过把数据减到 最少的技术来降低这种风险

为了学习这类技术以及具体应用的事例 你们可以找找去年的WWDC演讲 看一下IOS和OS X中的 用户隐私安全部分

如数据聚合 分辨率降低 这些都是减轻持有数据的风险的方法

但具体你应该选择哪种方法呢？

为了回答这个问题 我们可以从数据的用途入手 你将用这些数据来做些什么？ 你想解决一些什么问题？ 它们可以辅助做出什么决策？

如果你回答不出以上问题 你就什么都想不出来 那么保存这些数据对你一点用都没有 那可以使用列表中的 最后一项技术数据最小化 你根本就不需要收集和传输这些数据

如果你觉得可以用这些数据来做些什么 那么在转出过程中 所有数据都应该得到保护

一会儿傑森将要讲讲关于 app传输安全的问题 这是我们在IOS 9中 采用的一个新方法 来改进服务过程中的安全传输

为了降低风险 尽可能地避免在设备中输出数据 尤其是对于敏感的数据类别 更要慎之又慎 这包括一些像健康情况的数据

举个例子在 cycling Workout中 我们可以得到一些 诸如用户的心率和运动距离的数据 而用户的身高 体重和校正数据 都可能在配对设备中获取 可以计算出在运动过程中 卡路里消耗的情况

这些数据都不会反馈到 服务器中处理分析

现在我们不仅需要 在传输过程中保护数据 在存储过程中也是一样

首先考虑一下是否需要存储这些数据？

是否只是需要短期保存？ 能不能只在内存中存储呢？ 或者说它需要被写进盘里吗？

IOS和watch OS 平台受益于数据保护 我将一会儿再谈论这个

如果你在服务端存储数据 要保证在空闲时段能对数据加密 使用CloudKit我们就 能很容易得实现这一点

思考一下在你的数据传输 和存储时应该用什么样的标识符呢 一会儿傑森将会深入介绍一下 如何选择合适的标识符的问题

现在你需要让用户明白 你将用你的这些数据 这些来源于用户的数据做些什么 你将如何使用它们 如果你将要和第三方分享数据 这些都需要保持透明 要确保用户可以理解你在做什么

避免用户产生任何的恐慌

这里有一种好的解决方式 让用户明白他们的数据 是如何被收集和存储的 那就是给用户检查他们数据的权利

而且在你收集数据的时候 或者说当你提供给用户选择权时 你希望通过透露一些信息 来帮助用户做出更好的选择 你可以通过采用目的字符串等解决方案 当用户在考虑他们是否要给你们 提供照片等信息的权限的同时

你也希望用户能掌握主控权 要给他们更改决定的权利 如果稍后他们的决定变得和先前不同 那时要给他们一个机会 对你已经存储的信息进行重置甚至删除

现在我要谈一些关于我们的平台 在提高用户隐私安全 方面做出的一些更新

我想讲一下在IOS,OS X 平台中发生的一些改变 还有一些在watch OS 平台中的基础的东西

首先说到IOS平台的发展 我们可以追溯到去年 在去年我们开始配置加密的MAC地址 来应对几种特定的wifi扫描方式

在ios 9平台里 我们增加了扫描方式的数目 对其MAC地址进行加密 值得注意的是 如果你的功能是基于外设的 一定要先在IOS 9中 对MAC地址做测试确认 因为在正式使用之前 你不能保证MAC地址的可用性

简单来说我们认为想在手机上 安什么软件是由用户决定的

用户可以用他们的手机做许多事 他们也有各种各样的理由 来安装自己喜欢的app 健康养生 金融理财 居家生活等 不胜枚举

就目前来说用户安装了哪些app 以及那些app从用户身上获取了些 什么信息已经变成了非常敏感的事

所以要尝试着检测出 用户安装了什么app 通过直接进行识别 或者收集相关信息来辅助判断 来找出一些违反IOS的 安全模型的内容

最终IOS安全系统会对确定 出来的app进行建模分析

它们仅在自己的沙箱中存活 这可以保护它们不被 其他的app和进程侵害

尝试确定用户在手机上安装了什么app 是IOS安全模型的一项颠覆性成果

现在与之相伴的是 canOpenURL今年也在改变

canOpenURL存在的意义 是为了确认一个app 能否打开指定的URL资源

这可以为一些功能提供支持 比如当手机里安装一个新的app时 它会提示用户可以实现 一些什么新的操作

有两个新方向你们可以了解一下 菜单和通用链接 他们支持一些和URL方案相同的功能 我希望你们可以多关注一下那些方面 但是如果你想继续使用URL方案 在IOS 9里开发你的app 并且想要调用URL方案 你需要知道的是你得先在app中的 Info.plist文件中声明它们 这里有个新增索引键叫 LSApplicationQueriesSchemes 在这里你需要把canOpenURL 添加进方案列表

现在你不用改变对 canOpenURL的调用方式 当前API也不会发生改变 但是一旦你调用了 canOpenURL 它就会检查你app中的 Info.plist文件 看看你所调用的方案是否已经被声明

所以说你需要先对其进行声明 当你在那个方案中调用 canOpenURL时 如果安装的app支持这个方案 那么返回值为真

如果并没有安装任何app 那么返回值为无

所以如果你没有声明URL方案 会发生些什么呢 不管这里是否有一个支持它的app 你收到的返回值始终为无

所以对于那些在IOS 9 之前版本被链接 以及在IOS 9中运行的app来说 只给它们50个独立的URL方案

一旦你连续调用到第51个方案的时候 你将会收到的返回值为无

即使当用户重启手机的时候 这50个URL方案也不会被重启

我之前提到的今年新出的 一种可替代方案是通用链接 通用链接的厉害之处就在于 如果用户已安装某个app 链接将会开启 同时也会发送一个反馈信息 如果没有安装这个app 链接将只会在app的网页端开启

Sysctl命令今年 也发生了一些变化 Sysctl是一种低水平的API 用以询问和设置系统信息

它涉及的初衷就是允许具 有合适权限的进程来浏览信息

但正如我之前所说 IOS中的app并没有浏览 其他app的信息的权限

所以IOS沙箱今年发生了一个变化

那就是它再也不能通过调用kern.proc kern.procargs 和kern.procargs2来看到 来自其他任何进程的数据

今年在IOS和OS X这两个平台上

我们即将引入内容过滤 方面的新的延伸点

你的分程序表将能适 用于Safari 以及所有使用 SafariViewController的app

你应该去测试一下 非常受欢迎的扩展功能 来了解它将为你的应用或网页 带来怎样的影响

你应该时刻做好心理准备 你的页面中的某一部分 会在加载和处理它时遇到些问题

接下来要说的是在OS X平台上 我们正在尝试改变cookie策略

自从产生了可以在所有应用和进程中 分享cookie的 Yosemite系统之后 Cookie如今已变成了本地所有 它们对于单一进程来说是 属于本地的并且不可共享 注意如果你已经在 App Store中运行过你的应用 那对你来说就不会发生任何改变 因为你已经在这种状态中了

如果你使用了Web Clips 或者Dashboard小工具 请注意要在OS X EI Capitan中进行测试

现在我要讲一些关于 我们最新平台的内容

在这些年里我们看着IOS 和OS X系统一步步得发展成熟 正是这些经历让我们从一开始就确信 对于在新平台中建设好隐私和安全问题 我们已经有不错的基础了

我们的优势包括一些已有的技术 比如数据保护和我们的即时预警技术 我们认为这些装置是紧密相关的

对于用户来说只需要与这 两个装置中的其一建立联系就行 这也是为什么许多设置可以通用的原因

这同时也包括 你在本地WatchKit app 中的隐私设置 所以不管用户是和你的 IOS中的app进行交互 还是和Glance 或者其他第三方进行交互

在隐私安全方面的设置都是相同的

我们相信如果用户对于 开发者是无条件信任的

他们就不会产生这样一些异议 比如想“能不能给他们权限 来访问我Glance中的照片呢？” 用户有着很单一的信任方式 他们因信任而允许你访问数据 并且对数据提供保护或者相反

所以我们认为 从一开始就把关注点放在 做好隐私保护工作是非常重要的 因为你的Glance可能成为 用户与你的app交互最多的一个地方

并且，在watchOS 2平台上 把钥匙串系统引进到Watch中

接下来将由Jason负责主讲他将 涉及更多关于如何选择标识符的问题

感谢姬蒂 现在我将讲一下 关于在IOS和watchOS中的 标识符的问题 这是我们在之前的演讲中 就谈到过的一个问题 你们可以回顾一下去年的WWDC演讲 来进行一下更加深入的了解 但是我认为 在讲watchOS中的标识符之前 回顾一下之前在IOS系统中 学过的一些知识也是非常必要的

标识符是具有很大作用的 它们的厉害之处就在于 如果你使用一些用户 相关的内容来鉴别他们 比如用户的姓名 电话号码 邮箱等 可以从中披露出许多信息

你可以建立更注重隐私安全的标识符 通过生成随机数来实现或者如果要求 随机数的结构规整你可以使用UUID 当一个随机数或者UUID 不能够鉴别用户 那就取决于你记录了什么信息 你以怎样的频率来切换标识符 以及用户掌控着些什么 超过规定时间标识符就会解除匿名 由于你记录着许多种不同的信息 那些信息可能识别具体用户 比如app动态 搜索词条 消息或者位置信息 这些都取决于你的app的行为 那就意味着所有标识符都携带有风险 即使标识符本身是可以匿名的 如果你持有的数据不能匿名 一旦其中一个数据违反了这一规则 你将担起危害用户隐私安全的后果 紧接着就是名誉受损 你会失去用户的信任 当我提及数据泄露你可能会想到黑客 或者其他不法势力 但那其实就像从把一个 未设密的笔记本从车的后备箱偷出来 或者备份文件从卡车上掉下来那么简单

正因为标识符的力量是如此强大 苹果花费了大量的时间 来研究标识符该如何运作 以及筛选一些最优方案

所以首先在你使用标识符之前 问一下你自己 你真的需要吗? 你是否用以下方式收集数据呢？ 通过一个存储到服务器端的 数据库或者字典值 由客户端向服务器发送信息 而你只需记录服务器的增量数据？

如果你确定了自己真的需要使用标识符 考虑一下你想用它来标识什么 你需要使用多长时间 你只是想识别一个会话 通过简单得在app中 发送标识符来为不同进程取得关联？ 你是否在尝试... 以及能不能在每次开启和 关闭app的时候都切换标识符呢？ 你是否只着眼于暂时性的活动 每隔5,10或者15分钟 都会切换标识符？

我们知道切换标识符因其 可以降低数据相关性 而能起到隐私保护的作用 我们一会儿将要通过 一个例子来说明具体情况

如果你要标识一个用户 你要怎样同用户解释 为何拒绝他们安装一些 同样需要标识用户的应用呢？ 你使他们通过你的服务建立了账户吗？ 你是否要求他们登录？ 你能在UI界面中用语言描述清楚 你之所以这样做 是为了让他们获得更好的用户体验吗？ 当你想清楚如何向用户 解释这些之后你真的考虑好 在收集数据的同时要承担的 用户标识方面的风险了吗？

最后如果你想收集 关于手机上app安装的信息在避免 触及用户的其他信息或者会话的情况下 你是否设计出了合适的度量方法 来统计计算用户在 设备上的一些操作实例 比如用户在第二个手机上 卸载或下载一个app 或者备份数据以及进行设备间存储呢？ 在那些过程中关于用户的隐私保护方面 标识符的重置和不变是否能在你的 度量体系中有合理的解释？

最后你该考虑一下关于 标识符范围的问题 通过一个固定不变的标识符 利用它属性上的特征来 跟踪用户的一切行为是非常容易的 但用户的隐私安全也被极大降低了 许多数据是通过单一标识符被收集的 当环境发生变化 内容发生变化时标识符却不会发生变化

而且用户也不希望用同一个 标识被跟踪所有的内容 审视标识符的作用域 你将会得到针对不同目的 针对和不同数据关联的 针对不同存活期的不同标识符

现在我要举一个例子 描述一种可以增加你 隐私安全的特殊的标识符 它把可能面临的风险降到最低 设计出用同一标识符搜索 所有信息的服务是非常简单的 可一旦发生了数据泄露 即使标识符是匿名的 也能通过已有信息来识别出用户 因为除了别的东西之外 用户还会搜索与自己相关的内容 这种情况将会造成用户对我们丧失信任

比如在这个例子中标识符是匿名的 它是123.但是我们可以 从中看出许多事实 用户123正在考虑订婚 可能在过去的周六 他们可能并不是来自圣弗朗西斯科 因为他们在寻找来自 圣弗朗西斯科的航班 他们可能要去WWDC 他们可能是 John Appleseed 他们可能对 John Appleseed很感兴趣 我们并不能确定但一旦知道了更多信息 我们能清晰得判断出真相 另一方面如果你的搜索服务 使用了可切换标识符 即使数据泄露了 对用户隐私安全的损害也被最小化 因为标识符在不断改变 在这个例子中 如果标识符每15分钟变换一次 我们就不能确定用户 123和用户456或者用户789 其实是同一个人

所以我要谈论一下固定标识符 由于他们能对用户提供长期跟踪 危害了用户隐私安全 所以它们在IOS和 watchOS中不再被设计使用

苹果想为用户提供惊喜和愉悦的体验 但如果不经过用户的同意而追踪他们 用户不会感到开心 这并不符合用户的心理预期 如果他们在同一标识符下 被一个app追踪 即使当他们卸载了 app并进行重新配置 或者采用其它更具破坏力的操作行为 比如擦除手机记录

但最终因为固定标识符是永久不变的 用户并不能对此进行改变 就像姬蒂之前说过的 我们认为让用户拥有更多的控制权 对隐私安全是非常重要的

为了在开发者对标识数据的需求 同保护用户隐私之间做权衡 我们在IOS平台建立了 一系列有目的作用域的标识符 让开发者可以收集他们需要的数据 投入进分析和智能广告环境中 同时用户也可以通过控制标识符的重置 来打破他们当前的行为记录 和被收集的历史数据 之间的关联

在app层级上 在用户从某个给定 team ID卸载了所有app之后 我们可以通过重置vendor 标识符和IDFV来实现

在广告环境中我们给用户 重置广告标识符的权利 可以通过依次选择“Settings” “Privacy”和“Advertising” 再点击 “Reset Advertisement Identifier” 来重置广告标识符 因此用户可以轻易重置手机中的标识符 不用擦除任何数据就可以打破 和被收集的历史数据之间的联系

在watchOS 1中 vendor ID和广告ID 在iPhone中是作为 WatchKit运行的扩展而存在的 在watchOS 2中 你需要从iPhone中 把vendor ID和广告ID 同步到Watch上使用 你需要维持vendor ID 和广告ID的同步更新

所以现在我将要回顾一些最佳方法

确定你需要一个标识符 你可以只发送一个值 然后在服务器端记录增量吗？ 通过标识符来收集信息带来责任的同时 也带来了风险 如果你可以仅在增量数据中收集值 那么就增加了用户隐私安全 也为你自己的数据收集降低了风险

使用合适的标识符作用范围 确定当你真的需要 标识一个会话一个用户 或者一个设备就根据你app的目的 来选择标识符作用范围

iOS 和 watchOS 提供了一些标识符 所以可以直接使用它们 不用新建你自己的标识符 试着建立一个永久标识符 它的值不因手机重置 或者其他毁灭性的操作 比如移除你的app 而改变这既不利于保护 用户隐私也不利于你的app运行 如果你在使用私有API 来建立一个永久标识符 你已违反了APP Store的条例 这将带来许多不良后果

最后要遵循设计标识符的基本原则 其中你该遵循的最重要的原则之一就是 在你调用广告标识符之前 检查一下Limit Ad Tracking的值 同时要时刻跟踪广告标识符的当前值 用户可以在任意时间 重置广告标识符的值 此外授权广告跟踪的操作 也造成了广告标识符的重置 正因为这个你需要保证自己知晓当前值 并且不要把它存在cache里

最后我们谈一点报告相关的问题 我们知道在座许多都有 给合作伙伴提供报告的义务 但是我们认为在给第三方提供报告时 维护用户隐私是非常重要的 我们考虑了许多如何做 和用户有关的报告的问题 你们也能看到我们把许多机器学习的 部分嵌入到了App Analytics中

在提供报告的过程中 主要有三种重要的思想 和用户相关的报告所处的视野 报告的聚合 以及设定一个阈值 我所说的报告的视野是什么意思呢？ 对于合作伙伴来说比起想了解 是哪些人在频繁得使用你的app 以及提供所有关于app 用量的数据来让他们计算 他们更想在确定计算方式定义的基础上 让我们基于数据进行计算 提供计算结果而不是递过去原始数据

保护用户隐私的下一步是做聚合 比起说出哪些用户是重度用户 不如说出你有多少个重度用户 他们在整个群体中占多大比例 最后报告中需要设定阈值 如果你要在报告中写你有一个重度用户 而你的app只有一个用户 如果你以对待群体用户的 方式来提供用户信息 比如提供邮政编码 那你就暴露了你的用户 在你提供用户信息之前要设置一个阈值 确定你不会暴露用户隐私 应该让他们以群体的形式出现

我将会讲一些关于如何 提示用户数据的最优方法 先讲在Watch平台的给大家提提神 再延伸到IOS和OS X中 当你想要接触到数据类的时候 操作系统不会直接提供给你数据 直到用户选择了是否能 让你的app获取接收数据的权限才行

所以用户可以知道 app用这些数据做些什么 因此你对数据的收集和使用 对用户来说就变成了透明的过程 因此我们在提示中提供了这样一个空间 你可以在这里向用户解释说明 这就叫做目的字符串 你可以针对多种受保护的数据类 把他们设置进你的app 和Info.plist中 我们认为如果用户理解 为什么你们想获得数据访问权限 他们就更有可能做出正确的选择

就像姬蒂之前说过的那样 提防着有限的“不动产”的可用性 让我们的意图变得透明增加用户控制 我们考虑过Watch上的app 如何获取用户数据的问题 首先就像在IOS和OS X中那样 watchOS上的app 并不能直接获取用户数据 直到获得用户的允许

然而和IOS和OS X 不同的是在watchOS上 用户不能选择接受 或拒绝设备本身发出的即时提示 或者说那些是指向iPhone的 正如姬蒂所说我们可以把 iPhone和与其配对的Watch 视作紧密相连的用户 在其中一个平台上做出的 关于隐私处理的决策将会 影响到另一个设备 在watch中限定“不动产” 我们认为比起在 iPhone上面做要更有意义 在iPhone端用户在更大的 屏幕上看到提示信息 其中包括目的字符串 它可以清楚得说明为何你的iPhone app 和Watch app想要获得访问数据的权限 不像在IOS端你可以选择是或者否 你可以选择提示或者解散 当你做提示设置时 用户不能在watch中做出选择 因此会停留在一种未设置的状态 在这种未设置的状态 你将会稍后进行提示

举一个未设置状态的例子吧 用户可以带着Watch 去跑步而不是Phone 所以把你的app安装在Watch上 你的app将会提示 这种提示将会被消除 而你的应用将会 在没有数据访问权限的 情况下继续运行 但是在下一个时间节点 你的app将会再次提示

现在如姬蒂之前说的 这些设置包括你的隐私设置 都是在Watch和iPhone上共享的 我们认为用户和你的 应用之间有单一的联系 与iPhone之间有单一的联系 与Watch之间有单一的联系 因此我们可以把 这些单一的联系组合起来 变成一种在iPhone 在watch在你的app中的设置 而这存在于我们平台里的其他地方 在IOS端如果用户对你的 app做出了关于隐私处理的决定 使得你的app的所有 进程都有获取那些数据的权限 如果你在app中提示了地理位置 你的扩展应用也可以使用它 如果用户是在app 扩展中首次进行提示 那么整个app 也将获得访问数据的权限

在Watch平台上用户做出的决定 对所有的watch中的app 对原有app以及你的Glance 还有你的Complication 来说都是有效的 当用户给你app的一部分提供许可 就相当于对你app的所有 部分都给予了许可

现在你知道在IOS,OS X和watchOS中 我们对什么数据有访问权限了 以及我们该如何提示它们 我们认为一旦用户在这些 平台上提供了数据访问权限

考虑如何保护它们是非常重要的 这里有一些你应该利用 和清楚的一些新的安全功能 第一个就是App传输安全 为了在默认情况下保证用户交流的安全 我们引入了App传输安全体系 在IOS 9和OS X EI Capitan平台应用 在默认情况下你们在更高 层级的API中的交流 会需要用TLS 1.2版的 加密方式来实现保密性 如果你尝试进行的连接违反了这些要求 将会出现报错

如果你的app需要 向非安全域发送请求 你必须在你app中的 Info.plist中指定这个区域 如果想了解一下细节 可以关注一下明天上午9点的 NSURL会话与网络方面的演讲 或者关注今天下午的安全性演讲

如果你真的想在APP 传输安全体系中声明一个特例 你需要在你app中的 Info.plist中声明然后随意 设置一个或更多的这种密钥

现在我要谈论一下奖励卡的问题 在IOS 9系统奖励卡可以 出现在联系人列表中 我们知道有些奖励卡使用了 用户的电话号码 邮箱地址或者其他 个人指向性明显的数据 来作为奖励卡的标识符 所以为了在奖励卡以及联系 人列表的传输中保护用户的隐私 我们给开发者提供了一种简单的方式 在遍历联系人列表时加密数据

你所要做的就是修改你的 pass.json 用这个新的nfc字典 你可以指定信息标识符和你的公钥 从这开始当在非 接触支付中用到奖励卡时 IOS会谨慎得为你加密信息

随着IOS9中App搜索App历史 记录和App链接的应用 这意味着你可以存储一些和你的app 有关以及在你app之外的信息 因此你需要做一个好管家 为用户保护好数据 这不仅包括位于你app里的数据 还包括在你app之外存储的数据

在星期三上午11点会有 一个很不错的演讲介绍这方面 到时候可以去听一下 他们讲的要比我更深入些 我将简单得讲一下 app的两种数据索引方式 以及它们在隐私保护方面所起到的作用

第一个是 NSUserActivity 它是一个为了支持 Handoff而被引入IOS8平台中的API 在IOS 9中我们对其进行了扩展 所以你可以使用 NSUserActivity在你的app中 建立索引视图让用户可以 回到那个地方搜索 比如在你的食谱app中 当用户看到一个干酪浇肉汁 土豆条的食谱时 你可以在视图中建立一个 NSUserActivity并将其索引 然后用户再次在手机里 搜索干酪浇肉汁土豆条的时候 显示出来的结果就包括 他们曾经看到过的这个链接 在未来它可以帮助我们解放双手 而不需要其他机器

我们从最开始就思考 如何让搜索变得更注重保护隐私

我们之前所做的包括 把默认设置为非索引数据 这是非常正确的 在默认情况下NSUserActivity 将继续为Handoff提供支持 如果你想制作可搜索的视图 你必须得把eligibleForSearch 属性设置为真 如果你想把那个 视图变成公开索引... 那个我们一会儿将要提到... 你需要做的也是把 eligibleForPublicIndexing 值设置为真

此外还有一个你需要设置的值 如果你想把数据变成可变址的 需要用到expirationDate 正如姬蒂之前提到的那样 保护用户数据是保护 用户隐私的重要组成部分 这可以通过删除数据与用户 之间的关联来完成

现在我将要谈一点关于 NSUserActivity和公开索引的问题 NSUserActivity 是一种很好用的简单方式 它让你的app变得可以搜索 我们提高索引方面的隐私安全 就是通过在默认情况下不进行索引 让开发者来决定是否要在 特定视图中添加索引

但是我们知道许多开发者想要添加一些 在所有设备中都能搜索到的公开内容

为了实现这一点 我们想出了这样一种方法 就是在保护用户安全的同时 为附加数据提供索引

当你创建了一个可搜索视图 把它标记为公共索引 如果它只包含可公开内容的话 然后当用户搜索这一视图并且使用它时 这一视图的散表 就被发送到Apple中

在经过多重设备之后 创建视图的散表并发到Apple里

最后当超过阈值时

真实视图将会被发送到Apple里 正是因为这个原因偶然被标记为公开的 视图并不会无意间被发送出去

这就是NSUserActivity 现在我要讲一点关于 CoreSpotlight的内容 CoreSpotlight是 IOS 9中新增的一种API 它使得你的app中的用户内容可搜索 比如邮箱 联系人 日历等 这些是派生数据 你需要像保护你app中的 基础数据那样保护它们 首先是要加入数据保护类 就像你对app中的数据所做的那样

接下来要用索引中的派生数据 来实现数据管理 你可以存储--首先你 应该存储相关的用户数据 比如有没有人需要 看草稿或者删除文档？

当用户在你的app中更新文档的时候 你应该在索引中更新 这些文档的拷贝文件 在用户在你的app中 删除文档的时候 你应该在索引中也删除文档 由于用户有多种在app中 删除文档的方式 像是删除所有类型的文件 或者一个我们把它的 多种条目变得易于删除的文件夹 直接删除或者先搜索再删除

这是一个简要的概述 介绍了IOS 9中新的隐私保护特性 接下来再由姬蒂介绍 一些你们如果没有用过 可以去尝试一下的已有技术

感谢傑森 我想强调几个已有的技术 它们让保护用户信息变得容易 你不需要自己去写一些 基本的东西

Touch Id是用来保护你的 app的一种很好的方式 它也能保护你app中的数据 你可以使用app中的 Apple Pay来实现它 而不需要创建或者接收 用户的一些基本信息以及信用卡信息

现在我要深入得讲一下 隐私策略和数据保护方面的内容 在研究保护你的用户信息的技术之外 向用户解释你对他们的数据做了什么 也是非常重要的 如果你想和第三方分享数据的话

我们实际上需要对几种固定 类型的应用实施隐私保护策略 其中包括和 HealthKit相连接的app 我们把引入隐私策略变得非常容易 在iTunes连接中你只需要输入URL 它就会在你所有的 App Store中显示 它给用户一个在做购买决策之前 阅读隐私策略的机会 你可以使用IOS中的创建数据保护类 来为你的数据进行加密 其密钥源于用户的登录密码

这种加密技术有着惊人的力量 你可以轻松得利用它的优势 不需要自己写任何加密码

现在 每个IOS设备 都通过密钥层级管理来实施数据保护

它建立在硬件加密的基础上 应用于所有的IOS 和watchOS设备

数据保护是由每个基础文件来控制的 每个文件都被赋予一个类

这些类是否被解锁 决定了访问权限是否开启

这里有四种数据类我将依次进行介绍 但是你最要清楚的一点是 Ns文件保护直到出现 第一个认证时才完成 在IOS 7中 所有的第三方app 数据都默认成这种数据类 如今你的app 在启动之前是不能运行的 直到用户输入他们的密码 所以至少你的数据会 经过以上过程的保护

我们知道有些开发者 并没有使用任何数据保护措施 因为那样做是没有任何理由 也没有任何价值的

所以我要迅速得介绍一下 这种模式中的几种不同的数据类 正如你所见在没有任何保护的情况下 即使用户输入了密码或者没有输入 数据都是没被上锁的数据很容易被获取 最后直到出现第一个认证 之前它们被保护的 这就是你的默认类

现在这在启动中是不可访问的 但是一旦用户输入密码 所有数据都变得可用 即使设备加锁了数据依旧可用

下一个数据就会一直 被保护只到开放为止 这种设计面向的对象是 对设备上锁敏感的数据 所以这里有两种操作类型读和写 一旦设备启动了就关闭了数据访问权限 用户输入了密码后 你可以同时读写 当设备再次上锁 你不能读数据但你依旧可以写数据

最后我们完成了保护工作 现在对于所有的敏感数据 包括健康数据金融信息

在设备启动之后它们变得不可用

当用户输入了密码数据就变得可用 当设备上锁数据就不能用了

这将带来一个很大的工作量 来思考你要应用哪种数据保护类

最后确认你已测试过数据保护是可用的 你可以通过这些内容来核查 Settings, Touch ID和Passcode 向下滑动看看你是否启动了数据保护

我们今天讲了许多东西 你需要在IOS 和OS X上测试你的app 你希望理解这些改变所带来的影响 来保证你依旧可以 为用户提供优秀的体验 有目的地提示

确保让数据最小化 保持更新

从一些我们今天讲过的 平台中的技术中获益 最后用户隐私安全是我们共同的责任 我们必须携起手来 我们应该保护用户的隐私权

谢谢大家