正在阅读:

SDK国标开启试点,窃取隐私的黑手又少了一只

扫一扫下载界面新闻APP

SDK国标开启试点,窃取隐私的黑手又少了一只

SDK本身想要作恶难度太低,但是想要发现SDK作恶的难度却又太高。

文|三易生活

自2018年Facebook的剑桥分析门爆发以来,隐私安全与数据透明就很快成为了全球网民共同关心的问题。在海外市场,苹果扛起了保护用户隐私的大旗,iOS 13的苹果登录(Sign in with Apple)和iOS 14.5的应用跟踪透明度(ATT)等功能深入人心,但在Android端情况就要复杂得多,除了APP本身之外,SDK这个不起眼的“小玩意”也能成为用户隐私泄露的渠道。

日前有消息显示,国家标准《信息安全技术移动互联网应用程序(App)SDK安全指南》(下文简称为《指南》)试点工作启动会近日拉开帷幕,而这也是国内首次对于SDK安全提出的国家标准。据悉,《指南》从SDK安全开发、在SDK个人信息安全、App集成安全等方面,提出SDK控制者在开发、运营、个人信息处理、数据安全管理、跨境管理等环节,所应遵循的原则和安全措施。

无良APP超范围/违规收集用户信息的一事,相比许多朋友多多少少都会听说过,但更加隐蔽的SDK也同样能够默默地收集用户信息。那么问题就来了,各式各样的APP是大家每天都在使用的,而看不见摸不着的SDK到底是什么呢?事实上,SDK(Software Development Kit)指的是软件开发工具包,广义上是指辅助开发某类软件的相关文档、范例和工具的集合,可以理解为是“软件中的软件“。

其实SDK并不是一个面向消费端的概念,其更多的是为开发者服务,可以将其想象为一个虚拟的程序合辑,在这个合辑中有一个个做好的细分功能。并且作为APP的重要组成部分,SDK可以帮助开发者在APP中高效率、低成本地实现例如地图、支付、推送、图像识别等功能。

一个典型的例子,就是谷歌也会推出包含有Android SDK的Android Studio工具包,为开发者提供API函数库和必要的工具用于构建、测试和调试Android应用。例如支付宝想要实现扫码支付,其实是开发者在APP中写入了调用Android SDK里的camera API接口,然后SDK调用camera.open来打开手机的摄像头完成扫码。

但在系统级的SDK之外,各大SDK提供商也为具体业务和特定功能,开发了更为细化的应用型SDK。例如在游戏中如果遇到需要付费购买的道具时,通常游戏厂商并没有支付牌照,这时候就需要用到银联、支付宝或微信支付,而想要在游戏中调用这些支付渠道,就需要在包体里集成这些SDK。

显而易见,标准化、可复用的SDK作为工具,大幅度提升了开发者的效率,免去了“重复造轮子”的烦恼。特别是在互联网行业中,时间就是金钱、效率就是生命已被奉为圭臬,适合日新月异的市场变化也是各大互联网厂商的生存之道,所以能够大幅缩短开发周期的SDK,也就顺理成章的成为了从大厂到独立开发者的共同选择。

为什么SDK会与个人数据收集会有关?在这里就要引出API(应用程序接口)的概念,而这则是为了能够在各系统间共享数据,而开放的技术接口管道。如果开发者想要让APP拥有SDK中的某项功能,就必须通过API连接你的系统和SDK工具包。因此在一个APP需要借助SDK实现某项功能时,用户数据其实经过了从APP服务器流向SDK提供商的服务器再流回的过程,只要SDK提供商进行代码埋点,就能很轻松地在这一过程里抓取截留到用户的数据。

由于APP想要使用SDK带来的便捷时,就不可避免地需要与SDK提供方实现数据交互,因此SDK想要在被使用的APP中“做点手脚”实在太简单,并且在很多情况下甚至不需要侵入APP的业务代码,就可以实现诸如抓取用户点击事件、运行异常崩溃等事件。事实上在去年,央视3·15晚会就曾经曝光了SDK提供商违规窃取个人隐私的案例。

显而易见,此次的《移动互联网应用程序(APP)SDK安全指南》就是为了规范SDK乱象,让其不再成为用户隐私泄露的渠道。不过从实务层面出发,单靠这样的一个《指南》很难解决所有的问题,想要规范SDK市场乱象还存在着多方面的阻力。

从开发者的主观出发,在当下强调效率、要求快速抓住风口的互联网生态中,APP的上线与迭代周期通常都非常严格。如果APP急着上线,特别是缺少专业QA测试团队的中小企业,既没有意愿也没有技术能力检查每一个SDK是否包含恶意代码,甚至不乏开发者与SDK供应商沆瀣一气共同作恶的案例。

