What this page is for. It is deliberately hosted on a different domain and a
different server from the streaming site, over real HTTPS, so we can confirm that an embedded
player behaves correctly as a genuine third party — and that the branding under the video
cannot be removed by the page hosting it.
Stream shown below: the Driveway camera at Eat at Joe’s, on UAT.rsquo;s, on UAT.
The share key is locked to letter.brianwatts.com, so these frames render here and
nowhere else — paste the same iframe on any other site and the browser will refuse it.
If Chrome asks to “access other devices on your local network”, click Allow.
That is Chrome’s Private Network Access protection, and you will only see it when you are
inside Brian’s LAN: this page resolves to a public address, while
uat.currentsituation.live resolves to a private one (10.0.0.159) for internal
clients. Public page plus private resource makes Chrome ask first.
From outside the LAN — which is how the team and every real customer reaches it — both
sides are public and no prompt appears. Production is unaffected for the same reason.
1. Does the embed work at all, cross-origin over HTTPS?
The player requires a secure context. This is the real-world path that
localhost testing cannot exercise.
checking…
2. Can this page read the player's DOM?
If it could, it could delete the branding element outright. The same-origin
policy is the load-bearing protection in the whole feature.
checking…
3. Can this page inject CSS into the player?
A single display:none rule would be enough to hide the message.
checking…
4. Can this page crop the branding off the bottom?
It can — but the branding sits on the video, so cropping the message
also crops the picture. Compare the two frames: that visible cost is the deterrent.
This frame and the next use a second, offline camera on purpose — they are
demonstrating cropping and overlay, and the branding renders in every state including
offline.
Visual check — the bottom of the picture is gone along with the message.
5. Can this page cover the branding with its own element?
Yes, and it always will be able to. Nothing served to a browser can stop a host
page from positioning something on top of an iframe. This is a known and documented limit:
the answer is detection and revoking the share key, not engineering.
THIS PAGE'S OWN OVERLAY — known limitation
6. Does the domain allowlist actually block a disallowed site?
When the share key is locked to specific domains, this page should be refused and
the browser should block the frame outright via frame-ancestors. Point the key at
a different domain in the Share Center, reload, and this frame should fail to render.
Manual step — see the note above.