自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一旦有了严格的监管，对于用户未来的隐私保护就势必将会有十分积极的意义。
还没有评论，来说两句吧...