Unrestricted API

Entitlement: unrestrictedApi. No EP switch or method is required. It makes the chrovia object available in additional contexts without granting the capabilities of individual domains.

Default versus unrestricted exposure

Only interfaces supported in that context are available. In particular, automation is Window-only. Use Window or Service Worker contexts; DedicatedWorker and SharedWorker contexts are not supported.

passwords is an exception: it remains Provision extension Service Worker-only, even with this entitlement. Every domain still checks its own capability. unrestrictedApi alone does not provide networkIntercept, extendedPrefs, or automation.

Use on a controlled page

For a page that reads instance metadata, request both unrestrictedApi and instanceMetadata:

const metadata = window.chrovia?.instanceMetadata;
if (metadata) {
  document.title = metadata.public?.label || 'SDK page';
}

Configure internal.instance_metadata.public.label using the metadata guide, then reload the instance with the issued License and EP.

Choose the narrowest integration

This is a broad exposure capability, not a per-origin allowlist. Unrelated pages in the browser can also reach granted domains. Do not enable it just to make a toolbar popup work; use popup-to-Service-Worker messages instead.

Keep secrets out of page-accessible EP and metadata. Broad access to process, prefs, messaging, or network affects instance behavior, not only the caller's page. If you enable this capability for automation, account for all other entitlements issued on the same License.

Turn it off

Request a License without unrestrictedApi, install it, and fully restart. There is no internal.unrestricted_api switch. Provision Service Workers can continue using their individually granted domains. See License replacement.