在提供隔离浏览器选项卡（虚拟机）的 Web 浏览器开发中应用管理程序（例如 xen）原则将如何提高或降低现有 Web 应用程序（编码良好或编码不良）的安全性。
在这种情况下，Web 应用程序将是一个选项卡，具有跨源策略，使用白名单方法并将选项卡（unix 监狱）囚禁在作为核心浏览器的可写副本的父窗口监狱中。实际的浏览器本身可以是只读的，并在启动时执行签名检查。
跨源策略将只是一个清单文件，它将允许的资源（如图像、javascript、css、字体等）列入白名单。
这个概念是什么都不共享，关闭浏览器窗口将完全删除任何痕迹。所有 tmp 文件都存储在监狱中。这应该可以防止在窗口/选项卡关闭后浏览器实现中的漏洞被利用。
从理论上讲，这个概念可以扩展到允许像 Tor 这样的窗口插件/插件，使主流用户可以使用匿名和隐私。
Web 浏览器已经尝试将选项卡彼此隔离。Chrome 开创了“每个标签一个进程”的原则，其他浏览器也纷纷效仿。这种隔离是为了可靠性而不是安全性：当一个标签崩溃时，例如由于插件中的错误，也可以防止整个浏览器进程死亡。
使用 VM 技术，无论是 Unix 级别的监狱还是成熟的虚拟机管理程序，都可以在标签被破坏的情况下提供帮助：通过一些安全漏洞，攻击者设法在您的浏览器中运行他自己的恶意代码。然后，VM 将尝试遏制该攻击。请注意，该问题具有深远的影响：例如，Web 浏览器必须能够读取本地文件，才能支持要求上传本地文件的网站。当强制执行完全隔离时，功能会减少。
如果您想要完全隔离，请参阅Qubes OS：这是一个基于 Linux 的操作系统，它为单个应用程序（或一组应用程序）启动小型 VM，并允许您运行多个相互看不到的浏览器实例。
但是，问题是您通常不希望完全隔离，并且恶意的全进程劫持很少见。浏览器已经应用了某种不使用管理程序但（通常）有效的隔离。安全问题不是来自标签进程的中断，而是来自浏览器为实现所需功能而在标签之间维护的通信渠道。同源策略是一个重要的概念，它是问题的一部分：SOP 体现了浏览器强制执行的安全模型，Web 浏览器的大多数安全问题是由于定义 SOP 边界的模糊性造成的。
打个比方，考虑一堵砖墙，里面有一扇门。使用管理程序技术类似于用钢加固墙壁和门框。这还不错，但如果真正的问题是门没有锁上，那将无济于事。当试图在浏览实例之间强制隔离时，真正困难的是准确定义哪些可以共享，哪些不应该共享；管理程序在较低级别运行，只是执行策略的工具，但必须首先定义策略。
感谢@Thomas Pornin 和 @Ramhound，
基于浏览器的 VM 已经有一些实现（无头浏览器）。在写这个问题的时候，我并没有意识到 Chrome 已经实现了这一飞跃。
概念实现：
替代概念：
批评：
请在评论中添加到此列表中，我将更新答案。