What prevent a malicious pod browser (or any app) to sneak/delete/corrupt all my data?

After several experimentation with Solid, I think I missed something

A pod browser usually need full permission (control included) to manage my pod

If I give these permissions, the pod browser can do everything it wants, including sneaking my data to some bad actor, or encrypting it then asking some ransom

But if I don’t, the pod browser is not usable

Is there something in between this “all or nothing” situation?
A way to give full access to an app only for specific folder?
A way to ask user to validate before doing some critical action?
I can’t find anything like that

(This is related to this another question of mine : Bootstrapping a shared folder from an app without giving all access to this app)

2 Likes

My understanding, is that there is work being done on using webids for apps. Once that happens, we can make more specific statements such as

 **<webidOfappX>
    acl:accessTo <ContainerY> ;  
    acl:mode acl:Control .

Hopefully, there will also be a GUI that an app could call requesting user permission to grant those more specific rights.

2 Likes

I should also point out that giving an app control ONLY works if the person who is logged in with it also has control. So if I have a folder that only I can access, regardless of how trusted the App is, only I can access that folder. Both app and user permission are required to access a resource. So when your bad App tries to do something, it will only succeed for portions of your pod that you have made accessible to all users as well as to the App.

2 Likes

That would be interesting!
Could you point me some resources about that?

The solid-oidc authentication protocol incorporates client identifiers. Essentially, a client identifier provides added context allowing authorization at the pod to evaluate both the agent (e.g. Alice), and the client they are using (e.g. Acme App).

3 Likes

Thank you for the pointer @justin

1 Like