对内容阻止、安全工具和开放Web有害的WebBundle

2020-08-26 12:26:01

这是描述新的和拟议的网络标准以及它们如何支持或威胁网络隐私的一系列博客文章中的第二篇。这篇文章是由高级隐私研究员Peter Snyder(@Pes10k)撰写的。

谷歌正在提出一项名为“WebBundles”的新标准。这一标准允许网站将资源“捆绑”在一起,并将使浏览器无法通过URL推理子资源。“这有可能将Web从一个超链接的资源集合(可以审计、有选择地获取,甚至替换)变成不透明的全有或全无的”BLOB“(如PDF或JSWF)。相信开放的、用户服务的、透明的Web的组织、用户、研究人员和监管机构应该反对这一标准。

虽然我们赞赏WebBunles和相关提案旨在解决的问题,[1]但我们相信还有其他更好的方法可以在不损害Web的开放、透明和用户至上的性质的情况下实现相同的目的。一种潜在的替代方案是对独立获取的子资源使用已签署的承诺。这些替代方案将填补一个单独的帖子,其中一些已经与规范作者分享。

网络之所以有价值,是因为它以用户为中心,用户可控,用户可编辑。只有少量专业知识的用户可以看到页面包含哪些网络资源,并决定他们的浏览器应该加载哪些资源(如果有的话);而非专家用户可以通过安装扩展或隐私保护工具来利用这一知识。

Web以用户为中心的本质与大多数应用程序和信息分发系统非常不同。大多数应用程序都是代码和资源的编译集合,很难区分,也很难推理。这一区别很重要,这也是为什么有很多用于Web的隐私保护工具,但用于“二进制”应用程序系统的工具很少的部分原因。

从根本上说,使Web与其他应用系统不同、更开放、更以用户为中心的是URL。因为URL(通常)指向一件事[2],所以研究人员和活动家可以提前测量、分析和推理这些URL;然后其他用户可以使用这些信息来决定他们是否想要加载URL指向的东西,以及以什么方式加载。更重要的是,专家可以加载https://tracker.com/code.js,确定它侵犯隐私,并与其他用户共享这些信息,这样他们就知道未来不加载该代码。

谷歌最近提出了三个相关标准,即WebBundles、签名HTTP交换协议(有时缩写为SXG)和数据加载。除非另有说明,否则本帖子将使用单一术语“WebBunles”来指代所有三个规范。到目前为止,WebBundles已经被推介用于拟议的智能广告系统(即Turtledove,Sparrow),以及作为谷歌AMP系统后续行动的一部分,尽管我怀疑这只是冰山一角。

从高层次上讲,WebBundles是将资源打包在一起的一种方式,因此您的浏览器只下载一个“包”,而不是单独下载每个网站、图像和JavaScript文件,并且该文件包括加载整个页面所需的所有信息。URL不再是对Web上资源的通用全局引用,而是对捆绑包的任意索引。

换句话说,WebBunles让网站的行为就像PDF(或Flash SWF)一样。PDF包括渲染PDF所需的所有图像、视频和脚本;您不需要单独下载每个项目。这有一些方便的好处,但也使得独立于PDF本身对PDF中的图像进行推理几乎是不可能的。例如,这就是为什么没有PDF的内容拦截工具的原因。PDF实际上是要么全有要么全无的命题,而WebBunles将把网站变成同样的东西。

通过将URL从有意义的全局标识符更改为任意的、与包相关的索引,WebBunles为广告商和跟踪者提供了强大的新方法来规避隐私和安全保护Web工具。下一节给出了几个例子。

WebBunles中的URL是对捆绑包[3]中资源的任意引用,而不是对资源的全局共享引用。这将允许网站以多种方式规避隐私和安全工具。

从根本上说,所有这些规避的共同原因是,WebBunles为资源创建了一个本地名称空间,独立于世界其他地方看到的内容,这可能会导致各种名称混乱,破坏隐私活动家和研究人员多年来改善隐私和安全的工作。以下各节仅讨论WebBunles网站可能利用这种混淆的三种方式。

以前,如果站点想要包含(比方说)指纹脚本,它将包括指向站点上的指纹脚本的<;script>;标记。网站上的每个页面将通过相同的URL引用相同的指纹脚本。然后,研究人员或众包可以将该指纹脚本的URL记录在类似于EasyPrivacy的列表中,这样注重隐私的用户就可以在不获取指纹脚本的情况下访问该网站。这就是今天绝大多数屏蔽和隐私工具在Web上的工作方式。

WebBunles通过将不需要的资源的URL随机化,使网站很容易规避隐私工具。比方说,当前Web上到处都被称为example.org/tracker.js的东西,可以在一个WebBundle中称为1.js,在下一个2.js中称为1.js,在第三个3.js中称为3.js,等等。WebBunles通过消除站点的所有成本来鼓励这一点;缓存变得轻而易举(因为您已经将所有资源返回给每个用户并缓存整个捆绑包),并且不需要维护URL映射(因为您发送给用户的捆绑包已经具有随机的URL)。

