-
Notifications
You must be signed in to change notification settings - Fork 38
Changing Authorisation UX to clarify data sharing between apps #265
Comments
For reference, the content of my proposal is as follows, but the link includes additional context which may be useful. Maybe we need to rethink the Launcher UX here, for example... Instead of seeing the data as "belonging" to an app, which it clearly doesn't because another app can access it with the user's permission, perhaps "Authorisation of an app" is what is misleading here. At the moment, an app can ask for authorisation to access App or Drive:
What's confusing is that any App can request and be given access to the App data created by another App - but to do so has to "pretend" to be the other App. This is very confusing in the UI, and misrepresents what is really happening. So instead of keying the "App" data bucket using the name of the application we should see it as named bucket of data, like Drive, and which any App can explicitly request access to. This removes the need for one app to pretend to be another - it can be honest about who it is, and clear about what it is asking to access. So instead of authorisation in Launcher saying:
The app would supply a name for the each data bucket it wants to access, and this would appear under Permissions. If an app wants its own bucket, it can have it, but another app could also request access to the same bucket. So for the SAFE Demo App it might say:
Then, it would be clearer if another App seeks access to that same data, as in SafeEditor:
I think this can be tidied up further, by hiding details that are not needed unless the user asks for them by clicking on a "more info..." link. So the authorisation message could be much simpler. For example:
Note: I've reversed position of "ALLOW" and "DENY" as I think the default should be first, reading left to right.
|
@theWebalyst, thanks for you time taken to explain in detail. If other apps can directly access other application's data just with user's consent, then there are chances for the data to get corrupted. For example, android and iOS also have a similar approach. They provide apps a sandboxed environment to store app related data and this can not be read by another application. To share the data they will have to store in a secondary storage or a common place to access it. If we map it to our structure at present, the app root directory is sandboxed and can be read only by the application. If they want to store data in a common place apps can choose to save in SAFE Drive. But for the problem you have stated, the apps can choose to use the low level apis and try to make the needed content available for other apps to access. Again if you take Android for example, they provide a API called |
Thanks @krishnaIndia (and by the way, thanks for the Test 10 release - lots of fun and very neat to play with)... I'm a bit confused by your response though, because my comment is premised on the fact that App data is not sandboxed, and that any App can gain access to another App's data just by impersonating the other app and the user giving authorisation (quite likely without realising that it isn't the app they think it is). If an App was really in control of its data, I could well agree with you here, but it isn't, and that is the root of the problem I think. The current situation - as demonstrated by SafeEditor - seems very unsatisfactory. |
While I agree with your points here Mark(@theWebalyst), what I'm wondering is if this proposal would be a solution to this issue at all? Cos the point of App based sandbox was to provide apps a storage location which "only" it can access and in this attack case, that no longer applies since another app has pretended to be the original app after getting the user to allow it through as the original app. Isn't that the fundamental issue though and needs addressing to improve fingerprinting of apps to prevent apps from impersonating each other? Cos say we didn't go down ^^ route and went down the buckets only route. So for example say we have categories such as:
Now if we have Apps
However thats just a choice though and don't see it actually solving the issue here.
Thats kinda why I'm finding it hard to see how switching the storage type to containers/buckets fixes this cos the problem is fundamental indeed here where the user has been "tricked", and the whole point of getting the user involved in the auth process is to get the confirmation from the user as the final authority and not let the automated system decide the validity of the incoming request. In the case of |
There's a SafeEditor App which allows users to edit data created by other apps (eg SAFE Demo) and which shows how weak the ownership of App data is.
Given the difficulty of tightening this ownership, and the utility of users being able to access data created by an App, without using that same App, I have suggested a change to the UX for authorisation within SAFE Launcher.
My forum post explains this proposal (and the topic gives fill context) here:
https://safenetforum.org/t/safeeditor-mvp-edit-your-safe-files-directly-from-your-browser/11057/21?u=happybeing
The text was updated successfully, but these errors were encountered: