Qube security explained
Know what stays protected
Qube runs the meeting and shared work in a trusted cloud session. The protection of the view and audio delivered to a participant depends on the client and session policy. Use the controls with a clear understanding of what has been designed, what has been observed, and what remains unverified.
Qube · Content reviewed
The work runs inside Qube
The shared environment contains the session’s tools and working files. Participant devices send input and receive the rendered view. The architecture trusts the cloud runtime, control plane, identity system, and authorized recording components.
That changes the place where work executes. It does not make the cloud provider unable to process the work, or prove that application export paths, external cameras, or human disclosure are impossible.
Protected presentation has client conditions
The intended protected path uses a browser content-protection system and the policy supported by the client. Browser, operating system, hardware, key-system robustness, and output policy affect the result. Do not describe the architecture as universal Widevine L1 playback on every device.
Check the negotiated protection and actual capture behavior before relying on the session for sensitive work. A client that cannot meet the required policy needs an explicit unsupported or restricted outcome rather than an assumed equivalent level of protection.
Each additional control answers a different question
Context controls can respond to focus and fullscreen changes. A paired second-device camera can add a view of the surrounding workspace. An acoustic-leakage control can provide a signal about protected sound reaching the room. These controls are not interchangeable.
Session identifiers and watermarking may support attribution if material is captured. Attribution is a different claim from prevention. A measured recovery result must identify the watermark method and the conditions under which the copy was recovered.
Published validation status
This page describes the architecture and its conditions. It does not publish an independently qualified device-level capture matrix or a measured deepfake-detection accuracy result. No browser/OS combination should be treated as capture-validated merely because it appears in a product illustration.
Windows browser capture, macOS browser capture, and system-audio or loopback capture must be qualified separately. Tool-specific macOS system-audio and loopback capture behavior remains unverified unless a test method and result are published.
- Record the browser, operating system, hardware, and software versions.
- Record the negotiated key system, robustness, and output policy.
- Observe moving video through the stated screen/window capture method.
- Test audio independently, including the local path relevant to the threat model.
- Record unsupported-client and failed-protection behavior.
What remains outside the software boundary
Another camera can film a display. Another microphone can hear sound in the room. A person may relay information or receive help that the session cannot observe. Side channels and misconfigured tools can also matter.
Keep those risks in the decision. Use an appropriate task, an explicit assistance policy, and human review of the available evidence. No security event by itself determines intent or hiring fitness.
A disposable workspace can leave an authorized record
Closing a temporary execution environment and retaining an authorized recording are different lifecycle decisions. The meeting may end while the organization still retains a review record according to its policy.
Before a sensitive session, agree on recording, participant notice, authorized reviewers, and retention. Confirm the actual settings and the applicable data-handling policy rather than assuming that disposal means every copy and record disappears.
Questions before the meeting
Which protections are guaranteed on every device?
This page makes no universal device-level capture guarantee. The delivered protection depends on the supported client and negotiated policy. Validate the intended devices and capture methods before relying on a particular boundary.
Is Qube proven to block every system-audio recorder?
No such universal result is published here. Speaker leakage, local system-audio capture, and external microphones are separate paths. An audio control must be tested against the path it claims to address.
Does a successful automated test prove screenshot exclusion?
A build, mocked control, license exchange, or headless page check does not prove device-level capture exclusion. A relevant observation needs the actual protected session, client, capture method, and visual/audio result.
How should my team evaluate Qube?
Bring the intended workflow and devices. Define the information and capture paths you need to protect, demonstrate the relevant controls, and agree on the remaining risks and retained records before using the room for sensitive work.
Sources and review method
First-party documentation reviewed on October 18, 2026. Availability can change by plan, client, and rollout. Product documentation describes a capability; it is not an independent security test.
Bring your workflow into Qube
Walk through the room, the shared tools, and the participant devices with us. Agree on the protection and review settings before you use it for sensitive work.
Book a demo