@Jasonjoel Good point, it would easily circumvented.
Best to keep it at :
Only install Apps and Drivers where the user has examined the code and has a confidence in the code or can isolate HE on a vlan.
That keeps it much simpler.
1 Like
And don't get me wrong - I think it is a good discussion.
End users do need to keep in mind that user app/drivers are installed at their own risk - they aren't vetted by anyone other than the community at large.
The Groovy sandboxing in Hubitat does help a lot in preventing malicious code from destroying the hub itself or allow for code privilege escalation, but obviously it does little to prevent data exfiltration or remote control potential. But even remote control issues are limited to what can be done in the sandbox, too.
4 Likes
I had hoped we could raise the bar, slightly, making it a bit harder for the script kiddies 
1 Like
I get the principle, but realistically for somebody to publish something on this forum, and have nobody skim read it, and you to install it, and the exploit to happen is fairly remote to begin with. If you have a tool like HPM installed then the risk increases as things can update without you thinking, but still fairly tenuous, and easy for anybody to report and have it removed.
Also everybody having to check the same app/driver is annoying when it should only happen once, hence perhaps the check should actually be on this forum when a new thread is created, or HPM on an update. That way you can be safe in the knowledge that you don't need to think with the forum.
But again if you're worried about that, more than somebody putting a brick through your window, or a crowbar against your door then probably some level of reality check is needed. Unless you're a secret celebrity being targeted.... Imho.... Standard ISP routers or similar probably open up bigger holes than Hubitat....
1 Like
Just my opinion here... But I fall into the "if you do not trust the developer/community driver/app, do not install it". I have a bunch of drivers I have developed/publish on my website for anyone here to use. The code is completely open (obviously) for anyone to see. However, if you are worried about them contacting X site, my drivers would cause some sort of flag every time.
Why? Because every single one checks my website to see if there is a newer version of itself every day. It cannot auto-update, but it will post an event (if the user checks) to see that there is a newer version available. Also, the vast majority of my drivers (not all) are API-querying drivers. So they either check another company's (and thus site) API for data (like my variety of weather api drivers, Blink API, etc...) OR some device on your local network for it's data (like my Neptune Systems Apex, Neurio, or Tesla Powerwall, etc...).
But... you can check through the code, before you even set a device to use it, and see all those things. Searching for HTTP calls or other network-access type of things.
So even if there is an app or system to check the drivers you are still going to have to trust the developer and either OK those things or not.
3 Likes
I think the question everyone who contemplates using any home automation system, or networking system (WiFi, cellular, Zigbee Z-wave, etc.) for that matter, must ask themself is: âHow risk averse am I? The answer to this question will set the tone for how you evaluate and interpret everything else.
We have all heard about the white hats who proclaim they can hack into a network, choose your flavor, in minutes. The ones I have seen for Zigbee and Z-wave depend on being within feet of your house.
The reality is if you adhere to reasonable typically recommended practices for setting up your networks and network perimeters, you have thwarted the vast majority of the risks. Bad actors typically go for the greatest reward fir the least effort. I donât know about your situation, but I ainât that big a catch to go after.
I do think this is a good discussion. I agree with @marktheknife and @aaiyar. It is up to us, the community, to do any âpolicingâ. So those of us who do have an understanding of coding should take time to review any code we are personally planning to use, and bring any questions about the intent of functionality to the community fir review and discussion.
The moral of this diatribe: there is safety in numbers, if we all watch out for each other and the community as a whole.
Thank you for starting this discussion @habitat. This is a great discussion item that we need to revisit regularly.
Ok. Iâm off my soapbox.
4 Likes
The concern is less that someone accessed my HA, it was that they could use it as an entry point 
I can harden it, an interesting project that I wanted to do anyway as part my overall goal of making HA more fault tolerant and robust.
The reason I moved to HE was because I can run two HEs each watching the other and apply a cloud oversight through Sharptools and maintain the ability to remote reboot HEs through Hue hubs and HomeKit.
I am loving it, I am loving HE!
The question was raised by a friend who I have introduced to HE.
I thought it worthy to post on the community.
I would like, but do not set any expectations, that the developers of HE build in some basic security capabilities that the community developers can use.
This will raise the bar for everyone.
2 Likes
I fully understand the entry-point concern. I work in a large enterprise IT organization, so I get it. This is one reason why we have multiple layers of security zones. This might be a good discussion to have about how to apply something similar, albeit on a much smaller scale, to our own environments.
I agree, HE is a great system, and we should never quit thinking about and reviewing our security posture.
I think we, as the community, will have to lift that bar by our own actions, and hold anyone publishing code that has even a hint of being nefarious accountable. The awareness and subsequent discussions will be good for us all.
5 Likes
Not sure if it is possible to hold someone accountable. But it is definitely possible to make the community aware of something potentially dodgy.
2 Likes
First of all, I don't know you or your situation but...
Unless you have bunker doors that can't be broken into with a crowbar, glass windows that are 2 inches thick and all of the walls made of concrete. Having someone use malicious code to remotely unlock your doors or open your garage doors so that they can go inside and steal whatever you have to protect is very unlikely.
Also if you do have that kind of house, I'm pretty sure you will not be using HE to control the locks or the garage door of your home.
I'm not sure what else could be hacked that could be a concern, if somebody manages to hack my HE and starts flashing my lights, I would probably find it funny more than anything else.
I have talked with an ex-robber a few times (friend of a friend kind of deal) and like some pointed out, they always look for the biggest payoff with the least effort, this is the real world and what you see in movies is fictional and rarely about somebody planning 4-5 weeks in advance to steal a few hundred dollars worth electronics in someone's house. It's more like, I heard that this guy has this or that and they just do it after making sure no one is home, if any doubt, they just walk away and many times just don't try again.
1 Like
No argument with any of that. But I'll point out that digital security vs physical security is an AND, not an OR.
Nothing wrong with a device being made more reliable - within reason. How many viruses and other malware are done by people "just because" with no monetary gain involved (spoiler - MANY)? The digital equivalent of graffiti.
I think this actually has a lot to do with why Hubitat has adopted a fairly hands off attitude when it comes to community-based code.
It would be one thing if a company made no effort to protect all their users from malicious code in the routine course of using a product or service. Like Microsoft Windows.
But thatâs a very different situation than a group of power users that meet online and use an optional feature of an IoT hub.
We all have a different risk tolerance, and @wayne.pirtle stated, so for those that have the interest and skill to segment their LAN, they should absolutely go ahead and do that if they also perceive the need to minimize the risk of being subjected to a bad actorâs code.
Yes of course, but HE is not your PC and it's not used to access your bank account, sure HE might be able to communicate to the outside world the details of your internal IPs and what not (if that can be done from within the Groovy sandbox) and then that info could be used in a malicious way. But I'm sure there are a lot easier ways to get that info with shareware on the PC (windows, Linux, etc.).
Again, no argument.
But whatever data is in hubitat - life360 login, control of my lights etc - is still MY info and important to ME.
You seem to be saying that since it isn't the MOST important data, it isn't important at all. And I disagree with that.
1 Like
I look at it somewhat differently. I am more concerned about the security and privacy issues around built-in apps, than I am about apps written and provided by community members. This is not to say, I am worried about the HE built in apps. I believe the built in HE apps have a very small security risk, but I also believe this very small security risk is greater than the risk posed by community apps.
I should add that this argument would only apply to community apps that are prevalent and widely used. On my hub I use several community developed apps/drivers and all of them are somewhat popular and used by a significant amount of people. If there was a security risk with any of them, I trust that it would be exposed by the community in fairly short order. I don't have to rely on my own "level of programming knowledge", but rather I need to rely on the communities' "level of programming knowledge". Is this foolproof? No, it is not. But I am comfortable with that level of review and security.
Compare this to the security risk of HE's built in apps. This code is not open. Nobody outside of Hubitat employees can review this code. Lately, (last 10-15 years) there has been a report, or two, about technology companies collecting user data without explicit permission. I am guessing it might have happened once or twice in the last couple decades. Not accusing Hubitat of doing anything like this, but I do consider it more likely than malicious code in a community app/driver. Why?, simply because HE has the ability to do it secretly, while a community app/driver code is open for all to see.
1 Like
Not at all and I too am 100% with you on that point, just saying it's unlikely and what would that serve them IF they could get to that info.
Maybe HE should limit what an app / driver can access from other apps / drivers so that sensitive info like logins are not available in any way, but then again can an app access this kind of info?
Then for the apps that do ask you to enter that kind of info, if you are not comfortable in doing so, just remove the app if you can't be sure it will used for other motives, no one is forcing anyone to use a weather app that needs login info to a third party site.
1 Like
What? You haven't used the driver that monitors your bank accounts, flashes warning lights when your checking account gets low and automatically sends a transfer notice to shift money from your savings to your checking?! I thought everybody used that one... That nice-sounding guy from Nigeria said it was all on the up and up...
8 Likes
Any developer with a bow tie in their profile picture cannot be trusted.
16 Likes
I understand the OP's position to a certain extent
All my maintained apps & drivers 'phone home' once a week to check for updates and alert the user if there are any. (I don't use any form of auto updating - just reporting)
A lot of developers here use variations of the same code that I released a couple of years ago showing people how it's done
I also have one of my drivers that has the ability to send emails directly from your hub
I could easily collect any data that the hub has and email it to anyone I wish (I don't!) so I can see the OP's point of view.
However, when asked by a user how to disable the update feature on a particular app, as he was uncomfortable with the idea, I happily showed him which code to delete to prevent this from happening.
I would hope that my reputation in this community would give most people 'peace of mind' that I don't want to do anything malicious with their hubs, but again I understand the OP's reasoning here.
Anyone is free to examine my code, and I know many have, so I'm sure that if there was anything malicious in there it would have been flagged by now and nobody would use my apps/drivers
If in doubt don't install
Andy
15 Likes
