Chrome AutoLaunchProtocolsFromOrigins: 允许网页自动启动应用

2025-04-19 08:42:33

Chrome 里有没有类似 Edge DoNotSilentlyBlockProtocolsFromOrigins 的策略？

不少朋友用 Edge 时，可能会用到一个叫 DoNotSilentlyBlockProtocolsFromOrigins 的策略。它的作用是允许特定来源（网站）在不需要用户每次都手动确认的情况下，启动某些自定义协议（比如 myapp:// 这种链接）。这在一些企业内部应用或者需要网页与本地应用频繁交互的场景下，挺方便的。

那么问题来了：Chrome 浏览器里，有没有功能相似的“兄弟”策略呢？毕竟，很多时候我们不能只考虑 Edge。

问题来了：网页想“悄悄”启动本地应用，Chrome 同意吗？

简单来说，就是想实现这样一个场景：用户在公司内网的一个管理后台（比如 https://internal.mycompany.com）上点击一个链接，这个链接指向一个自定义协议，比如 internaltool://launch?param=123。我们希望 Chrome 能直接尝试启动注册了这个 internaltool:// 协议的本地应用程序，而不是弹出一个警告框问“你要允许这个网站打开 XXX 应用吗？”，或者更糟——干脆直接、默默地阻止了这次启动，用户点了没反应，还以为是链接坏了。

Edge 提供的 DoNotSilentlyBlockProtocolsFromOrigins 策略，就是用来解决这个“默默阻止”或“每次都问”的问题的，它允许管理员配置一个列表，告诉 Edge：“嘿，从这些特定的网站（Origins）来的、要启动这些特定协议（Protocols）的请求，你别拦着，也别每次都烦用户，直接放行！”

那 Chrome 呢？我们能不能也给 Chrome 做类似的配置？

为什么浏览器会“阻止”这种行为？

在找解决方案之前，咱们得先搞明白，为啥浏览器（不管是 Chrome、Edge 还是其他现代浏览器）默认情况下对这种“网页启动本地应用”的行为那么警惕。

答案很简单：安全。

想象一下，如果任何网站都能随随便便通过一个链接就启动你电脑上的程序，那风险可就大了去了。恶意网站可能会：

尝试启动已知的、有漏洞的应用程序 ，利用漏洞搞破坏或窃取信息。
尝试启动系统工具 ，执行一些危险操作。
构造参数，让正常程序执行非预期操作 。
就算启动的是个“安全”的程序，也可能造成骚扰 ，比如不停地弹出程序窗口。

所以，浏览器设置一道“关卡”是完全必要的。这道关卡通常表现为：

首次启动提示 ：第一次从某个网站尝试启动某个协议时，浏览器会弹框询问用户是否允许，并可能提供“始终允许”的选项。
后续启动 ：如果用户选择了“始终允许”，后续从同源网站启动同一协议就可能直接放行。但如果没有，或者浏览器策略限制，可能每次都需要确认，或者在某些情况下（比如没有明确的用户手势，像直接点击）会被默默阻止。

Edge 的 DoNotSilentlyBlockProtocolsFromOrigins 策略，实际上是在管理员确信“来源网站”和“目标协议”组合是安全的前提下，对这道安全关卡做了一个有限度的“豁免”。

Chrome 的应对之策：有没有直接的“替身”？

直接说结论：Chrome 确实有 一个功能上非常接近甚至可以说是对应的策略，虽然名字不叫 DoNotSilentlyBlockProtocolsFromOrigins。

过去一段时间，Chrome 在处理这类请求时，策略和用户体验有过一些调整。如果你查找比较早的资料，可能会找到一些不完全准确的信息，或者提到一些只能部分解决问题的策略。但目前，Chrome 提供了一个针对性的策略来处理这个问题。

退而求其次：Chrome 里管理协议启动的相关策略

在介绍那个“正主”之前，我们先看看 Chrome 里其他几个可能被提及，但并不完全是 Edge 那个策略等价物的相关策略，了解一下它们的局限性。

方案一（非直接等价）：`URLAllowlist` 和 `URLBlocklist` - 控制能访问哪些“门牌号”

这两个策略是 Chrome 企业版管理中非常常用的。

URLAllowlist：指定一个允许用户访问的 URL 列表。如果配置了这个策略，用户只能访问列表中的 URL，其他所有 URL 都会被阻止。
URLBlocklist：指定一个禁止用户访问的 URL 列表。用户可以访问除了黑名单之外的所有 URL。还可以用 * 来阻止所有 URL，然后配合 URLAllowlist 只放行特定站点。

