Ubiquiti cranky customer

Very happy with my Ubiquiti network hardware. Unimpressed with the software experience. Just sent this cranky email to their support, where I’m sure I will get a canned “thanks for the note” reply and nothing will improve.

Your products have three problems that harm the perception of security. Y’all make excellent network hardware, but your software should be as excellent. I’ve already worked around these problems, just registering a complaint.

The Unifi Controller Mac application is not signed. MacOS refuses to launch it until I disable Gatekeeper security.

The Unifi Controller does not come with a valid SSL certificate. I realize this is complicated, but it’s a bad experience to require users to disable Chrome SSL checks to use the product.

Your reset password links from ZenDesk are being flagged as spam by Gmail. They say “Why is this message in Spam? It has a from address in ubnt.com but has failed ubnt.com’s required tests for authentication. Learn more”.

Thanks for listening,
Nelson

3 thoughts on “Ubiquiti cranky customer

  1. I ran across this post which might give you a bit of an idea of why some of this is the way it is – https://help.ubnt.com/hc/en-us/articles/204976094-UniFi-What-protocol-does-the-controller-use-to-communicate-with-the-UAP-

    The whole ‘running the controller on your personal computer to set up your one AP’ thing is a sort of hack. Their overall goal seems to be (seemingly polling-based) device fleet management by a controller that can be anywhere – they even have a video that shows you how to set it up on AWS. From the way they talk on their forums, it sounds like the low-level networking nerds run the show there (with the strings possibly being pulled a shadow council of powerful, radiowave consuming warlocks).

    Careful what you wish for, though, they might end up ‘fixing’ this by making the controller advertise a name over mDNS and blasting a self-signed cert into cert store, sight unseen. Which, in the long run, could make you crankier.

  2. Oh that’s a good explanation of how the devices are communicating, thanks. I get that they want a central controller and think it’s neat. But boy they better get it right, particularly with respect to security. Being thrown all these errors because they couldn’t get their shit together is discouraging.

    There’s no excuse for the Mac client signing for a commercial product. The SSL problem is pernicious to solve but has been solved several times before. Let’s Encrypt most recently, also this:
    https://blog.pivotal.io/labs/labs/sslip-io-a-valid-ssl-certificate-for-every-ip-address

    Personally I’d settle for them also working without SSL if connected via localhost.

  3. It definitely has an air of half-assery (i.e. they should have signed the binary, etc) but I’m not sure the SSL problem is that simple, especially for the potential returns. The thing you’re describing still needs DNS and there’s no way the controller can trivially do that. And if you’re going to know how to deal with DNS, you’ll know what to do with certs too. Defaulting to non-SSL under any conditions would probably generate a lot more email, far less polite than yours. You could even make an argument that it’s _Chrome_ that’s being too much of an unreasonable jerk about authenticating connections to localhost.

    At the end of the day, you’re likely right that this won’t change much and we’ll have to be satisfied with there being a coven of warlocks somewhere, designing wireless networking gear that doesn’t suck.

Comments are closed.