更糟糕的是,WebBunles会使每个捆绑包中的相同URL指向不同的内容,从而允许网站避开拦截工具。在目前的网络上,https://example.org/ad.jpg指出每个人都有同样的事情。对于一个网站来说,让同一个URL从同一个URL返回两个不同的图像是很困难的。因此,拦截工具可以拦截ad.jpg,因为他们知道它们是为每个人屏蔽广告;几乎没有风险为某些用户屏蔽广告,为其他用户屏蔽公司徽标。

WebBunles再次以一种危险的方式改变了这一点。*Example.org可以建立一个网站捆绑包,这样一个捆绑包中的https://example.org/ad.jpg表示广告,另一个捆绑包中的标识指的是网站的徽标,第三个捆绑包中的标识指的是其他东西。这不仅使研究人员很难不可能建立名单,而且它给网站提供了一种强大的新能力来毒害阻止名单。

最后,WebBundles实现了一种更危险的规避形式。目前,像UuBlock Origin和谷歌的安全浏览项目这样的组织正在建立有害和危险的网络资源的URL列表。这两个项目在确定资源是否有害时,将URL视为唯一的或重要的输入。URL的通用性、全局性再次使这些列表变得有用。

WebBunles允许站点通过已知好的URL引用已知的坏资源,从而再次使站点能够规避这些保护。比方说,要让网站在更广泛的网络上把https://cdn.example.org/cryptominer.js,当成https://cdn.example.org/jquery.js一样对待(反之亦然)是非常困难的;在WebBundle中,这将是微不足道的。

WebBundle规范的设计者和倡导者争辩说,所有这些都不是什么新鲜事,上面所有规避隐私保护的方法都已经有可能了。这在技术上是正确的,但忽视了经济学,从而错过了大局。WebBunles提供了目前昂贵、脆弱和困难的规避技术,取而代之的是廉价甚至免费的技术。

例如,网站确实不能使用大量的URL来引用同一文件,从而使拦截工具变得困难,但在实践中,这对网站来说是很难做到的。将URL随机化会损害缓存,需要将从随机URL到真值的映射永久存储在某个位置,并将其推送到CDN,依此类推。网站可以做到这一点,但难度和成本都很高,因此并不常见。

类似地,今天的站点可以使用cookie或其他跟踪机制来使单个URL对每个用户的行为不同,从而进行上面讨论的相同类型的URL混淆攻击。但是,这又是脆弱的(对新访问者怎么办?)、困难(您需要维护和分发cookie到资源的映射)和昂贵(大多数Web服务器和托管系统依赖于积极的高速缓存来扩展,使得这些规避技术对于在超大型公司规模以下运营的站点是令人望而却步的)。

这篇文章的重点是WebBunles将对隐私和安全工具造成的危害。我们对WebBunles和相关标准还有其他顾虑。我们可能会在未来的帖子中写到它们,但部分列表包括:

SXG缺乏否认系统:如果一个网站今天意外地包含了恶意软件,该网站只需更新网站就可以解决问题。如果一个站点用SXG签署了WebBundle,那么签名者没有明确的方式表明“不再信任这个特定的捆绑包”。

与Manifest v3的交互:Manifest v3将扩展限制为使用URL模式进行阻止;WebBunles使这些URL变得毫无意义。这两个功能结合在一起将允许网站完全绕过屏蔽。

来源混乱:加载+SXG允许您从一台服务器获取内容,但使用另一台服务器的隐私和安全属性执行它。用户混淆的可能性是巨大的,虽然我们相信谷歌员工正在努力尝试解决这里的UI/UX问题,但用户面临的风险是巨大的,而且没有减少到可管理的形式。

Brave致力于改善Web上的隐私,在我们构建的Web浏览器中,在我们构建和共享的工具中,以及我们在标准机构中所做的倡导工作中。这篇文章中分享的担忧只是Brave努力确保网络标准专注于隐私、透明度和用户控制的一个例子。

我们已经试图与WebBundle的作者进行详细的合作,以解决这些问题,但没有成功。我们强烈建议Google和WebBundle小组暂停这项提议的开发,直到本文讨论的隐私和安全问题得到解决。我们还鼓励网络隐私和安全社区中的其他人也参与到对话中来,在这些担忧得到解决之前不要实施该规范。

加入对话的一种方式是与WebBundles一起就此问题发表评论,描述这些担忧(该问题和这篇博客文章都是由同一个人撰写的)。其他选择包括根据规范打开新的问题,或者让您的Web浏览器知道隐私工具对您有多重要,以及此建议对这些工具构成的风险。

[2]虽然有例外,Web平台中没有任何要求这样做,但事实是URL通常被认为是半永久性的。这种半永久性的期望反映在整个Web平台上,包括缓存策略的各个方面,以及库如何指导人们部署代码等。

[3]它们也可以是对捆绑包外部资源的引用,但这样做首先违背了捆绑包的目的,所以本文不再进一步讨论这一点。

[4]正如后面讨论的那样,不是不可能,而是困难。关键是WebBunles提供了目前对攻击者来说既困难又脆弱、容易和毫不费力的规避方法。

继续阅读有关广告拦截、功能、性能、隐私和基本关注令牌相关声明的新闻。