Secure video preview in Confluence Knowledge Base without allowing downloads

Martin Spernjak

Hi everyone,

I’m looking for some advice from the community on a specific use case involving Confluence Knowledge Base / Jira Service Management.

I have a requirement to share training/instructional videos with a closed group of customers.

The requirements are:

• Videos should be accessible only to authenticated customers who belong to a specific customer group.
• Customers should be able to watch/preview the video directly in the Knowledge Base.
• Customers must not have a download option.
• The solution should preferably work with Confluence Cloud / JSM Knowledge Base without making the video publicly accessible.

I have already tested a few approaches:

Loom

I looked at using Loom and embedding the video into the Confluence page. However, from what I can see, this works properly only when the video is publicly accessible, which doesn't satisfy our requirement for restricted customer access.

Custom Confluence macro / Forge

I also considered creating a custom macro that embeds the video and hides the download links/buttons.

However, this isn't really secure because the underlying video URL can still be discovered through browser Developer Tools / Network requests. So even if the download button is hidden in the UI, the user can potentially retrieve the actual video URL.

Confluence attachments

The classic Confluence attachment approach is actually quite close to what I need because access can be restricted through Confluence/JSM permissions.

The problem is that the attachment player provides download functionality, and there doesn't appear to be a supported way to completely remove/disable the download option for specific video attachments.

Atlassian Guard

I am aware that Atlassian Guard provides some controls related to downloading content, but that doesn't fit our current setup and requirements.

---

My question is:

Has anyone implemented a similar solution where customers can stream/preview a video inside a Confluence/JSM Knowledge Base article while preventing them from downloading or directly accessing the video file?

I'm particularly interested in solutions that provide:

1. Restricted access to a specific customer group
2. Embedded video playback
3. No download option
4. No publicly accessible video URL
5. Ideally, something that works natively with Atlassian Cloud or can be integrated with Confluence

I understand that "no download" is difficult to guarantee once a user is allowed to play a video, since the browser ultimately has to receive the video data. I'm mainly looking for a solution that prevents normal downloading and doesn't expose a directly usable video URL.

Any recommendations or real-world implementations would be greatly appreciated.

Thanks!

Sami Shaik

Hi @Martin Spernjak , your testing already found the honest truth, so let me confirm it and then give you the architecture that satisfies your list as written.

Your conclusions are correct. Within native Confluence Cloud on Standard, there is no supported way to keep attachment playback and remove the download option. Your Forge-macro objection is also right: hiding buttons is cosmetic while the underlying file URL stays discoverable. And Loom effectively needs public (or workspace-member) access, which external customers do not have. You tested your way to the real boundary.

The pattern that works: let Confluence decide WHO, let a streaming host decide HOW. Keep the page gated exactly as you do now (KB article visibility plus page restrictions for the customer group). Host the video on a platform built for gated streaming, and embed it. Two properties do the heavy lifting: domain-restricted embedding (the player only works inside your help centre's domain) and signed, short-lived HLS streams (what DevTools reveals is a tokenised, chunked manifest that expires in minutes, not a reusable file URL). No download button exists, and there is no directly usable URL to copy. Purpose-built video platforms in the Vimeo/Wistia class do this out of the box, if your org prefers its own infrastructure, signed URLs on CloudFront or Azure with short-TTL HLS achieve the same, and given you already build Forge macros, a small Forge app can mint those short-lived tokens after checking the viewer's session, which directly fixes the DevTools problem you found.

One line on Guard, since you set it aside: its data security policies are the only native download-blocking lever today, and they are org-policy-shaped rather than per-video, so your call there was right too, and the ceiling you already named is real: once playback happens, screen capture always exists. The goal is removing every casual path, and the pattern above does exactly that.