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

Delete all shared data #40

Open
LGro opened this issue May 25, 2024 · 4 comments
Open

Delete all shared data #40

LGro opened this issue May 25, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@LGro
Copy link
Owner

LGro commented May 25, 2024

As a user I'd like to delete every bit of information I control (i.e. all DHT records I have written any of my contact details or location infos to) and with that stop sharing to anyone. This is the equivalent of deleting a coagulate "account".

@LGro LGro added the enhancement New feature or request label May 25, 2024
@Skivling
Copy link

Would it make sense to send a message to all contacts to tell them to delete your data, or is this just to stop sharing and updating it?

@LGro
Copy link
Owner Author

LGro commented May 26, 2024

Thanks a lot for your input ☺️

To me there are the following concerns more broadly:

  • When a user would request deletion of their data from a contact's device
    • we can't technically guarantee that to be successful, so I'd like to do some expectation management here and rather not suggest we can do it
    • it might mean that we delete the user's contact information from the contact's address book, which feels quite invasive but might help in cases of abuse (Protect users from stalking and abuse #26)
  • I'd like a silent option for stopping to share / requesting deletion where the contact does not get notified, in case the user fears repercussions (Protect users from stalking and abuse #26)

So I could see one option, like you mention, where a user requests deletion knowing that it is but a request, the contact gets notified and can choose to comply. Whether to offer this alongside other ways to disconnect or pick one hopefully sane default behaviour, I'm unsure.
What's your take on the above mentioned concerns?

@Skivling
Copy link

I think the request is good if it can be marked as such. But maybe the basic info like name, phone number, email etc shouldn't be deleted and things like this shouldn't delete things from the contact's address book. But I think it's reasonable to send a deletion for location data and other things that would usually not be kept in the device address book. Especially like an address, if I was disconnecting from someone, I probably don't want them to continue to know where I live. No guarantees that it actually deletes or they haven't saved it somewhere else though.

A silent option would definitely be the most important, and maybe makes sense as the only option. For someone who doesn't have stalking or abuse problems, it would still be useful to be able to be silent. Imagine you have a few friends from a couple years ago and don't want to send info to them anymore. If I was disconnecting in that situation, I wouldn't want them to be notified.

I'm also imagining a dialogue screen where it's like:
'Would you like to disconnect from ? You will stop sending (and receiving??) contact [and location (if applicable)] information, and <first_name> won't be notified about your disconnection.'

Stopping sharing is essentially the best way to do this, and there also can't be any status info like 'last updated 2 days ago' otherwise people would notice.

@LGro
Copy link
Owner Author

LGro commented May 27, 2024

Loads of good stuff in there.

It seems like we have three major aspects here:

  • extent of remote deletion
  • how silent is which way of stopping to share / deleting
  • do I want to remove my (encrypted) data from the DHT

I agree that current and future temporary locations (check-ins, journeys) should be removed whenever any kind of stopping to share happens. Locations from the past are anyway already removed whenever an update is written to the DHT. Whether post addresses from the contact details (they are treated as part of the address book entry right now) should be removed/removable while other details like email and number remain, I'm still not sure. My current impression is that the cleaner and easier to understand option is to just allow stop sharing contact details updates, at least in a scenario where one wants to do it silently.

  • TODO: We need to ensure that removal of temporary locations (check-ins and journeys) are not listed on the updates page of a receiving contact

The bit about how easy it is for someone to find out whether a contact has stopped sharing is interesting. If we want to technically guarantee that my contact can't figure out that I have stopped sharing updates, I need to leave the DHT record in place untouched. That's nice from a silent stopping perspective, but not so nice in terms of keeping only the minimum required data on the DHT (for security not storage concerns). However, I also don't want to explain to users what a DHT is, and why they could potentially have their data deleted from there but not their contact's address book. So maybe scrapping the DHT data is only happening when someone deletes all data in preparation for stopping to use Coagulate in the spirit of this original issue #40.

Somewhat related, I was thinking to include a "last successful lookup of the DHT record" kind of timestamp for each contact to signal a user that in case their contact shares new updates with them they would receive them. Especially in a P2P setting, where unexpected stuff might go wrong with (re-hydrating) DHT records, this seems valuable to me. To get that together with the aforementioned silent aspect, would mean that DHT records are never intentionally fully deleted unless one wants to explicitly make sure that no (encrypted) personal data remains on the DHT, accepting that contacts could notice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants