Send a press screener before release.
The embargo is a contract, not a control.

A press screener is the opposite shape. You are deliberately giving an unreleased film to people whose job is to write about it, often thirty or forty of them, on a schedule, under an embargo you cannot technically enforce. Access is the point. Nobody reviews a film they could not watch, and a critic on deadline who hits an obstacle simply covers something else that week.

So the security question is not how to prevent access. It is three other questions. Can each viewing be attributed to one named person. Will the embargo hold. And at the end of the round, do you have a record you can read. Everything below answers one of those three, and nothing below promises a control that does not exist.

What makes an outlet hold is that it agreed to in writing, that its editor understands the terms, and that it wants the next screener too. A publicist who understands this designs a better programme than one shopping for DRM, because the effort goes into the terms and the list rather than into a feature that was never going to bind anybody.

Be honest about the cost. At forty outlets this is administrative work: an afternoon of issuing links, a list you keep updating, and a follow-up round for the people who never opened theirs. There is no trick that removes it. The shortcuts that remove it are exactly the shortcuts that make a leak unattributable, so the clerical cost is the feature rather than an overhead to design away.

Keep the list in whatever you already use, a spreadsheet is fine, and keep these six columns. It is the entire apparatus.

The practical answer for most rounds is a high-bitrate HEVC or H.264 export of the graded film, with final sound. Not the ProRes master, which a browser cannot play and which turns the screener into a download. Not a small proxy, which invites a review of a compression artefact you did not put there.

If you burn a visible mark into that export, be honest with yourself about what it costs. A name and an email address running across the frame is legible to the recipient and it is a distraction for someone who is reviewing the photography. It is still a legitimate choice, especially for the first wave of a film that has not screened anywhere. It is a trade, not a free precaution, and the next section is how to decide it.

For press, many publicists use both, and the reasoning is not complicated. The discreet visible mark does the deterrent work at the moment of temptation, when someone is considering whether to pass the link on. The imperceptible per-person mark does the attribution work later, if a copy turns up somewhere it should not be, without asking a critic to review a film through a caption.

One caution worth carrying. Forensic marking is an attribution tool, not a prevention tool. It tells you whose copy leaked, after the leak, once someone has obtained the leaked file and run a detection process on it. Frame.io documents that its own platform does not run detection: the customer has to obtain the file, work with the watermark vendor, and bring an identifier back. Nothing about a mark, visible or not, stops the copy leaving in the first place.

Screen recording is not preventable in a browser. The W3C specification for Encrypted Media Extensions, the standard behind browser DRM, states that it does not define a content protection or Digital Rights Management system, and that it instead defines a common API for interacting with such systems. On the other side, MDN’s Screen Capture API documentation describes how a page can ask the user to share a screen. It documents no mechanism for a page to opt its own content out of being captured. Between those two documents there is no browser feature that stops a viewer recording their own screen, and any vendor claim to the contrary deserves to be read very closely for the list of browsers and operating systems it applies to.

A native application is a different path, with a different price. Our Vault masters open in the macOS app, where screen capture is blocked. That is a property of the native-app path, not of a browser link, and we will not describe it as anything else. If you are discussing native applications with a developer, one correction is worth knowing: Apple documents the none case of NSWindow.SharingType, the constant most often cited as the way to exclude a window from screen capture on macOS, as a legacy constant macOS no longer uses. It is not the answer anyone remembers it being.

And the reason the strict path is usually wrong for press. A viewing requirement that involves installing anything will lose you reviews. A critic with four films to watch this week and a Thursday deadline will not install an application to watch one of them, and will not email you to explain why. For press, the right trade is usually the ordinary link that opens in a browser, combined with a per-recipient policy, a written embargo, and a mark the platform can carry on that link. Keep the strict, native-app path for the distributor screener, where the room is five people and every one of them has a commercial reason to jump through the hoop.

State the consequence plainly, because it is the whole reason this comparison is on the page. A journalist you emailed a screener to is never a logged-in team member of your account. So Vimeo’s documented viewer-level analytics do not answer the question “which critic watched it”. And an unlisted link is, by Vimeo’s own description, transferable by whoever holds it. If your round depends on knowing who watched, that is the gap to plan around, whether you plan around it with a different tool or with a per-recipient discipline on the tool you already pay for.

None of this depends on a platform. It depends on a journalist chasing an asset at midnight being able to find it without emailing you, so send the kit in the same message as the link, name every file so a picture editor can tell them apart without opening them, and restate the embargo beside both.