Where the film actually is
Most answers to this question are a list of features. Below is a list of mechanisms, in the order they would have to fail. Where a mechanism has a limit, the limit is stated next to it rather than at the bottom of a contract.
- —Only the part you choose is ever sent. The rest of your film is not hidden — it is simply not there.
- —Only the people you name can open it, and none of them can see who else was invited.
- —It ends when you say — closed twice, by two separate routes, so one failure cannot leave it open.
- —Every screen carries that viewer’s name, and every screening leaves a report.
- —There is no DRM today. The section near the bottom says exactly what that means.
The window is cut, not gated
Arming a session produces a separate rendition containing exactly the circled span. The remainder of the film is not held behind a token, a signed URL or a policy check — it is not present in the thing the guest is able to address.
This is the difference the whole product turns on. A client-side stop is a claim the interface makes; a rendition that only contains 45 minutes is a fact about what exists on the CDN.
The roster is enforced in the database
A guest may select their own seat. They hold neither a row-level policy nor a table grant on guests, sources, profiles, session events, door keys, playback grants or notifications — so "who else is here" is not a question their credential can ask.
Two independent layers, on purpose: row-level security decides what is visible, and the grants are withheld separately, so a policy written wrongly later cannot open a table on its own. A suite of 57 assertions states each of these as something the database must refuse, and runs against the live project.
The link is a door; the key is separate
Each seat gets one permanent address that carries no access at all — safe to forward, preview and bookmark. Entry is six digits sent to the invited mailbox, or a browser that has been trusted before.
The two never travel in the same message. Putting them together would rebuild the magic link Lodge deliberately does not use. Attempts are capped per seat rather than per key, so asking for a fresh key does not buy fresh guesses.
Closing revokes twice, independently
Ending a session rotates the playback id and revokes every outstanding grant. Separately, the token in the guest’s browser expires on its own clock.
Either one alone closes the room. A scheduled job that fails to run must not be able to leave a screening standing open, which is why the second path does not depend on the first.
Then the cut is deleted
Seven days after a session closes, the rendition that was screened is deleted outright from the provider. Not revoked — removed. Seven rather than zero so that a screening closed by mistake can still be looked at.
Your master is not touched. That is your film and you uploaded it; deleting it on a timer is not a decision this software should be making on your behalf. Removing it is an action you take.
Every copy is identifiable
The picture carries a visible mark tied to one seat, and the guest is told so on their own screen rather than discovering it later. Playback grants are bound to a device.
Visible burn-in deters, and it identifies a phone-camera leak — which is the threat screeners actually face. It does not survive a determined re-encode, and we do not describe it as forensic.
Afterwards, there is a record
Every screening produces a chain-of-custody document: who was invited, who accepted or declined, the exact timecodes cut, each seat’s watermark, join and leave times, how much of the window was watched, every message Lodge sent, and when each route back to the film was closed. Print it, or take the JSON with its SHA-256.
The record carries its own limits as part of the document rather than as a footnote: that playback was not DRM-protected, that the watermark is not forensic, that attendance is what Lodge observed rather than who was in the room, and that the checksum is not a signature. A custody document that overclaims is worse than none, because somebody relies on it.
There is no DRM today
Lodge does not encrypt the stream. Protected playback here means a visible watermark, a cut that contains only the circled span, a door, short-lived device-bound tokens and a record — not Widevine, PlayReady or FairPlay. If a supplier has told you otherwise about this product, they were wrong.
Lodge runs on Mux, which does carry all three, and playback is written against a provider interface so that turning them on is configuration rather than a rebuild. It is not turned on: it needs an onboarding approval and a FairPlay certificate, it carries a standing monthly cost, and we are not adding that to every customer’s bill to make a page read better. It is quoted into the engagement that requires it.
Worth saying plainly, because it is what the argument usually skips: DRM stops copying. It does not stop a phone pointed at a monitor, which is the way screeners actually leak. That is what the watermark is for, and why the watermark is on every seat today while DRM is not.
Ask us the hard one
If your legal or delivery team has a question this page does not answer, it is a question we want. Send it with the access request and it will be answered by someone who wrote the policy, not by a form.
Request access