Web是否会曝光硬件功能？

最近，我对不同浏览器供应商对 Web 未来的不同意见很感兴趣——特别是在推动 Web 平台功能更接近原生平台的各种努力中，例如 Chromium 的 Project Fugu。

主要立场可以概括为：

• 谷歌（与英特尔、微软和三星等合作伙伴一起）正在积极推进和创新，使用大量新的 API，如 Fugu 中的 API，并在 Chromium 中发布它们；
• 苹果正在以更保守的方式进行反击，将许多新的 API 标记为引发安全和隐私问题；
• 这（连同 Apple 在 iOS 中对浏览器选择的限制）创造了一种立场，将 Safari 标记为新的 IE，同时声称 Apple 正在减慢 Web 的进展；
• 在这点上，Mozilla 似乎更接近于苹果而不是谷歌。

我在本文中的目的是查看 Google 确定的声明，特别是 Fugu 项目负责人 Alex Russell 在平台邻接理论中的声明，查看这些声明中提供的证据，也许会得出我自己的结论。

具体来说，我打算深入研究 WebUSB（Fugu 项目中一个特别有争议的 API），检查针对它的安全声明是否有价值，并尝试看看是否会出现替代方案。

平台邻接理论

上述理论提出以下主张：

• 软件正在转向网络，因为它是更好的计算版本；
• 网络是一个元平台——一个从其操作系统中抽象出来的平台；
• 元平台的成功是基于它完成了我们期望大多数计算机做的事情；
• 以安全为由拒绝向 Web 元平台添加相邻功能，同时忽略原生平台中的相同安全问题，最终将使 Web 变得越来越不相关；
• Apple 和 Mozilla 正是这样做的——拒绝向网络添加相邻的计算能力，从而“将网络投射成琥珀”。

我与作者保持开放网络相关性的热情有关，并且担心使用新功能增强网络速度太慢会使其无关紧要。 我对应用商店和其他围墙花园的厌恶加剧了这一点。 但作为一个用户，我可以理解相反的观点——当我不知道我正在浏览的网站能够做什么或不能做什么时，我有时会头晕目眩，我发现平台限制和审核令人欣慰。

元平台

为了理解“元平台”这个术语，我研究了这个理论使用这个名称的含义——Java 和 Flash，它们都是世纪之交的产品。

我发现将 Java 或 Flash 与 Web 进行比较是令人困惑的。 正如理论中提到的，Java 和 Flash 在当时都通过浏览器插件广泛分布，使它们更像是浏览器平台之上的替代运行时。 今天，Java 主要用于服务器和作为 Android 平台的一部分，除了语言之外，两者没有太多共同点。

今天，服务器端 Java 可能是一个元平台，node.js 也是服务器端元平台的一个很好的例子。 它是一组 API、一个跨平台运行时和一个包生态系统。 事实上，node.js 一直在添加更多功能，以前只能作为平台的一部分。

在客户端，基于 C++ 的跨平台框架 Qt 没有单独的运行时，它只是一个（好！）用于 UI 开发的跨平台库。

Rust 也是如此——它是一种语言和包管理器，但不依赖于预安装的运行时。

开发客户端应用程序的其他方法主要是特定于平台的，但也包括一些跨平台的移动解决方案，如 Flutter 和 Xamarin。

能力与时间

理论中的主图显示了元平台在能力与时间的二维轴上的相关性：

当谈到上面提到的跨平台开发框架（如 Qt、Xamarin、Flutter 和 Rust）以及服务器平台（如 node.js 和 Java/Scala）时，我可以看到上图的意义。

但是以上所有内容都与网络有一个关键的区别。

第三维度

前面提到的元平台确实在与它们的主机操作系统竞争能力，但与网络不同的是，它们对信任和分布没有固执己见——在我看来，上图中缺少的第三个维度。

Qt 和 Rust 是创建应用程序的好方法，这些应用程序通过 WebAssembly 分发，直接下载并安装在主机操作系统上，或者通过 Cargo 等包管理器或 Ubuntu 等 Linux 发行版进行管理。 React Native、Flutter 和 Xamarin 都是创建通过应用商店分发的应用的不错方式。 node.js 和 Java 服务通常通过 docker 容器、虚拟机或其他一些服务器机制分发。

