How to give other users access to parts of a user's POD

Hi

I am wondering what is the recommended approach to allowing a user to share parts of their POD with other users. As a concrete example - say we have an app for managing a user’s music library. The User might want to share a set of songs with a group of other users. Each song could be an mp3 file in the POD and we would want to allow a set of users access to these mp3 files.

From my understanding my app would have to change the .acl settings for these files. And for this the app would have to be granted control permission by the user. But I have been told this can be dangerous as it gives the app full control to do what it wants with any part of the user’s pod. So if this is not how I should be doing it then is there another way?

Thanks
Des

If the access permissions you want to grant aren’t complex, you could just tell the user to use their preferred way to share the files (and also give them a link to a default app in case they don’t know how to do that). If it’s just about giving some other users read/write permissions this could be done in the databrowser for instance.

So for basic permission granting I would go this way. If it isn’t too specific to your app, an external app for that should suffice imo. If it doesn’t, then I think you will need to ask for Control permissions.

Sorry but I don’t understand your answer. I will try to be more clear in the question:

Say we have a set of 5 users using the app and they all know about each other. Lets call them “user1”, “user2”, … “user5”.
Now user1 wants to share a song with user3 and user4. Within the app there is a screen for them to grant access to these users. The app might send a message to these users’ inbox saying this song has been shared and the message could contain the url for this song.
These users are also running the app and they will see the message and now want to play the song. But user3 and user4 will by default, not have access to this document (mp3 file) as it is stored in the POD of user1.

Therefore my app needs to be able to grant user3 and user4 access to this document. So my question is the following:

Should my app be changing the .acl for this file accordingly?
If so, does the app need Control permissions?
And if this is the case is this a dangerous thing to do?

We have two ways of seeing the problem.

  1. The app supposes that the users know each other through the use of the app. In this case, each app implements its own definition of “friends”. From the user’s perspective, it is not great, because for each new app, user1 will need to grant access to user3, user4 etc.
  2. The app understands how the user’s music library works and does not bother with controlling who has access to the data. This is a little more work for user1, as now user1 needs to create a group of friends, and share things from the solid UI. However, this work is only done for the first app, and then every other music-related app will respect the prior sharing decisions of user1.

I understand that there is a tension between platform “killer apps” that will want to control who you share things with and users that will end up frustrated because they will need to explain their sharing preferences to all the apps.

Sorry, I hope this will be more understandable. If not just ask again :))

If you want to share the file with your own UI you will need to modify .acl files to change the permissions. For that your app would need Control permissions.

Currently this means that the app gets full control over the pod and could also completely take it over, therefore (1) users should (and hopefully will) be more cautious giving these permissions and (2) your app should be safe and trustworthy. There’s also a possibility to grant apps permissions only per file/folder, but that is in an “experimental” status and will somehow change in the future.

So my advise would be that you don’t change the permissions yourself. Instead you forward the user to another app, where they can select what files they share with whom. For example, tell them to use the data browser (or Solid Share which is a PoC I’ve made that should work, but I don’t actively maintain it).

In your case this could mean:

  1. user 1 wants to share files with user 3 and 4
  2. your app tells user 1 how s_he can do that with another app
    2.1. tell the user the urls of the files
    2.2. tell the user the webIds
    2.3. tell the user to set the appropriate permissions (for databrowser, go to the containing folder → open the file → click on the sharing icon → set specific sharing → green plus → person → enter webId → drag person to desired permissions)
    2.4. wait until user is finished
  3. notify user 3 and 4 that they have access to the file

The advantages of this are:

  • no control access required for your app
  • user can share files with their preferred and trusted app
  • a sharing app could have a good UI for that, as it specializes on it

Disadvantages:

  • currently a bit inconvenient to change permissions with the databrowser (imo)
  • user has to leave the app

An alternative way would be to that the user grants permissions to a group file (list of persons). Then you could add or remove people from this group file and with that change who has access to the mp3 files. For that only Write is needed. But the user would still have to initially create these group files. (And probably has some more caveats)

In the future there possibly will be a standard way to request permissions for files. For instance the app could take a look at the user profile for a sharing-app, and then open this app in a popup with some queryParameters to indicate what you would want to share with whom. The user then can confirm it in the Sharing-App, close it and it’s done. That would be a much better UX in my opinion, hope it will come in the future :))

And of course you could also ask for Control permissions, which will probably be more user friendly in the short term. In the long term I think this will be the wrong solution

Tx for the clarification I think I understand the issue now.

From a UX point of view I find the idea of having to use a separate app to manage document sharing to be abhorrent quite frankly. If I was writing this as a traditional client/server app such a solution would not even enter the equation. And by the sounds of it there is no really good solution to this problem on the horizon. When I first started to read up on solid I had the impression this was one of the cornerstones - the ability to keep one’s own data private and choose what and with whom to share. But now it sounds like this cannot be done in a user friendly manner.

(From my perspective) Solid is still in the development phase with several rough edges, especially on the UX for non-tech people. And sure, Solid is about data ownership and having control about it, but the spec for this part is still not complete.

As mentioned before, fine grained control access could let an app modify permissions without possibly taking over the pod. This is also part of the current spec and actively worked on as the current Origin solution was only experimental and not 100% safe (imo at least). So from the spec side I am confident that it will be easier to do this in the future.

And even with the current status one could do several things. You can give persons different levels of access for specific files/folders, use groups to implement different user roles (or possibly create an “invite” link for sharing a file) and specify which apps you trust to work on your pod. Based on that you could already make a Sharing tool with a good UX and an API for other apps to request permissions. Which is already good, but sure, still some place for improvement :))

If you want, you can ask in the Gitter chats if they have a better solution to this issue. I think they have more discussions about the spec there and are more up to date with this. Not sure though

Yes I totally understand that we are still in development phase and there will be rough edges. And have no problem having to deal with the complicated aspects as they are at the moment. But at the same time would like to be secure in the knowledge that this issue will have a good resolution some time in the future before investing a whole load of time and effort into developing a Solid App.

I will check out the gitter chats so to see if I can find out more. In my mind an ideal solution would be that an app could be granted full control access to a designated container that can act as a sandbox somewhere on the user’s pod. This way the app has total control of who can access what within that container while keeping anything outside this container totally protected. But no idea if this would be something that is in line with the spec.

The solution you propose is pretty much the current spec: You can specify which apps can be used to work with a resource by adding it as a trustedApp. So you could create a /my-app/ folder and the user could grant you Control permissions for it.

But…

  • as pointed out in this thread, this currently can be bypassed by sending the authentication tokens to a server
  • it’s considered experimental in the spec and it’s just been pointed out once again that it will be updated
  • it’s not very Linked-Data and interoperability friendly to put every application into it’s own sandbox. A more linked data like approach to permissions could also be interesting imo (maybe permissions based on shapes? Idk if that makes sense, but something more into the direction of “access to my music” instead of “access to my music folder”)

So if you want you can give trustedApp a try, but from my perspective it’s only a short-term solution

@hughgearse You’ve identified a key pain point that the data interoperability panel is working on.

You can find a detailed breakdown of the problems we’re looking to solve here: https://github.com/solid/data-interoperability-panel/blob/master/problems-and-goals.md

We meet weekly (Mondays at 7:30PM UTC) - meeting minutes can be found here: https://github.com/solid/data-interoperability-panel/tree/master/meetings - all are welcome to join and contribute.

1 Like