双方同意的软件：如何优先考虑用户安全-InfoQ

本文要点：

双方同意的软件（Consensual Software）表示我们应该从用户那里得到明确的答复“同意”我们与他们或他们的数据交互。

许多出于善意的特性会被不正当地用来骚扰用户。时刻牢记构建双方同意的软件有助于预防这些问题，防患于未然。

GitHub 的社区和安全团队构建双方同意的软件并评审其他团队的代码，将这种不当地使用在部署之前就得以解决。

在产品规格说明阶段使用常见不正当使用的检查表，使此类特性在向公众发布之前就把这些问题解决掉。

“好的谷歌，什么是巨型汉堡？”

这个短句触发整个美国成千上万个谷歌家居设备和安卓手机去搜索“巨型汉堡”的维基百科词条。这马上就引起了骚乱，因为它做了一件预期之外的事：违反消费者的意愿去使用他们的设备。

在智能设备、物联网甚至侵入式广告实践时代，我们所构建的每个特性都要征得明确的同意就变得很有必要了。试想一下，如果下一代电视广告每次广告播出时都向Alexa 询问去购买二十卷卫浴壁纸会怎样？如果谷歌家居把医疗广告播放给不想告知家庭其他成员他们健康情况的用户会怎样？如果Alexa 把女同性恋者用户暴露给她们家人使之陷入危险境地会怎样？或者，基于浏览记录为想要逃离家暴的用户提供自卫类或救生物资，使他们面临危险？

现在，网络服务提供商能够出售消费者的浏览记录，用户隐私比以往更为重要。

最容易做到的保持用户隐私的方式是向用户提供他们需要做出知情决策的信息，征得同意再使用我们的产品，而不是假定被动或暗示的接受。

这篇文章将说明双方同意的软件将如何在其成为公关噩梦之前帮助处理线上骚扰以及不正当使用的。它还看将回顾GitHub 社区和安全团队已经构建的特性、我们如何评审其他团队的特性，以及忽视线上困扰的代价。

什么是同意？

同意意味着什么？好的，同意就像茶那么简单，生活中随处都在用它，包括技术。双方同意的软件意味着我们应征求用户明确“同意”与他们及他们的数据进行交互。

通过征得用户明确的“同意”，我们确保所构建的特性不会被用于骚扰、打搅用户或使用户遭受危险。如果我们假定用户隐式地同意使用一个特性，那么我们就会带来缺陷和漏洞，会被利用去骚扰其他人。Amazon Echo Look 就是一个绝佳案例，它告诉了我们一个善良的想法是如何导致恶劣后果的。

我们假设Alice 买了一个Echo Look，因为她想把每天的照片配到她的博客里。她把Echo Look 放到卧室里，让它拍摄她的着装秀。

问题是，像大多数网络摄像头一样，让设备拍照的人不一定就是正在拍照的人。所以虽然Alice 会在她着装完毕后明确授权拍照，然而其他人却可以很轻松就让摄像头在未经她授权下进行拍照，只需要简单说一句“Alexa，拍照”就可以了。

因为Amazon Echos、Google Homes 和大量其他物联网设备一直都在监听热麦，所以增加一个热摄像头会带来更多的问题，它很容易就会被人劫持去对目标人物进行羞辱、勒索和报复。

更令人头痛的是，通过Echo Look 拍照还未受版权法的保护。美国版权官方声明“官方将不登记由机器或纯机械过程（毫无创意或没有人类作者干预的随机性和自动化操作）完成的工作”。这使 DMCA Takedown （数字千年版权法）的实行成了空谈，仅有的几种有效方式之一是让未得到双方同意的照片远离色情报复网站或论坛。虽然美国36 个州现在有报复色情法律，但检举某人经常会遭受精神疮伤、浪费时间和金钱，且解决不了实际问题。

我们作为产品设计人员、工程师和技术专家，在此面对的实际问题是需要在产品概念阶段就开始构建具有用户明确授意的产品。我们需要确保，Alice 在通过Echo Look 拍照时总能先进行授意，而且是每一次。

GitHub 的双方同意的软件

作为 GitHub 社区和安全团队的一名工程师，我的职责是结束不正当使用的情况和构建反骚扰工具，从而改善与开源项目的合作。我的团队构建的其中一个特性是 Repository Invitations （资源库邀请）。之前，一名用户可以增加任何人作为项目资源库的协作者。我们收到了许多投诉，某个恶意用户创建带有种族主义、污辱性字眼的资源库，并增加了几个卓越的用户作为协作者。这个资源库在他们的时间线上作为支持的项目展现出来，因为该特性假定是默许的。现在，用户在被添加到一个项目的资源库时必须得到本人的明确授意。

这个特性得到许多用户在推特上的强烈支持：

社区和安全团队实现的另一个特性是拒绝推送来自私人邮件的提交。许多用户近些年给我们的支持团队写信说，垃圾邮件制作者搜集通过命令行意外推送的 GitHub 邮箱地址。垃圾邮件制作者然后自动发出邮件试图得到新用户或推销些东西给 GitHub 用户。使用双方同意的软件模型，我们决定我们要为用户提供他们做出决策所需的信息。如果用户不清楚他们正在通过命令行把私人邮箱地址给发出去，我们将让他们清楚这么做的风险，如果他们愿意的话，允许他们使用无应答邮箱地址。

如何构建双方同意的软件

