iOS11 SDK新特性- DeviceCheck
通过使用DeviceCheck,你能够在某种程度上追踪到这个手机使用了你开发App的情况.(即使这个App被卸载,或者机器被刷机).这么说可能你还是觉得有点抽象.
1.我们举几个例子.
某个人养了一堆帐号专门用来薅羊毛,节日一到,各个帐号轮翻上阵领优惠券.
这种行为电商是很反感的,电商的游戏规则基本上是一个手机一个帐号只能领取一次.
电商为了限制这些人恶搞,基本上就通过idfa,idfv等标志符来识别帐号的唯一.
但是有心的人,通过卸载app,重置广告标志符,恢复出厂设置等种种手段来产生不一样的idfa,idfv.在同一个手机上不端切换帐号来领券
之前很典型的是UBER,从2014年为了反欺诈,以hack的形式,获得了设备的唯一标识符( device Serial Number,无论你怎么刷机,都能终身标识一台设备)
因为这个事情,最终Tim Cook直接指责Travis Kalanick.
Uber辩解这么做是中国无良司机刷单.........这些司机通过多个帐号,然后给自己刷单获取补贴
所以app对于获取设备唯一标识符是多么地渴望.然而苹果基于隐私的保护,牢牢把这个唯一标识符握在自己手里.
这次放出来这个DeviceCheck功能,相当于某种程度上帮助开发者结合自己的业务做一些标识,特别是反欺诈.
2.DeviceCheck的实现方式
苹果在自家的服务器,为每一台设备的每一个app维护一个2bit大小的数据(没错,就是2bit!!!!! 就是这么小,总共4种可能),App后台服务器通过token到苹果后台进行查询.苹果后台返回这个2bit的数据以及对应的timestamp.
这样即使app被卸载重装,被刷机,App后台照样可以拿到之前设置的状态.
3.应用实例
我们还是通过第一个例子领取优惠券来解释这个流程
1.app侧通过调用苹果的api generateToken获得一个token,然后把这个通过传递给后台server,告诉后台,我要领优惠券
2.后台收到app领优惠券的请求之后,拿着这个token先去苹果后台查询这台设备的状态.
3.后台查询到状态之后根据这个2bit数据以及对应的timestamp决定要不要发放优惠券,
4.如果要发优惠券,发送完优惠券之后,后台拿着token去更新苹果后台的2bit数据.
4.其他需要注意的东西
4.1 苹果这个token是设计的时候是single-use,也就是说只能用一次.
Although the token remains valid long enough for your server to retry a specific request if necessary, you should not use a token multiple times. Instead, use this method to generate a new token.
4.2苹果后台和app服务器后台通信
苹果后台和服务器后台之间的通道链接,也是需要加密,这种消息传递的加密参考消息推送.
Refer:
Uber responds to report that it tracked devices after its app was deleted
DeviceCheck framework
Accessing and Modifying Per-Device Data
Apple Rolls Out New Feature That Permanently Associates Devices with Apps, Even After Deletion
