[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.