demo · v141

Device Attributes Policy Configurator

Build a Permissions-Policy header for the device-attributes feature, probe your current frame's access, and see how top-level policy flows into embedded iframes. Useful for kiosk and IWA deployment planning on managed ChromeOS.

Context matters The Device Attributes API (navigator.managed) is only exposed to policy-installed kiosk web apps and policy-installed IWAs on managed ChromeOS. On the open web the probe will always report unavailable — the configurator still lets you model the header and understand iframe inheritance rules.

Allowlist builder

Choose who may call the Device Attributes API via the Permissions-Policy header or the iframe allow attribute.

probing document.featurePolicy…
Press "Build policy & test iframe" to generate the header and check iframe access.

Header vs iframe attribute

Permissions-Policy: device-attributes=(self)

Send this header on the top-level response. The policy then gates all subframes — even if a frame sets its own allow attribute, it cannot exceed what the top-level header grants.

<iframe src="https://kiosk.example/embed"
        allow="device-attributes"></iframe>

The allow attribute delegates permission into the iframe. The frame still needs to be in the top-level policy's allowlist — the attribute can delegate but not escalate.

Enterprise kiosk scenario

A managed ChromeOS kiosk app shows a main shell and embeds a third-party signage widget. The shell needs device serial number; the widget must be denied.

// kiosk app server — Node.js / Express
app.use('/kiosk', (req, res, next) => {
  // Allow only the kiosk origin itself
  res.setHeader('Permissions-Policy', 'device-attributes=(self)');
  next();
});

// HTML: embed signage widget without delegating device-attributes
<iframe src="https://signage-vendor.example/widget"
        allow="fullscreen">
  <!-- device-attributes NOT listed → widget is blocked -->
</iframe>

// Shell (same origin as kiosk app):
const serial = await navigator.managed.getSerialNumber();
// → resolves on managed ChromeOS kiosk
// → throws NotAllowedError on all other origins

Security audit: which contexts should access device attributes?

Context Recommended policy Rationale
Top-level kiosk app shell ALLOW Needs serial/model for enterprise asset tracking
First-party iframe (same origin) ALLOW with explicit allow="" Delegate explicitly — don't assume inheritance
Trusted vendor iframe (known origin) ALLOW specific origin Add to allowlist only if the vendor genuinely needs device ID
Third-party ad / analytics embed DENY Device serial is PII — ad networks must not access it
Cross-origin plugin / widget DENY Vendor code is outside your security perimeter
Public-facing web page (non-kiosk) DENY (N/A) API unavailable outside managed kiosk/IWA contexts regardless

see also