The practical meaning of browser-side
Browser-side processing means the visitor's browser performs the large media requests and MP4 assembly. It does not mean that the entire workflow is offline or that no third party receives network information. The browser still connects to the website, the resolver, and Kommodo's approved media hosts. Each party can receive ordinary technical information needed to serve those requests.
The important architectural distinction is that this application's server does not relay the video segments. After the resolver returns an approved playlist URL, the browser uses the Fetch API to request the playlist and segments directly from Kommodo's delivery infrastructure. The bytes then remain in browser-managed memory until the MP4 is saved or the page is closed.
The data flow, item by item
| Data | Where it goes | Why |
|---|---|---|
| Public recording URL | Cloudflare resolver and Kommodo page | Locate the approved HLS playlist |
| Playlist and segments | Kommodo hosts to visitor browser | Receive the recording data |
| Recording title | Resolver response and browser UI | Create a useful file name |
| MP4 Blob | Visitor browser memory | Prepare the local save action |
| Contact email | Email provider, only if you contact us | Reply to support or legal requests |
The application has no user account system and does not intentionally place analytics cookies or advertising cookies. Cloudflare and other network providers may still process IP address, user agent, timestamps, request paths, and security signals as part of delivery, abuse prevention, and routine logs. Because the resolver request contains the share URL, avoid using links you are not permitted to submit.
Why CORS controls the browser transfer
Browsers apply the same-origin policy to scripts. A script loaded from this site cannot freely read a response from another domain. Cross-Origin Resource Sharing lets the remote server opt in by returning access-control response headers. MDN describes CORS as the HTTP-header mechanism through which a server identifies permitted origins.
The Kommodo share page does not provide the browser access needed for this tool to parse its HTML directly, which is why the restricted resolver exists. Compatible playlist and segment hosts do provide browser-readable responses. If those headers change, the browser may block the transfer even if the recording still plays inside Kommodo's own interface. The downloader does not and cannot disable browser security.
More detail is available in the MDN CORS documentation and the project's technical architecture guide.
Memory, temporary URLs, and device limits
The current implementation stores downloaded segment buffers, transmuxed MP4 parts, and the final Blob in browser memory. The exact peak is larger than the final file because intermediate representations can overlap. Browser and operating-system limits vary, so there is no universal maximum recording size.
A Blob URL is a local browser reference, not an uploaded web address. The application revokes it when a new job resets the state and again when the page closes. Your browser may also release related memory after navigation or process cleanup. Until you choose Save MP4, the result is not safely stored as a normal file.
Security controls in the open-source implementation
- The resolver accepts only secure Kommodo recording URLs with a strict path shape.
- Returned HLS URLs must use approved Komododecks hosts and HTTPS.
- Remote titles are displayed with
textContent, not interpreted as HTML. - Page and segment counts have safety limits, and failed segments receive bounded retries.
- The media library is bundled on the same origin and the Content Security Policy restricts scripts to the site.
- API errors avoid returning network exception details that could expose implementation information.
These controls reduce risk; they do not promise absolute security or privacy. Review the Privacy Policy for the operational policy and the source code for the exact implementation.
Privacy checklist before processing a recording
Decide whether browser-side processing is appropriate before pasting the share URL. Confirm that the recording owner permits a local copy, that the device is trusted, and that the destination folder follows your organization's access and retention rules. Close screen-sharing software if the recording title or progress should not be visible, and avoid public or managed computers where browser downloads may be inspected by another administrator.
The finished MP4 can be more portable—and therefore easier to redistribute—than the original share page. Protect it with the same care as the underlying meeting. Use device encryption when available, restrict synchronized folders, and delete temporary or duplicate copies according to policy. For highly confidential, regulated, private, or exceptionally large recordings, an official export managed by the recording owner may provide a more appropriate audit trail than a public-link workflow.
Your choices
You can use the project locally from its source code, avoid contacting support, close the page to release its temporary in-memory result, and refrain from submitting a share URL. You can also ask a recording owner for an official platform export when browser processing is unsuitable for the sensitivity or size of a recording.
For common failure symptoms related to CORS, expired signatures, memory pressure, or unsupported media, continue to Troubleshooting Kommodo downloads.