利用 Identity Lookup 过滤垃圾信息

大家好 我叫斯图尔特·蒙特高里 在本次演讲中 我们会讨论在iOS11 如何在应用程序里使用全新的API 来过滤不需要的SMS和MMS信息 并帮助用户避免不断增加的打扰

在开始之前 来看一下 iOS 10.3接收到不需要的 SMS信息时会发生什么

这里收到一条非常明显的 不需要的 垃圾SMS 像这样的信息对用户来说很烦人 因为它们会发出声音或震动 就像普通的信息一样 并分心你正在做的任何事情

如果打开信息应用 它就位于顶部 和真正的信息混合在一起 让列表越变越乱 不幸的是 一些iPhone用户 收到很多这种信息 希望有一种方法可以过滤掉它们 iOS 11推出了全新API 可以让你的应用程序分析 来自未知发件人的 SMS或MMS的发件人和内容 并且尝试过滤那些未经申请的信息 让我来向大家展示其工作原理

在运行iOS 11的iPhone上 启动全新的信息应用 由于我已经安装了一个 信息过滤应用程序扩展 并且在设置中启用 我看到第二个选项卡 名为SMS垃圾 如果收到应用程序认为是垃圾的信息 将会显示在该选项卡下

啊 有一个新信息 来看一下是什么

这和之前信息一样 但现在它不再出现在 已知联系人的常规列表里 并且不会发出声音或通知让我分心

如果点开它阅读 可以看到底部的标签 它被一个名为“Filter It”的 应用程序标为垃圾

我们决定添加该功能有几个理由

不需要的信息 即用户收到的任何未经申请的 或垃圾类信息 近年来已经越来越成为用户的困扰 但除了困扰 更值得担心的是 这些信息往往带有诈骗目的 并含有可能会损害用户的链接 因此 当然我们要阻止这些消息的发送 只要有可能

有一个重要区别 在iMessage SMS和MMS信息之间 对于iMessage 我们在设备上 提供报告为垃圾邮件的功能 因为这些信息是端对端加密的 并通过iMessage网络发送 但我们对SMS或MMS无法这样做 因为它们直接通过 无线运营商发送到用户设备 因此过滤这些信息必须在本地进行 而不是在集中式的服务器上 因此这些API都在本地

最后 我们听说你们中很多人都是 分析并检测不需要信息的专家 我们十分激动能够邀请一些应用程序 帮我们完成这个任务

在本次演讲的剩余时间里 我将详细介绍几个方面

首先 我会详细介绍 我们称之为信息过滤扩展 以及它们的工作原理

接下来 我会讲一些 关于隐私的重要考虑 因为这些扩展都有一些特殊的规则 然后 我会讲讲扩展 如何使用网络支持服务进行检查 对某些应用来说应该有用

我会做几个演示 在Xcode里创建扩展的过程里 现在开始

（信息过滤器扩展） 实现目标的方法 我们称之为信息过滤扩展 让我们来深入了解一下

顾名思义 这是个新的应用程序扩展类型 可以包含在你的应用里

它的API位于iOS 11全新的框架中 名为Identity Lookup 如果用户安装了一个应用程序 带有其中一个扩展 开始使用时 必须先在信息设置里启用

一次只能启用一个扩展 若用户想要禁用该功能 可以选择“无” 如果被启用 该扩展被调用 在每次从未知发件人 收到SMS或MMS信息时 还可以使用其他一些标准 来决定何时把信息发给扩展 马上就要来讲解这一点 首先来看一张显示整体流程的图 当手机收到信息时 首先会在信息应用里 如果是SMS或MMS信息 并且发件人不在收件人的联系人名单里 用户在设置里选择的扩展将会启动 并且会被传递发件人和正文信息 通过一个对象名为 ILMessageFilterQueryRequest 它也是Identity Lookup框架的一部分

当扩展收到后 将开始检查信息 查看信息发件人或正文 或两者 还可能检查不良电话号码列表 也可能检查正文中 是否有可疑的网页链接 任何适当的检查均可 最后扩展必须产生一个回应 使用一个对象名为 ILMessageFilterQueryResponse 描述是否允许或过滤掉该信息 并将回应发还给信息应用 信息应用收到回应后 要么正常提醒用户 要么禁止通知 将该信息线程移动到垃圾选项卡

