7.6.9 Locked Meetings

Hosts and co-hosts have the ability to lock and unlock the meeting. While a meeting is locked, no new users will be admitted into the meeting. In non-E2EE meetings, the server performs all access control, but locked E2EE meetings will offer stronger guarantees. When the leader presses the “Lock Meeting” or “Unlock Meeting” buttons in the user interface, their client adds a corresponding link to the LPL. Other participants’ clients show that the meeting is locked only when it is set in LPL; the server does not have the ability to influence this part of the user interface. When a locked meeting becomes unlocked (as indicated by the LPL), all participants’ user interfaces display a prominent warning indicating the change.

Note that due to the tolerances in propagating the LPL, the server might prevent some participants from learning that the host has locked a meeting by withholding the relevant link and selecting a new host within 100 seconds. However, because each heartbeat includes the hash of the previous one, this would result in a meeting partition between the participants who received the lock link and those who didn’t. While the meeting is locked, the leader’s client will refuse to send the meeting key to any new participants who request to join. However, if a user leaves and then rejoins with the same IVK (as is recorded in the LPL), the leader allows them to rejoin. This lets participants who drop out due to network issues automatically reconnect even while the meeting is locked. If the leader changes while the LPL indicates that the meeting is locked, participants ensure that the new leader was in the previous LPL. If not, they drop out of the meeting. The new leader can then copy over the locked bit and the list of participants from the old LPL into the new link. Co-hosts are also able to lock and unlock the meeting. They do this by sending a signed message to the leader via the bulletin board. The leader ensures that the co-host is really a member of the current LPL before processing the change, and trusts the server to identify whether each participant is actually a co-host. Since the server also has the ability to select a new meeting host among existing participants of a locked meeting, this change does not significantly degrade the security of the meeting. In order to prevent replays, co-hosts sign over the latest LPL link hash, and leaders ensure that this matches their view of the LPL before accepting. If the LPL changes before the co-host’s message was received and processed, the co-host tries again. From a security perspective, once a participant learns that the meeting is locked and checks that all current participants are trustworthy (e.g., via a meeting leader security code check), they can be sure that no unintended parties have or will have access to the meeting until an “unlocked meeting” warning is displayed. These additional guarantees for locked E2EE meetings were added in Zoom client version 5.6.0 (see Appendix A).