Add "fake state" as a possible state.

[flatsiedatsie]

Currently the smart lock has a number of states it can be in. If memory serves, it's:

• locked
• unlocked
• unknown
• jammed

I would like to suggest two more:

• Stealth locked
• Stealth unlocked

Stealth locked Imagine a teenager that wants to spend some small amount of time in a room with the knowledge that the door will be locked. But at the same time they don't want to signal to others in the household that the door is now in the locked state, as that could create unwanted social scenario's. For example, they may not want to signal to log every time they masturbate.

Stealth unlocked Some situations may require the reverse scenario. A door is locked, but a user wants to unlock it for a short period of time without indicating this in the system, let alone in the logs. For example, a husband might let in some friends through the back door in order to prepare for a surprise birthday party. Or perhaps the mailman has arrived with the ring he/she wants to use to propose marriage with, but doesn't want any "who was at the door?" question later.

In either case it would be necessary for the system to pretend to stay in / be in one state, while actually being in another.

Locks are just an example of this. There are many social situations and cultures where a smart home that would help the user to 'save face' would be highly valued. Situations where the "owner" of a device has access to the actual information, while others may be left in the dark for a little while.

At least until they try to actually open the door and find it locked, hearing only a faint sigh of relief from the other side.

More on this, including a mock-up, can be found here.

More about the need for this sensitivity can be read here.

[benfrancis]

It wouldn't make sense to implement this at the API level as that just exposes the "stealth" state to all WoT clients which query the state of the device. It would have to be implemented on individual devices which provide a UI to make the lock report a locked state while not actually locked, or vice-versa.

[flatsiedatsie]

I agree that making the actual state available ("I am a door lock that is currently fake-locked") would be counter productive :-)

I guess my first question is: do you agree that there is a value in this functionality?

My hope was that this would allow devices to ask the smart home controller to generate a UI that offers control over these 'fake' options to the 'owner', while showing the pretend state to everyone else. In that sense this suggestion presupposes the idea of different levels of control over devices.

I'm trying to understand where it should be suggested. I'd love to have a discussion about this with the community that is implementing the webthings standard. Where should I address this?

More pragmaticaly, how would you propose that his type of behaviour could be engineered in a sane way?

[kgiori]

I agree with your assessment that access controls or a device administration hierarchy would be a possible way to address these types of privacy requirements. We should brainstorm what list of rights/needs would facilitate user privacy. Then put them in some sort of hierarchical order. Examples of rights:

• ability to fake/override device truth (and if so, are the fake states allowed to be logged too? as an alternate reality?)
• ability to log device data
• view device state
• view device logs
• manage a device state (including edit and remove) I wonder then if a three-tiered hierarchy could address administrative rights sufficiently:
• ownership (admin)
• user
• viewer My next question is whether these types of user rights are also applicable to jwt (auth) token relationships between the gateway and other applications. Today jwt auth is shown as being applicable on a device basis, with options of "monitor" or "monitor/control". (I don't know if it actually works, but that is what the UI shows...) If so, then perhaps the user rights and the application rights use the same/similar logic and UI/UX approaches.

[benfrancis]

I guess my first question is: do you agree that there is a value in this functionality?

It's certainly not something I would want for my own family, but that isn't to say that some families might find it useful.

I'm trying to understand where it should be suggested. I'd love to have a discussion about this with the community that is implementing the webthings standard. Where should I address this?

You could submit this as a use case to the Web of Things Community Group. Personally I don't think this is something which needs building into a standard, it seems like an implementation-specific feature.

More pragmaticaly, how would you propose that his type of behaviour could be engineered in a sane way?

It could be implemented at the individual device level, or as a gateway add-on, by getting devices to report different states to different users. Having different users receive different representations of the same web resource depending on their identity and permissions is a pretty basic feature of web services, and therefore the Web Thing API.