用户大多不知道用于开发他们的内容的内容，但在一定程度上知道它是如何分发的。 用户不知道 Xamarin 和 node.js 是什么，如果有一天他们的 Swift 应用程序被 Flutter 应用程序取代，大多数用户不会而且理想情况下不应该关心它。

但用户确实了解网络——他们知道当他们在 Chrome 或 Firefox 中“浏览”时，他们是“在线”的，可以访问他们不一定信任的内容。 他们知道下载和安装软件可能存在危险，并且可能会被 IT 管理员阻止。 事实上，对于网络平台来说，用户知道他们当前正在“浏览网络”是很重要的。 这就是为什么，例如，切换到全屏模式会向用户显示一个清晰的提示，并说明如何从中恢复。

网络之所以成功，是因为它不透明——但显然与其主机操作系统分离。 如果我不能相信我的浏览器会阻止随机网站读取我硬盘上的文件，我可能不会去任何网站。

用户还知道他们的计算机软件是“Windows”还是“Mac”，他们的手机是基于 Android 还是基于 iOS，以及他们当前是否正在使用应用程序（在 iOS 或 Android 上，以及在某种程度上在 Mac OS 上） . 操作系统和分发模型通常为用户所知——用户信任他们的操作系统和网络来做不同的事情，并且信任程度不同。

因此，如果不考虑其独特的分发模型，则无法将 Web 与跨平台开发框架进行比较。

另一方面，Web 技术也用于跨平台开发，例如 Electron 和 Cordova 等框架。 但这些并不完全是“网络”。 与 Java 或 node.js 相比，“Web”一词需要替换为“Web Technologies”。 并且以这种方式使用的“网络技术”不一定需要基于标准或在多个浏览器上工作。 关于 Fugu API 的讨论与 Electron 和 Cordova 有点无关。

原生应用

在为 Web 平台添加功能时，不能忽视或轻视第三个维度——信任和分发模型。 当作者声称“Apple 和 Mozilla 关于新功能风险的姿态被公认的现有原生平台风险所掩盖”时，他将 Web 和原生平台在信任方面置于同一维度。

诚然，原生应用程序有其自身的安全问题和挑战。 但我不明白这是支持更多网络功能的论据，就像这里一样。 这是一个谬论——结论应该是解决本机应用程序的安全问题，而不是放松网络应用程序的安全性，因为它们处于与操作系统功能相关的追赶游戏中。

如果不考虑信任和分发模型的第三维，Native 和 Web 无法在能力上进行比较。

应用商店限制

理论中对原生应用程序的批评之一是 iOS 上缺乏浏览器引擎选择。 这是对苹果的普遍批评，但对此有不止一个观点。

批评专门针对 Apple 应用商店审查指南的第 2.5.6 条：

“浏览网页的应用程序必须使用适当的 WebKit 框架和 WebKit JavaScript。”

这似乎是反竞争的，而且我对 iOS 的限制程度有自己的保留。 但是如果没有应用商店审查指南的其余部分的上下文，则无法阅读第 2.5.6 项，例如第 2.3.12 项：

“应用程序必须在其‘新增功能’文本中清楚地描述新功能和产品变化。”

如果一个应用程序可以接收设备访问权限，然后包含可以执行来自任何网站的代码的自己的框架，那么应用程序商店审查指南中的那些项目将变得毫无意义。 与应用程序不同，网站不必在每次修订时描述其功能和产品更改。

当浏览器提供实验性功能时，这将成为一个更大的问题，例如 Fugu 项目中的功能，这些功能尚未被视为标准。 谁定义了浏览器是什么？ 通过允许应用程序发布任何 Web 框架，应用程序商店实质上将允许“应用程序”运行任何未经审计的代码，或完全更改产品，从而绕过商店的审查流程。

作为网站和应用程序的用户，我认为他们都在计算世界中占有一席之地，尽管我希望尽可能多地转移到网络上。 但考虑到网络标准的当前状态，以及围绕蓝牙和 USB 等事物的信任和沙盒维度如何远未得到解决，我不认为允许应用程序自由执行来自网络的内容对用户有什么好处.

