To Reproduce(If applicable)
Steps to reproduce the behavior:
User1 joins meeting as guest from one browser on a machine
User2 joins meeting as guest from another browser on a different machine
User1 presses the claim host button and becomes the host of the meeting
User1 closes the browser/tab
After a few minutes User1 disappears from the participants list and User2 becomes host automatically
I have tested this with 3 or more participants and it seems the host permission is being given to the available person that joined after the host.
Also, host is being given to a guest even if they have closed their browser and they are not longer in the meeting but their username remains in the participants list, and of course once that list refreshes, the host is then being given to another person.
I believe this is a byproduct of a host having to pass the host to someone to leave the meeting. As they don’t have the option of just leaving, but only ending the meeting or passing the host to someone else, even though the meeting allows participants without the host being present, which is funny.
This has been tested on Safari, Chrome, Firefox and Edge, all latest versions and the same thing happens on all of them.
This is quite a big security issue, as you don’t want a random guest from a meeting to become host and be able to control the whole meeting and participants.
Hey @alexbudin , thanks for bringing this up. This is expected behavior for Zoom Meetings and the Meeting SDK (Web, mobile, and desktop platforms). If a meeting is occurring and the host leaves, a host is assigned until an authenticated host rejoins the meeting.
Following the thread in 2020 about 1.8.x, we did introduce a change to re-join/reclaim the meeting host permission using the host signature in the join process of the Web Meeting SDK.
If you assign Co-host or alternate host to a participant, they will receive host permission rather than another participant.
Additionally, in the event that a meeting host ends their session and has not ended the meeting, you can update meeting status using the REST API to update meeting status.
@michael.zoom There is no way this is normal. Hopefully an option is added in the meeting settings that prevents this. A checkbox or something that lets the app creator/admin to not allow the host to be given to anyone else. This is quite a big security problem.
@j.schoenemeyer is right, this appears to be a problem in the recent version as well.
Imagine losing internet access for 2 minutes and a random guest getting admin rights. Not to mention that on the web once there is a host in the meeting, nobody else can see the CLAIM HOST button to become host or get the host from that guest.
Thank you for your feedback @alexbudin and @j.schoenemeyer! As @michael.zoom mentioned, this is expected behavior. However, you can control who is passed host controls (meeting admin rights) and manage the experience if a host loses connection.
To mitigate a random guest getting admin rights, you would assign a Co-host or alternate host to a participant. This way if the host was to lose internet access for 2 minutes and a random guest would not get admin rights. Instead, the designated co-host or alternate host will receive host permission rather than another participant.
Host and co-host controls in a meeting
Additionally, if the host and co-hosts are not present or if they lose connection during a meeting. In the Zoom Web portal, you can select the check box to move participants to the waiting room if the host drops from the meeting unexpectedly. Once the host rejoins, they will regain host permissions and can admit participants all at once. Note, if you select this option, join before the host will be disabled. See our Enabling and customizing the Waiting Room for more details on this feature:
But this is still a bug. I dont want to use waiting rooms. Imagine having a live stream and the host drops and a guest just gets host and terminates the meeting.
There are legitimate reasons why someone might not want to use a waiting room and its not even default. If you would have this as a default at least i can see you are trying to avoid this.
But all yu have done is offer me a WORKAROUND. This is not a fix.
What you are saying is this is intended but this is how you can avoid losing host access because we can see this happens, but look here where you can have this workaround :))) Which is just not admiting this is a security issues and having a proper fix for a feature that you have and thats to create a meeting WITHOUT a waiting room.
Does it make sense? You are just offering workarounds for a LEGITIMATE SECURITY ISSUE.
Why allow the creation of meetings without waiting rooms when you have this security issue?
Its not intended behavior if you can do it without having a co-host and without a waiting room.
You actually say: “To mitigate a random guest getting admin rights” which i read as “we clearly have this security issue but here is how to go around it…but hey this issue you are describing…we do this on purpose”
People need to know you have this issue because by default you can create meetings without cohosts and without waiting rooms. There is no warning, there is no fix.
I would rather hear form you guys a plan to fix this, some concrete plans or solutions.
Thank you for taking the time to share your feedback with us, @alexbudin. I understand your point that there are legitimate reasons why someone would want to create a meeting without a waiting room. In this situation, I do see an issue allowing the creation of meetings without waiting rooms. I’ve forwarded this feedback to our developer team and will get back to you.
Feel free to ping us here for updates on this matter and do let us know of any other additional feedback you might have now—we’re here to listen!
You SHOULD allow creation of meetings without a waiting room, but a simple checkbox to not allow the transfer of the host would just fix this where there is no waiting room configured. It should be such a simple fix to do. This is currently a security issue as it stands.
is there any way to see in the SDK version, if someone is host or co-cost - the guest, who get the lost host right, is named as (Host, Me) after the 2 minute timeout
is there a info page, where the difference between Host and Co-Host is described in detail
@alexbudin , @j.schoenemeyer , I appreciate the detail in testing here and the feedback. We’re working with our Meetings product teams on this, as this does extend outside of the Meeting SDK (which, as the client, is the consumer of the meeting settings here).
I hear your feedback that the meeting host reassignment could cause unintended meeting control in the event that the waiting room option is not workable. Let me circle with some folks and get back.
which i read as “we clearly have this security issue but here is how to go around it…but hey this issue you are describing…we do this on purpose”
