Security
Secure video hosting
Four independent layers, all available on the first paid plan: every HLS segment encrypted as it is packaged, playback keys issued only to the domains you list, signed links that expire for one-off sharing, and a watermark that attributes a copy if one escapes. They stack, and this page tells you which combination your case actually needs.
Key requests
- app.yourcompany.com
- ✓ Key issued — origin allowed
- members.yourcompany.com
- ✓ Key issued — origin allowed
- scraper.example.net
- ✕ Refused — not on the allowlist
The layers
Four layers, and what each one does
They address different problems. Reading them as a list of features misses the point — the value is in which ones you combine.
- Encrypted on-demand deliveryEvery plan
- Each HLS segment is encrypted with AES-128 as it is packaged. A segment pulled off the wire or out of a cache is not a watchable file on its own — playback needs the key, and the key request is where the next layer applies.
- Playback keys locked to your domainsEvery plan
- List the origins allowed to play your video and the key is only issued to requests from them. This is the layer that makes a copied embed snippet useless on someone else’s site, and it is the single most effective control here.
- Signed links that expireEvery plan
- For access that has to happen outside your own pages, generate a signed private link per video. It can be revealed to a recipient, rotated if it needs replacing, and revoked outright — so sharing has an end date you control.
- Dynamic watermarkingEvery plan
- An overlay applied at playback. It does not prevent a recording; it makes one attributable, which is the layer that addresses the threat the other three cannot touch.
- API keys you can rotateEvery plan
- Programmatic access uses keys that can be created, listed, rotated and deleted, so credential hygiene is a routine operation rather than a support request.
- Viewer identity stays under your controlPlus and larger for user IDs
- Aggregate reports work without a user identifier. On Plus and larger plans, your application can pass its own user ID when individual viewing history is required, so you decide when that data is attached.
Choosing
Which layer your case actually needs
Start from the thing you are trying to prevent. That points at a combination far more reliably than a feature comparison does.
- Paid content being watched by people who did not pay
- The realistic route is a shared embed or a shared URL, not an attack on the encryption.
- On DynTube — Origin allowlist plus encrypted delivery. Your members area is on the list, everywhere else is not, so a shared snippet does not play elsewhere.
- Internal material leaving the business
- The risk is a forwarded link reaching someone outside the organisation.
- On DynTube — Origin allowlist for the intranet, signed expiring links for anything that must go outside, and watermarking on the sensitive set for attribution.
- Pre-release material leaking before a date
- Reviewers and partners need access, and each of them is a potential source.
- On DynTube — A signed private link per recipient, revoked after the window, with watermarking so an escaped copy points somewhere.
- Course video being redistributed
- Determined redistribution usually involves screen capture, which no delivery control prevents.
- On DynTube — Encryption and origin restriction stop the easy routes; watermarking makes the hard route traceable. Being straight about that boundary is the point.
- Reducing your own data-protection exposure
- Every system that holds viewer-level data is a system you have to defend and account for.
- On DynTube — Use aggregate reporting without passing a user identifier, or supply your own user ID on Plus and larger plans when individual viewing history is required. That choice belongs in your privacy design.
Setup
The order to switch this on
Protection configured before publishing is worth far more than protection added afterwards.
- 01
1. Populate the origin allowlist before the first upload
- 02
2. Test the refusal
- 03
3. Decide the external-sharing rule
- 04
4. Apply watermarking where a leak would matter
- 05
5. Put credential rotation on a schedule
Questions
Security questions, answered without overreach
How is my video encrypted?
Each HLS segment is encrypted with AES-128 as it is packaged, and playback requires a key. A segment obtained without the key is not a watchable file, which is why the key-issuance rules matter as much as the encryption itself.
Can I stop my videos playing on other websites?
Yes, and this is the most effective control available. Add the domains allowed to play your video to an allowlist and the playback key is only issued to those origins. Populate the list, leave the account-level exemptions off, and an embed copied onto another site stops playing in a browser.
How do I share one video with someone outside my site?
Generate a signed private link for that video. It can be revealed to the recipient, rotated if it needs replacing, and revoked when access should end, so sharing does not depend on a link being forgotten.
Can you stop someone screen-recording my video?
No. Someone permitted to watch can capture what they see, so ask for evidence whenever prevention is promised. Dynamic watermarking is the honest response: it makes an escaped copy attributable, which changes behaviour among people who know it is there.
Which plan do I need for these controls?
All four layers are on every published plan, starting at USD 24 a month with 300 GB of storage and 1 TB of monthly delivery. Your band is decided by library size and monthly viewing, not by which protection you want.
Do you offer DRM?
We do not market a DRM capability, so do not plan around one. What is available and documented here is encrypted segment delivery, origin-restricted key issuance, signed expiring links and watermarking. If a studio-grade DRM requirement is genuinely mandatory for your content, tell us and get the answer in writing before committing.
Will this satisfy my security or compliance policy?
Bring us the policy rather than a checkbox list. We will answer against the specific requirements plainly and in writing, and tell you where something is not available. No certification or compliance guarantee is offered on this page.
Tell us the threat, not the feature list
Describe what you are actually trying to prevent and we will tell you which layers address it and which do not. That conversation is worth more than any comparison grid.