同时,Android O之后系统不再让不必要APP驻留后台的情况下,SDK也成为了不少APP“拉新”、“保活”的工具。APP被杀后台怎么办?其他驻留后台的APP中,只要有使用了同一款带有“保活”功能SDK的APP存在,SDK在符合配置条件的情况下执行对指定APP的重新唤醒是很简单的一件事。而APP想要快速度过冷启动期,SDK提供商利用SDK远程控制设备在后台进行静默应用安装同样也是“小菜一碟”。

更何况,SDK本身很难被监管。通常来说,SDK是基于APP的权限和授权收集数据,但从理论上来说,SDK可以通过跨越Android系统接口的方式,执行linux命令来获取相关权限,只要系统所允许的数据SDK都可以被收集。这是因为APP是产品,而SDK在某种意义上来说是生产力工具,谷歌能够监管APP,但对于隔了一层的SDK基本没有太多的管控。

简而言之,SDK本身想要作恶难度太低,但是想要发现SDK作恶的难度却又太高。开发者为了更便捷的开发体验很难放弃使用SDK,而作为平台方的谷歌出于繁荣Android生态等方面的考量,也没有动力去管控SDK。

这就造成SDK是否合规,基本全看SDK提供商本身的良心,以及APP开发者的技术水平和市场地位。对于技术能力较为欠缺的开发者来说,SDK提供商提供“加料版”,对于大企业提供正常版本并不罕见。更为致命的是,从用户的角度出发,如果一款APP被曝光出来存在过度收集用户隐私的丑闻,用户自己就能够将其卸载的,但SDK是一个面向开发者的B端产品,用户看不见摸不着,因此对于恶意的SDK往往是束手无策的。

这就显露出如今这个SDK安全国家标准试点的重要所在,《指南》为SDK的规范化、透明化提供了一个可能,一旦APP与SDK之间的安全责任关系等关键问题被规范化,就能够在极大程度上为开发者和SDK提供商之间的行事,提供一个标准化的解决方案。

相比于摆在明面上的APP,潜藏在水面之下的SDK一旦有了严格的监管,对于用户未来的隐私保护就势必将会有十分积极的意义。

本文为转载内容,授权事宜请联系原著作权人。

评论

暂无评论哦,快来评价一下吧!

下载界面新闻

微信公众号

微博

SDK国标开启试点,窃取隐私的黑手又少了一只

SDK本身想要作恶难度太低,但是想要发现SDK作恶的难度却又太高。

文|三易生活

自2018年Facebook的剑桥分析门爆发以来,隐私安全与数据透明就很快成为了全球网民共同关心的问题。在海外市场,苹果扛起了保护用户隐私的大旗,iOS 13的苹果登录(Sign in with Apple)和iOS 14.5的应用跟踪透明度(ATT)等功能深入人心,但在Android端情况就要复杂得多,除了APP本身之外,SDK这个不起眼的“小玩意”也能成为用户隐私泄露的渠道。

日前有消息显示,国家标准《信息安全技术移动互联网应用程序(App)SDK安全指南》(下文简称为《指南》)试点工作启动会近日拉开帷幕,而这也是国内首次对于SDK安全提出的国家标准。据悉,《指南》从SDK安全开发、在SDK个人信息安全、App集成安全等方面,提出SDK控制者在开发、运营、个人信息处理、数据安全管理、跨境管理等环节,所应遵循的原则和安全措施。

无良APP超范围/违规收集用户信息的一事,相比许多朋友多多少少都会听说过,但更加隐蔽的SDK也同样能够默默地收集用户信息。那么问题就来了,各式各样的APP是大家每天都在使用的,而看不见摸不着的SDK到底是什么呢?事实上,SDK(Software Development Kit)指的是软件开发工具包,广义上是指辅助开发某类软件的相关文档、范例和工具的集合,可以理解为是“软件中的软件“。

其实SDK并不是一个面向消费端的概念,其更多的是为开发者服务,可以将其想象为一个虚拟的程序合辑,在这个合辑中有一个个做好的细分功能。并且作为APP的重要组成部分,SDK可以帮助开发者在APP中高效率、低成本地实现例如地图、支付、推送、图像识别等功能。

一个典型的例子,就是谷歌也会推出包含有Android SDK的Android Studio工具包,为开发者提供API函数库和必要的工具用于构建、测试和调试Android应用。例如支付宝想要实现扫码支付,其实是开发者在APP中写入了调用Android SDK里的camera API接口,然后SDK调用camera.open来打开手机的摄像头完成扫码。

但在系统级的SDK之外,各大SDK提供商也为具体业务和特定功能,开发了更为细化的应用型SDK。例如在游戏中如果遇到需要付费购买的道具时,通常游戏厂商并没有支付牌照,这时候就需要用到银联、支付宝或微信支付,而想要在游戏中调用这些支付渠道,就需要在包体里集成这些SDK。

显而易见,标准化、可复用的SDK作为工具,大幅度提升了开发者的效率,免去了“重复造轮子”的烦恼。特别是在互联网行业中,时间就是金钱、效率就是生命已被奉为圭臬,适合日新月异的市场变化也是各大互联网厂商的生存之道,所以能够大幅缩短开发周期的SDK,也就顺理成章的成为了从大厂到独立开发者的共同选择。

为什么SDK会与个人数据收集会有关?在这里就要引出API(应用程序接口)的概念,而这则是为了能够在各系统间共享数据,而开放的技术接口管道。如果开发者想要让APP拥有SDK中的某项功能,就必须通过API连接你的系统和SDK工具包。因此在一个APP需要借助SDK实现某项功能时,用户数据其实经过了从APP服务器流向SDK提供商的服务器再流回的过程,只要SDK提供商进行代码埋点,就能很轻松地在这一过程里抓取截留到用户的数据。

由于APP想要使用SDK带来的便捷时,就不可避免地需要与SDK提供方实现数据交互,因此SDK想要在被使用的APP中“做点手脚”实在太简单,并且在很多情况下甚至不需要侵入APP的业务代码,就可以实现诸如抓取用户点击事件、运行异常崩溃等事件。事实上在去年,央视3·15晚会就曾经曝光了SDK提供商违规窃取个人隐私的案例。

显而易见,此次的《移动互联网应用程序(APP)SDK安全指南》就是为了规范SDK乱象,让其不再成为用户隐私泄露的渠道。不过从实务层面出发,单靠这样的一个《指南》很难解决所有的问题,想要规范SDK市场乱象还存在着多方面的阻力。

从开发者的主观出发,在当下强调效率、要求快速抓住风口的互联网生态中,APP的上线与迭代周期通常都非常严格。如果APP急着上线,特别是缺少专业QA测试团队的中小企业,既没有意愿也没有技术能力检查每一个SDK是否包含恶意代码,甚至不乏开发者与SDK供应商沆瀣一气共同作恶的案例。

同时,Android O之后系统不再让不必要APP驻留后台的情况下,SDK也成为了不少APP“拉新”、“保活”的工具。APP被杀后台怎么办?其他驻留后台的APP中,只要有使用了同一款带有“保活”功能SDK的APP存在,SDK在符合配置条件的情况下执行对指定APP的重新唤醒是很简单的一件事。而APP想要快速度过冷启动期,SDK提供商利用SDK远程控制设备在后台进行静默应用安装同样也是“小菜一碟”。

更何况,SDK本身很难被监管。通常来说,SDK是基于APP的权限和授权收集数据,但从理论上来说,SDK可以通过跨越Android系统接口的方式,执行linux命令来获取相关权限,只要系统所允许的数据SDK都可以被收集。这是因为APP是产品,而SDK在某种意义上来说是生产力工具,谷歌能够监管APP,但对于隔了一层的SDK基本没有太多的管控。

简而言之,SDK本身想要作恶难度太低,但是想要发现SDK作恶的难度却又太高。开发者为了更便捷的开发体验很难放弃使用SDK,而作为平台方的谷歌出于繁荣Android生态等方面的考量,也没有动力去管控SDK。

这就造成SDK是否合规,基本全看SDK提供商本身的良心,以及APP开发者的技术水平和市场地位。对于技术能力较为欠缺的开发者来说,SDK提供商提供“加料版”,对于大企业提供正常版本并不罕见。更为致命的是,从用户的角度出发,如果一款APP被曝光出来存在过度收集用户隐私的丑闻,用户自己就能够将其卸载的,但SDK是一个面向开发者的B端产品,用户看不见摸不着,因此对于恶意的SDK往往是束手无策的。

这就显露出如今这个SDK安全国家标准试点的重要所在,《指南》为SDK的规范化、透明化提供了一个可能,一旦APP与SDK之间的安全责任关系等关键问题被规范化,就能够在极大程度上为开发者和SDK提供商之间的行事,提供一个标准化的解决方案。

相比于摆在明面上的APP,潜藏在水面之下的SDK一旦有了严格的监管,对于用户未来的隐私保护就势必将会有十分积极的意义。

本文为转载内容,授权事宜请联系原著作权人。