Comment by spaceribs | Hacker News Reader

Comment by spaceribs | Hacker News Reader

Parent Full thread

If you want to really break down their viewpoint on the situation, lets translate their PR statement line by line:

> Zoom believes in giving our customers the power to choose how they want to Zoom.

Zoom believes if their app isn't convenient to use, their customers have the power to leave their ass, as they are in an incredibly competitive market.

> This includes whether they want a seamless experience in joining a meeting with microphone and video automatically enabled, or if they want to manually enable these input devices after joining a meeting.

This includes making sure that they aren't asked to provide confirmation to access their camera/microphone, which impedes the convenience of the app to all participants. Less clicks equals less thinking.

> Such configuration options are available in the Zoom Meeting client audio and video settings.

Stop complaining about this as we have given ourselves a legally compelling user defined control hidden in a single tab deep within our preferences.

> However, we also recognize the desire by some customers to have a confirmation dialog before joining a meeting.

We can tell you aren't going to drop this.

> Based on your recommendations and feature requests from other customers, the Zoomteam [sic] is evaluating options for such a feature, as well as additional account level controls over user input device settings. We will be sure to keep you informed of our plans in this regard.

We don't care. We have lots of users, and lots of success having this option turned on by default. The support costs alone telling non-technical people how to turn on their cameras don't make it worth it.

Oh come on. There is no easy way to send people without the app to a installer page, that is the issue. And that is something every single person wants.

Good point. Maybe MacOS/iOS should have a feature where, just like going to a custom service that can launch an already installed app, such as zoomus://123456789, they can allow software vendors to register an install URL that users who don't have the app already installed will be directed to. Let the OS handle security, where it should be, and still make the first install user experience good.

They have the opposite starting with Catalina and iOS, Universal Links that lets an app register to take the first pass at handling zoom.us URLs. Android always had this with their intent system.

Was available long before Catalina

Bad behavior for unknown protocols is not a MacOS specific problem. Instead of registering things with Apple, a link to the handler should be included in the protocol link and the OS should send the user there if a handler is not installed. Something like <a href="zoom://12345" handler="https://zoom.us/install">

Your proposal is the closest thing to the best solution I have seen. It still has at least several issues:

* When Zoom is already installed:

- should be able to handle most instances

- needs to account for version management, eg installed version zoom could still be version that is too old to process the uri correctly. Version could be in the uri.

When Zoom is not installed:

- an information dialog needs to be somehow shown to the receiving user, asking them if they want to install 'Zoom'.

- that screen must include the 'uri' and validate certificates etc to prevent abuse (hence must necessarily be 'ugly' and not 'seamless')

- the language on that dialog has to be provided by the OS/Browser, not the software vendor, to prevent abuse. For similar reasons the Windows UAC dialog text can't be written by the vendor.

- the language employed by the OS/Browser has to of necessity be fairly neutral, neither encouraging nor discouraging installation, to prevent abuse. This is necessarily at odds with the UI principle of leading the inexperienced user through clear steps to achieve their intended goal.

- the user of average-to-lower-quartile experience, as of 2019, for a product with a client base of 40 million+, is likely not in a position to meaningfully distinguish a legitimate Zoom install uri from a malicious / imposter one. Hence any popular software using this install-from-uri-handler becomes an appealing target for malicious actors to mimic, which they will.

- some proportion of users will likely install from malicious links, and whichever product (let's say Zoom for example) is the most likely software for malicious actors to masquerade as will become the name associated with the attack in the mind of the wounded public

Those are some interesting points. I'm not convinced that versions should be in scope for this sort of thing though. If I'm writing a protocol handler, I think it's my responsibility to make sure my software can update itself, and make the default behavior that it should check for updates if it is given a URI it doesn't understand.

Secondly, version checks assume that the user wants to run this specific protocol handler. I as the user might prefer to run an open source non-official zoom client. I think the OS should only be trying to help me if I don't have any handler.

The UA could go to the handler site which would be a landing page.

Well, presumably if that's the case, their ZoomOpener could simply be configured to respond that it exists. That would be enough to either direct the user to a download page or open the protocol-specific URI.

If I'm understanding it correctly, the reason it does more than that is to bypass the "protocol-specific URI opening" UX.

I'm unclear what subset of users are desktop only Zoom users that aren't also familiar with the same "Do you want to allow this app to access your camera/microphone?" dialogs on mobile devices. This can't be a large demographic, can it?

Ah, but that's an interesting question right? do they WANT to be asked? If you only had to make one click to join a meeting, doesn't that FEEL better?

In fairness, I get irritated about the fact I need to tell WebEx to use my computer's audio to join the call every damn time I join a meeting quite annoying.

If only there was some happy middle ground between never asking and always asking ...

For me the problem isn't that it asks, it is that it forgets (and they don't have the same options consistently across hosting orgs).

I'd be totally fine with default-on voip sound - with a red, muted mic button and a bubble saying 'tap to unmute'.

Reply on news.ycombinator.com