demo · v141

iframe Isolation

A managed ChromeOS kiosk app embeds a third-party widget (analytics dashboard, signage feed, video player). Before this Permissions Policy, the embedded frame inherited Device Attributes API access — so it could read serial number, asset tag, annotated location. Now the top-level app must explicitly allow each frame; the default is deny.

Heads up Requires Chrome 141+ on managed ChromeOS. This page is not actually a kiosk — it simulates the iframe policy decision in-page so you can see which combinations would yield which outcome. The Permissions-Policy header and allow attribute rules are the same; only the underlying API is gated.
checking support…

Pick what the top-level app declares, then see whether each example iframe gets Device Attributes access:

the header + iframe

// Top-level managed kiosk app declares the policy
Permissions-Policy: device-attributes=(self "https://trusted-widget.example")

// Embeds a third-party widget; must explicitly opt it in or the frame gets denied
<iframe src="https://trusted-widget.example/dash"
        allow="device-attributes 'src'"></iframe>

// In the embedded frame
const serial = await navigator.managed.getDirectoryId();   // throws NotAllowedError without policy + allow

why this angle

The Device Attributes API exposes serial numbers, asset IDs, annotated location — exactly the kind of identifiers an admin doesn't want bleeding to embedded third parties. Per the explainer, the migration path from Chrome Apps to PWAs/IWAs is the actual deployment driver: enterprises had policy-controlled Chrome Apps that read these attributes; the web equivalent needed the same per-origin gating story. The Permissions Policy hook is how an admin's DeviceAttributesAllowedForOrigins setting maps to runtime checks an iframe respects.

see also