Web捆绑包是为内容可寻址网络构建的

2020-08-30 17:23:21

前几天,我在HackerNews上看到了Brave的这篇文章,它解释了WebBundles(谷歌为Web提出的新标准)在我们所知的Open Web上可能会带来的潜在危害。我知道我有相当的偏见,但是当我读到这篇文章的那一刻,我的大脑开始在WebBunles、去中心化的Web、IPFS等之间建立联系,我得出了以下结论:WebBunles可能对传统的Open Web有害,但对于去中心化的Web和Internet的未来来说,它们可以非常方便地发挥作用。

WebBundles(不要与webpack混淆)是谷歌提出的一个标准,用于将网站捆绑为单个文件,使其可共享。一个网站的所有资产都包含在同一个包中。我们可以用WebBunles做一些事情(根据这篇文章):创建我们自己的内容并以各种方式分发,而不局限于网络;通过蓝牙或Wi-Fi Direct与我们的朋友共享Web应用程序或一段Web内容;或者在USB上承载我们的网站,甚至将其托管在我们自己的本地网络上。

我不知道所有这些东西的用处,但我会添加一个我自己的东西,从世界上任何一台机器上接收捆绑包,而不是内容的生成器(是的,就像CDN,但稍后会详细介绍这一点)。

WebBundle是一种用于将一个或多个HTTP资源封装在单个文件中的文件格式。它可以包括一个或多个HTML文件、JavaScript文件、图像或样式表。捆绑包是一个扩展名为.wbn的CBOR文件(按照约定),它将HTTP资源打包成二进制格式,并使用application/webbundle MIME类型提供服务。Web捆绑包中的HTTP资源由请求URL编制索引,并且可以有选择地附带担保资源的签名。

因此,现在,如果我们向https://example.com发出请求,而不是获得引用呈现网站所需的所有资产的URL的索引文件,我们将被重定向到例如https://example.com/<;bundle_id>;,,在那里我们将下载包含生成用于消费的所有网站资产的捆绑包。

签名HTTP交换(也称为。SXG)(IETF草案):它们允许浏览器信任单个HTTP请求/响应对是由其声明的来源生成的。

Web捆绑包(以前称为捆绑的HTTP交换)(IETF草案):HTTP资源的集合,每个资源都可以签名或未签名,其中有一些元数据描述如何将捆绑包作为一个整体进行解释。

它允许网站将资源“捆绑”在一起,并将使浏览器不可能通过URL来推理子资源。这可能会使Web从一个超链接的资源集合(可以审计、有选择地获取甚至替换)变成不透明的全有或全无的“BLOB”(如PDF或SWF)。

通过将URL从有意义的全球标识符改变为任意的、与套餐相关的索引,WebBunles为广告商和跟踪者提供了强大的新方式来逃避隐私和安全保护网络工具。“。

“避开隐私和安全工具,因为WebBundles中的URL是对捆绑包中资源的任意引用,而不是对资源的全局共享引用。比如,当前Web上到处都被称为example.org/tracker.js的东西,可以在一个WebBundle中称为1.js,在下一个2.js中称为1.js,在第三个3.js中称为3.js,等等,因此缓存“间谍脚本”以便隐私保护工具可以阻止它变得非常复杂。

“更糟糕的是,WebBunles允许网站通过使相同的URL指向每个捆绑包中的不同内容来避开拦截工具。在当前的网络上,https://example.org/ad.jpg为每个人指出了同样的事情。对于一个网站来说,让相同的URL从相同的URL返回两个不同的图像是很困难的。因此,拦截工具可以拦截ad.jpg,因为它们知道它们是在屏蔽每个人的广告;

我强烈推荐阅读这篇文章,以全面了解Brave杰出研究工程师共同关注的安全和隐私问题。

在基于位置的寻址互联网中,对WebBunles的大胆担忧是合法的,但一旦我们从基于位置的寻址方法切换到互联网的基于内容的寻址方法,所有这些问题都会立即消除。但是你知道吗?我们已经有了一个基于内容的互联网寻址版本,它被称为IPFS。为什么不在那里开始测试这些标准呢?

为了理解这两种方法之间的差异和对互联网的影响,让我分享我的同事扬尼斯的这篇帖子中的这两个很棒的段落。

他说:“我们的互联网是为定位寻址而设计的。从本质上讲,这意味着如果同一条街道上的两个家庭正在传输相同的内容,网络将需要将相同的信息从原始源位置传输两次:第一次传输到一个家庭,然后传输到另一个家庭。这是因为我们的请求正被转发到内容所在的服务器(的IP地址)。

使用基于内容的寻址,内容可以由以前的收件人传送,而不是每次都从原始源重新传输数据。第一个家庭或附近的网络路由器将临时将内容存储在本地设备上,然后当另一个邻居请求此内容时,该设备将充当源。使用基于内容的寻址,内容具有唯一标识符。(可以将其视为设备的序列号,或者数字出版物的数字对象标识符或ISBN号。)。我们的请求明确要求内容本身,而不是内容所在的IP地址。因此,我们的请求将找到存储在离请求者最近的内容副本,而不需要前往原始源。“

您明白为什么WebBunles在传统Web中可能没有意义,但在基于内容的寻址Internet中却可能是一次飞跃?WebBunles可以存储在分散的网络中,并提供给来自存储内容的“最近”同行的用户。此Web替代架构具有CDN by-design。不用再去互联网的中坚力量去获取所有的内容,这有多酷?

更重要的是,在内容寻址网络中,捆绑包是唯一标识的,因此不会再伪造到捆绑包不同版本的链接。如果https://example.com指向包<;CID1>;,则对此URL的每个请求都将指向相同的内容。此外,此内容将使用SGX进行签名,因此我们不仅可以检查捆绑包是否正确,还可以验证生成内容的来源。这个想法并不新颖,它已经像这段视频中显示的那样进行了简短的原型制作:

当然,出于说明性的原因,我可能过于简化了场景,但是我想在这里强调的一点是,虽然WebBunles对于传统Internet来说可能看起来是一个可怕的想法,但与IPFS提出的替代体系结构相比,它可能并不是一件坏事。

对我来说,WebBunles感觉像是朝着弥合网络和我们的设备之间的鸿沟又迈进了一步。归根结底,WebBundle之于浏览器就像应用程序包之于操作系统,主要区别在于WebBunles可以被视为比传统软件包更具动态性。下载WebBundle的更新相当于在浏览器中按F5。我们正变得越来越依赖Web应用程序,而应用程序本身正在发展成极其复杂的系统,WebBunles可以为新的应用程序、UX和新的互联网使用方式打开大门。

计算正在与底层基础设施脱钩。在我看来,像WebBundle或WebAssembly这样的技术的目标是建立一个代码可以在任何地方无缝执行的世界的基础。不再需要供应商锁定、浏览器/操作系统依赖或特定于系统的执行。什么鬼东西!总有一天,我们可能根本不需要设备,一切都会在网络中,我们只有连接全球、计算和存储的接口。但我想我们得一步一步来。下周见!

如果您想帮助构建这一愿景,请毫不犹豫地查看一下,它可能会让您感兴趣;)