IPFS和Igalia在浏览器中的dweb上合作

2021-01-18 16:01:19

IPFS和Igalia做出了初步努力,以改善对分布式平台以及整个Web社区有利的Web平台功能的支持和互操作性。

  TL; DR

  •IPFS和Igalia开始了一项合作,并将在2021年继续进行。

  •Chrome 86的自定义处理程序实现中已将分布式Web方案列入安全清单,并已在IANA上注册。

  •Chrome 89允许浏览器扩展注册跨域处理程序或具有prefix的方案的处理程序ext+。权限UI正在等待优化。

  •Firefox 84将http://*.localhost/URL标记为安全上下文,这意味着从本地子域网关加载的网站将可以访问与HTTPS版本相同的Web API。

  •Firefox 84改进了对加载本地交付的混合资源的支持。修补程序也已提交给WebKit,但正在等待评论和讨论。

  •有关安全上下文概念的工作正在改善Chromium的一致性和规范合规性,包括删除非标准的localhost名称。

  •Firefox和Chromium的自定义处理程序实现还进行了其他修复。


  背景

  如今,Web上的大多数页面都来自其所有者控制的中央服务器。所述IPFS协议设想未来的Web其中内容可被传递对等网络,个人之间或群体内直接的意思。为了达到分布式Web的目标,已经进行了Web平台和浏览器的努力。

  尽管如此,要使浏览器本地支持并在Web标准中考虑到相应的协议,就需要与Web的不同参与者进行协调,包括标准化组(W3C,WHATWG等)和浏览器实现者。

  考虑到这一目标,Protocol Labs与Igalia开始了合作,Igalia是一家开源公司,在浏览器开发和Web平台方面具有专业知识。在此博客文章中,介绍了今年针对非本地实现获得的初步结果。对于用户而言,这是一个很好的第一步,也是开始讨论并提高对分布式Web的认识的机会。


  自定义处理程序中的分布式Web协议

自定义处理程序中的分布式Web协议


  在本机不支持该协议的浏览器中使用IPFS的现有方法是依靠HTTP网关。此外,可以使用HTML自定义处理程序自动执行IPFS链接的重定向。但是,这种方法有几个局限性:

  1、自定义处理程序仅在Mozilla和Chromium浏览器中实现,而不是在基于WebKit的浏览器中实现。

  2、定制处理程序仅接受带有前缀web+或属于预定安全列表的方案。

  3、自定义处理程序仅允许注册与注册它的页面具有相同来源的处理程序。

  4、处理URL的Web规范可能无法很好地重定向到HTTP网关。

  关于第一个问题,过去人们已经向WebKit提交了补丁。尽管最终可能会再次考虑这一点,但到目前为止,WebKit社区内部尚未就是否应实现此API达成任何共识。

  其结果之一是,为了安全列出更多方案,必须从Mozilla和Chromium实现者那里获得支持。事实证明,这在历史上是困难的,许多用户打开了针对不同方案的请求,但由于缺乏共识而最终被搁置了。第一个任务是重新打开浏览器供应商与用户之间的讨论,以消除这种情况。

  然后重点已经转移到分布式网络协议(cabal,dat,did,dweb,ethereum,hyper,ipfs,ipns,和ssb)。这些(以及社区要求的其他几种方案)已在IANA上注册。Firefox和HTML规范的相应更改也已准备就绪,但仍在Mozilla上进行。最后,这些用于分布式Web协议的方案已在最新的Chromium版本中安全列出。


  浏览器扩展

  出于安全原因,当网页注册自定义处理程序时,希望具有同源限制。但是,当这样的注册发生在用户信任的浏览器扩展中时,将其作为例外是有意义的。例如,很长一段时间以来,Firefox一直允许ipfs直接在WebExtension清单中声明自定义处理程序以及其他协议,而无需进行同源检查。

  Chromium错误跟踪器中已有关于此功能的请求。为了解决这个问题,第一步是遵循Chromium项目的流程,并根据现有用例和Firefox实施的内容起草提案。

  由于Chromium项目强烈希望依靠Web API来提供新的扩展功能,因此代码所有者的反对建议是registerProtocolHandler在扩展上下文中(跨域处理程序和特定于扩展的方案)赋予更多权力。这些补丁的两个补丁最近登陆了Chromium,并将在89版中提供!

  目前,由于存在权限UI错误,协议注册必须在扩展标签中进行,但是您已经可以在此视频中了解新的可能性(请确保启用字幕进行详细说明):