Appiness的追求

在另一篇相关的博客文章中，同一位作者在谈到原生应用程序时谈到了其中的一些问题：

“成为‘一个应用程序’只是满足一组任意且可变的操作系统约定。”

我同意“应用程序”的定义是任意的，它的定义依赖于定义应用程序商店政策的人的观点。 但是今天，浏览器也是如此。 帖子中声称Web 应用程序默认安全的说法也有些武断。 谁在“什么是浏览器”这个问题上划清界限？ 带有内置浏览器的 Facebook 应用程序是“浏览器”吗？

应用程序的定义是任意的，但也很重要。 事实上，使用低级功能的应用程序的每个修订都由我可能信任的人审核，即使这个人是任意的，这使得应用程序成为它们的样子。 如果那个人是我购买的硬件的制造商，那就更不随意了——我购买计算机的公司是对该计算机功能较低的审计软件。

一切都可以是浏览器

无需像 Apple 应用商店本质上那样画一条“什么是浏览器”，每个应用都可以发布自己的网络引擎，诱使用户使用其应用内浏览器浏览任何网站，并添加任何跟踪代码它想要，折叠应用程序和网站之间的第三维差异。

当我在 iOS 上使用应用程序时，我知道我的行为目前会暴露给两个玩家：Apple 和指定的应用程序制造商。 当我在 Safari 或 Safari WebView 中使用网站时，我的操作会暴露给 Apple 和我当前正在查看的网站的顶级域的所有者。 当我使用带有未识别引擎的应用内浏览器时，我会接触到应用程序制造商 Apple 和顶级域的所有者。 这可以创建可避免的同源违规，例如应用程序的所有者跟踪我在外国网站上的所有点击。

我同意也许“Only WebKit”的界限太苛刻了。 对于不会创建用于跟踪用户浏览的后门的浏览器的另一种定义是什么？

关于苹果的其他批评

该理论声称，Apple 拒绝实施功能不仅限于隐私/安全问题。 它包含一个链接，该链接确实显示了许多在 Chrome 中而不是在 Safari 中实现的功能。 但是，当向下滚动时，它还列出了在 Safari 中实现而不是在 Chrome 中实现的大量其他功能。

这两个浏览器项目有不同的优先级，但这与“游戏在缩小时变得清晰”的明确声明以及对苹果试图将网络投射为琥珀色的严厉批评相去甚远。

此外，标题为it's hard 的链接，我们不想尝试导致 Apple 声明，如果满足安全/隐私问题，他们将实施功能。 我觉得将这些链接与这些标题放在一起是一种误导。

我同意一个更平衡的说法，即在实现功能和推进网络方面，谷歌比苹果更乐观。

权限提示

谷歌在 3rd 维度上进行了长期的创新，开发了新的方法来在用户、开发人员和平台之间建立信任，有时取得了巨大的成功，例如可信网络活动。

但是，与设备 API 相关的第 3 维中的大部分工作都集中在权限提示上，使它们更加可怕，或者诸如时间框权限授予和黑名单域之类的东西。

“可怕的”提示，就像我们不时看到的这个例子中的提示一样，看起来它们是为了阻止人们去那些看起来可能是恶意的页面。 因为它们如此明目张胆，这些警告鼓励开发人员转向更安全的 API 并更新他们的证书。

我希望对于设备访问功能，我们可以提出鼓励参与并确保参与安全的提示，而不是阻止它并将责任转移给用户，而 Web 开发人员没有可用的补救措施。 稍后再谈。

我确实同意 Mozilla 和 Apple 至少应该尝试在该领域进行创新而不是“拒绝实施”的论点。 但也许他们是？ 例如，我认为来自 Apple 的 isLoggedIn 是一个有趣且相关的提议，它是未来设备 API 可以构建的第三维度——例如，当当前网站已经知道用户的身份时，可以提供易于指纹识别的设备 API。用户。

网络USB

在下一节中，我将深入研究 WebUSB，检查它允许什么，以及它是如何在第三维处理的——什么是信任和分发模型？ 够了吗？ 有哪些替代方案？

