我正在尝试将任何已安装的 Google Chrome/Chromium 扩展程序与我更私密的网页浏览活动隔离开来。我的想法是设置两个 Chrome“用户”，其中一个用户进行更多私密浏览，另一个用户使用扩展程序进行较少私密浏览。我想知道这是否“合理”(*见下文) 安全。
假设我有以下设置：
- 我设置了 Chrome/Chromium，以便我有两个“用户”（通过Chrome 设置页面）。 给他们打电话用户Alice和用户鲍勃。
- 用户Alice有不已安装扩展。
- 用户鲍勃安装一些扩展。安装时，其中一些扩展被授予权限。
鉴于这种情况，主要问题是：
- 做扩展用户鲍勃有任何有可能访问哪怕是一小部分的活动和内容用户Alice？
- 如果“是”，那么哪些权限允许这种跨用户访问？
* 我说的“合理”是指我想防止以下情况：假设用户鲍勃安装了恶意扩展程序，可以以某种方式读取浏览的网站（例如电子邮件或银行）的用户名和密码。用户Alice浏览电子邮件和银行网站。“合理安全”意味着用户Alice的用户名和密码、电子邮件、银行信息等都无法被任何恶意扩展程序访问。用户鲍勃。
答案1
简短回答：只要您从 Chrome 网上应用店安装 Chrome 扩展程序，并且没有明确安装单独的独立二进制文件，那么默认情况下，该扩展程序就会被困在浏览器配置文件中，无法访问或修改其他 Chrome 用户。说“没有文件系统保护”是不准确的，因为 Chrome 从未支持过 XUL 类型的扩展程序。
我将介绍另一个答案中提到的两种方式，即扩展程序可以利用这两种方式来摆脱浏览器配置文件的限制并访问文件系统的其他部分，另外还有一种方式。第一种是通过 WebExtensionnativeMessaging权限，第二种是通过触发文件对话框，第三种是通过isAllowedFileSchemeAccessAPI。没有一种是自动的（无论是后台还是其他方式），都需要用户明确同意这种访问。
1) 使用该权限的 WebExtensionnativeMessaging无法自行引入特权原生应用。除非用户明确决定安装原生应用，否则 WebExtension 会被困在安装它的浏览器配置文件中。
另一个答案是，“如果任何扩展需要管理员权限才能安装”，那么该软件不仅仅包含一个纯粹的 Chrome 扩展，例如，该扩展会接入一个nativeMessaging安装在 Chrome 之外的独立客户端，而通过安装外部客户端（在 Chrome 之外），人们可能还会安装一个系统范围的独立键盘记录器二进制文件，它影响的不仅仅是浏览器。游戏结束了，但这是用户的错，因为他/她已经覆盖了浏览器提供的安全性。
2) 来自另一个答案：“我……能够启动一个便携式 Firefox 副本，其中我安装了 sqlite 浏览器……并浏览我的旧配置文件并查看我的历史记录。”文件对话框需要明确的用户交互，因此这不是安全漏洞。如果用户明确将文件加载到浏览器配置文件中以供扩展程序操作，则用户已表示同意将其数据与扩展程序共享。否则，扩展程序只能希望用户在“打开文件”对话框中选择一个文件，用户（回想一下配置文件是为了捕获潜在的不可信扩展程序）只需关闭即可。
3) isAllowedFileSchemeAccessChrome 上的 API 允许通过 file:// 协议对文件系统进行只读访问。但是，“用户必须通过 chrome://extensions 中的 Chrome 偏好设置窗格明确允许特定扩展程序执行此行为”，并且截至 2017 年初，CWS 上只有 55 个扩展程序要求执行此操作。（来源：Mozilla 维基百科) 不仅遇到扩展程序滥用此权限来窥探文件系统的可能性极小，而且该权限还要求用户手动将其授予浏览器扩展程序。
使用单独的浏览器配置文件来隔离潜在危险的扩展程序已经足够了，因为单独的操作系统级用户帐户是多余的，除非有人在防御完全破坏 Chrome 的 WebExtension API 权限模型的零日浏览器漏洞，在这种情况下，虚拟机级保护是必要的。如果我们使用的是利用漏洞的软件，那么操作系统级用户帐户提供的保护就不够了，因为我们现在正在玩恶意软件。
Chrome 应用完全是另一回事，因为它们比标准 Chrome 扩展程序享有更多权限，但它们是一种弃用的技术，更重要的是，超出了 OP 问题的范围，因为它询问的是 Chrome 扩展程序。因此，本答案不涉及 Chrome 应用。
总之，Chrome 扩展程序无法跨浏览器配置文件，除非 1）用户手动安装了 Chrome 外部的独立可执行文件，在这种情况下所有情况都无效 2）用户在扩展程序生成的文件打开对话框中选择一个文件，在这种情况下用户明确授予扩展程序任意文件访问的权限 3）用户手动勾选 chrome://extensions 中的框，而扩展程序本身无法修改该框。
答案2
只要这些用户是 Windows 中完全独立的用户，而不仅仅是 Chrome 中独立的配置文件，并且只要两个用户都没有管理员权限，那么他们的扩展和数据就应该完全独立，并且一个用户将无法访问另一个用户的数据。
Chrome 会安装到Program Files目录中。此目录不是所有人都可写的，用户必须将其个人数据存储在自己的C:\Users\myProfile目录中。当 Alice 登录后运行 Chrome 时，它会在 下的某个位置创建一个配置文件C:\Users\Alice\appdata，而当 Bob 运行 Chrome 时，则会在 下创建一个新的配置文件 C:\Users\Bob\appdata。
这些 Chrome 配置文件将存储该用户的扩展程序、他们的书签和缓存。Windows 本身和文件系统权限决定一个用户是否可以访问另一个用户的数据。默认情况下，非管理员用户将无法访问任何其他用户的数据。
如果任何扩展需要管理员权限才能安装，那么它们完全有可能更改文件系统权限或安装管理辅助服务，甚至直接复制其他用户的用户配置文件。请注意，在首次安装后，扩展将失去更改权限或查看其他用户配置文件的能力，除非它安装了管理辅助服务。
除非 Alice 明确授予 Bob 访问权限，或者 Bob 设法让管理员允许安装需要在 Chrome 用户配置文件之外安装的插件，否则 Bob 不应该能够访问 Alice 的数据。
如果 Bob 或 Alice 是管理员，那么他们都可以几乎自由地访问其他用户的数据。
当然还有其他情况，比如 Bob 入侵了机器，并设法利用已知的系统漏洞安装 rootkit，但那是另一个故事了……
我错过了您问题中提到的这些是 Chrome 而不是 Windows 中的配置文件的部分，我不得不说，一个 Chrome 配置文件中的扩展完全有可能访问另一个配置文件中的数据，因为没有文件系统保护，并且 Chrome 不会强制执行任何保护措施来阻止您访问配置文件之间的文件，因为这是操作系统内不同用户的工作。
举个例子，我以前使用过 Firefox 并将其卸载，然后我能够启动 Firefox 的便携副本，在其中安装了一个 sqlite 浏览器（FF 将数据存储在 sqlite 数据库中）并浏览到我的旧配置文件并查看我的历史记录，在 Chrome 中几乎肯定也可以做到这一点。
如果您确实需要多个用户，那么您应该使用操作系统功能而不是程序功能来加强安全性。如果 Bob 和 Alice 都共享相同的 Windows 用户配置文件，那么一个人可以在 Chrome 之外轻松浏览其他用户的数据，而根本不需要扩展程序。