扩展注册IPFS的HTTP网关的演示


  安全上下文

  重定向的URL不能像普通URL一样表现出一些棘手的问题,并且可能来自多种原因。对于本地HTTP网关(例如IPFS Desktop提供的网关),一种解释是浏览器过去不将这些本地URL视为安全上下文,因此阻止了各种Web平台功能。三年前在Chrome中对此进行了更改,并相应地更新了规格。更确切地说:

  •潜在可信赖来源的定义包括那些宿主为环回IPv4和IPv6地址以及(可选)localhost和*.localhost名称的来源。

  •此可选行为取决于以下事实:浏览器在解析localhost名称时会覆盖本机DNS。

  Mozilla支持此更改。自Firefox 55起就实现了环回IP地址的情况,但是由于这种情况发生在开发资源和优先级有限的情况下,因此本地主机名称的工作从未完成。困难之一是许多现有的网络测试没有采取上述行为,并且需要进行一些调整以保持通过。经过几次尝试,主要补丁降落而未还原,并在最新版本的Firefox中发布。

  WebKit社区中的位置尚不清楚,有些成员对授予网站访问本地主机的权限持怀疑态度,另一些成员则认为在Chrome和Firefox中实现的行为是有意义的。与Firefox类似,一个困难是需要调整许多测试。此外,在WebKit级别似乎不容易实现地址重定向。可以找到有关相应bug的详细信息。为了使事情顺利进行,已提交了基于首选项的修补程序以供审核。

  实际上,这个问题不仅仅是本地资源。在浏览器之间,甚至在每个浏览器中,“安全上下文”的整个概念并不是一致实现的。除了上面提到的一种潜在可信赖的来源之外,该规范还具有一些潜在的可信赖的URL的一般概念,该概念用于与先验身份验证的URL进行区分。这些概念如何与自定义处理程序进行交互目前还有些模糊。

  在Chromium中,至少有6种“安全”的实现。其中一些实现与当前规范不太吻合。更糟的是,他们中的一些包括像历史和非标准的本地主机名localhost.localdomain,localhost6和localhost6.localdomain6。正在努力逐步并仔细地统一这些实现并遵循规范。特别是,修补程序登陆以删除非标准的localhost 名称,并使data:URL可能值得信赖。


  其他修复

  像往常一样,执行此类工作会导致很多附带任务:社区和规范讨论,代码清理和重构,文档改进以及其他错误修复。修复了与自定义处理程序以及与Firefox的互操作性相关的Chromium错误:

  •让服务人员与自定义处理程序一起工作

  •验证(取消)registerProtocolHandler的URL时不要删除%s令牌

  •在由自定义协议处理程序计算的URL中,对U + 0020 SPACE进行百分比编码

  •解析URL时对删除字符进行百分比编码

  最后,对于Chromium和Firefox,根据Mozilla的建议,title参数已从registerProtocolHandler()中删除。


  火狐浏览器

  •改善protocol_handlers与registerProtocolHandler的兼容性

  •为registerProtocolHandler()安全列出cabal,dat,d,dweb,ethereum,hyper,ipfs,ipns和ssb方案。

  •从registerProtocolHandler()中删除title参数

  •运行XPCShell时不要设置network.dns.ipv4OnlyDomains

  •添加测试以确保环回主机名不能被覆盖

  •硬编码本地主机回送


  WebKit

  •不要把环回地址(127.0.0.0/8,:: 1 / 128个,本地主机,.localhost)混合内容

  •不要把环回IP地址(127.0.0.0/8,:: 1 / 128个)的混合内容

  •引入首选项,不要将localhost和.localhost视为混合内容

  •[GTK]允许WebKitTestServer运行非环回地址进行API测试

  •将WebKitTestServer迁移到libsoup 2.48 API

  •治疗回送地址(127.0.0.0/8,:: 1 / 128个,本地主机,.localhost)为潜在可信赖URL


  结论

  IPFS和Igalia做出了初步努力,以改善对分布式平台以及整个Web社区有利的Web平台功能的支持和互操作性。除了开始在不同参与者之间进行讨论之外,浏览器中已经安装了多个补丁。我们期待在2021年继续进行这项工作……敬请期待!


最新推荐