> These things shouldn’t end with a bounty for the researcher and a patch by the vendor. It should end with a root cause analysis and a plan to fix that type of vulnerability across the entire app, or better yet, the whole industry via a research paper.

I'm unsure (and open to discussion) on which classes of bugs make that possible. My initial thought is that finding a stack overflow bug (to randomly choose a bug class) results in "don't goof up memory", which is technically correct, but not actually useful in finding others of that class.

In this hypothetical, maybe the result would some combination of accessing programming language choice, programming practice, and testing tooling? Can't say those are a silver bullet though.

I'm still upset they try to force you to use their plugin. These would be less scary if it were jst a web app.

You can force it to use a web app by declining permission to run locally.

The web-app has fewer capabilities (no gallery view, last I used it), but works great.

Also, Meet is fully-featured and runs entirely in-browser.

Meet performs quite poorly with large number of participants (the tipping point being around 10 or so for me) in a meeting. I tried various browsers and found Chrome to be the worst performer and surprisely Firefox was somewhat better but still needed a refresh every now and then. Macos on a 2017 MacBook. This is one of many reasons keeping my $employer on Zoom. We just haven't found a decent video conferencing software that manages 25+ videos flawlessly. I know of colleagues using Teams successfully but many people we meet with outside our organisation expects Zoom nowdays. I suspect any alternative will have to be very good to take over Zoom as the preferred platform. That has yet to appear.

Evidently, it depends on multiple factors.

My son's school uses Google Meet for online classes. 2 instructors + 36 students per section. All participants have their videos switched on. Even when the bandwidth fluctuates, we haven't noticed issues. In particular, Meet degrades well: audio continues to be high quality, with video becoming grainy or getting suspended. But, that is pretty rare. And, slide shows are never a problem.

Ah that is interesting. I work for a school for Deaf learners who use sign language. We rely on having good quality video so we can see each other. Your description of video degradion matches my observation. Unfortunately this is not suitable for our use case. Zoom maintains high quality video really well on the same connections meets will degrade quite badly. I've always thought there should be a switch to decide which of video or audio should receive priority.

I've wondered whether things like the gallery view limitation were actual technical hurdles, or just the modern equivalent of nagware to boost the app download metrics.

At the start of the pandemic, the web client had gallery view.

Is the lack of a gallery view a genuine technical constraint, or an artificial one introduced to get users to use the plugin?

False dichotomy. There's a (likely) third option where they do not have sufficient engineering effort to do everything at once. Most users are on the app so that's where effort is applied. Yes, this means the webapp loses even more market share but thems the breaks.

Given that Facebook removed functionality from the mobile web view that was present in earlier versions and is still there in the desktop view (messages, cough), I think that it's a very fair question to raise about Zoom's choice to not allow gallery view in the web app.

Putting aside that Zoom is not Facebook, "Zoom's choice to not allow gallery view" sounds very much like, "How long have you been beating your wife?" Zoom has not implemented gallery view. We know nothing about the whys, hows, and whats of the matter.

Look, I prefer webapps when possible and keep mobile apps to a very minimum on my mobile (and preferably from F-Droid, at that). But I also understand that you can only do so much in a release and if your engineering team expertise, backlog, users, sales, EVERYTHING, is centered around native apps. Then damn it, you're going to make your native app look stellar because otherwise your competitors will get a leg up over you.

I can still get FB Messages in the mobile web view by telling my browser to use Desktop view and ensuring the URL starts with "www" rather than "m." It's painful but it works.

I deleted the FB app from my phone years ago (with difficulty because Samsung makes it undeletable by non-hackers) because the app gives FB far too much info about me.

On macOS my experience with Zoom in the browser is that the gallery mode works in Chrome, however in Chrome it has problems with the camera (it reports that the camera is in use, or will hog the cpu and work at about 1 frame per second). On Firefox the camera works fine, but there is no gallery mode. On Safari the gallery mode and camera both work, but audio does not work! So I need to choose whether to do without video, audio, or gallery mode, or I can connect to the meeting twice with two different browsers.

Yes, but they keep pushing the binary anyway.

The web client now has gallery view

They do? I don't have any plugin installed and use Zoom in Firefox without major issues

Lol, I forgot that it could even be run in a web browser!

“ does not affect the browser version” at least they weren’t able to combine this with a browser security flaw to escape the JS sandbox.

What makes you assume no RCA will be done?

I should clarify: public RCA.

Is $200k enough to motivate a company like Zoom to do an RCA after something like this? Maybe? I personally doubt it but don’t have any real reasoning for it one way or another.

Oh the link actually says that it is not patched. So now everyone with an interest in nuclear devices knows that the code is something really easy to guess. The silver lining in this moving the nuclear warning system a few minutes closer to 12 is that the guy who pointed it out got a bonus and a raise!