Script-tag embed

The customer hosts the player themselves: a container div and loader.min.js, which injects the bundle into this page. Materially different for identity, and the difference is not subtle.

Player runs on	this page’s own origin — first-party, in the customer’s document
Config comes from	`data-*` attributes only. `standAlone()` never runs, so query params are not read
Sign-in transport	iframe on the Resi origin, nested in a first-party page
This page can read the viewer id	yes — unavoidably; see below

The markup

<div
  id="resi-video-player"
  data-embed-id="…"
  data-type="event"
  data-autoplay="false"
  data-identify-viewer="required"></div>

<script src="https://control.jefflowery.dev/webplayer/loader.min.js"></script>

Expected

No data-resi-body, so isInOwnFrame() is false and standAlone() is skipped. The mode switch above sets data-identify-viewer directly rather than passing a query param.
The sign-in page builds its postMessage target from the origin of the window running the player — which here is the customer’s. So the result is delivered to this page, and the log below shows the viewer id in red.
That is correct behaviour, not a leak: the customer is executing our bundle in their document, so anything the bundle can see, their scripts can see. The wildcard rule still matters — it is what keeps the other five cases clean.
Storage for the nested sign-in frame is still partitioned under this site, so the Safari paths behave as they do in an iframe embed.

Messages reaching this page

Expect a red [VIEWER ID] line after a successful sign-in. On this page only, that is the design: the player is running in this document, so the message is addressed to this origin.

include same-origin messages (browser extensions)

nothing yet