Are there any conditional access mechanisms available or being considered other than using time? Such as, revoke after N-requests, or a general “Revoke all temporary grants to all apps (since login / ever)” etc.
Thinking from user side, I’m wondering what I might want, and some kind of granularity in revocation might be useful. As a user I came up with three broad categories of access scope to help me think this through:
-
Everything Scope - this scope is always as high value/risk as the most valuable data in the account. Users can know this, and in theory could manage risk and security with different accounts. For example, keeping one for housekeeping, general administration and small change, another account for Safecoin vault earnings or investigative journalism. I think that’s fine in theory but IMO for most people is hard to do, and so it would be better if value/risk could be managed by granularity of access scope within the account, for as many users and use cases as possible. However, as I understand it whatever we do will have a limit that is not going to be very secure, and that the only very secure boundary is going to be account login, because apps can’t be trusted to store credentials as well as “in the user’s head”, and not to secretly steal credentials from each other. This means extra care will be needed with everything scope, unless I’m wrong? This has occurred in the past
. By extra care, I mean to ensure the user understands, knows what alternatives are available and finds them easy to make use of at the point this is realised (which might be long after the app is first installed or used). -
App Specific Silo Scope - here value equates to the most valuable data that the app can generate / access / is provided by the user. So value/risk is very variable, but often well defined according to the nature of a given app, and so relatively easy for a user to estimate and understand, even in advance. Examples: password manager v invoice generator v calendar v contacts manager v alarm clock etc. This is not always the case though, see next…
-
Task or Data Value Scope - covers the case where value/risk relates directly to particular data or the task associated with it. In terms of apps, think of spreadsheet, word processor etc. where the value of data produced by the app, or which you want the app to access, can’t be known in advance, or is simply anything associated with a particular task. For a given task or data silo it will also be impossible to know which apps will need access to it in advance, so here authorisation is at the point of use, and perhaps per use, and not per app. Thinking in terms of tasks, we can have shopping (so shopping list), writing a product review for magazine article (so spreadsheets comparing products, word processor for drafts, article etc), or working on maidsafe’s next acquisition etc.
. For many things default security is adequate, for others not so much, but only for very high value/risk things will the majority of users bother to take even the simplest precautions (look at Hillary Clinton’s email, and others who should know better at the top of government using services like Yahoo! even after they’ve been exposed as insecure…again!). I don’t know if that makes task/data silo access granularity pointless, or just means we need to make using such a facility very intuitive and as effortless as possible. I think it is worth trying though. It is not done well yet only because it is very hard to achieve (because it requires humans to think, and do work!) not because it isn’t very important. It is at the root of much of the surveillance and invasion of privacy we know about, and is what makes it hard for anybody to regain control. So for example we could consider the ability to lock data according to which folder it is in, and for permission to read and/or write to be required according to criteria that I have yet to think about. But for example, on access per session. Or in order to read. Or in order to write. Per folder, or even per file. Obviously though, no point providing features if they aren’t going to get used, so I think we need to consider usability almost as much as technical feasibility and theoretical value (by which I mean security achieved). Even if we can’t do this now, it may be worth thinking about in case their are things we’d like to implement in advance that ensure it can be achieved with least effort and burden for users later.
IMO usability is crucial in all of this. Everyone has to login to their SAFE account, but after that we know hardly anyone will put an ounce more effort into managing their risk and security than we actually enforce, and anything we enforce which causes the least bit of inconvenience will push users towards less secure alternatives which is bad.
In the end everyone wins by keeping as many users as possible more secure, so I think work hard to maximise usability, and within that do the best job we can to provide security.