当我的团队开发设计一个特性时，我们总问：怎样可以用它来伤害一些人？某些人如何以非预期的方式用它来打搅、骚扰他人，或把他人置于危险境地？用户安全特性经常是事后考虑的东西，在人们已经暴露给恶意分子之后。如果这些问题在产品规格说明和设计阶段就开始提出来，那么工程师们就可以一开始就构建安全的产品，而不是在之后去修复它，从而能节省他们许多的时间。

社区和安全团队是 GitHub 的一个非常新的团队，我们花了一整年去处理其他团队积累的技术债。在这些事上花了相当大的一笔时间和金钱，而这些事是在早期就应该得以解决的。

如果未优先考虑用户安全特性，用户很快就会对你的产品失去信心。Twitter 就是这么一个典型案例。用户多年来都在请求构建更好的屏蔽功能和安全机制，但 Twitter 却忽视了这些请求，理由是“言论自由”。现在，Twitter 得到了一个坏名声，说是他们培养了白人至上主义者和极端暴徒。这导致诸如 Salesforce 和迪士尼等多家公司撤回了收购交易，致使 Twitter 的股价大跌。

双方同意的软件是一种内置于产品概念阶段的简单框架，从而我们在产品成为公关噩梦之前就去改进产品的安全性。在 GitHub，社区和安全团队经常为其他团队进行特性审查，类似于应用安全性审查。对于这些没有专门信任和安全团队的人来说，整理一个常见的不正当使用和漏洞的检查表作为警示能节省大量的工程时间、金钱，并可防止未来出现许多负面报道。你可以提出以下问题：

每个用户是否明确同意使用这个特性，还是我们假定他们想要分享？
这个特性是否很容易放弃使用？
是否容易阻止有人不正当地使用这个特性去打扰、骚扰或威胁其他人？
是否有审计日志去看用户是否正在与你的特性进行互动？是否有度量？
如果出现了事故，是否能帮你的支持人员很容易理清发生了什么？
多少个人身份信息是公开的？编校过去或第三信息难易程度如何呢？（比如，修改变性人弃用的姓名、用户的物理地址、私人电子邮箱地址、AWS Key 等）我们真的需要保存或暴露个人身份信息吗？
你们是否允许用户上传图片？你们是否过滤了色情内容？所有用户是否明确同意接收上传的图片？你们能否通过集成预审核图片软件（比如 GIPHY ）来解决此类问题？
你是否为 0-day 账号和审查过的用户授予同样的权限？
跟踪狂可以如何使用这个特性去伤害其他人？
每个新版本的支持问题是如何处理的？

通过在构建特性和产品之前提出这些问题，我们可以在大多数不正当的用法在成为问题之前就解决它们。

永远不要以为一个人想要与你的特性交互。人们具有创造性，会找到方法去不正当地使用它。在与用户交互或与他们的数据交互前永远都要征得用户的允许。

线上骚扰的代价是什么？

忽略一个网站的线上骚扰和不正当使用不再经济有效了。Twitter 就是个很好的案例，由于它线上被不正当使用的问题，已经被谷歌、迪士尼和 Salesforce 拒绝收购，导致其股价狂跌 19%。 Twitter 的每日活跃用户数也在稳定下跌，用户增长也受到了影响。

用户开始注意到，公司在未经其同意的情况下使用了他们的个人数据。新闻中报道了几个著名的诉讼案，控告了未经用户同意就使用用户数据的技术公司，其中包括：

Twitter, Instagram, Yelp, Foursquare, Kik, Foodspotting, Gowalla 和 Path 因违反用户隐私赔偿 530 万美元。
性玩具制造商 We-Vibe 在未经用户同意下跟踪情侣使用他们产品的用法，他们同意为此赔偿 375 万美元。
头戴式耳机制造商博士音响正在处于诉讼之中，可能会由于违反窃听法令而需赔偿 5 百万美元。
亚马逊同意因为 Alexa 隐私问题向用户赔偿 190 万美元。
贝宝最近同意为移动交付应用 Venmo 的用户隐私问题赔偿 17.5 万美元。

用户还很有可能卸载他们认为会侵犯他们个人数据的应用。据皮尤研究中心分析，每 10 名用户中就有 6 名不会安装他们认为会侵犯他们隐私的应用，有 43% 的用户将出于同一原因卸载应用。

用户信任对于保持用户增长极为重要。在新应用和服务一天天冒出的今天，维持稳定的用户基础是长久生存的关键。确保用户同意使用你的产品特性和与他们的数据交互是保持透明和诚恳的极佳方式。

总结

随着软件开始成为我们日常生活的重要组成，物联网成为每个家庭的寻常模式，我们需要在用户安全成为问题之前就开始设计保护用户安全的软件了。不安全和未经用户同意的软件会付出金钱的代价、降低用户的信任感和忠诚度，并会增加数年的技术债。时刻记得，构建未经用户同意的软件不再经济有效了，用户正在用他们的脚和钱来投票。我们需要开始认真对待像应用安全之类的安全特性了，在特性开始开发之前就要在产品规格说明阶段把安全考虑进来。

通过先征得同意，我们可以避免之后再请求宽恕的公关噩梦和代价。

关于作者

Danielle Leong 是 GitHub 的社区和安全团队的一名工程师，她热爱构建工具来帮助开源更受欢迎和包容的环境。她也是 Feerless 的创始人，这是一个为具有创伤后应激障碍的 Netflix 用户触发警告的应用程序。她热衷于双方同意的软件、技术包容性、心理健康意识，以及提高线上公民权。她在业余时间攀岩、骑摩托车，以及打扮成一个霸王龙——偶尔也会在同一时间做这些事。