Thanks @Viv, a lot to take in. I hope I’m going to summarise accurately here:
- we can tighten things up in various ways, but if an app chooses to impersonate another app, and the user ok’s this, knowingly or not, nothing we can or should do to stop this.
I agree with this, except that you have skipped over the issue which kicked off this whole discussion. It wasn’t SafeEditor being a nice App that the user knowingly decides to authorise as SAFE Demo App - you do address this!
No, it was SafeEditor that alerted @jm5 to the possibility of any an App impersonating any other App and the user accidentally authorising the fake-app. And it was to address this that I made my suggestion, that by switching from authorising an app, to authorising access to particularly data buckets, we could make it more apparent to the user what they are granting access, and much harder for them to do something they don’t want, or don’t understand the implications of. This wouldn’t address repetitive authorisation fatigue though, see below.
So in your wallet thief App example, it is not going to be obvious to even an attentive user, that Fake-Wallet-Thief-App is asking for authorisation. Because Fake-Wallet-Thief-App will not be displayed by launcher. Launcher will say Trusty-Old-Friend-Wallet wants access, and the user only has to click “Allow” as a reflex - just once ever - to lose the content of that wallet.
My data-bucket suggestion isn’t perfect, so I’m not arguing for it as is. I’m looking for a good overall solution to this and that was just one first thought. I’ve never been comfortable with the UX of launcher, but I think it is a hard problem as you’ve noted, and I really don’t know what is going to work best.
Repetitive Authorisation Fatigue
Another issue I would like to address is having to authorise lots of apps, and every time they are run. Because that is both tedious and causes the user to authorise by reflex, not read or understand, and not make conscious choices which would be terrible for a security model which relies on the user being the authority (which is of course our aim). I don’t want to derail this topic, but to note the issue because I think it ties together with any discussion of launcher UX. Perhaps some kind of persistent app authorisation can be devised - which apps cannot spy on - like a password manager inside SAFE Beaker, or for each desktop, is one option, but I don’t know enough to say how it would be implemented (or if it is feasible).
My suggestion at this point is that by storing authorisation, so apps only need request access when first used on a particular desktop/device, it becomes much clearer to the user if an app attempts to fake a request for access - and which app is doing that - and to what. If we can’t achieve this, I think we’re going to find it hard to come up with a launcher UX that is either secure (helps user maintain conscious authority) or not a pain in the ass (nagging for authorisation).