Changing Authorisation UX to clarify data sharing between apps

[happybeing]

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

[happybeing]

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:

• App meaning, a bucket of data that is (behind the scenes) referenced using a hash based on the app's identifying information (name and vendor I think), and
• Drive meaning a bucket of data that any App can see providing the user "Allows" it.

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:

Authorise Request:

AppName: SAFE Demo App
Vendor: MaidSafe
Version: 0.6.0

Permissions:
  None

             DENY  ALLOW     

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:

Authorise Request:

AppName: SAFE Demo App
Vendor: MaidSafe
Version: 0.6.0

Permissions:
  SAFE Demo Files

             DENY  ALLOW     

Then, it would be clearer if another App seeks access to that same data, as in SafeEditor:

Authorise Request:

AppName: SafeEditor
Vendor: DavidMtl
Version: 0.1.0

Permissions:
  SAFE Demo Files

             DENY  ALLOW     

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:

SAFE Demo App ([details=more info...]
Vendor: MaidSafe
Version: 0.6.0[/details])

Wants to access: SAFE Demo Files

            ALLOW  DENY

Note: I've reversed position of "ALLOW" and "DENY" as I think the default should be first, reading left to right.

SAFE Demo App ([details=more info...]
Vendor: MaidSafe
Version: 0.6.0[/details])

Wants to access: SAFE Demo Files

            ALLOW  DENY

forum post

[hitman401]

@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.
As an app developer, if I want to isolate certain app specific configuration from other applications, I will be loosing a sandboxed environment.

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 content providers to expose data from sandbox using a structured means than granting access to the entire folder. Like wise, if SADE Demo files app wants to share the data with other applications it then it can use the low level apis depending on the need, to expose the contents that it would like to share.

[happybeing]

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.

[Viv-Rajkumar]

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:

Camera Roll
Calendar
Files
Private Files
Location Data

Now if we have Apps A and B, sure both can ask user for Camera Roll and gain access without trying to impersonate one another. I guess thats what you mean by

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.

However thats just a choice though and don't see it actually solving the issue here.

1. Without app specific sandboxed folders, if app A wants to store info it does not want any other app to access, it doesn't have an option cos B can also "ask" for the same permission.
2. Also say App A was the only app the user intended to get access to the bucket Private Files, even with this proposal without enhanced fingerprinting of apps, App B can pretend to be A and trick the user into getting access to Private Files bucket and thereby cause the same issue as what this proposal aims to make redundant.

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 SafeEditor, David certainly made it clear he was getting his app to pretend to be another app(Demo App) and users were made aware of it. I just wonder in the same post if we mentioned it was impersonating an app which was say holding private images or something of the user, if users would have trusted this app and allowed it to impersonate the private images app?