Feature request: property attribute "$secure"

[backinabit]

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]

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]

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]

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]

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]

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]

This is mixing and matching multiple things.

• Authorization: Homie has no notion of this. It requires Authentication
• Authentication, is also not covered. At best the MQTT level controls can be used.
• prompting for confirmation is yet another UI hint, as discussed here: Feature request: property attribute "$hidden" #181