Research question
Can a high-stakes meeting remain useful without trusting every participant computer with the conversation, files, applications, and decoded meeting surface?
In a conventional video call, the participant device is where the meeting is decoded, displayed, and often where the shared work is opened. The operating system composes the meeting window, manages local processes, and exposes capture surfaces. A browser extension, virtual display, local model, recorder, or privileged tool may therefore observe the same endpoint as the authorized participant.
Endpoint monitoring tries to identify unwanted software after the meeting has already reached that environment. Qube takes an architectural approach: move the meeting and work into a controlled cloud room and reduce the participant browser to the narrowest useful role.
Qube creates one security boundary by controlling where the meeting and work run, protecting how they reach participants, and collecting authorized evidence inside the same room.
Participant window
Camera, microphone, input, device qualification, and protected playback
Qube control plane
Identity, admission, session policy, keys, orchestration, and security events
Protected cloud room
Meeting media, Qube Computer, applications, files, evidence, and disposal
Threat model
The model assumes participants have administrative control of their local devices. They may install software, attach virtual displays, run OCR or transcription, and use local AI or recording tools. The network between the client and Qube is untrusted. The Qube control plane, room runtime, identity system, authorized recorder, and approved participants are trusted components.
- Protected asset
- Conversation media, workspace state, files, application output, decoded session pixels, and the synchronized evidence record.
- Primary adversary
- Software on a participant device attempting to read, copy, transcribe, or relay information from the live room.
- Security objective
- Limit direct access to session data outside the controlled execution plane and retain attributable evidence inside it.
- Non-goal
- Eliminating cameras, verbal coaching, social engineering, compromised cloud administrators, or every possible side channel.
System design
Qube creates an isolated workspace for each room. The workspace can contain the approved browser, documents, dashboards, development tools, models, and services required for the meeting. Participants join through a browser and interact with the remote workspace under separate identities and permissions.
This separation changes the location of sensitive state. Files, browser sessions, terminal history, model context, and intermediate work remain in the cloud room. Participant devices receive a rendered view and send input events. At the end of a disposable meeting, the temporary workspace can be destroyed while any authorized record follows the organization's retention policy.
Configure
The host creates a protected room, chooses admission, recording, retention, and security settings, and prepares the applications or files needed for the session.
Work
The browser, documents, dashboards, IDE, terminal, and approved services run inside Qube Computer. Participant devices send input without receiving the underlying workspace.
Deliver
Application-layer encryption protects live meeting media end to end. Qube then delivers the visual session through a protected media path on supported clients.
Record
When authorized, the conversation, workspace activity, security events, and supporting evidence are synchronized on the session timeline.
Protected delivery path
Qube encrypts live camera, microphone, and screen media at the application layer before WebRTC transport. Authorized meeting runtimes receive current SFrame keys; missing authorization, invalid keys, or runtime failure stops encrypted media rather than falling back to an unprotected stream.[1]
The protected media integration secures the next boundary. The W3C Encrypted Media Extensions API lets the browser select a content protection system and mediate license exchange.[2] Widevine supports browser playback through a content decryption module.[3] Qube uses that path to restrict ordinary software access to decoded frames on supported clients.
The room policy requires the negotiated protection level before protected content appears. Compatibility reporting records the browser, operating system, key system, robustness level, output policy, and observed capture behavior for every supported client.
Evidence model
Moving the workspace into the cloud keeps the reviewable process at its source. An authorized record can synchronize the conversation, application activity, shared artifacts, security events, and collaborator actions without inspecting unrelated processes on participant computers.
The record lets an authorized reviewer reconstruct what the group saw, said, and changed, then connect decisions to the evidence and security context surrounding them.
| Source | Recorded object | Review question |
|---|---|---|
| Workspace | Files, application state, and material opened in the room | What the group reviewed or changed during the session |
| Conversation | Authorized recording and diarized transcript | What was said, decided, or explained at each point |
| Interaction | Shared-computer actions and resulting artifacts | How the work moved from discussion to execution |
| Security | Admission, focus, surroundings, acoustic, and protection events | Which controls were active and what unusual events occurred |
| Collaboration | Presence and session annotations | Who joined, what context they had, and how the group worked together |
Properties and conditions
Each security property has an enforcement requirement. The table connects the protection Qube provides to the runtime condition that keeps it active.
Workspace isolation
Protected files and application state are not placed on participant devices.
Condition. The host must open and use the sensitive material inside the Qube cloud computer rather than distributing local copies.
End-to-end media encryption
Application-layer encryption protects live meeting media between authorized runtimes.
Condition. The meeting must use the encrypted SFrame runtime with valid authorization and current media keys.
Reduced pixel exposure
A protected media path can restrict direct access to decoded frames.
Condition. The joining browser, device, protected-media integration, negotiated security level, and output policy must satisfy the room policy.
Session traceability
Exposed frames and authorized records can be connected to the room and its timeline.
Condition. The forensic session mark and the relevant authorized record must be active, complete, and synchronized.
Limitations
The design narrows the trust boundary; it does not remove the need for access policy, participant judgment, device qualification, or security testing. The following limits define the conditions around the architecture.
Optical capture
A camera pointed at the display remains outside the software trust boundary. Watermarking may support attribution, but it does not prevent recording.
Client variability
Protected media capabilities differ across operating systems, browsers, hardware, and policy. A deployment must measure the negotiated protection on each supported client.
Human relay
No media architecture can stop a person outside the observed area from relaying information. Admission, surroundings visibility, access policy, and live facilitation remain important.
Side channels
Timing, bitrate, accessibility surfaces, notifications, and misconfigured session services can disclose information even when direct frame access is restricted.
Evidence requires human review
The session record preserves activity and security context. It does not determine intent or make legal, compliance, hiring, or business decisions for the organization.
Validation status
Security claims require device-level testing, adversarial evaluation, and clear compatibility reporting. Architecture alone is not proof of enforcement.
Conclusion
Meeting confidentiality is partly a systems problem. Delivering the meeting and sensitive work onto participant-controlled devices places protected information and local observation tools on the same host. Qube separates them by running the meeting and workspace in an isolated cloud room, encrypting live media end to end, delivering a protected view, and collecting authorized evidence inside the session.
The strongest version of this design depends on verified client protection, complete in-session instrumentation, and independent adversarial testing. Future work should publish device compatibility, measured capture behavior, latency, event completeness, and failure-mode results. Those measurements will determine where the architecture provides a strong control and where it provides only a useful reduction in risk.
References
- E. Omara, et al. SFrame: Secure Frame. RFC 9605, Internet Engineering Task Force, 2024. rfc-editor.org
- W3C Media Working Group. Encrypted Media Extensions. World Wide Web Consortium. w3.org/TR/encrypted-media-2
- Google. Widevine DRM overview. Google for Developers. developers.google.com/widevine