I get what you’re saying Corey - You are of course correct in that aspect I’m not thinking of me in this case or accidentally switching on or off something… It’s more the, if I can’t see it and KNOW I’m OK or instead have someone who is backing up what they say with warranty of some kind (Open source or closed source model). I can’t use it.
Groovy Smartthings, HomeAssistant, etc. Open source - I can see every bit of code therefore while it is on me to check (and admittedly I check and verify less than I should, but the point here is I CAN) and use at my own risk. So I do. A LOT.
Let’s assume we soon see a Pay to Play RBoy Edge Driver for Zwave locks. Closed source for obvious reasons, BUT - if I’m paying for it and RBoy puts money where their mouth is and supports their code if its broken or does bad. I’m still OK.
What I’m NOT ok with is trust without verification that all driver code out there is non malicious.
BTW - I would be OK with a voluntary link to GitHub to verify the source code of the LUA driver matches the code at the published link. If ST wants to be a real community player ST - OFFER THE LINK to the code in the app UI - if someone wants to chase the link and read it they can. It would only take one attribute of type string with a filtered URL… Would TOTALLY do that. That way it could be as simple as “If you want your code open - offer the link in your driver registration but it MUST be formatted as X and posted unchanged else your driver wont install and if you want it closed… Don’t”
Can you share any idea how the LUA code can be malicious?
As I understand, the drivers can only acquire any information or act on inside your networks (Zigbee, Zwave or LAN), but they do not communicate outside of that only to the Hub and SmartThings Cloud.
To use anything outside of that, you need a SmartApp and authentication (token) but those are not drivers.
(I have some ideas of malicious code, as search non-protected network drives and wipe them. Or turn on and off switches as high rate, but that would hit rate limits. Maybe automatically open a doorlock at a specified time, but that would show up in the logs…)
I think they will get something like this as the ecosystem matures. Or signed drivers that you can verify match what’s installed.
When going to Hubitat I missed the fact I could look up the source for most of the built in drivers. HE’s stock drivers are all closed source which sometimes makes debugging more difficult.
Since I rely on my memory for tracking conversations (I use a voice reader, so it’s quite difficult for me to go back and scan old threads) and there have been SO many duplicative conversations lately, it’s getting quite difficult for me to keep track right now. My problem, but just wanted to mention it as I may miss more stuff than usual.
Anyway, there has been a longrunning (more than a year) conversation in the developers’ section of the forum on security and closed source releases. Including some staff comments.
Standard denial of service attacks, such as malicious hackers have done against Nest previously. Anything which causes the hub to become unusable after a given time. Done for all the usual hacker reasons. The attack itself is the goal.
“Malicious ex” attacks against a specific target. These are typically attacks against locks and security features, but can also just be blinking lights and setting off sirens. These can be done remotely for psychological effect or followed up with a physical incursion.
“Ocean’s 11” attacks against a specific geographic area. These will be followed up by a physical incursion, usually for purposes of theft.
“LAN Takeover” attacks. These are done for the purpose of getting remote access to other devices on the same LAN. the motive is often financial, including ransomeware.
“Peeping Tom” attacks aimed at camera takeovers.
How big a threat any of these is to any individual household varies a lot. Most are at best minor annoyances, some are real. Malicious ex attacks where you are the individual target of someone who already knows the details of your household are probably the highest damage risk, but you probably already know what the likelihood of that is.
So why are these things opaque? I assume the LUA script(s) are compiled to bytecode, correct? If so, when/where does this happen? Again, I am assuming if installed via the CLI, the bytecode conversion is handled by it?
But there is this “Channel” installation method (which I don’t fully understand), where you register your hub from a website and the transfer “just happens”. Once again assuming what is transferred has already been compiled?
So the channel method is easier on the consumer, but if the dev makes their LUA source available, you could inspect it before installing via the CLI… right?
In order to get them onto the hub, you have to download them from a “channel“ which is in the smartthings cloud.
In order to do that download, you will follow a link that the channel owner gives you that takes you to a webpage which is accessing the smartthings cloud.
You sign into your SmartThings account on that webpage.
It then displays the channel details. You can subscribe to the channel and then select individual drivers that you want to have downloaded to your hub. ( download process can reportedly take as much as 12 hours, but it’s usually pretty quick.)
Once the driver has been downloaded to your hub, you will be able to see its presence through the smartthings app. But you don’t get to see the actual code.
In order for a developer to get a channel in the smartthings cloud, they have to go through some paperwork and sign up. But it’s not like an app in the Apple store: they are not required to have the code reviewed for malicious intent before it becomes publicly available.
So at no point does the code have to be available for the end user’s inspection. And even if there is code in GitHub that the channel owner says is what will be downloaded to your hub, there’s no guarantee that it will be the same.
Which is pretty much the same as apps on the Google playstore, if I understand that process. There are promises, but no guarantees that the promises will be kept.
The lua interpreter running on the hub does indeed execute the bytecode form. The CLI does not compile to bytecode as part of the upload/install. The compliation appears to happen in the cloud (it binds to the rest of the framework during that step), and the bytecode appears to be downloaded to the hub for later execution. I believe this is correct.
I pretty much remember reading something about Edge drivers being able to be installed from the CLI. This involves creating a channel and then selecting a LUA package (directory of source) which I guess means it is first uploaded to ST cloud:
smartthings edge:drivers:package [path_to_dir]
and then back down to your hub:
smartthings edge:drivers:install [ID]
So if the dev supplies the source, you could examine it before going through this process to install it?
Sure if some dev just wants to share their code, you can create your own channel and use it that way. But then you don’t get automatic updates, and I don’t think most devs are doing that.
A lot of developers have welcomed the change because it gives them a way to get compensated for all the hours they’ve put in. But there are always some who are open source all the way.
Ok… I guess I get it. They designed it purposefully to be opaque so devs no longer need to share their code, hence making their work more profitable if they so desire. But they take NO responsibility for vetting that opaque code! Way to go SmartThings!
Both iOS and Android app stores vets submitted apps. Both may be more effective than the other under different circumstances, but both make the effort. Due to the channel dist process, SmartThings has the SOURCE CODE (which is way more than Apple or Android has), but they’re too lazy to vet any of it?!
Plus if I have/wrote the source, why is the whole cloud thing even necessary then? Why can’t the CLI just do the compile and install. Way too many pieces of junk here… possibly the worst UX I have seen in recent years (decades in fact) for drivers and rules… it all just wreaks of laziness. I wonder if it will get better, but my money is on it just continues to get worse.
Sorry for the rant… we’ll soon see whether ST is worth keeping (but it is Samsung, and they’ve shown the middle finger to their customers way too often).
There is an entire framework that the driver compiles against that the CLI does not have or need. A driver is just a small component of the whole system. You’re not building an entire hub image. You’re uploading a sandboxed element that will be linked against the rest of the world at a later stage.
I’m not sure i get the outrage against community drivers. If you don’t like the model (can’t read the code, worried about bad actors, want Samsung have an acceptance process, whatever the case) then don’t use community drivers. They’re optional. If thats the case and the stock/supported/clean drivers won’t cover your devices at this stage, its time to switch platforms. Life goes on.
My outrage is due to a platform that was founded on open source now being closed. I get that some devs want money for their contributions… that’s ok, provided they take responsibility for their code. Sadly, that is not the case here (or doesn’t seem to be).
For community members that want to donate their work, bless them… but I’d like to look at their code before installing it. What ensured SmartThings current success WAS the community… and members sharing code that could be used/leveraged by other members. That is all gone now.
Understandable. I look at Edge as a new platform utilizing the existing hardware. With cloud dependency you can’t run the old platform unfortunately but thats no different than any other.
DTH
Edge
Maintentance
Web portal (IDE)
CLI on local computers / API
Language
Groovy
lua
Community Drivers
IDE source with optional GitHub sync
Subscription/Channel model with forced update
SmartApps
Groovy based, hosted for free in SmartThings cloud
API connected (create in any language) but no hosting provided
Local processing
limited to “built in” drivers only
All installed drivers run local
Local protocols supported
Zwave, Zigbee, a few specific LAN integrations
Zwave, Zigbee, LAN, WiFi via Matter, Thread via Matter, MQTT via custom Edge Driver and local server
I’ve been with ST from the very beginning, and I also welcome the change, even though it’s been a little rough. Change can be a little hard to deal with , but I’m good with it…
Can anyone tell me how to determine a device’s fingerprint after it has been converted to using an edge driver? Perhaps via the CLI?
I just realized that I might need this info for some of my devices after the transition (to find a working alternate edge driver, for example), but it is only reported in the IDE for devices with a legacy DTH installed.
Has anyone seen an answer to this? Assuming there is no replacement, anyone have a suggestion on where I can get half decent free brightness info I could build into my routines? Sans that, what’s a decent not overly high priced device I could try and use? My fear on a device is it will be impacted by the lights turning on wherever I place it (unless outside and I imagine a weather resistant one is even more expensive) and off in what ever room it is in. For a single room that would be fine, but I really want ambient light outside so I can build automations in different rooms off of it.
