General question about community provided edge drivers

Apologies if this is a stupid question. Is the direction of the Smartthings Eco system towards community developed drivers being delivered via channels and therefore the source code is not available to the user?

Is their any plans for Smartthings to ‘certify’ these as being safe?

1 Like

Hi, @Davec

Your question and concern are completely valid. So, answering to your questions:

The Driver Sharing (sharing drivers through channels) mechanism was designed to avoid copy-pasting installation flows, which at some point led users to frustration going through a long installation process for an unmaintained DTHs.

However, this doesn’t completely override the code distribution, as community developers can opt to share their repositories. But again, this is up to them.


Of course, we’re planning to provide Certification Guidelines for those developers / companies that are willing to distribute their devices as SmartThings Compatible Products, however, on this Beta stage, we’re focusing on the improvement and reliability of the architecture.

1 Like

Thanks. All seems sensible. From a personal perspective I like being able to inspect any code I plan to install on my LAN. -:slight_smile:

2 Likes

I wouldn’t be that concerned about channels published by a manufacturer or a well known developer, but if you don’t want code installed without inspecting it first then you’ll need to setup the CLI and run a command to package/publish/install their code on your hub instead of installing it from their channel.

If you install it from their channel then reviewing the driver code posted to a repository is pointless because it might not be the same code published to their channel and they can push new versions of the driver to your hub at any time.

1 Like

Any chance you can add some sort of notification feature for when a new version of a driver is installed on the hub?

If a developer (or ST) publishes a new version of a driver for something like a water sensor and I see a notification then I can test the device, but if I don’t know it was updated and it has a breaking change then I probably won’t find out about it until it’s too late.

If would also be nice if the hub update release notes included detailed information about changes to the driver base/default code because if I’m not mistaken a change to that code would impact all published custom and built-in drivers using it.

Yep I get that…Not too fussed about drivers from a manufacturer, just not too comfortable with community drivers where I can’t see the code

From a personal perspective I like being able to inspect any code I plan to install on my LAN. -

:laughing: then you probably want to inspect the ST code itself

the notification will arrive not only to you but potentially to thousands of users. And after several iterations, you will be tired to test the version like “fixing spelling in Italian”.

You should not be using free stuff (community drivers) for anything important. Think about it as for insurance.

You shouldn’t use free stuff (community drivers) for anything important. Think of it as insurance

Assume that is a joke? Do you not think it is sensible to be concerned? Installing a Smartthings hub on my LAN was indeed a risk I considered and decided the upside was worth it based on the brand.

I would like to install some drivers built by the community but I have decided the risk is not worth it if I cannot see the code.

Sorry if I am being churlish or lacking a sense of humour, I just think it is important to at least consider the topic of security

which brand? Samsung bought start-up SmartThings and now trying to get rid of costs by selling it to Aeotec(?). So if your LAN would be worth it any of these players can upload anything to a device controlled by rather a small team with now very high code quality.
The code you can not see.

I just think it is important to at least consider the topic of security

Even drivers already published by ST are under http://www.apache.org/licenses/LICENSE-2.0

so I would expect even less guaranties from community

Let’s agree to disagree. I’m not sure you are understanding my position and that’s fine

I do suggest that other readers consider the security risk from implementing any device or code on their network. There are a number of factors to consider and it is ultimately a personal risk decision

Take care

1 Like

Incorrect. Samsung has licensed out the manufacturing/selling of the SmartThings hardware. So far, Aeotec is the only announced partner. The SmartThings platform of software and the cloud is still maintained by Samsung SmartThings.

1 Like

Hi @Davec, I think the concern is valid and we encourage users to exercise caution when installing hubs and installing drivers from developers/publishers you do not trust as “peer-to-peer” channels are not directly audited by SmartThings in any way.

Basic Protections Provided by the Edge Driver Permissions Model

That being said, edge drivers have mitigated risk in a few ways:

  1. Drivers must declare permissions and we plan to make these permissions more user visible at install. Unless a driver requests “lan” permissions, it cannot interact with APIs to talk to devices on the local area network.
  2. In the future (not implemented at present), updates will not be able to increase their permissions set. That is, a developer who attempts to publish a driver update to the channel that adds permissions will be prevented from doing so.
  3. Within a permission, we prevent device cross talk. A zigbee driver may only send ZCL messages addressed to device short addresses from the set of devices associated with that driver. Same for Z-Wave. LAN is harder to restrict but we do enforce CIDR ranges that prevent drivers with the “lan” permission from directly phoning home to internet addresses.

Thoughts on Developing Community Trust

I expect and am planning to reach out to established community developers over time to encourage the development of a few somewhat more centralized Open Source projects with observable publication pipelines which might serve as a somewhat reliable source of drivers assuming a good set of maintainers in the community (possibly with SmartThings engineering support) is identified. This would:

  1. Provide “critical mass” to build out tooling to support CI pipelines to run tests, publish to channels automatically, run code lints, etc.
  2. Allow for a larger set of developers by way of the set of maintainers to ensure that issues get fixed and features get added. With a single developer sometimes life happens, circumstances change, etc. and this leaves the software unsupported. With an active project with several maintainers this is less likely to occur.
  3. Having more quality community drivers in one place reduces fragmentation and makes it easier to find reasonable support (if not supported directly).
  4. Over time with a successful track record, this provides some basis for trust.

Other Notes

If we do find malicious drivers published and shared on the community we will take actions to protect users and otherwise deal with the bad actors. In addition, I will submit an internal feature request that would allow for developers to opt into providing the source for their drivers and additional metadata such as a Github page for channels and drivers as I think that would be very useful and follows the same sort of pattern seen in some other packaging ecosystems.

We do believe that having a closed source model will be something that is desired for some manufacturers and community developers but definitely do want to do what we can to encourage auditable patterns of sharing work.

2 Likes

Good post, Paul. I’ve been watching this topic with great interest, as I have been providing, and would like to continue to provide, Edge drivers to the community. But I can empathize with David’s concerns, particularly as it pertains to drivers with LAN permissions.

You mentioned there are already some limitations on the CIDR ranges. Indeed I wondered if a driver would be allowed to post to an internet address and found that you cannot. While that prohibits some otherwise interesting possibilities, I definitely can understand it.

Here is a thought: perhaps there needs to be a mechanism to further limit the IP addresses that a LAN driver can access. Maybe have a configuration somewhere that defines which local subnets or IP ranges are allowable. There are always clever ways to defeat these limitations outside of the hub, but at least as far as the Edge platform is concerned, there would be full visibility and control for the user.

To go a step further, you could also publish a guide regarding ‘safe’ network configuration as there are certainly ways to securely fence hub access within your home network. It may be beyond most users’ capabilities, but for those that are serious about it, they’ll be armed with the right information.

2 Likes

Thanks for this response. Very helpful and reassuring.

I fully understand this, however I personally hope that the majority of community developers opt for the open source model. It will be interesting to see it all plays out