Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deleted account tombstone #72

Open
kjetilk opened this issue Oct 12, 2018 · 8 comments
Open

Deleted account tombstone #72

kjetilk opened this issue Oct 12, 2018 · 8 comments

Comments

@kjetilk
Copy link
Contributor

kjetilk commented Oct 12, 2018

To complete solid/solid#14, we need to record what to do with incoming requests after deletion. At the very least, we should make sure that nobody gets the same URI so that they can impersonate the former account owner.

As noted there, we should respond with 410 if nothing else has been recorded, but even better is it to allow users to register their new home and do a 301. At the very least, their new WebID should be saved.

I thought about using the old .htaccess format for this, that we just dump such a file in the former home dir of the user.

@dmitrizagidulin
Copy link
Member

Another option would be to delete everything in the user's account dir, and then add a tombstone root .acl (and we can add an appropriate triple etc).

The way that the account creation API currently checks if an account already exists is - it looks for the presence of the root .acl file. So I figure, we might as well reuse that mechanism for the 410?

@dmitrizagidulin dmitrizagidulin changed the title Deleted account thombstone Deleted account tombstone Oct 15, 2018
@kjetilk
Copy link
Contributor Author

kjetilk commented Sep 25, 2019

I think we should transfer this issue to specification, anyone opposed?

@dmitrizagidulin
Copy link
Member

@kjetilk +1, let's do it. (re transfer this issue)

@kjetilk kjetilk transferred this issue from nodeSolidServer/node-solid-server Sep 25, 2019
@csarven
Copy link
Member

csarven commented Oct 2, 2019

This issue should crosscheck with:
#103 (general case)
#46 (reuse)
#14 (privacy)
#41 (delete)
#61 (memento)

@brownhoward
Copy link

brownhoward commented Jun 1, 2020

It might be good to have an override for this functionality to allow the WebID can be reused. If a Pod got corrupted, sometimes the easiest approach to fixing it is to delete the Pod and immediately create a new one using the same WebID. Maybe have a "Pod reset" option?

@csarven
Copy link
Member

csarven commented Aug 14, 2020

A resource server doesn't have knowledge of accounts eg. a WebID URL is an RDF source like all other RDF sources. Whether a deleted account is associated with a WebID can be reusable or not is something should be up to an identity provider. We don't have an interface to help indicate that a deleted account's resources should return a particular status message or a provenance record. If that becomes available, when requesting to access a deleted WebID URL, implementations can potentially mirror identity provider's intention, promise, or what's possible eg. 4xx, 3xx, or something else. I suggest to leave the specific status code or marking an account as "tombstone" to implementations to their discretion - same decision made for all resources: #103 ie. 410 is optional (falling back on RFC 7231). In that view, by default WebIDs can reused provided that URI persistence is taken into account.

@TallTed
Copy link
Contributor

TallTed commented Nov 18, 2020

I think it's worth noting on this topic that existing social networking sites tend to have "sunset", "grace", and/or "purge" terms for terminated/"deleted" accounts.

For a period of time (typically, a year or so), actions trying to interact with the terminated account receive an appropriate error message, and no-one is allowed to assume that account's identifier (typically, a simple username). Some sites also preserve the terminating user's data for this defined period. Some sites allow the original user to revive the account and, if preserved, restore that data, during the same period.

At the end of such a grace period, any preserved data is generally purged. Typically at the same time, but sometimes after an additional waiting period, the username is "freed", and another user can adopt it.

I don't see any long-term viable reason why Solid should follow a different path, even with the oft cited but impossible to deliver credo that "A given URI always refers to the same referent, and should/can not be reused to refer to a different referent, forever and ever." Just considering the temporality of domain registrations, at some future date "github.com", for instance, could be taken over by a new registrant, and all the users now identified by such gems as https://github.com/TallTed could find those URIs now point to other entities than today.

@elf-pavlik
Copy link
Member

Just considering the temporality of domain registrations, at some future date "github.com", for instance, could be taken over by a new registrant, and all the users now identified by such gems as https://github.com/TallTed could find those URIs now point to other entities than today.

I think this on itself should be enough of the reason for not taking it for granted that any given WebID, currently by definition HTTP(S), stays under control of the same actor. We can encourage some best practices while staying realistic that this can happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: To Do
Specification
  
To Do
Development

No branches or pull requests

6 participants