前提

WebUSB API 允许对未列入黑名单的设备类的 USB 协议进行完全访问。

它可以实现强大的功能，例如连接到 Arduino 板或调试 Android 手机。

看到 Suz Hinton 关于这个 API 如何帮助实现以前非常昂贵的事情的视频令人兴奋。

例如，我真的希望平台能够找到更开放的方法，并允许对教育硬件/软件项目进行快速迭代。

有趣的感觉

但是，当我看到 WebUSB 支持什么以及 USB 存在的一般安全问题时，我仍然有一种有趣的感觉。

USB 感觉太强大了，因为它是一种暴露在网络上的协议，即使有权限提示也是如此。

所以我进一步研究了。

Mozilla 的官方观点

我首先阅读了 David Baron 在 Mozilla 的官方标准立场中谈到了 Mozilla 最终拒绝 WebUSB 的原因：

“由于许多 USB 设备并非旨在处理通过 USB 协议进行的潜在恶意交互，而且这些设备可能会对它们所连接的计算机产生重大影响，因此我们认为将 USB 设备暴露于 Web 的安全风险也很大。宽泛的风险让用户接触他们或向最终用户正确解释以获得有意义的知情同意。”

当前的许可提示

这是发布这篇文章时 Chrome 的 WebUSB 权限提示的样子：

特定域 Foo 想要连接到特定设备 Bar。 做什么？ 我怎么能确定呢？

在授予对打印机、摄像头、麦克风、GPS 的访问权限，甚至是一些包含更多 WebBluetooth GATT 配置文件（如心率监测）的权限时，这个问题相对清晰，并且侧重于内容或操作而不是设备。 清楚地了解我想从外围设备获得什么信息或我想用它执行什么操作，并且用户代理进行调解并确保处理此特定操作。

USB 是通用的

与上面提到的通过特殊 API 公开的设备不同，USB 不是特定于内容的。 如规范介绍中所述，WebUSB 走得更远，并且是专门为未知或尚未发明的设备类型设计的，而不是为键盘或外部驱动器等知名设备类别设计的。

因此，与打印机、GPS 和相机的情况不同，如果没有深入了解特定设备并审核访问它的代码。

Yubikey 事件和缓解措施

不久前的一个很好的例子是 Yubikey 事件，其中 Chrome 的 WebUSB 被用来从 USB 供电的身份验证设备中钓鱼数据。

由于这是一个据说已经解决的安全问题，我很想深入研究 Chrome 在 Chrome 67 中的缓解工作，其中包括阻止一组特定的设备和一组特定的类。

类/设备块列表

因此，除了当前非常通用的权限提示之外，Chrome 对野外发生的 WebUSB 漏洞利用的实际防御是阻止特定设备和设备类。

对于新技术或实验来说，这可能是一个简单的解决方案，但是当（以及如果）WebUSB 变得更流行时，它会变得越来越难实现。

恐怕通过 WebUSB 在教育设备上进行创新的人们可能会遇到困难。 当他们完成原型设计时，他们可能会面临一组不断变化的非标准阻止列表，这些列表仅与浏览器版本一起更新，基于与他们无关的安全问题。

我认为在不解决这个问题的情况下标准化这个 API 最终会对依赖它的开发人员产生反作用。 例如，有人可能会花费周期为运动检测器开发 WebUSB 应用程序，但后来发现运动检测器成为一个被阻止的类，要么是出于安全原因，要么是因为操作系统决定处理它们，导致他们的整个 WebUSB 工作都转移到了浪费。

安全与功能

平台邻接理论在某些方面认为能力和安全是一场零和游戏，在安全和隐私问题上过于保守会导致平台失去相关性。

让我们以Arduino为例。 使用 WebUSB 可以进行 Arduino 通信，这是一个主要用例。 开发 Arduino 设备的人现在必须考虑一个新的威胁场景，其中一个站点尝试使用 WebUSB（在某些用户许可下）访问他们的设备。 根据规范，这家设备制造商现在必须“将他们的设备设计为只接受签名固件”。 这会增加固件开发人员的负担，并增加开发成本，而规范的整个目的是做相反的事情。

