[muzzio]

Zoom responded to this point [1]:

> This is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting. The local web server enables users to avoid this extra click before joining every meeting. We feel that this is a legitimate solution to a poor user experience problem, enabling our users to have faster, one-click-to-join meetings. We are not alone among video conferencing providers in implementing this solution.

Presumably they're both doing the janky web server solution for the same reason. Either way, I'm not sold, that browser behavior exists for for a reason.

[1]: https://blog.zoom.us/wordpress/2019/07/08/response-to-video-...

[AgloeDreams]

Wow that is really damning, trashing user security in trade to remove a single click that makes it clear as to what is happening.

This totally breaks Apple's Developer Terms right?

[josteink]

> Wow that is really damning, trashing user security in trade to remove a single click

As someone who has had to develop and maintain a similar web-to-desktop bridge I can tell you that this one issue was responsible for around 90% of my company’s total support requests, despite only being a small feature in a optional addon in one of our main products.

For businesses just trying to keep their customers happy, this particular one click is a very real problem.

I can absolutely symphetize with people trying to come up with workarounds.

[nickdandakis]

Did your company try to write an FAQ page on how to accept the double-confirm dialogs in all major browsers (with screenshots) to maybe reduce your "90% of support tickets"? Does your ticketing software redirect you to (or display) an FAQ page that matches the ticket title?

I've come to understand how features like these get built, but I've also come to understand that people that use software are a lot more resilient and savvy than we think.

If 90% of your support tickets are about getting through a standard double-confirm, patio11 would probably recommend increasing your pricing to limit your paying customers to a pool that probably won't have much more trouble with that.

[p_l]

Ahhh, sweet naivety.

The people who end up calling support often aren't the ones paying the bill, for starters. That's definitely the case for Bluejeans and Zoom.

It also doesn't matter if you make a great FAQ page. Majority of dissatisfied people will never see it. Majorly because they won't call support but instead complain and grumble locally, the second biggest portion because once sent towards FAQ by support.... They won't follow it.

Only the tiny sliver of most dedicated will follow up long enough to reach the FAQ.

[tobr]

That is interesting. What were the support requests, how to remove the confirm step, or what to do if you denied it but didn’t mean to? Or something else?

[josteink]

Most desktop-browsers have in the name of security made it exceptionally hard to accidentally launch external programs through this mechanism.

We’re talking software engineering phd can’t complete it without hand-holding hard (true story!)

So normal users definitely don’t understand nor manage to navigate the dialogs presented by the browser to produce a “successful” outcome.

In the past we used this mechanism to “automatically” provide configuration-data a desktop component, so that it could call back to our application. And our users just didn’t manage to configure it.

In the name of security, browsers made one path so hard to use, without considering what people would then develop instead.

And here we are now. Oops!

[dpkonofa]

I have to call BS on this. Are you claiming that users can't complete a single prompt of "[Your browser] needs to open an external application to follow this link. (Decline) (Launch Application)"? That seems really unlikely. I've done enough user testing to, at least anecdotally, say with some certainty that this is not true.

[josteink]

It’s a two-dialog process (allow website to use external protocol & what external program should be used for this protocol), with intentionally confusing wording making it easy to choose the wrong choice (disallow) if you don’t read thoroughly.

Unless you already know what to do it’s fairly unintuitive.

Most users don’t even know the difference between a single click and a double click.

Expecting them to even know what an external protocol is, or why it should be launched at all is completely unreasonable.

[amluto]

And this is why the web browser vendors need to simply disallow this behavior. Websites seem to think they seem to engage in awful behavior to compete with each other. If the browsers just block it outright, then everyone will be on a level playing field.

[AgloeDreams]

Thats kinda what happened here, Apple made the user confirm that they were going to take an action on an app on their computer and Zoom built functionality in on the app to bypass it.

[amluto]

No, you’re misunderstanding me. Websites should not be able to talk to localhost over HTTP. Browser vendors should eliminate the back channel.

[scarface74]

There are no “developer terms” that developers have to abide by for the Mac.

[monocasa]

If they're notarized there's around a hundred pages of terms and conditions you have to agree to. Although I'm not sure this gets in the way of any of them except on one of the blanket ones that Apple keeps intentionally vague.

[scarface74]

Yes if 6 == 100.

A sibling reply posted the link.

https://developer.apple.com/terms/apple-developer-agreement/...

[monocasa]

Can you expand? I'm not sure what your comment means.

[scarface74]

You said there are “about 100 pages of terms and conditions you have to agree to”. There are six pages.

[chrisfinazzo]

Ahem.

https://developer.apple.com/terms/apple-developer-agreement/...

[scarface74]

And you are not forced to abide by the developer terms to release a program for the Mac just as I said. Despite all of the HN conspiracies, you can develop for and release code on the Mac without Apple’s permission. You don’t have to abide by those terms.

