User Permissions

[kgiori]

I want to add users who can access my system with "guest" privileges. They should be able to:

• add and control "Things" but not "remove" them
• add new rules and enable/disable existing rules, but not edit or delete existing rules
• view floor plan page but not edit
• view settings pages but not edit

[hobinjk]

This would be great to have! #338 should form a pretty good basis for this as long as the permission denied errors are exposed to the user (which they aren't right now).

[speccy88]

I would like to add that it would be useful to be able to let some users see only a limited set of devices.

[benfrancis]

I think this can be generalised to a permissions system for users. Currently all users have full access. Guest Users is one use case of that.

[benfrancis]

@draggett suggested that this could go down to the level of different permissions for different properties, actions and events.

[draggett]

@kgiori's idea of different permissions for guest users makes sense. Another use case is parental control of TV's where the children have restrictions in what they can view and when (e.g. no watching TV in their bedrooms after 9am). One solution is to annotate properties and actions, and then to have separate rules that parents can enable in terms of these annotations.

[coreyo]

We need the ability to create arbitrary security groups, the ability to assign arbitrary devices to each group, and the ability to allow actions to arbitrary users for each security group. The idea is as follows:

Suppose that I run an AirBnb. I rent out my basement which has any number of smart devices such as lights, fan, thermostat, etc. I want my guests to be able to control all devices in the basement, but none of the devices in the rest of my house. I could create a guest account with permissions to only those devices and change the password with each guest (or make it local-network-login only)

[flatsiedatsie]

Perhaps related a bit: it would be nice to be able to have a way to show some things without needing to log in. For example, if the WebThings Gateway is given the same physical form as something like Google Home Hub.

[flatsiedatsie]

While developing the Candle smart home we realized that current generation smart home software often uses/assumes hierarchical user management and permission systems, but that this design might not be optimal for real-world family scenarios. In fact, increasingly we hear stories of smart home systems that are seduce its users to spy on each other, creating tensions. Especially children are having a hard time growing up in homes where their activities are surveiled, and past behaviour can be recalled in detail.

A proposal for a 'next generation' system can be found here: https://www.candlesmarthome.com/healthy-social-dynamics

If the Mozilla Gateway acknowledges these issues and designs a different system, it could gain a unique selling point and show a different way forward to the industry.

Specifically:

• Digital 'human rights'. Besides the normal rights system, there could be special rights that cannot be revoked once given. A parent could give a child the right to 'own'/veto certain devices, for example when they turn 13.
• A user system that is not modeled on corporate hierarchical systems. Currently, there's always an 'admin' distributing rights. This is akin to a 1950's family where the father is the 'lord of the manor'. Next to this 'basic' system, more complex social relations could be modelled, and more democratic decision systems could be made available. For example, imagine that a majority of residents would have to agree to delete an account. The users could put things to a vote, and these would end up in a 'decision inbox'. Some devices could be owned by one person, but in an emergency these rights could be overruled by the majority. But only if the devices have been setup to allow this democratic override.
• All data logging devices should have a small toggle that allows users to easily disable data collection for a while, and even automate this. For example, to never record what time people come home on a friday or saturday night.
• Granular data accessibility. Imagine that the main user has access to the full detailed log, but other users may only be able to get a log that shows hourly/daily averages, or only the last day.
• Generate fake data. Just as people use instagram filters, they may want to polish/manipulate their data easily. They may want to hide the fact that they went to bed late on thursday, or secretely smoked a cigarette on friday. I've hear stories from people who were ashamed that their Nest thermostat revealed to their friends what their life patterns were.