（隐私考虑） 这就是扩展工作原理概述 在继续之前 我想讲一个非常重要的主题 就是用户隐私

关于如何维护Apple客户期待的 强大的隐私级别 我们花了很多心思 也允许客户启用该类扩展 如果他们想要面对 不需要的信息这一持续性问题 扩展必须符合一些特殊规则 在使用这些API时

第一条规则是 信息收件人的电话 绝不能发送至扩展 只有发件人的电话号码或邮件地址可以 因为需要这样做 来决定是否过滤一条信息 另一条关键规则是信息过滤扩展 绝不能在容器外导出信息内容 因此这些扩展还有额外的限制 它们不能写入 和所包含应用共享的文件 也不能执行网络操作 这么规定的原因是 尽管一些信息是不需要的垃圾 另一些可能是合法的 只是发件人还不在收件人的联系人里 因此所有信息都要保密 这是必须的 并且绝不能以任何方式 导出会暴露收件人的信息 除了信息本身包含的以外

尽管它们自己无法执行网络操作 这些扩展可以 间接向服务器推迟请求 当扩展请求推迟时 iOS会以扩展的名义 用一种安全的方法发出网络请求 之后我们会来看一个例子

需要记住的重点事项 是扩展绝不能在容器外 导出信息 这样才能维护用户隐私

信息应用有一些具体的标准 来决定是否给扩展发送信息 首先该功能只针对SMS和MMS信息 iMesssage除外 如前所述 不需要的iMessage 使用不同的机制来处理 所以扩展标准只适用于SMS和MMS

我反复提到 只有未知发件人 或不在收件人联系人名单里的 才真正发送给扩展进行分析 如果发件人在联系人名单里 我们认为收件人认识发件人 并想要从发件人处收到信息 也就是说如果一条信息 曾经错误地被归为垃圾 那么用户可以把该发件人 加入到联系人名单 以保证未来不会被过滤掉

如果用户正在 和不是联系人的人交换信息 并且多次回复了该线程 我们会停止发送任何该线程的后续消息 至扩展当中 或者 如果用户多次回复 已经被标为垃圾的线程 该线程将会恢复至非垃圾选项卡 多次回复将会被解读为 来自收件人的信号 即他们确实想要和发件人进行交流 因此 所有这些标准不直接影响API 但是作为扩展开发者的你们 在测试应用时应该注意这一点

现在 我想在Xcode里做一个演示 关于如何创建信息过滤扩展

我编写了一个应用程序 名为Filter It 我想添加一个信息过滤扩展

首先需要做的是 添加一个新目标

选择iOS信息过滤模板 给它一个名字

一个新文件已经加入到项目 该文件名为Message FilterExtension.swift 来看一下该文件

首先看到一个方法 名为handle_queryRequest context 该方法呼叫扩展 因此它可以检查传入的信息 以及返回的回应 使用completion处理程序

模板现有的结构是先尝试离线检查 使用这个方法名为offlineAction (for:queryRequest)

它将返回一个操作 即允许 过滤或无

在该演示里 我们需要做的是 自定义该offlineAction 帮助方法 来看一下它当前的功能

现在它总是返回无 我将会把它替换为一些简单的逻辑 改为如果信息包含“垃圾”一词 则总是过滤

在真正的扩展里 可以把这一步设得更复杂 但目前这样已经可以了 这就是如何创建一个简单的 离线的 信息过滤扩展

（网络推迟） 尽管一些应用可以离线做大部分 或者所有的检查 另一些应用可能认为 利用网络服务器检查 是否需要过滤信息更为有用 接下来 我想讲讲网络推迟

展示网络推迟工作原理的最好方法 就是用另一张图

如前所述 当消息被接收 会首先在信息应用里 然后被发送至选中的扩展 但这次扩展选择推迟该请求 至网络服务器 该服务器的URL信息 在info.plist中指定 它告诉信息应用推迟 然后信息应用对该服务器URL 发出JSON请求 然后服务器检查 JSON请求中的信息内容 并可以以任何格式进行回应 该回应会马上传回给扩展 这里 扩展从服务器读取响应 并最终返回一个 ILMessageFilterQueryResponse

