search

homieiot / convention

🏡 The Homie Convention: a lightweight MQTT convention for the IoT
https://homieiot.github.io/
Other
710 stars 59 forks source link

Feature request: property attribute "$secure" #182

Open backinabit opened 4 years ago

backinabit commented 4 years ago

This would be an optional property with default value "false". There would be no impact unless the property is set AND understood.

Secure wouldn't necessarily mean that it requires additional authorizations (although it could be implemented in that manner), but that there may be security implications with respect to this property, especially if it also bears the "$settable=true" attribute.

When $settable==true, this could be handled in a UI by prompting the user for additional confirmation, or a fingerprint, before allowing the set to be sent.

For example; the implementation of a garage door opener. Conceptually, a garage door opener trigger switch is, in implementation, no different than a light switch. HOWEVER, you want a light switch to be easy to reach and extremely convenient, which can potentially lead to being triggered unintentionally.

With a garage door opener, there is a very serious security consideration present. If it is triggered unintentionally, it exposes the contents of your garage (and possibly your entire home if its an attached garage!) to theft or vandalism, which may not be covered by your homeowner's insurance (who would consider it as you having left the door open, and therefore caused by your negligence).

backinabit commented 4 years ago

An alternative implementation (which would introduce a potential for incompatibility) would be to alter the definition of $settable to tri-state (false/true/secure), since I can't think of any significant use for $secure without $settable.

davidgraeff commented 4 years ago

This is already application specific. If you think that it can be of greater benefit for other use cases, please create a Homie extension. That is what the extension system is created for :)

backinabit commented 4 years ago

This is not at all application specific. The application I suggested is only an example. The use is universal for any properties that need to be treated with greater sensitivity than usual.

backinabit commented 4 years ago

More examples of properties that may need to be treated with additional care;

The light in the baby's room, which you don't want to be turning on by accident at 2 AM. The burglar alarm. Anything that may make noise. The furnace in the winter, if you accidentally turn it off while you're on vacation in jamaica, your plumbing will be frozen.

schaze commented 1 year ago

While I understand the intent and potential use cases I believe any implementation for handling a "secure" property would be very specific. In your example above what should the behavior for the device/property be in this case? How would you model this in a generic way? If the light in the baby's room should not turn on at 2 AM, what should happen if /set message is sent to turn it on? What if it is an exception to the rule (e.g. fire alarm) an you "really, really" need it to be on? @Tieske what do you think?

Tieske commented 1 year ago

This is mixing and matching multiple things.