@tommy
please just disable this from non-host participant
thank you
There are a lot of people waiting for this fix. I think it is pretty intuitive that the host should have the absolute control over who gets the meeting link and password.
Is it at least in the works? We intend to use Zoom on our platform but are getting skeptical about such security issues. Request the team to share relevant updates on this topic.
Is it possible to get some update, whether it is Feasible/Not Feasible, if feasible what are the timelines. We need to handle so many support issues because of this one functionality where uninvited users come create problem and go away.
Zoom is talking about security enhancements, we have a basic requirement which is not addressed for so many days.
Is there any progress for this request? I need it very much!
This thread was started in April and now its just the end of the year and yet this feature is not implemented.
Can we get any update ? Why not simple toggle to hide meeting invite/share link & passcode from meetings ? Upto when we will have to wait for this simple feature.
Yes for us in our university this is a security problem as any student can copy the link and share with any one, and could be worse, a student can use it to try to get iwth other names too.
Please @tommy have you had an ETA for this.
@tommy @shrijana.g Any Update on this? Itās been more than a year since this issue is open and unresolved. At least do let us know why it is taking soo much of time to implement this feature and by when you guys can release it?
Hello! Any news on a way to disable the infoicon showing link to meeting and password?
Was anyone able to solve this? This simple feature is a huge security issue and hundreds of users donāt use zoom because of it.
Please help.
I suspect the main reason for this type of delay is not totally zoomās fault, but the architecture that the initial engineers for Zoom have built. It heavily relies on the concept of a meeting id and password, and their product has been built in such a way that each meeting has to have some of identification, and in case of zoom, itās only the meeting ID. So when the web client (the one in the SDK) has to connect to the backend, it has to identify which meeting it has to connect to using some fetch calls, to hide it on the frontend is not enough (even us devs could do it ourselves using a few lines of code). The problem is the API part. If the user could join via the web client, so they could theoretically scrape the fetch calls to get the meeting-ID-containing-request.
This makes it unpractical to hide the meeting IDs on the frontend (at least it is sort of effective because non-technical people would not be able to access the meeting IDs themselves) because the app needs it to join the meeting. So I suspect zoom would have to reimagine their whole meeting joining and authorization system in order to make this feature request effective, and in case of a company like zoom, it would take half a year just to plan, and then thereās the implementation part. Oh, boyā¦
I do agree that the SDK should give the option of hiding the meeting IDs and passcodes altogether, but it wonāt be complete protection against the impersonation or spammers threat. Zoom would have to totally change how clients connect to meetings.
Then thereās the economic factor. Does zoom really want to invest 1000s of their engineersā hours into make something manageable, great; or would they rather prefer to make implement some kind of exciting feature to capture more of their market shareā¦
Hence, I donāt expect this feature request as their biggest consideration for now; maybe weāll just have to wait