原理和作用：
它们主要控制的是浏览器能导航到（加载）哪些网页地址，而不是直接控制“网页启动外部协议”这个动作本身是否需要提示或会被阻止。虽然你可以用它们来限制哪些网站能被用户打开，从而间接控制了能发起协议启动请求的来源范围，但这跟 Edge 那个策略的关注点不同。它不能解决“某个被允许访问的网站，在启动特定协议时被默默阻止或需要重复确认”的问题。

操作示例（Windows 注册表）：
假设你想允许所有来自 internal.mycompany.com 的请求：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\URLAllowlist]
"1"="https://internal.mycompany.com"
"2"="http://internal.mycompany.com"

; 或者如果只想允许这个域及其子域下的所有地址
; "1"="[*.]mycompany.com"

局限性：
如上所述，这个策略管的是“能不能访问这个网站”，不管“这个网站启动协议时要不要弹窗/会不会被拦”。

方案二（非直接等价）：`ExternalProtocolDialogShowAlwaysOpenCheckbox` - 让用户“一劳永逸”？

这个策略控制的是，当 Chrome 弹出那个“是否允许网站打开 XXX 应用？”的确认对话框时，对话框上那个“始终允许...” (Always open these types of links in the associated app) 的复选框是否显示。

原理和作用：
如果设置为 true（或者不配置，让 Chrome 自行决定，通常是显示的），用户在第一次允许启动某个协议时，可以勾选这个框。之后，从同一个网站再次启动同一个协议，Chrome 就会记住用户的选择，直接启动，不再弹窗。如果设置为 false，用户就没有这个“记住我的选择”的选项，理论上每次启动都需要手动确认（不过浏览器的具体行为可能随版本演变）。

操作示例（Windows 注册表）：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001 ; 设置为 1 (True) 来显示复选框
; "ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000000 ; 设置为 0 (False) 来隐藏复选框

局限性：
这个策略只是提供了 让用户“一次授权，后续免问”的可能性，并且决定权在用户手上。它不能替用户做决定，也不能阻止浏览器在某些情况下（比如没有用户交互就尝试启动协议）可能出现的、不弹出对话框而是直接阻止的行为。它更像是优化重复操作的用户体验，而非强制放行。

真正的“选手”：`AutoLaunchProtocolsFromOrigins` - 这才是你要找的！

终于轮到主角了。Chrome 提供了一个名为 AutoLaunchProtocolsFromOrigins 的策略，这在功能上几乎就是 Edge DoNotSilentlyBlockProtocolsFromOrigins 的直接对应物。

原理和作用：
这个策略允许管理员定义一个列表，列表里包含若干规则。每条规则指定了一个“协议”（比如 myapp）和一个允许自动启动该协议的“来源（Origin）列表”（比如 ["https://*.mycompany.com", "https://partner.com"]）。当 Chrome 遇到一个来自指定来源、要启动指定协议的请求时，如果这个组合在策略列表里，Chrome 就会跳过用户的确认对话框，也不会 默默阻止，直接尝试启动对应的本地应用程序。

这完全符合我们最初的需求：让特定（信任的）网站能够顺畅地、无需额外交互地启动特定的（信任的）本地协议。

操作示例（Windows 注册表 - 值是 JSON 格式的字符串）：

假设我们想允许所有来自 internal.mycompany.com 及其子域的 HTTPS 页面，以及 https://trusted-partner.com 页面，自动启动 internaltool:// 协议和 anothertool:// 协议。

策略的值需要是一个 JSON 字符串，格式如下：

[
  {
    "protocol": "internaltool",
    "allowed_origins": [
      "https://*.mycompany.com",
      "https://trusted-partner.com"
    ]
  },
  {
    "protocol": "anothertool",
    "allowed_origins": [
      "https://internal.mycompany.com"
    ]
  }
]

然后你需要把这个 JSON 字符串设置到注册表里。注意，注册表里的字符串值可能对特殊字符有要求，实际部署时可能需要转义。

在 regedit 中，路径是：
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\AutoLaunchProtocolsFromOrigins

