v155 · extensions · enterprise
Stricter enterprise policy enforcement for chrome.debugger API
From Chrome 155, chrome.debugger.attach() on a managed browser validates enterprise host and screenshot policies up front, all-or-nothing. An extension blocked by runtime_blocked_hosts or by screenshot/DLP policy now gets one deterministic error at attach time — "Host access is restricted by policy." or "Screenshot capture is restricted by policy." — instead of individual DevTools-Protocol commands failing unpredictably mid-session. chrome.debugger is an extension API: a web page cannot call it, so these demos are honest about what runs where — real page-side probes where they exist, working admin/developer tools, and clearly-labelled simulation for the attach gate itself.
concepts
-
Attach gate simulator
Compose a policy environment — blocked-host patterns,
DisableScreenshots, DLP — pick a target URL, and run an attach → command timeline against it. The host-pattern matcher is real, spec-faithful match-pattern logic running in-page; the attach verdict is a labelled simulation of the documented Chrome 155 contract, shown side by side with the unpredictable pre-155 behaviour. -
ExtensionSettings policy composer
An admin tool that builds the
ExtensionSettingsJSON that triggers the new attach-time enforcement: per-extension or wildcard scope,runtime_blocked_hosts/runtime_allowed_hostswith live pattern validation against the real match-pattern grammar, and copy-ready output for Windows registry, macOS plist, and Linux JSON deployment. -
Graceful degradation playbook
What an extension developer ships instead: pick the capability you were using
chrome.debuggerfor and get the restricted-environment alternative —chrome.scripting,declarativeNetRequest,tabs.captureVisibleTab— plus the manifest permissions and the attach-rejection handler that catches the two new deterministic error strings. -
What can a web page see?
Live probes from this very page:
chrome.debuggeris genuinely absent from page script (run the check),navigator.webdriverreveals automation but not debugger attachment, and the classicdebugger;-statement timing trick — run it yourself — detects open DevTools only, labelled as the manual observation it is. Attachment is disclosed by browser UI (the infobar), deliberately outside the page's reach.
why it shipped
The debugger permission hands an extension the Chrome DevTools Protocol — read any page, run script, capture screenshots. Managed environments restrict that power with ExtensionSettings.runtime_blocked_hosts and data-loss-prevention rules, but before Chrome 155 the enforcement was scattered: attach() would succeed, and then some CDP commands failed while others worked, depending on which internal check each one hit. Extensions could neither predict nor gracefully handle the restriction, and admins could not reason about what a partially-blocked debugger session could still do.
Chrome 155 moves the whole check to attach(): if any host restriction applies to the extension, or screenshot capture is restricted for the target, attachment is refused outright with a stable error message. All-or-nothing is deliberate — a debugger session is all-powerful by design, so a policy that limits any of it now refuses all of it, and developers are pointed at chrome.scripting and declarativeNetRequest, which support granular, per-origin permission models that policy can reason about.
the contract
// Extension-side (service worker) — NOT callable from a web page:
try {
await chrome.debugger.attach({ tabId }, "1.3");
} catch (e) {
// Chrome 155 managed-browser rejections are deterministic:
// "Host access is restricted by policy."
// "Screenshot capture is restricted by policy."
if (e.message.includes("restricted by policy")) {
return fallbackToScriptingAPIs(); // see the playbook concept
}
throw e;
}
Note the all-or-nothing rule: runtime_blocked_hosts blocking any host blocks attach() for every target, even targets listed in runtime_allowed_hosts.