Device "Security" in Apps

This is something I still don't get the point of, the need to select devices in Apps for the sake of "security". There are plenty of cases where this just creates confusion and makes things less user-friendly.
As far as "security" goes, first, if you don't trust 3rd party code, then don't install it. Second, if a developer wants to embed code in a 2-3000 line app or driver that most wouldn't bother to read through before using, it would be possible to expose anything connected to, at least, the same subnet as HE. It would also be possible to auto-add devices to any selection list, reset your hub or anything else that the developer wants to. No amount of device selection in lists prevents that, there's just too many ways around it.

Just to be clear, I'm talking about the device selection elements in Apps here, but it also applies to any other "access separation" of apps and devices or between different devices or between different apps. In my opinion, any app should be able to find and call any method in any device, and vice versa. It can already be done, just in a convoluted way.

Then someone brings up: but there's the performance penalty... The performance penalty comes from subscribing to device events, of course it's a bad idea to subscribe to all the events of all devices unless that is what is truly needed for the app to function. This is something the app should regulate and needs to be well thought-through by the developer. In terms of selecting which devices to operate on as a configuration option, then of course these device selections make sense, but for "security" or performance reasons? How does that make sense?

If someone can explain to me the reasoning behind why this is done for "security"? I'd love to know!

Same question is also valid for all other device/child device/app/child app separations. Where does that make things more "secure"? It sure does make certain features more convoluted to implement and possibly either less user friendly or very much non-standard, but "secure"? Can't see it... Too many ways around it. Even if there were no ways around it, what are you protecting against whom?

I'm sure this can be elaborated more on, but as a start, what are the thoughts on this?

EDIT: Tried to make it easier to understand, might still miss the mark...

You've completely lost me... :thinking:

What are you specifically referring to? I am not familiar with the need to select devices for the sake of "security".

