Why Hubitat Elevation? This is why


#1

Out of frustration the other day, I almost made the mistake of investing in a ST hub. I was having a bad day with rules 3.0/HSM apps and decided to take a look at alternative solutions. This is what my research revealed:

No thank you, I’m staying put. Instead, I’ll be investing my time in helping make this platform even better by working through the bugs one at a time. The developers at Hubitat have been very responsive. @bravenel has been very helpful getting 2 of my bugs resolved in record time. Top notch development team.

Cheers,

Ron


#2

They also just shutdown ArloPilot for anyone using it, claiming that it was affecting the platform. That's complete BS.. Too coincidental that they had an Arlo outage recently, and I bet Arlo discovered that there was another integration out there and demanded they shut it down without any advance warning, and without even contacting the developer. Thats a solid indicator that in was done in response to a complaint from Arlo.

Another reason why HA in the cloud is a sucky concept. You are absolutely beholden to the whim of your corporate masters.


#3

Expect Samsung to kill all groovy apps they host through the classic IDE because they are. Even beloved WebCore is doomed. The new integration IDE has you having to host the automation yourself because they don't want to pay for it.


#4

Yeah... Samsung SEEMS to be really screwing things up here... I say seems, because maybe they will pivot based on reaction and do something more reasonable. Not holding my breath, but still...

But based on what is public right now, it certainly looks like Samsung is killing off SmartThings as we know it (at least all of the open, good parts).


#5

My main concern here with ST is that the exposed GitLab instance also contained private certificates for Samsung’s SmartThings’ iOS and Android apps. I certainly hope they've replaced these compromised certs. I wonder what other secrets were revealed. People need to take secure DevOps more seriously.


#6

The certs per article were revoked.


#7

This... And the recent Nest announcement, Iris closing up shop, etc.. All of these recent moves (and others) are going to eventually lead to consumer frustration and distrust. These major companies go through great lengths to position their brands as being perceived to be trusted and reliable, yet at every turn, deliberately take actions to the contrary.

While I tend to think most consumers are too naive or complacent to understand this, it doesn't take a genius to know that he's been screwed if his expensive thermostat stops working with his Echo, all because the corporate master behind the thermostat wanted to.

SmartThings as we know it has already been killed off, Samsung just isn't saying that officially, but all of their actions support that. I fully expect that over the next 6-18 months the groovy platform will be shut down. I also expect that Samsung will close access to the new API eventually and start charging developers to access it. I would also not be surprised to see the SmartThings community shut down once these change happen either.

I'm very glad I got out when I did!


#8

I realize that’s what they said, but were the private keys to the issuing CA’s compromised? Wouldn’t surprise me. Moreover, this speaks volumes to their security practices.


#9

They are code signing certs. Unless you have a time machine and can time stamp them before they code signing cert was revoked they are now worthless.

They are not used for HTTPS and other TLS connections and if were they would be checked if valid at connection. We also no longer use static keys and use changing encryption passwords during the connection with forward secret so having the private key doesn't mean they just got all your past and future encryption. (It could though in certain cases result in weaken security and file at rest issues)

TL;DR; Revoking the cert makes it safe.


#10

This is assuming that the clients are not configured with a soft-fail revocation policy. In this configuration, should CRL or OCSP points become unavailable for revocation status (This is fairly common), all signed malicious files can remain valid even after the certificate is already revoked.

"TL;DR"? Yeah PKI and X.509 are not for the faint-hearted. Definitely not a short read.