你需要创建一个新的字符串值 (REG_SZ) ，名称为 1 (或者 2, 3 ... 如果你要添加多条，但通常是把所有规则合并到一个 JSON 里赋给一个名称，比如 "1")。然后把上面那个 JSON 字符串（可能需要处理转义符，但在 regedit 编辑器里直接粘贴通常没问题）作为它的值。

或者，使用组策略 (GPO)：
在 Chrome 的管理模板 (ADMX/ADML) 中找到 "Computer Configuration" > "Policies" > "Administrative Templates" > "Google" > "Google Chrome"。找到名为 "Automatically launch protocols from these origins" 的策略，启用它，然后在选项框里输入上面的 JSON 结构。组策略编辑器通常会更好地处理格式。

关键点：

protocol: 你想自动启动的协议名称（不需要 ://）。
allowed_origins: 一个包含来源字符串的数组。来源格式遵循 RFC 6454，通常是 scheme://host[:port]。
- 可以使用通配符 * 作为 host 的前缀，例如 https://*.mycompany.com 匹配 mycompany.com 的所有 HTTPS 子域。
- 只写域名 mycompany.com 会匹配 http://mycompany.com 和 https://mycompany.com 以及对应的默认端口。
- 指定 * 作为来源会匹配所有来源（极不推荐！ ）。

安全提醒：
这个策略的威力很大！它绕过了用户确认步骤。所以，在使用时务必非常谨慎：

最小权限原则 ：只为绝对必要且完全信任的协议和来源组合开启自动启动。来源越具体越好，避免使用过于宽泛的通配符。绝对不要使用 allowed_origins: ["*"] 这样的配置！
协议本身的安全 ：确保那个被启动的本地应用程序本身是安全的，并且它处理传入参数（?param=123 部分）的方式也是安全的，不会因为恶意构造的参数导致问题。
仅用于内部或受控环境 ：这个策略更适合在企业内网、教育机构等管理员可以完全控制来源网站和用户机器的环境下使用。

进阶使用技巧：

来源的精确匹配 ：https://app.internal.mycompany.com 比 https://*.mycompany.com 更安全。如果只需要特定子域，就用特定子域。
端口号 ：如果你的服务跑在非标准端口，记得在来源里加上端口号，如 https://app.internal.mycompany.com:8443。
测试充分 ：在小范围内部署测试，确保它按预期工作，并且没有引入意想不到的安全风险。

没策略就没办法了吗？其他可能的思路

如果因为环境限制不能使用企业策略，或者 AutoLaunchProtocolsFromOrigins 还不够灵活，还有没有别的办法？

引导用户操作 + 利用“始终允许” ：
最符合 Web 安全模型的方式，还是让用户主动点击。可以在网页上清晰地说明点击这个链接会启动一个本地程序，并在首次启动时，引导用户勾选浏览器弹出的“始终允许”复选框（前提是 ExternalProtocolDialogShowAlwaysOpenCheckbox 策略没有禁用它）。这之后，用户在该网站上的后续操作就会顺畅很多。
Chrome 扩展程序 ：
理论上，可以开发一个 Chrome 扩展程序。这个扩展程序通过 Native Messaging 技术与一个本地安装的辅助程序通信。网页可以通过 postMessage 与扩展程序交互，扩展程序再通过 Native Messaging 把请求转发给本地辅助程序，让它去启动目标应用。这样做比较复杂，需要用户安装扩展和本地辅助程序，并且涉及更多的开发和安全考虑，但提供了最大的灵活性。

安全第一，别忘了加把锁

无论采用哪种方式在 Chrome（或任何浏览器）中实现网页启动本地协议的功能，请牢记：

验证来源 ：尽可能确保只有受信任的网页能发起这个动作。使用 AutoLaunchProtocolsFromOrigins 策略是强制验证来源的好方法。
用户知情与控制 ：除非有非常强的理由（如完全受控的企业环境），否则让用户知道发生了什么，并给予他们控制权（比如首次确认），通常是更稳妥的做法。
保护本地应用 ：协议处理器（本地应用）自身必须设计得足够安全，能妥善处理来自网页的各种可能的输入。

总而言之，针对“Chrome 中是否有类似 Edge DoNotSilentlyBlockProtocolsFromOrigins 的策略”这个问题，答案是肯定的，它就是 AutoLaunchProtocolsFromOrigins。使用这个策略，管理员可以精细地控制哪些网站可以免确认、不被阻止地启动特定的本地协议处理程序。只要谨慎配置，它就能在提高效率的同时，将安全风险控制在可接受范围内。