请注意有一些限制 在使用网络推迟时 首先 推迟的网络请求 不包含任何个人身份信息 关于信息收件人

网络URL被静态硬编码至 扩展的info.plist文件 键名为ILMessageFilterExtension NetworkURL 因此不同的请求或不同的用户 该URL都不会改变

所有URL都必须是安全的Https 服务器必须被配置为 不需要任何应用程序传输安全技术 即ATS覆盖 因为无法配置它们

该功能还需要应用和服务器 都使用关联的域 或Apple App Site Association功能 也许你们对此已经很熟悉 如果曾经采用过别的iOS功能 比如 App Links 或者Shared Web Credentials

更多信息请观看演讲 2015年WWDC上的 “无缝连接你的应用程序”

最后要注意的限制是 任何网络服务器 想要设置的Cookie 出于维护隐私 都会被忽略

向网络服务发送的请求 都是格式化的JSON 并包括ILMessageFilterQueryRequest 对象里的相同信息 包括信息发件人 即一个电话号码或邮件地址 以及信息正文

请求还包括应用程序的版本 即应用程序的info.plist文件中的 CFBundleVersion键值 这一点可能有用 如果应用程序已经发布了 几个具有不同功能的版本 并且需要格式化回应 以确保某个特定版本的 应用程序可以理解

还包括了JSON请求格式本身的版本 也就是当前版本

和请求格式不同 回应格式完全取决于你的应用程序 并不一定非要JSON格式 回应正文传回扩展进行解析 因此对其格式没有要求

快速看一下JSON请求格式 可以看到 它包含所有之前提到的信息

回到Filter It应用 为扩展添加网络推迟功能

再看一下 之前的handle _query Request方法 可以看到 在离线检查结束后 如果返回的操作是“无” 即处于Switch语句的这种情况 我们假设该查询请求 无法只用离线检查进行处理 需要咨询网络服务器得到解答

为此 代码调用 deferQueryRequestToNetwork方法 在扩展上下文 这将导致以扩展名义做出网络请求 请求完成后 将异步调用该完成块

在该完成块内部 如果网络有一个回应 并且没有错误 可以使用另一个帮助方法 名为action(for: networkResponse) 将其转换为一个操作 来看看该方法及其功能

和离线检查帮助方法一样 该方法也默认返回“无” 来对它进行自定义 解析服务器回应

假设服务器返回JSON 尽管不是必须 我将使用Swift 4中 新的Foundation Decoding API 来解码回应

我会把之前写好的代码粘贴过来 简单讲一下

首先定义了一个结构 描述服务器返回的JSON格式

然后创建了一个JSON解码器实例

用于解码网络数据 作为结构实例

最后返回解码完成的操作 并保存在结构里

如果有任何错误 会在下面处理

并返回默认回应“无”

就这样 我们成功添加了网络推迟支持 在信息过滤应用扩展里 现在对于传入的信息 该扩展既支持离线也支持网络检查

这就是应用程序 如何帮助过滤不需要的信息 使用新的信息过滤扩展 以及iOS 11的Identity Lookup框架 我们希望在用户隐私 和解决用户该迫切需求之间 取得一个平衡 结果是推出了应用程序 可以使用的强大API 但其中有一些特殊规则需要注意 请下载最新的STK 看看最新的Identity Lookup框架 今天就试着写一个信息过滤扩展吧

更多信息请查看演讲页面的链接 在WWDC官网上

今年的大会 确实还有一些相关演讲 关于平台上隐私实践的更多信息 请观看“隐私和应用程序”演讲 将于周二11:20在行政大厅举办

关于演示中Foundation 和Coding API的更多信息 请观看周三11点 在2号大厅举行 的“Foundation新特性”演讲 2015年WWDC有一个很棒的演讲 名为“无缝连接你的应用程序” 详细讲解了相关联的域功能 是使用网络推迟时 信息过滤扩展所需要的 请在档案中查看该演讲 关于如何在应用程序 和服务器上实现的详细信息 非常感谢观看