demo · v141

Enterprise Rollout

An admin in the Google Admin console manages three enterprise policies: DeviceAttributesAllowedForOrigins, DeviceAttributesBlockedForOrigins, and DefaultDeviceAttributesSetting. This concept models the decision tree — type any origin and see which policy fires and why.

checking support…

DeviceAttributesAllowedForOrigins

DeviceAttributesBlockedForOrigins

DefaultDeviceAttributesSetting:
…

the precedence order

// 1. URL matches DeviceAttributesBlockedForOrigins  -> DENY  (highest precedence)
// 2. URL matches DeviceAttributesAllowedForOrigins  -> ALLOW
// 3. DefaultDeviceAttributesSetting                  -> default behaviour
//
// In the embedded frame:
try {
  const id = await navigator.managed.getAnnotatedAssetId();
  console.log("asset:", id);
} catch (e) {
  if (e.name === "NotAllowedError") console.warn("policy denied access");
}

why this angle

The chromestatus entry called out three enterprise policies that interact with the new Permissions Policy. Together they form a precedence chain admins need to reason about, especially when rolling out across many origins. The default-deny + targeted-allow pattern is what most enterprise admins want: only the named first-party apps see device identifiers, every embedded analytics or ads frame is denied by default. This page makes the decision visible without spinning up a managed ChromeOS device.

see also