Usable Security in permissioning

WG Private Data
1

I’ve tried to read through the topics, but I’m opening a new topic on something that I didn’t find discussed: Usable security (I used to call it security usability, but apparently, the world has converged on “usable security”). Whatever we end up with must be thoroughly tested with users to ensure that they are able to express their intent and resist manipulation.

To illustrate a possible failure mode around the latter: A permissioning system with bad usability could end up flooding the users with requests to grant access, so that the user perceives the system meant to protect them to just be in the way, so they end up clicking “agree” to everything. Given that there are industries with decades of experience in manipulating people to click "agree” to everything, or similar, I suspect this is by far the most likely failure mode of any private data system.

Security and usability is often said to be a balance, I don’t think that’s the case, you can’t have one without the other. However, permissioning systems have traditionally been designed for experts, with usability for them, with their training in mind. That’s a very different thing than what we need to do as we try to get the next billion people into the ATmosphere. That’s not to say that there can’t be expert systems living alongside systems for the general public, but I think it is important that their existence cannot be abused to compromise the security of the general public.

Apart from deliberate manipulation, and just bad usability, this consideration is particularly difficult when there is a balance between overpermissioning and user workload. For example, you could do a design where people can grant access on a per-term basis, which is great since the user will not need to grant permission to more data than absolutely necessary, but OTOH, you could make it require so much effort that they instead grant a permissions they shouldn’t need to.

Another thing is to make sure that you have the right operations, for example, if you just have an Update operation, and you have to grant Update to do an Append, which wouldn’t require read at all, then that’s also a case where the design encourages overpermissioning. I’ll return to that topic later.

I have received a little bit of funding to work AT proto stuff now, but I could only set aside a little bit of time to private data. I’m going to try to find funding for a next phase so that I can have someone help with usable security, but if that fails, I hope the community will consider it.

2

How different organizations and apps implement private data (and there will always be more than one, including the ones that are already deployed) is going to be different.

For instance, Leaflet supports private drafts, and has “view” and “edit” links that can be used on drafts. This is app specific behaviour dependent on the app.

For the purposes of discussion, private data that is multi user and server protected (i.e. not encrypted - there are other architectures) is most likely to just use OAuth Scopes and Permissions. Since THAT is just finalized now, the whole ecosystem is going to learn about it, and need to work on educating people.

It’s great that you’re looking at funding to work in this area! It is likely that building / deploying an app that makes use of private data is going to be most helpful – including whose codebase you might work with or interoperate with.

3

Yup, certainly, but that’s not the point. Usable security is not just about the design choices made at the application level or UI, the affordances deep down strongly influence how applications can be designed, and so, it has to be done well down there. I have just briefly looked at the OAuth stuff, but it seems to be the scaffolding around where the most consequential choices happens.