[ceejayoz]

The Zoom and BlueJeans apps are both signed, which indicates they're part of Apple's Developer Program, and thus bound by its terms.

If you want to distribute an unsigned app and guide users into bypassing Gatekeeper for it, by all means, do so... but that's not what's happening in this case, nor is it particularly common due to the intentional hoops they make you (or more accurately, every single prospective user of your app) jump through.

[scarface74]

And that still doesn’t contradict my statement that you can distribute apps for the Mac without being in the developer store....

[chrisfinazzo]

Wait a while. Holding one's breath not recommended.

For those who don't want to (or cannot, due to the nature of their application) use the Mac App Store to distribute software, the requirements will only continue to get more specific until (to the extent possible) all executable code and resources are notarized and signed with an identity.

<Insert Perry the Cynic rant about unsigned code - "What the hell is wrong with you!?">

[scarface74]

This same prediction has been going on since 10.6 - over 7 versions ago. How do you propose that Apple forces code signing on programs that run on top of a VM like the CLR or JVM? How do you propose they enforce it for programs run using a scripting language? The best they could do is force signing on the runtimes.

But my point still stands. Today on July 9th 2019 you are not forced to be part of the developer program to distribute apps on the Mac. Despite all of the pollyanish the sky is falling type that has been going on for over a decade.

[ceejayoz]

I'm fairly certain you have to agree to some to join the Apple Developer Program, which is (sort-of) required if you want people to be able to run your app.

[scarface74]

You don’t have to be in the developer program ftp distribute your app on the Mac.

[ceejayoz]

Technically? No.

It'll largely refuse to run ("App can't be opened because it is from an unidentified developer") if it's not signed via Gatekeeper, though.

There's a procedure to bypass that, but it's hardly user-friendly. https://support.apple.com/kb/ph25088?locale=en_US

[scarface74]

Yes control click is really complicated.

[vbezhenar]

How is it trashing user security?

[ghostpepper]

By running a web server with the ability to circumvent installation? It could almost be considered a backdoor

[vbezhenar]

User willingly installs their software, they are not backdooring it. There are plenty of services running on every computer, including TCP servers and web servers. If you're going to call them backdoors, you've got a long list.

[ghostpepper]

If I think I have installed your software and it's secretly running a web server with the ability to reinstall itself, I am calling it a backdoor. I think that list is pretty short, but perhaps I am wrong.

[dpkonofa]

Look at what just happened with Zoom. The web server could be used by a malicious third-party to gain access to the system.

[goerz]

I don't think I understand the security implications of this either. Seems distasteful, but how could it be exploited?

[sabbour]

https://www.wired.com/story/zoom-bug-webcam-hackers/

[kstrauser]

I resisted the urge to vote you down simply because their response you quoted pissed me off so much. I'm going to remind my CTO of this when our contract expires and it's time to evaluate alternatives.

Signed, Unamused CISO

[prophesi]

They were probably also against Window's UAC popups.

[komali2]

Everyone I knew was against UAC popups, including security professionals.

They were likened to California Prop 65 warnings: so prolific as to be ignored, and arguably causing more harm than good, because just as apparently since EVERYTHING causes cancer one can't make decisions about avoiding things that actually do, so to does EVERYTHING trigger a UAC popup and so who gives a fuck, one more thing to quickly ignore and click through.

[chrisfinazzo]

UAC is the correct idea (elevated user privilege levels), but implemented in the worst way possible. As I understand it, things have gotten MUCH less annoying since Vista, but it still left a bad taste in people's mouths.

[syn0byte]

It pops up with exactly as much frequency as a normal user account in most Posix-like systems would require "su" of one form or another. For exactly the same reasons. It's just expected behavior for those systems, but completely unacceptable for Windows.

And we wonder why Microsoft sucks so bad at securing Windows.

[munchbunny]

It was the collision of Microsoft trying to limit "run as admin" and Windows developers taking users running as admin for granted for too long. There had to be a period of pain as "if it ain't broken don't fix it" developers got around to not asking for unnecessary permissions.

These days you mostly see the prompt when you're installing or updating an app, which makes a lot of sense.

What I mean is, this is Microsoft's fault so far as users got in the habit of running in admin in the first place, but I doubt you would've been able to do better given where Microsoft was with its software ecosystem going into Vista.

[prophesi]

Yeah, that makes sense. And I can't think of any way to accomplish it better :/ Every app you install can potentially cause computer 'cancer'.

As a sister comment mentions, it's akin to warning the user whenever they run a command under su/sudo.

[peterwwillis]

Move fast, break security

[LeoNatan25]

GAAS—garbage as a service

99% of software world these days fits this description, sadly.