I have never seen 'security' specifically called out for the design of how Apps present lists of Devices for a user to choose from. (If that is in fact what you're describing above.)

Please elaborate and share some background information. I am genuinely trying to understand where you're coming from on this... :thinking:


Sorry about that, but I think you got me:

That is what I'm referring to, this and any another mechanism dissallowing access to any device not selected by a user or granted access to by being a child device or child app of the parent device or parent app in question.

There is this:

Other posts in the forum I remember seeing, but not finding right now. I'll add them when I find them.

I'm guessing you want the ability in an app to have an option to auto include all devices and HE support quoted security as the reason to not do this.

This would allow you to not have to always go into an app like the Alexa skill and have to keep adding devices.

I can see this being an issue with something like Maker API where there is a cloud component so you really want to be careful as to what you want to include in that app.

But I can also see the argument behind, "give us the feature and let us manage the security".

Hopefully I go this right.

1 Like

Exactly, or for some lan device drivers, like one I maintain, which may be installed manually without the app, but the user could choose to install the app later on for access to additional features.

Yes, but security should still be managed by the app, not "enforced"...

Exactly this :slight_smile:

Spot on, sorry for being a bit hard to understand...

I got it. And I was there probably a year ago with the same argument "Just let me include all devices!". But I moved on. lol.

But I feel your pain.

1 Like

Yeah, I guess that is what there is to do. Or "fix" it with JS... Or other ways...

:slight_smile: I think at this point I just want to know what the reasoning behind this is, and what the user perspective is. I don't see the benefits anywhere. Please prove me wrong :wink:

Not feeling to take on that challenge just yet. Only 1/3rd of the way through my practice coffee.

1 Like

:point_up_2: :heart: (I'm out of likes, this is my workaround)

I appreciate the additional information and context to this thread's purpose. As a user and developer of both SmartThings since 2014 and Hubitat since it was launched in early 2018, I can honestly say that I have never really found myself missing the ability to include all devices within an App. I am not saying there aren't valid reasons for wanting to do this....rather, just that I have never personally felt the need. Perhaps that is because I have focused much more on developing Device Handlers/Drivers for both platforms, rather than SmartApps/Apps.

I am still struggling a little to understand how this is 'limiting' to an App/Driver developer? @markus, you mention something regarding users manually creating devices using a driver, but then also possibly installing an App afterwards. Can you please explain a little more what you'd like to be able to do in this situation that is limited today? I am speculating that you're possibly referring to a Parent App/Child Device scenario. In that scenario, the child devices are typically created by the parent device. Usually, the Parent App then handles all communications with whatever physical device (or cloud service) on behalf of its children. Likewise, a Composite Device can be used to create a Parent Device which then creates its own child devices. This is what I use extensively in many of my device drivers. Again, the one Parent Device performs all communications to the physical device in this case.

The choice to use a Parent App versus a Parent Device is usually based on specific use-case needs. Both designs have similar functionality, but there are definite differences. For example, a Parent App can be an OAuth endpoint, whereas a Parent Device cannot.

Again, I am just trying to understand the need for this functionality. I am not trying to discount your opinion in any way.

1 Like

If you want to select all devices connected to the system you just have to use capability.* When you do, at the top of the list you get this:


That allows you to toggle all devices selected. You will have to go back in and re-toggle when you add devices but if you REALLY need it, the option is there. I wouldn't recommend using it since there really is no need for all devices to be included in an app, but the option is there.


With that much time spent on the platforms as a developer, this is an important point. If it didn't work the way it is now, would you feel that would be wrong or inconvenient?

This is the same focus I have.

My new drivers, currently in a closed beta, are parent child drivers, very much like yours, with child devices created automatically based on the device configuration and model.
With this new driver there is a new app which has device discovery functionality as well as some management and monitoring features.
The current drivers I have previously released can be replaced with the new Parent driver, regardless of device type. In this case the device would not be installed by the app.
It is also possible to install a device by adding it as a virtual device and have it configure itself that route by selecting the parent driver. Also not installed by the App.
If the user then realize they do want to use the app because of cool features X, they install it and for the app to have access to the device have to select it, instead of the app just going through all available devices looking for those running my driver. It does this check now from the list of devices selected, so selecting the wrong device doesn't matter, it will be filtered out. Still, it is an extra step.

In my use case above, the app is optional, but is related and only useful with devices running my drivers.
The parent device handles communication. There are special use cases where it would have made sense to "group" devices and send commands more efficiently, This currently needs to be done through the parent app as it is now, devices can't reference devices not child or parent devices of themselves.

I am aware of the different use scenarios of parent apps, parent devices etc :slight_smile:

No worries, I know your background and appreciate the input, I'm really trying to understand the underlying reasoning behind this design choice.

Yes, though that is a lot of devices and could be off putting and still requires a toggle. As it is now, I filter on the Initialize capability since all parent devices have that.

Having all devices included has no I'll effect as long as events are not subscribed to and the app doesn't send events to all devices, but I do get your point.

I don't understand. If you toggle "Toggle All Devices" then all devices are selected. Isn't that what you were asking for?

I'm not really asking for anything. I'm asking for the why and why it is not seen as an issue, or if it is seen as an issue then why in that case? I'm asking for opinions/knowledge in order to understand this design choice.
I am however questioning the "security" purported to be had by the current design.
If I would ask for anything it would be full device access to all devices in apps without any user selection needed. I don't expect to get that. Ever.

All apps do have access to all devices. But apps can only use devices selected by an input.

I think we're just talking about the same thing here. For me access means I can use them. If I can't use them, I don't consider it as having access., you're wondering why that security feature is in place? So that smart apps cannot control devices that the user doesn't give it access to. If you don't want to give a app access to a device, you don't have to. That way you can't get an app accidentally controlling a device it is not supposed to. How else would have an app decide which device to control if they weren't selected? If the user didn't define in the input which devices was to perform what function, how would the app know?

Maybe it's because your model is backwards. If an app needs to be linked to a device, the app typically creates that device. Take for example, the Hue App. The app creates the child devices of the hub and all the lights. If you were to manually create the Hue Bridge device and then try to link it back to the app, you would have to select that bridge device. The app just can't assume which one it should use based on driver type of capability. What if you had two bridge devices? That's why the user has to explicitly select the device.

But if the app creates that device that it automatically has access to it, meaning the user is not required to do anything. So, if you're looking to have an app that automatically has access to devices it needs, then the app should create said devices, not the other way around.

I'm wondering why it is this way yes, it is clearly not for security since there are numerous ways around it.

This does make sense for a lot of apps, maybe even most.

By checking which driver the device is using and knowing it is not meant to be run as multiple app instances, only one. That way, any device with that driver is of interest to the app.

Not backwards, flexible. See the different use cases/ways of doing things in my post above.

Depends on the use case. See above.

This do give me some insight into how and why this is done this way. Thank you. I don't necessarily agree with the why and the how, but it is what it is and what we will have.

1 Like

But that's not how the system is designed. Apps aren't allowed to assume what device is should control. And it shouldn't. That is not an accident, it's on purpose.

And it's done for a reason. You are assuming that an app will know what devices it should control based on the driver. And that just isn't the case. What if you have multiple instances of that device? How would the app know which one to control?

Download the Hubitat app