本文来源于理深科技时评,作者为
滴滴在美国刚刚“低调”上市,国家网信办的安全审查就接踵而至。审查的结论已于昨日公布,滴滴的App被明确要求下架。
不管是涉及到了客户的隐私也好,涉及到了国家道路基础设施数据的出境也好,滴滴作为平台公司,拥有并知晓这些数据,却是不争的事实。笔者从2017年起就在多次演讲中介绍并呼吁业界重视隐私计算技术,提到隐私计算的演讲不下十余次。眼下的形式,恰好对笔者这几年来的呼吁作了很好的注解。本文尝试从隐私计算技术的角度做一个分析,看看如果这两部分数据对滴滴来说是“可用不可见”的,会不会影响滴滴的业务。
首先,就事论事,对于网约车业务来说,客户是谁其实是不重要的。只要你有支付能力、有位置信息、有出行需求,把你需要的车给调度到位就是了,管你是谁。当然,有人会问,如果不绑定某个真实的用户,怎么知道你有没有钱。
这个其实简单,用户只要把预付款“匿名”打到一个智能合约,等到运输服务完成,再由智能合约按分成比例转给司机和平台方就是了。中间如果服务不得不中止,也可以按照智能合约的约定,按中止的条件予以结清。这里面,用户是谁显然并不重要。只要能够精准地拉到活儿,收到钱,就不应该过问用户是谁。
其次,对于网约车业务来说,道路数据确实是不可缺少的信息基础设施,但是道路数据发挥作用,并不以平台“知晓”该数据为基本前提。
在隐私计算框架之下,道路数据可以“背靠背地”与客户的地理位置和车的地理位置相关联。也就是说,道路基础设施可以像一个黑箱一样,通过API接口来响应客户的请求,匹配就近车辆、计算优化路径,预估时间和价格等等。
这些都不以平台公司必须“看穿”道路数据为前提;但借助于隐私计算技术,可以在不看穿计算过程的情况下确认计算结果是可信的。所以,有了隐私计算技术,道路数据服务可以封装为一个黑箱,数据不可见,但API可用,而且API的使用在隐私计算意义下是可以自证的。只要国家法律要求这部分数据不得泄露,黑箱保持为黑箱就可以了,甚至可以交由一支国家认可的特别的团队来开发和运行它。
有人可能会说,根据支付的历史,推断一个客户的支付能力,由此关联到推荐挡位乃至定价(大数据杀熟),这意味着除了在线的接单、匹配、调度之外,还要进行后台的大数据分析,离开了数据的“可见”特性,这一切还能做到吗?
当然,大数据分析本身的隐私计算框架还不完善,但实际上,技术上已经可以做到允许客户用两种不同的匿名方式来发起业务:一种是“一次性匿名”,即本次出行不与该用户历史上的任何一次出行相关联;另一种是“连贯性匿名”,即本次出行可以与自己在历史上选择为“连贯性匿名”的各次出行相关联,但与出行场景之外该客户是谁仍然不相关联。
把关联的开关掌握在用户手里,就可以防止平台方对关联数据的滥用。如果客户选择了匿名发起业务,恰恰说明客户不想把自己的本次出行行为跟自己历史上的出行行为相关联。你硬要关联,说是为客户好也罢什么也罢,是不是有点违背客户的意志了呢?这背后之所图,是不是有点超出业务范围了呢?
个人出行的轨迹,对于“有关方面”来说也许是有用的。这里有一个平台方不可见、无关方不可见但可以让“有关方面”看见的技术安排问题。
这个技术安排,也不是做不到,关键是私钥的管理问题。这件事做好了,也省得各家平台都举着“有关方面”的大旗,跟用户要隐私数据。有关方面为了调取隐私数据,开的口子越多越难以管控。还不如一个口子解决实名映射问题,剩下那些从平台处拿到的隐私数据都可以在实名映射之下还原为可见数据。这是杜绝隐私数据流失的最好办法。
期待有一天,平台公司以可以自证没碰用户隐私数据,没碰国家关键基础设施数据为卖点,而现有平台的服务功能并不缺失。这一天或许不会太远了。从事隐私计算技术研发的诸君,努力迎接这一天的到来吧。