Loss of Control Mitigation

[kjetilk]

As noted in #58 , we need a strategy to address the situation where a user is locked out from their pod through errors in the ACL. This can occur in several situation, e.g. syntax error in ACL files, that users pass end up not granting control permission to any agent, etc.

We have server-side validation to mitigate the former, and we have discussed introducing the concept of an agent that is understood to be the "owner", to mitigate other situations. We should have a more general discussion on it.

[dmitrizagidulin]

In addition to missing or malformed ACL resources (especially the root storage ACL), loss of control (user being "locked out" of their account or storage space) can also occur from the deletion of several important resources:

• Deletion of the WebID Profile document (prevents the user from being able to authenticate)
• Modification of the WebID Profile doc to remove a few key triples (location of storage, and authentication-related triples)
• Deletion of the root .meta resource. (This one's weird, but we currently store the recovery email for a user's account in the root /.meta resource. Not sure how that came about, but we should probably change that.) - renders the user unable to change their password etc.

[kjetilk]

@justinwb has somet thoughts on how to use meta resources (#102) to address this.

[csarven]

re critical changes to the WebID Profile description:

Modification of the WebID Profile doc to remove a few key triples (location of storage, and authentication-related triples)

We may need the notion of "update-only properties" ie. clients are only allowed to update the object of a statement, but never remove the statement or the subject-predicate pair(s).

"update-only properties" is clearly different than than how "server-managed properties" are handled as well as what "write-once properties" (as LDP calls it).

[gibsonf1]

Concerns as a Pod service provider:

It should be impossible for the user to compromise their account functionality in any way with the exception of an intentional account deletion.

To that end, there are several triples that the system requires and user should not be able to modify in any way. Some examples are:

<https://frederick.trinpod.us/@>  
    solid:account <https://frederick.trinpod.us/> ;
    solid:oidcIssuer "https://trinpod.us"^^<xsd:string> ;
    solid:privateTypeIndex frederick:t_72 ;
    solid:publicTypeIndex frederick:t_6x ;
    space:preferencesFile frederick:t_8d ;
    space:storage <https://frederick.trinpod.us/> ...

I think state level permissions are needed to solve problems like system vs user data on the same resource, where a state is a uri representing a triple.

Additionally, system level containers like / /inbox /profile etc should also not be modifable by the user. Our work around for this is adding a system control acl to required containers and disallowing any user changes to those containers.

[RubenVerborgh]

To that end, there are several triples that the system requires and user should not be able to modify in any way.

Note that this is only one possible solution (and an undesirable one, as I want the ability to switch OIDC providers).
Other solutions exist; some within LDP, some outside.

[gibsonf1]

Ruben,

So you are objecting to the one triple about solid:oidcIssuer, not the others and the general concept about protecting system triples from user editing?

[RubenVerborgh]

Objecting to all; that was just an example. There are good reasons to change any of those.

We need to understand that automatically determining which triples lock a user out is an intractable problem; assuming the existence of any solution in that direction is a fallacy.

[gibsonf1]

Ruben,

I guess I'm missing how these triples have any meaning outside of a specific system and why a user would ever want to change them? :

<https://frederick.trinpod.us/@>  
    solid:account <https://frederick.trinpod.us/> ;
    solid:privateTypeIndex frederick:t_72 ;
    solid:publicTypeIndex frederick:t_6x ;
    space:preferencesFile frederick:t_8d ;
    space:storage <https://frederick.trinpod.us/> ...

These define a specific Pod in a specific system. The user, if they want to move their pod to another provider, the other provider would have different values for these woudnt' they? So the user has no role in them unless I'm missing something?

I would envision an import process to move a pod from one provider to another, where the new provider would change system triples if/as needed.

[RubenVerborgh]

I guess I'm missing how these triples have any meaning outside of a specific system

They do:

<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/solid/terms#oidcIssuer> <https://drive.verborgh.org> .
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/solid/terms#publicTypeIndex> <https://drive.verborgh.org/settings/publicTypeIndex.ttl> .
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/solid/terms#privateTypeIndex> <https://drive.verborgh.org/settings/privateTypeIndex.ttl>
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/pim/space#preferencesFile> <https://drive.verborgh.org/settings/prefs.ttl> .
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/pim/space#storage> <https://drive.verborgh.org/> .

source: https://ruben.verborgh.org/profile/

Spans the systems https://ruben.verborgh.org/ and https://drive.verborgh.org/.

These define a specific Pod in a specific system

They would if identity and storage were tied. As my example above shows, they are not.

[gibsonf1]

I don't list the OIDC triple in the last example set as you have a good point on that, the others are my question now.

[RubenVerborgh]

Same answer.

<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/pim/space#storage> <https://drive.verborgh.org/> .

means: I (https://ruben.verborgh.org/profile/#me) use as storage (http://www.w3.org/ns/pim/space#storage) the space at https://drive.verborgh.org/.

Tomorrow I might (literally) change that to https://css.verborgh.org/.

[gibsonf1]

Those triples are stored in drive.verborgh.org. So to change them, it means they are being stored somewhere else, and my point is the somewhere else system should be changing them as needed on import - normal non-geek users could never handle that sort of thing, and why should they - those are a function of the system hosting the pod.

[RubenVerborgh]

Those triples are stored in drive.verborgh.org.

They are not.

somewhere else system should be changing them as needed on import

They are not moving.

[gibsonf1]

Ruben,

Could you explain the context of those triples, where they are, what the use case is?

[RubenVerborgh]

As I wrote above, I have multiple Solid spaces.

The triples are stored on ruben.verborgh.org.
They currently point to drive.verborgh.org as storage.

I need the ability to change my preferred storage location to anywhere I want. In fact, it so happens that I have just set up https://css.verborgh.org/ as a new pod today. So I might literally change that triple tomorrow.

Hence, we cannot prevent people from changing such triples, as valid use cases exist.

[gibsonf1]

So what you're talking about is a sort of Pod dashboard index if you will, that dispatches as needed to different things. Basically a config file. But in the production world of mass users, if you had such a system to dispatch on demand to different pods, it would also not be user editing of turtle but automated system configuration.

[RubenVerborgh]

it would also not be user editing of turtle but automated system configuration.

Exactly. So that system needs to be able to; hence, we must not prevent modification of such triples.

Hence, users can lock themselves out. It's not a problem we can solve on the triple level.

[gibsonf1]

For TrinPod, we will be preventing users from destroying their pods as if they destroy their pod, they would be pretty mad at us about the fact that they inadvertently could. So we will put acls on states/triples that should not change inside their pod. Your case is a very different scenario and not inside a specific pod.

[RubenVerborgh]

That's all fine; just not something we want in Solid in general.

[gibsonf1]

No worries, I guess we will differentiate ourselves by users not having their pods corrupted by accident.

[RubenVerborgh]

But at the same time also not giving them the option to use external storage. That's fine; it's a trade-off.
With great power comes great responsibility.

And as I wrote, other mechanisms exist. Allowing changes to those triples and non-corruptible pods are not mutually exclusive.

[gibsonf1]

Our app will support any Solid Pod service (other storage), I'm just talking about the user that chooses us as storage, and not wanting to let them mistakenly mess it up. So I guess I don't see how we reduce any user options - they can not use us for storage, they can use us and other providers and link them together through our app, etc

Ruben, I agree, I'm sure Pod providers will take their own measures to protect users from themselves as needed, even if spec does not require it.

[elf-pavlik]

Please correct me if I'm wrong but enforcing shape validation on WebID document would ensure presence of needed triples by defining it in the shape which the document would need to validate against.

To avoid deleting WebID document all together we may need a way to distinguish write between update and delete. Than disable delete access on WebID document. This would allow updating it, as long as it validates, but not deleting it.

EDIT: You can find example of such shape in https://solid.github.io/data-interoperability-panel/specification/#shexAgent