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:
- 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.
- 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.
- 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:
- Provide “critical mass” to build out tooling to support CI pipelines to run tests, publish to channels automatically, run code lints, etc.
- 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.
- Having more quality community drivers in one place reduces fragmentation and makes it easier to find reasonable support (if not supported directly).
- 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.