Group deletion

[dmlls]

HI, first of all, thanks for this app, I've been using it for a while and works great!

I have two questions related to group deletion:

1. How can I delete a group? I couldn't find it anywhere on the UI.
2. How long are groups stored for? That is, if for example I didn't update a group for months, will it be automatically deleted eventually?

[scastiel]

Hi @dmlls, glad you like the app :)

About deletion, I assume you’re talking about actual deletion, not just removing it from the recent groups list? (Although that would be useful too).

For now there is no mechanism in place to delete the groups, but that would be a nice feature.

For automatic deletion, I guess I could implement something like deleting all data related to a group after one year without the group being accessed.

The only concern I have is that (by design) there is no user account and no email address, therefore I can’t send any warning or reminder about group deletion… Maybe a warning when creating the group (and maybe in the settings) would be enough for the users to be careful about it.

[dmlls]

About deletion, I assume you’re talking about actual deletion, not just removing it from the recent groups list? (Although that would be useful too).

Yes, I was thinking about actual deletion, but I guess it would also make sense to remove the group from recents once it's removed.

Maybe a warning when creating the group (and maybe in the settings) would be enough for the users to be careful about it.

This sounds sensible to me. Automatic deletion would probably also help you keep the database a bit tidier :)

[manuerwin]

Perhaps some kind of warning icon/note near a group to indicate it "will be auto-deleted soon"?
Prompting the user to export/download if needed?

[neonshobhit]

But there is no authentication. If someone randomly opens a group, can delete a lot of data which might not be intended.

[dmlls]

@neonshobhit If a malicious actor gets access to a group, the group is pretty much "done", with or without this feature (e.g. they could simply delete all transactions or edit them maliciously).

In order to mitigate brute force attacks, group ids are generated randomly, contain letters, numbers and symbols, and are long enough. It's basically like trying to brute force a password.

If hypothetically they still got the group id by other means, what @manuerwin proposed in #9 (comment) would also mitigate malicious deletions, since the legitimate group members could revert the deletion before it's completed. Furthermore, if #34 gets implemented, the group members could then set a password for the group to make sure the malicious actors can no longer access it (or change the password, in case they had previously set it).

[neonshobhit]

@dmlls

It's basically like trying to brute force a password.

Not exactly like trying to brute force a password. Passwords are hashes of a string generally. If any character mismatches, you can't access particular password.
But here, I can still brute force for a existing groupId. When scales, probability of getting one groupId randomly increases as there will be lot of groupIds.

since the legitimate group members could revert the deletion before it's completed.
We don't have emailIds, so communication with legitimate group owners is still hard.

Sure, #34 works. Just that sharing passwords in urls can still be logged somewhere or malicious people can read it over the network. Blast radius will be very small though. If this is a calculated risk we are okay taking, I can resolve #34 after I'll be done with #5.

[quinncomendant]

Deleting groups, and auto-deleting after one year of inactivity are both reasonable features. I just learned about Spliit and created a couple test groups just to try it out. I'm sure a significant portion of all the groups in the database at spliit.app are just tests. :)

[UnlimitedCookies]

I think some feature like this would be required for spliit to be GDPR-compliant.