指南|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一旦有了严格的监管，对于用户未来的隐私保护就势必将会有十分积极的意义。