是什么让 WebUSB 与其他外设不同

在浏览器中，用户交互和合成交互（由网页实例化的交互）之间有明显的区别。

例如，网页不能自行决定点击链接或唤醒 CPU/显示器。 但是外部设备可以——例如，鼠标设备可以代表用户单击链接，几乎任何 USB 设备都可以唤醒 CPU，具体取决于操作系统。

因此，即使使用当前的 WebUSB 规范，设备也可以选择实现多个接口，例如调试 adb 和用于指针输入的 HID，以及使用利用 ADB 的恶意代码，成为键盘记录器并代表用户浏览网站，假设正确的可利用固件刷新机制。

对于使用 ADB 或其他允许的闪存形式破坏固件的设备而言，将该设备添加到阻止列表为时已晚，并且将使设备制造商比以前更加依赖浏览器版本来获取与其设备相关的安全修复程序。

知情同意和内容

如前所述，知情同意和 USB 的问题在于 USB（特别是在非通用 WebUSB 用例中）不是特定于内容的。 用户知道什么是打印机，什么是相机，但对于大多数用户来说，“USB”只是一根电缆（或一个插座）——一种达到目的的手段——很少有用户知道 USB 是一种协议以及在网站之间启用它的原因和设备手段。

一个建议是有一个“可怕的”提示，类似于“允许此网页接管设备”（这是对看似无害的“想要连接”的改进）。

但就像提示一样可怕，他们无法解释通过原始访问浏览器不知道的 USB 外围设备可以完成的可能事情的广度，如果他们这样做了，他们头脑正常的用户不会点击“是” ”，除非它是他们完全相信没有错误的设备，并且是他们真正相信是最新且无恶意的网站。

像这样的可能提示将显示“允许此网页可能接管您的计算机”。 我不认为像这样的可怕提示对 WebUSB 社区有益，对这些对话框的不断更改会使社区感到困惑。

原型与产品

我可以看到一个可能的例外。 如果 WebUSB 和 Fugu API 的其他项目的前提是支持原型设计而不是产品级设备，那么包罗万象的通用提示可能是有意义的。

不过，为了实现这一目标，我认为必须做到以下几点：

1. 在规范中使用对原型设计设定期望的语言；
2. 只有在某些选择加入手势后才能使用这些 API，例如让用户在浏览器设置中手动启用它们；
3. 有“可怕的”权限提示，例如无效 SSL 证书的提示。

没有上述内容让我认为这些 API 是针对真实产品而不是原型的，因此，反馈是成立的。

另一种建议

我同意原始博客文章中的一个部分是说“不”是不够的——网络世界中拒绝某些 API 有害的主要参与者也应该采取进攻并提出这些功能重要的方式可以安全地暴露给用户和开发人员。 我不代表任何主要玩家，但我会谦虚地尝试一下。

我相信这个问题的答案在于信任和关系的第三个维度，并且它超出了许可提示和阻止列表的范围。

直截了当且经过验证的提示

我要提出的主要情况是提示应该是关于内容或操作，而不是关于外围设备，并且可以为具有一组特定验证参数的特定直接操作授予知情同意，而不是针对一般操作，例如“接管”或“连接”设备。

3D 打印机示例

在 WebUSB 规范中，以 3D 打印机为例，所以我将在这里使用它。

在为 3D 打印机开发 WebUSB 应用程序时，我希望浏览器/操作系统提示询问我是否允许 AutoDesk 3ds-mask 将模型打印到您的 CreatBot 3D 打印机？ ，显示一个浏览器/操作系统对话框，其中包含一些打印参数，如细化、厚度和输出尺寸，以及将要打印的内容的预览。 所有这些参数都应该由受信任的用户代理验证，而不是通过路过的网页。

目前，浏览器不知道打印机，它只能验证提示中的一些声明：

• 请求域具有注册到 AutoDesk 的证书，因此可以确定这是 AutoDesk Inc；
• 请求的外围设备称自己为“CreatBot 3d 打印机”；
• 在浏览器的阻止列表中找不到该设备、设备类和域；
• 用户对他们被问到的一般问题回答“是”或“否”。

