Hubitat App Ecosystem and Security

I noticed, it can be quite easy to acquire custom apps and drivers for Hubitat. Especially if vehicles like Package Manager are used. In other words, I get the unsettling feeling the apps ecosystem is the wild west and perhaps arguably worse than any Android App store. What is stopping bad actors from publishing nefarious code? Are there checks in place to vet apps prior to users installing them? I get Hubitat was born from the "open and configurable" mindset and that we are responsible for our actions. The problem is Hubitat has evolved beyond the "geek base." Hubitat is fully marketed to any and all consumers. It has to be or Hubitat will cease to exist. So that being said, what is being done along the lines of app and driver security? What is stopping Tonesto (Echo Speaks) from having a bad day and inserting a foul line of code?

In all honesty, I agree with part of what you are saying - but not sure I agree with the premise "...evolved beyond the 'geek base' ". I still think of my unit as DIY, and all over these boards are comments like 'keep your alarm systems separate' and such. Regardless, (and not wanting the wrath of Bravenel) HPM - the package Manager is a USER app. While it does centralize and open a door to ease of install of potentially nefarious code, (or maybe just a poorly written driver!) I don't feel that falls on HE, it falls on the user. Just as you can install crap on a PC or a phone, so it is true as well here. A locked down environment would kill development... and who wants the world of Apple all over again? not me!

2 Likes

Architecturally the platform has some built in limitations that make it difficult to do too much nefarious stuff, but outside of the built-in drivers and apps it is up to the user to decide whether to trust the developer and install the software.

4 Likes

Where I will disagree with you, is right now it's REALLY hard for someone to install custom apps in Hubitat. To get something like HPM you have to go find the code and manually install it into HE.
HPM also isn't sanctioned or built by HE. It's more akeen to you going to above and beyond efforts to get an app story (not Google) installed on your Android device.

Disagree as well, at-least here you have the opportunity to not only see the code, but modify it if you wish, or even pay someone to vet it on your behalf.

That assumes there is a centralized authority doing app vetting. Again, something like HPM is community driven, as are the apps you would find on this forum. The closest thing to "vetting" would be any action the HPM volunteers take to vet a repository before checking it into HPM.

I think you bring up valid points, but seem to ignore that this is community driven - much more like NPM or community based app stores - v.s. centralized control of a 3rd party Eco-system.

HE as a company could do the latter (build a controlled and centralized eco-system/platform), but regardless the former can always exist as they do on other platforms as well.

Heck, even SmartThings with Samsung.

1 Like

I totally get it. Everybody's input makes good sense. Heck even Apple is not fully immune to bad actors. This whole thread was spawned by an Ars Technica article about a developer who basically has gone rogue and sabotaged his code libraries that are used by countless developers and enterprises. Indeed we are a community. And it is our hopes that we all follow a quiet code of conduct around trying to be a good person. But it's never perfect. And the definition of community is broadening in the eyes of Hubitat. Hubitat needs warm bodies to buy hubs to survive. The changes you see in the UI, the paid services, the YouTube How-to Videos Etc.. all reflect an effort to diversify and cater to more than DIY. For us in this thread I'm not terribly worried. I'm worried for the folks who scoop up these hubs and go to town blind and of little time to peruse our forums. I worry because an idiot will eventually pay us all a visit through code, through all our integrations, or through any other means. It will be up to us folk to clean up the mess. Thanks for the input all. Of all the communities I belong, this one is hands down still my favorite and I respect all of you and your efforts.

There are no checks; that's up to you to trust the author, and it's a risk of using custom code (on any platform). However, due to the nature of the platform, almost all Hubitat apps and drivers are open-source (not necessarily freely licensed, though most also are). Because of this, you are free to vet them yourself if you have the skill, or you can trust that someone in the community may have done the same. (Recently, they actually did add a "pro bundle" way to install custom code without being able to see the source, but that was created for one specific partner and I'm not sure any community developers use it--and honestly, I wouldn't as a user, with maybe rare exception.)

There are also some limitations at the platform level. For example, apps can only reference devices that have been selected by the user (and will show up as "In use by" on the device page), so it's unlikely an app you install that you think is for lights will end up unlocking all your doors. Also, devices (driver code) cannot "talk" to other devices on the hub directly, ignoring things like Z-Wave Association; that is traditionally the role of an app. Built-in apps can do a few thing user apps can't, like look what devices you have even if they aren't selected (why Rule Machine will hide some trigger types and say you don't have any such devices, or why HSM can do things like "use all smoke/CO detectors" without you needing to choose them all), but the risk is less for user apps since they can't. You can also get some insight into what an app is doing, e.g., by looking at its "Scheduled Jobs" (or the new feature that shows all such things on the "Logs" page tab).

But I do think some caution is warranted, and looking towards the built-in apps first before trying to find a community solution is not a bad idea. My rationale there is usually based on support and performance (not all code is well written), but this isn't a bad thing to think about, either. I do think the community would be quick to point out anything suspect, however.

2 Likes

My biggest concern for custom apps is that they can open network connections on the inside of my network, and try to talk to arbitrary other devices (e.g., attempt to send exploit payloads). I think the best approach to limit that is to use a VLAN to limit the scope of what is on the home automation side of your network. But this is why I usually peek at source code of drivers and apps when I install them.

Update: I wish there were a permission model in Hubitat that limited code from calling network APIs unless I specifically granted that code the permission. Sort of like the way OAUTH needs to be selected.

4 Likes

Very fair, and yeah that really sucked.

The good news from my perspective is;

  1. You actually load the code onto your HE, so independent on what happens to the actual source hosting at the end of the day doesn't affect your HE unless you choose to update the code.

  2. Even if you update the code (e.g. via HPM), and there was a bad actor who decided to remove the logic and replace it with flags, you can still go back to your automated HE backups to recover. (kind of like what a central authority like Github did in this case with controversy)

That's one of the beauties in my mind about the HE model, true local gives you more power over these kind of bad actors. Not perfect, but a huge leg up to other services.

1 Like