不受扩展身份限制的 API
了解 unrestrictedApi 如何扩大 JavaScript 开放范围，以及为何它不会授予能力或向页面开放密码 API。
能力：unrestrictedApi。不需要 EP 开关或方法调用。它改变 chrovia 根对象的开放范围，不改变各 API 域的能力要求。
默认与扩大后的开放范围
| 上下文 | 默认 | 拥有 unrestrictedApi |
|---|---|---|
| Provision 扩展 Service Worker | 可访问 chrovia | 可访问 |
| 普通 Window 页面 | 不可访问 | 可访问 |
| 扩展 popup 或标签页 | 不可访问 | 可访问 |
| 非 Provision Service Worker | 不可访问 | 可访问 |
只能使用该上下文支持的接口。例如 automation 仅限 Window。应使用 Window 或 Service Worker 上下文，不支持 DedicatedWorker 和 SharedWorker。
passwords 是例外：即使拥有此能力，它仍只对 Provision 扩展 Service Worker 开放。每个域仍检查自己的能力。仅有 unrestrictedApi 不会获得 networkIntercept、extendedPrefs 或 automation。
在受控页面使用
页面需要读取实例元数据时，应同时申请 unrestrictedApi 和 instanceMetadata：
const metadata = window.chrovia?.instanceMetadata;
if (metadata) {
document.title = metadata.public?.label || 'SDK page';
}按元数据文档配置 internal.instance_metadata.public.label，安装已签发 License 和 EP 后重新启动实例。
选择范围更小的集成方式
这是扩大开放范围的能力，不是按域名设置的白名单。浏览器中的其他页面也能访问已授权域。不要仅为工具栏 popup 工作而启用它，应使用 popup 到 Service Worker 的消息。
不要把秘密放在页面可访问的 EP 和元数据中。向页面开放 process、prefs、messaging、network 会影响实例行为，而不仅是调用页面。为自动化启用此能力时，应同时考虑同一 License 上授予的其他能力。
关闭
申请不含 unrestrictedApi 的 License，安装后完全重启。没有 internal.unrestricted_api 开关。Provision Service Worker 仍能使用独立授权的各个域。参见 License 替换。