但为了显示真实的提示并与上述详细信息对话，浏览器还必须验证以下内容：

• 获得许可后，执行的操作将是打印 3D 模型，仅此而已；
• 将尊重所选参数（细化/厚度/尺寸等）；
• 向用户显示了将要打印的内容的经过验证的预览；
• 在某些敏感情况下，需要额外验证这实际上是 AutoDesk，可能使用可撤销的短期令牌之类的东西。

在不验证上述情况的情况下，被授予“连接”或“接管”3D 打印机权限的网站可以由于错误（或其依赖项之一中的恶意代码）开始打印巨大的 3D 模型。

此外，想象中的成熟网络 3D 打印功能将比 WebUSB 提供的功能多得多——例如，假脱机和排队不同的打印请求。 如果浏览器窗口关闭，将如何处理？ 我还没有研究所有可能的 WebUSB 外围用例，但我猜测从内容/操作的角度来看它们时，大多数需要的不仅仅是 USB 访问。

由于上述原因，使用 WebUSB 进行 3D 打印可能会很笨拙且寿命短，依赖它的开发人员必须在某个时候为他们的打印机提供“真正的”驱动程序。 例如，如果操作系统供应商决定添加对 3D 打印机的内置支持，则所有使用该打印机和 WebUSB 的站点都将停止工作。

提案：司机审计机关

所以，像“接管外围设备”这样的总体权限是有问题的，我们没有足够的信息来显示一个完整的参数对话框并验证它的结果是否会得到尊重，我们不想发送用户在不安全的旅程中从网络下载随机可执行文件。

但是如果有一段经过审计的代码，一个驱动程序，在内部使用 WebUSB API 并执行以下操作：

• 实现了“打印”命令；
• 显示页外打印对话框；
• 连接到一组特定的 USB 设备；
• 当页面在后台时（例如在服务工作者中），甚至在浏览器关闭时执行它的一些操作。

像这样对驱动程序进行审计可以确保它所做的相当于“打印”，它尊重参数，并显示打印预览。

我认为这类似于证书颁发机构，这是 Web 生态系统中与浏览器供应商有些脱节的重要部分。

司机联合

驱动程序不必由 Google/Apple 审核，但浏览器/操作系统供应商可以选择自行审核驱动程序。 它可以像 SSL 证书颁发机构一样工作——颁发者是一个高度信任的组织； 例如，特定外围设备的制造商或认证许多驱动程序的组织，或像 Arduino 这样的平台。 （我想象会出现类似于 Let's Encrypt 的组织。）

对用户说：“Arduino 相信这段代码会用这个固件刷新你的 Uno”（固件预览）可能就足够了。

注意事项

这当然不是没有潜在的问题：

• 驱动程序本身可能是错误的或恶意的。 但至少它是经过审计的；
• 它不那么“webby”，并产生了额外的开发负担；
• 它今天不存在，也无法通过浏览器引擎的内部创新来解决。

其他选择

其他替代方案可能是以某种方式标准化和改进跨浏览器 Web 扩展 API，并使现有的浏览器插件商店（如 Chrome Web Store）成为某种驱动审计机构，在用户请求和外围设备访问之间进行调解。

意见摘要

作者、谷歌和合作伙伴通过增强其功能来保持开放网络相关性的大胆努力令人鼓舞。

当我深入了解细节时，我认为 Apple 和 Mozilla 对网络的更为保守的看法，以及他们对新设备功能的防御方法，具有技术优势。 围绕开放式硬件功能的知情同意的核心问题远未得到解决。

在讨论中，苹果可能会更加积极地寻找启用设备功能的新方法，但我相信这来自于计算的不同观点，这是苹果几十年来身份的一部分，而不是从反竞争的角度来看。

为了支持 Fugu 项目中有些开放的硬件功能，特别是 WebUSB，Web 的信任模型需要超越权限提示和域/设备阻止列表，从证书颁发机构等信任生态系统中汲取灵感，以及包分发。

关于 SmashingMag 的进一步阅读：

• 提高网站性能如何帮助拯救地球
• 迈向无广告网络：使在线经济多样化
• 除了编写出色的代码之外还有未来吗？
• 在网页设计中使用道德规范