Underlying all this is the understanding that people constantly tell little white lies. As social animals we constantly manage our perception by others (even though we pretend we don't). Smart homes should, in my opinion, support this very human behaviour. In fact, I don't think they'll ever become very popular until they become sensitive to these issues.

[benfrancis]

This topic has come up before (including the issue you posted last year), and I think it's a really interesting potential differentiator.

I think this requires some further user research and UX design to come up with a system which can accommodate non-hierarchical permissions, without being too prescriptive. And without adding too much complexity. For example, I don't think we should enforce any particular decision making process on a family, but we could give them the tools and agency they need to make those decisions themselves.

Issues like giving children rights which parents can't revoke and allowing users to create fake data are tricky social issues which may not have an easy answer. But we could start with some simple mechanisms like allowing different users to own different devices, rather than having a single admin user who can access all devices (or give all users access to everything as we currently do). It could be that when a device is added it has an owner assigned who can then share ownership or grant permissions to other users.

[flatsiedatsie]

I think it's a really interesting potential differentiator.

That's exactly what I feel too.

I presented the concept at ThingsCon last friday, and people really got it. Especially students understood the issue. As more news about broken relationships and the impact on children surfaces, I think this will become a broader societal question in the coming years. A smart home should have the built in ability to not measure all the time, lest it becomes restrictive. A smart home shouldn't be a surveillance home.

we could start with some simple mechanisms

Sounds great! I was wondering if it would be an idea to break this down into a few concrete issues. Perhaps the simplest solution would be if the gateway has some kind of lightweight interface/AP/scaffoldingI that allows add-ons (and built-in features) to work with. That way implementation could be something that is done and explored by the community.

It could be that when a device is added it has an owner assigned who can then share ownership or grant permissions to other users.

Ownership sounds like a good place to start. Another interesting light-weight starting point could be a rights system that covers devices as well as add-ons. Then it would be possible to create experiments such as:

• People with the 'ownership right' of a device can see a lot of detail in a log, but non-owners can only see the last day/hourly averages (e.g. electricity use of your home can be sensitive).
• Owners can decide at what times devices record data in the first place. They might disable a device's data transmission during certain times by creating a rule. This would allow them to turn of camera's during poker night, disable whether the use of the back door is logged during certain evenings, or allow them to plan a secret birthday party without raising suspicion.
• Owners are allowed to manipulate data logs to a greater extent. E.g. with the Privacy Manager add-on, perhaps anyone could delete a data point, but only the owner is allowed to change and create new datapoints. It could also be that the privacy manager add-on brings with it a few new rights, such as "delete point", "manipulate points" and "create points".
• A device owner might give others a 'fake data allowance', which limits how many data points per month they are able to delete/manipulate. This allowance could be used up across multiple add-ons. Perhaps related to rights, this would require some sort of 'global variables' that add-ons can create and share access to.

In the long run things could get to a point that a rights system might not be able to cover. For example, a smart lock might have a stealth lock ("pretend to be unlocked but is actually locked") state, which could be added to the WebThings schema. Similarly, being able to easily disable data logging for certain devices for a while could be a general feature of the Gateway ("don't record data from devices in the study room while grandma is staying over, because she will use it as her bedroom").

We could discuss getting development for this experiment funded through the EU or other cultural/innovation funds. There are also academics exploring these issues.

[flatsiedatsie]

Just a small thought experiment, thinking out loud. Here's a popup that appears if a user installs a new add-on.

• Ownership can also be communal or perhaps even shared by a group of people, such as parents. If ownership is communal (anyone can change settings at any time, like a free for all) then the option to set Usage to communal wouldn't have to be shown, as that would be implied. But if one user owns the device/add-on, then that user could decide who can access it.

• Record and play audio could also be "record audio" or "play audio" only. For example, the internet radio add-on would only need rights to play audio. Even features like muting audio output of the voice assistant could then in theory be handled by taking away the right to play audio. If each add-on is run as a separate linux user (as MrStegeman once mentioned), this could perhaps build upon Linux's existing permission system. Then again, perhaps this is way too much granularity, and something simple as allowing an add-on to just 'access hardware of the Gateway' would be enough.

• Read and change is just read and write permissions. I was wondering if for log data you'd also want to set if those rights extend into the past or not. "read + access the past" would give access to log data, and "write + access the past" would allow manipulating and deleting log data.

• On a related note, perhaps users would want to have an option to automatically allow an add-on to access new things that may be added in the future, or require the user to sign off for future new devices.

• If options are selected that require more details (e.g. if the user decides only some devices may be accessed), the popup turns into a wizard where another page allows the user to detail which devices specifically, similarly to the current oath page (perhaps with shortcuts to quickly select groups such as "all livingroom devices" or "all devices owned by Janet").

• If someone with "install add-ons" rights installs a new add-on that would require access to device they don't have ownership over, then the add-on wouldn't be able to access the device until its owner signed off on it. For example, if John install an add-on that wants to access electricity use data of all devices in the home, then Janet will see a pop-up the next time she logs in stating that john's actions generated a request to access some things she manages. She could quickly accept (they probably discussed this at the dinner table already), decline, or allow only a subset of her things to be accessed (excluding her smart vibrator). Perhaps she could say her devices could only be read and not written, e.g. if an add-on wants access to all the locks in the house.

As I once mused about the rules interface, it might be interesting to create an interface that puts the emphasis on manipulating sentences. The advantage would be that rules and permissions could be manipulated through speech input. The more I think about it though, having any level of security when using voice as input is really hard - the system would have to learn to recognise users by their voice. This would always be easy to hack/fake (although voice input through the browser would be easier to secure, as in that case you know which user is logged in).