Clarity cross-origin iframe visibility boundary and masking policy gaps

Goal

Determine whether Microsoft Clarity can surface interaction data from embedded third-party widgets — such as chat widgets, payment forms, or consent banners — without requiring the vendor to install the Clarity snippet on their framed page.

Constraints and uncertainty

Clarity instruments only the top-level document and any same-origin iframe that also contains the tracking snippet. For cross-origin iframes the product provides no permission model, consent flow, or postMessage bridge that would grant the parent page visibility into clicks, scrolls, or rage clicks inside the widget. The vendor's own analytics remain the sole source of that interaction data. Separately, masking behavior is a per-project policy choice: what Clarity hides by default versus what a team must explicitly mark sensitive can differ between projects, so two teams may reach different conclusions about the same recording. Because Clarity is a continuously delivered SaaS snippet rather than a versioned library, both the iframe boundary and masking defaults can change without a release note.

Questions

1. Is there any supported mechanism — current or planned — that allows a Clarity project to capture interactions inside a cross-origin iframe the team does not control?
2. What is the current default masking behavior for input fields inside same-origin iframes that do contain the snippet, and how does it differ from the top-level document?
3. How should a team document and re-verify the iframe and masking boundary given the SaaS delivery model?