> Launch the BlueJeans desktop application into a meeting without prompting the user with confusing browser dialogs. This allows meetings to launch quickly on one click without requiring any additional user interaction. It also prevents the user from making a wrong decision on a browser dialog which might permanently lock them out of launching meetings.
join.me seems to have solved this problem effortlessly, and taking a gander at procs, I only see a client running. The BlueJeans rationale here isn't passing my anecdotal sniff-test...
Only problem I've found with join.me is performance. My experience may not be common, but there is so much stuttering with join.me that it's unusable... And I've tried it multiple times on different days with different people.
Aren’t you talking about their actual video stream though? The focus here seems to be on initiating the conference, which join.me does without installing a hidden web server on a users machine the way Zoom and BlueJeans do.
Have these video conferencing services never heard about External Protocol Requests in browsers? It's a much less hacky, and much more secure method to pull off this same feature-set.
> 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.
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.
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.
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.
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.
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.
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.
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.
First, the dialog doesn't give any indication it can be bypassed in that fashion. Second, users should rightfully be suspicious of "just bypass the security!" install instructions - especially non-technical ones.
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.
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.
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!?">
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.
Not to put too fine a point on it, but those examples don't pass muster.
- If you're not using .NET, the CLR doesn't affect you, and although Microsoft has done well with ,NET, I wouldn't necessarily expect Apple to make Redmond's job easier.
- Java is much the same boat, and is perhaps in even worse shape as it used to be included by default in macOS releases but now isn't.
Read: security nightmare.
- From 10.16 on, scripting languages also aren't included by default. This seems less adversarial than the situation with Java, but for things like Homebrew, it's a stumbling block they will need to overcome.
Apple introduced the Mac App Store over a decade ago. Since then, conspiracy theorists have been predicting that Apple will force all apps to be signed.
Are you predicting that Apple will disallow all scripting language runtimes and all VM based development environments? So if these same predictions have been wrong for over a decade - and still aren’t happening with 10.13, exactly when will this happen?
As far as Apple not including (outdated) versions of various scripting languages or Java - neither does Microsoft. That hasn’t been a major impediment to adoption.
I have NO TROUBLE imagining that Apple will continue to tighten the screws on this, enforcing signing through Developer TOS and requiring MAS apps to pay for distribution certs.
Direct download isn't going away, not after all the work that's gone into securing it, but if you think you can sell an app off your own site without giving Apple some identifiable info about who you are and what your code does, prepare to be disappointed.
Runtimes won't be disallowed, just that you (the user) are responsible for installing them and keeping things updated.
Oh, and for record, my reference to "Perry the Cynic" is no accident...he literally invented how code signing works.
So you realize you’re kind of arguing against your point? He made a prediction that still hasn’t come true over a decade later.
And citing the patent office isn’t helping either. Every company patents everything they can.
Direct download isn't going away, not after all the work that's gone into securing it, but if you think you can sell an app off your own site without giving Apple some identifiable info about who you are and what your code does, prepare to be disappointed.
Well today you can. As you have been able to do since the info-Mac archives since before the World Wide Web existed. So unless you can bring back some proof from either your time machine or visiting some other world in the multiverse, I would rather talks about facts as they exist today.
And code signing still won’t stop you from being able to run code that runs on top of a VM or scripting languages without them being signed and you won’t have to do the ctrl-click bypass.
Why is it wrong for Apple not to bundle extra runtimes (scripting/JVM) software that increases the attack surface? Should they also start back bundling Flash?
> Well today you can. As you have been able to do since the info-Mac archives since before the World Wide Web existed. So unless you can bring back some proof from either your time machine or visiting some other world in the multiverse, I would rather talks about facts as they exist today.
> And code signing still won’t stop you from being able to run code that runs on top of a VM or scripting languages without them being signed and you won’t have to do the ctrl-click bypass.
It is easy to do this? No, in many cases I'd expect it to be a serious P.I.T.A, but it's unquestionably the right move going forward.
That has nothing to do with distributing the programs that run on top of VMs/runtimes. The operating system only sees the JVM/CLR as an executable. Even if that has to be signed, there is no way of enforcing the programs that run on top of them to be signed.
My statement was very clear “developers are not forced to be part of the developer program.” Meaning that unlike ios, there are ways to distribute your app without signing it. “Notarization required by default” != “there is no method to distribute unsigned apps”.
Catalina still runs apps which haven’t been notarized or even signed, including those built after 1 June 2019. But you may find them more complex to run, and they don’t of course benefit from any of new security protection unless they’re signed and hardened.
What part of Catalina still runs apps which haven’t been notarized or even signed, including those built after 1 June 2019. But you may find them more complex to run
Is difficult to understand? In Catalina just like in the current OS, there is a built in method for the end user to bypass code signing for any app. The user can choose to run unsigned third party code.
The article states that code you create doesn’t have to be signed and you don’t have to go through the “complex” process to run it.
Third party code forces you to go through the “complex” task of ctrl clucking.
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.
I literally just went through them at work in preparation for Catalina. They're hidden behind the developer account stuff you need to get your certs registered.
> 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
This answer and your other answer are basically non-answers. You haven't listed any specific reasons why using them is difficult. Unless you have a specific scenario that applies to enough people, EPRs are the best way to handle this currently in a way that gives the users control over what happens. You shouldn't need to work around these controls.
I'm not advocating running a local web-server. That's bad.
What I'm saying is that none of the big actors are using custom protocols anymore even though lots of them used to, because browser security policies have rendered them useless for regular end-user interaction.
They have all found other approaches instead. (Some bad, like here. Others better, like the solutions I chose instead).
Command-shift-N to open a new private browsing link.
Paste. Return.
Idiots. Why is all that necessary? The page should work first time, and gracefully degrade if you won't accept their cookies.
(To clarify, I am suggesting that making an FAQ page that won't display static text without cookies enabled is idiotic. I am not saying that the person I'm replying to is an idiot, or that people who won't grant cookies to random web pages are idiots. Just the opposite.)
A lot of desktop applications do this. The Spotify client used to do it to enable play/pause controls from any webpage. Dropbox also definitely used the same method for single sign on, maybe still does, I don't use it anymore.
You’ve used past tense in all your examples. Is it still true? As Apple has moved more towards a system with GateKeeper where apps must operate in a sandbox, this behavior seems less acceptable in 2019. I don’t want apps having complete access to my home directory because they absolutely do not need it to function.
I like that when I remove an app installed via App Store on Mac, I know it’s actually gone. It seems like this was part of the thing that people couldn’t stand about Windows — spyware coming along for the ride that is not removed when you delete the main app.
Look, all that makes sense if users are giving informed consent to have an app install a web server. Users should be able to run whatever they want, but they should also know what an app is installing.
At least the Bluejeans people have this page. The Zoom people did the same thing (possibly worse), but it was undocumented.
I had a WiFi router that by default was set to filter out DNS responses with RFC1918 addresses. A surprising amount of stuff was broken until I figured that out.
This browser won't play nicely with some features on this site. For the best experience, update your browser to the latest version, or switch to another browser."
What on earth is that supposed to mean? Update to what browser? (Using Firefox on Android, latest version)
Has anyone found a similar vulnerability with the BlueJeans local server? I tried sending a few test URLs and they don't seem to do anything so I'm not sure what the protocol is. If BlueJeans can't cause a webpage to launch it's app like Zoom does then I'm less concerned.
> However, this dialog is an annoyance to the user at best, and at worst may scare the user into denying a legitimate request.
It is a great security feature at best. It tells me that a website I visited is about to launch something on my computer. A website launching an app on my machine scares me more than any pop up.
Typical "My functionality is the only thing that matters" pretentious mindset.
It's a general purpose personal computer. Not some device you sold me which exists for the purpose of solely connecting to your app.
Let's treat automobiles the same way you'd like us to treat computers. I go to a Shell station to fill up with gas. They have custom nozzles, and I have to drill a hole and weld on a special fitting to get gas. Two days later I go to BP and fill up again. They have proprietary nozzles that don't work with Shell fittings. So I drill another hole and weld on another fitting. 6 months and 40 gas stations later my car barely moves because it's a tragic mess of holes and ugly shit welded all over it. Why? Well I might want to stop at a Shell station in the future.
It's a bit of an arms race between bluejeans, zoom, webex, gotmeeting, teams for who can get people into a meeting with the least friction. The people requesting meetings are probably also the ones requesting "make it easier for people to get into my meetings."
> Determine if the BlueJeans desktop application is already installed. This allows us to offer a new installation or launch the existing app based on the user's machine.
If the "Detector" is installed, but the desktop app is not the user removed the BlueJeans app at some point because they didn't want it. How is silently installing it again against the user's prior wishes a reasonable behaviour?
I don't think that's the rationale behind this. If a user is clicking a link to start a BlueJeans session, then it's not against the user's prior wishes anymore. It's the user's current wish to start a BlueJeans meeting and that wish requires the BlueJeans app to continue. Without the "detector", the link click just fails and nothing happens. With the detector, it's determined that the app isn't installed and the user is prompted to install BlueJeans. Otherwise, the app is opened and the correct meeting is started/joined. Nothing is silently done here.
That being said, this is still a crappy way to do this. Installing a server is not the solution to this. Browsers need to do a better job of dealing with this and that would get rid of the root issue but, in the interim, these developers need to figure out a better way than installing web servers on everyone's machine. Otherwise, everyone's computer ends up with 10000 of these stupid little single-purpose applications that are always running.
It looks like if you delete Blue Jeans.app and then restart (or log out), the webserver won't relaunch. It will attempt to run on load, but the actual script to start it invokes the app binary with a special argument, so deleting the app is sufficient.
The "log out" part is because the webserver will presumably continue running in memory after deleting the app until you force it to quit. It's possible that it watches for the app to be thrown away, but I don't have any way of testing that right now.
What's rather curious is it uses what appeared to be a nodejs server stored in ~/Library/Application Support/Blue Jeans/, but it passes the path to that to the app bundle (I can't inspect it further since I already deleted that whole folder). My best guess is Blue Jeans wanted the ability to update the server independently of the app, though I don't know why.
Logitech also runs a local webserver. It's listening on port 4800. I've never even used a Logitech video conference. I do have a Logitech camera though, so perhaps this is from the driver.
97 comments
[ 2.9 ms ] story [ 58.8 ms ] thread> Launch the BlueJeans desktop application into a meeting without prompting the user with confusing browser dialogs. This allows meetings to launch quickly on one click without requiring any additional user interaction. It also prevents the user from making a wrong decision on a browser dialog which might permanently lock them out of launching meetings.
launchctl remove com.bluejeansnet.BlueJeansHelper rm ~/Library/LaunchAgents/com.bluejeansnet.BlueJeansHelper.plist
Then delete the app from /Applications
> 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-...
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.
And we wonder why Microsoft sucks so bad at securing Windows.
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.
As a sister comment mentions, it's akin to warning the user whenever they run a command under su/sudo.
This totally breaks Apple's Developer Terms right?
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
This isn’t unique to these two. Dropbox does some ungodly things when installed on the Mac....
https://developer.apple.com/terms/apple-developer-agreement/...
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.
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!?">
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.
- If you're not using .NET, the CLR doesn't affect you, and although Microsoft has done well with ,NET, I wouldn't necessarily expect Apple to make Redmond's job easier.
- Java is much the same boat, and is perhaps in even worse shape as it used to be included by default in macOS releases but now isn't.
Read: security nightmare.
- From 10.16 on, scripting languages also aren't included by default. This seems less adversarial than the situation with Java, but for things like Homebrew, it's a stumbling block they will need to overcome.
https://discourse.brew.sh/t/mac-os-deprecating-system-script...
Are you predicting that Apple will disallow all scripting language runtimes and all VM based development environments? So if these same predictions have been wrong for over a decade - and still aren’t happening with 10.13, exactly when will this happen?
As far as Apple not including (outdated) versions of various scripting languages or Java - neither does Microsoft. That hasn’t been a major impediment to adoption.
I have NO TROUBLE imagining that Apple will continue to tighten the screws on this, enforcing signing through Developer TOS and requiring MAS apps to pay for distribution certs.
Direct download isn't going away, not after all the work that's gone into securing it, but if you think you can sell an app off your own site without giving Apple some identifiable info about who you are and what your code does, prepare to be disappointed.
Runtimes won't be disallowed, just that you (the user) are responsible for installing them and keeping things updated.
Oh, and for record, my reference to "Perry the Cynic" is no accident...he literally invented how code signing works.
https://weblog.rogueamoeba.com/2008/03/07/code-signing-and-y...
https://red-sweater.com/blog/514/development-phase-code-sign...
http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=H...
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=H...
And citing the patent office isn’t helping either. Every company patents everything they can.
Direct download isn't going away, not after all the work that's gone into securing it, but if you think you can sell an app off your own site without giving Apple some identifiable info about who you are and what your code does, prepare to be disappointed.
Well today you can. As you have been able to do since the info-Mac archives since before the World Wide Web existed. So unless you can bring back some proof from either your time machine or visiting some other world in the multiverse, I would rather talks about facts as they exist today.
And code signing still won’t stop you from being able to run code that runs on top of a VM or scripting languages without them being signed and you won’t have to do the ctrl-click bypass.
Why is it wrong for Apple not to bundle extra runtimes (scripting/JVM) software that increases the attack surface? Should they also start back bundling Flash?
Watch WWDC 2019 Session 701, you'll learn something.
https://developer.apple.com/videos/play/wwdc2019/701/
> And code signing still won’t stop you from being able to run code that runs on top of a VM or scripting languages without them being signed and you won’t have to do the ctrl-click bypass.
It is easy to do this? No, in many cases I'd expect it to be a serious P.I.T.A, but it's unquestionably the right move going forward.
https://mjtsai.com/blog/2019/06/17/notarizing-command-line-t...
Apple has announced that is changing very soon[0] and you attacking everyone who already knows this as 'conspiracy theorists' is kind of insulting.
0: https://developer.apple.com/documentation/security/notarizin... - "Beginning in macOS 10.15, notarization is required by default for all software".
You can only have software notarized as a member of the developer program.
https://www.google.com/amp/s/eclecticlight.co/2019/06/07/not...
Catalina still runs apps which haven’t been notarized or even signed, including those built after 1 June 2019. But you may find them more complex to run, and they don’t of course benefit from any of new security protection unless they’re signed and hardened.
Apps distributed over the Internet, like, you know, the ones we're talking about, must be notarized according to your own source.
Is difficult to understand? In Catalina just like in the current OS, there is a built in method for the end user to bypass code signing for any app. The user can choose to run unsigned third party code.
The article states that code you create doesn’t have to be signed and you don’t have to go through the “complex” process to run it.
Third party code forces you to go through the “complex” task of ctrl clucking.
A sibling reply posted the link.
https://developer.apple.com/terms/apple-developer-agreement/...
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.
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!
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.
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.
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.
99% of software world these days fits this description, sadly.
Signed, Unamused CISO
Have you tried using them?
Then you would know they don’t do that for a good reason. I answered a similar question in the zoom thread:
https://news.ycombinator.com/item?id=20389310
There’s a reason literally no big companies are using this tech anymore, when they used to do so 10 years ago.
Go on. I’ll be here to say “I told you so”.
I'm not sure if I know of any big companies that surreptitiously run a local web-server to save users a click whom haven't received flak for it.
I'm not advocating running a local web-server. That's bad.
What I'm saying is that none of the big actors are using custom protocols anymore even though lots of them used to, because browser security policies have rendered them useless for regular end-user interaction.
They have all found other approaches instead. (Some bad, like here. Others better, like the solutions I chose instead).
Technical Stuff
To view this site, enable cookies in your browser.
Command-shift-N to open a new private browsing link.
Paste. Return.
Idiots. Why is all that necessary? The page should work first time, and gracefully degrade if you won't accept their cookies.
(To clarify, I am suggesting that making an FAQ page that won't display static text without cookies enabled is idiotic. I am not saying that the person I'm replying to is an idiot, or that people who won't grant cookies to random web pages are idiots. Just the opposite.)
> This allows us to offer a new installation or launch the existing app based on the user's machine.
These all sound like problems that can be solved by fixing the interface itself and by polling for a desktop client connection.
A lot of desktop applications do this. The Spotify client used to do it to enable play/pause controls from any webpage. Dropbox also definitely used the same method for single sign on, maybe still does, I don't use it anymore.
I like that when I remove an app installed via App Store on Mac, I know it’s actually gone. It seems like this was part of the thing that people couldn’t stand about Windows — spyware coming along for the ride that is not removed when you delete the main app.
Macs are general purpose computers and it would be absolutely inappropriate for Apple to try to prevent users from running software on them.
At least the Bluejeans people have this page. The Zoom people did the same thing (possibly worse), but it was undocumented.
I guess I'm losing touch with the user-hostile "innovations" coming out of the valley.
>"Your browser isn't supported
This browser won't play nicely with some features on this site. For the best experience, update your browser to the latest version, or switch to another browser."
What on earth is that supposed to mean? Update to what browser? (Using Firefox on Android, latest version)
To test if the BlueJeans server is running:
It is a great security feature at best. It tells me that a website I visited is about to launch something on my computer. A website launching an app on my machine scares me more than any pop up.
It's a general purpose personal computer. Not some device you sold me which exists for the purpose of solely connecting to your app.
Let's treat automobiles the same way you'd like us to treat computers. I go to a Shell station to fill up with gas. They have custom nozzles, and I have to drill a hole and weld on a special fitting to get gas. Two days later I go to BP and fill up again. They have proprietary nozzles that don't work with Shell fittings. So I drill another hole and weld on another fitting. 6 months and 40 gas stations later my car barely moves because it's a tragic mess of holes and ugly shit welded all over it. Why? Well I might want to stop at a Shell station in the future.
F* that and any company who operates this way.
> Determine if the BlueJeans desktop application is already installed. This allows us to offer a new installation or launch the existing app based on the user's machine.
If the "Detector" is installed, but the desktop app is not the user removed the BlueJeans app at some point because they didn't want it. How is silently installing it again against the user's prior wishes a reasonable behaviour?
That being said, this is still a crappy way to do this. Installing a server is not the solution to this. Browsers need to do a better job of dealing with this and that would get rid of the root issue but, in the interim, these developers need to figure out a better way than installing web servers on everyone's machine. Otherwise, everyone's computer ends up with 10000 of these stupid little single-purpose applications that are always running.
The "log out" part is because the webserver will presumably continue running in memory after deleting the app until you force it to quit. It's possible that it watches for the app to be thrown away, but I don't have any way of testing that right now.
/Library/Application Support/Logitech/com.logitech.vc.LogiVCCoreService/LogiVCCoreService.app/Contents/MacOS/LogiVCCoreService