Feature request: a "delete my account" button

[ldidry]

There should be a "delete my account" button that unsubscribe you from all lists and remove your account immediatly.

To protect that feature, Sympa could

1. asks for the user password
2. send a mail with a link containing a token

[qosobrin]

I totally agree with this feature.

[racke]

Sounds a good idea to me ... what would be the workflow if the user is logged in to the web interface already?

[ldidry]

Well, ask him/her to enter its password to confirm the action.

[ldidry]

I could use some advices on how to do that properly. See my message on sympa-developpers ML: https://listes.renater.fr/sympa/arc/sympa-developpers/2018-12/msg00003.html

Currently, there is only a web interface, asking for the password to confirm identity. I'll test it today.

[dverdin]

This is a very useful feature. However, it is wrong to restrict it to native authentication.
This feature is useful mainly in publicly available services, such as Framasoft, Riseup or Universalistes, where people use the service because they want to.
It should not be allowed in enterpises instances where people are subscribed to mailing list because it is part of their job.
Therefore, I think there should be a global control over the activation of this feature. An "on/off" parameter at the virtual host level.
I think also that it should not be based on the authentication mechanism for a lot of reasons:

1. some publicly available services, such as Universalistes, use SSO. Any instance run under Yunohost uses LDAP.
2. at the opposite, some enterpise services use native authentication, for their guests,
3. how to decide to enable / disable the service when using several authentication mechanisms, which is allowed by Sympa?
4. When somebody authenticates using SSO, an entry is added to the user_table. This is the main reason that seems to justify the restriction to native authentication because we can't prevent it and therefore the user would be re-provisionned if he authenticates. I don't think it is such a big deal. We could certainly prevent this entry to be added. It is not usefull anyway, as long as the user has no subscription and is not admin of any list.
5. Currently, the workflow seems to ask for a password confirmation before accepting the account deletion. this is possible with native authentication only. It should be replaced by sending a mail with a link to click to confirm. And a last confirmation on the web interface for good measure. this way, no need to restrict to native authentication.

Finally, I think we should restrict unsubscription to the lists where it is allowed, namely base unsubscription on the unsubscribe scenario, which is the standard mechanism for unsubscriptions. If you think it is unfair, then you probably should not allow to close owners unsubscription on your server in the first place (reminder: any scenario - like unsubscribe.closed - can be made unavailable by adding ".hidden" in the end of its name).

To sum up, this feature could be generalized by:

• allowing third party authentication,
• replace password confirmation by email confirmation,
• add control to the feature with:
  • a global parameter to enable / disable it
  • add control with the unsubscribe scenario.

OK. That's about it. What do you think?

[ldidry]

@dverdin I think it's good 👍

[ikedas]

I've wrote why this feature should be enabled only with native (user_table) authentication. See #511 (comment)

This is a very useful feature. However, it is wrong to restrict it to native authentication.
This feature is useful mainly in publicly available services, such as Framasoft, Riseup or Universalistes, where people use the service because they want to.
It should not be allowed in enterpises instances where people are subscribed to mailing list because it is part of their job.

I think of the services open to public, such as FramaListes, Slack etc., and focus on the control over personal data: Using those services naturally means leaving user's personal data (typically account information) in trust with these services. It is desirable that the users could control personal data of their own.

Conversely, it may not be allowed for the services (itself) dedicated to particular organization including universities, enterprise or other autonomous groups which manage personal data with their own policies by each.

Therefore, I think there should be a global control over the activation of this feature. An "on/off" parameter at the virtual host level.
I think also that it should not be based on the authentication mechanism for a lot of reasons:

1. some publicly available services, such as Universalistes, use SSO. Any instance run under Yunohost uses LDAP.
2. at the opposite, some enterpise services use native authentication, for their guests,
3. how to decide to enable / disable the service when using several authentication mechanisms, which is allowed by Sympa?

By reason I wrote in above, I agree to add an option to activate/deactivate this feature, while I still think that identity sources not controllable by Sympa should be excluded.

4. When somebody authenticates using SSO, an entry is added to the user_table. This is the main reason that seems to justify the restriction to native authentication because we can't prevent it and therefore the user would be re-provisionned if he authenticates. I don't think it is such a big deal. We could certainly prevent this entry to be added. It is not usefull anyway, as long as the user has no subscription and is not admin of any list.

I think this behavior is a fault of design. Using user_table as cache of information about authenticated users might cause leakage of personal data beyond the different identity sources (You can see similar problem on #347).

I think information about authenticated users should be kept in volatile web session and should not be stored in any persistent spaces such as user_table without permission by the user themselves (I want to submit PR in near future).

5. Currently, the workflow seems to ask for a password confirmation before accepting the account deletion. this is possible with native authentication only. It should be replaced by sending a mail with a link to click to confirm. And a last confirmation on the web interface for good measure. this way, no need to restrict to native authentication.

By the reasons above, I disagree to this suggestion.

Finally, I think we should restrict unsubscription to the lists where it is allowed, namely base unsubscription on the unsubscribe scenario, which is the standard mechanism for unsubscriptions. If you think it is unfair, then you probably should not allow to close owners unsubscription on your server in the first place (reminder: any scenario - like unsubscribe.closed - can be made unavailable by adding ".hidden" in the end of its name).

As I wrote in the comment at the beginning, this matters authorization instead of authentication.

• replace password confirmation by email confirmation,

I also don't agree to it.

---

Edit: Insertion.

[dverdin]

Hi Soji!

I think of the services open to public, such as FramaListes, Slack etc., and focus on the control over >personal data: Using those services naturally means leaving user's personal data (typically account >information) in trust with these services. It is desirable that the users could control personal data of >their own.

Conversely, it may not be allowed for the services (itself) dedicated to particular organization >including universities, enterprise or other autonomous groups which manage personal data with their >own policies by each.

Ok, so we have the same opinion.

1. When somebody authenticates using SSO, an entry is added to the user_table. This is the main reason that seems to justify the restriction to native authentication because we can't prevent it and therefore the user would be re-provisionned if he authenticates. I don't think it is such a big deal. We could certainly prevent this entry to be added. It is not usefull anyway, as long as the user has no subscription and is not admin of any list.

I think this behavior is a fault of design. Using user_table as cache of information about authenticated users might cause leakage of personal data beyond the different identity sources (You can see similar problem on #347).

I think information about authenticated users should be kept in volatile web session and should not be stored in any persistent spaces such as user_table without permission by the user themselves (I want to submit PR in near future).

Totally agreed!
It is what I suggested when writing "We could certainly prevent this entry to be added."

1. Currently, the workflow seems to ask for a password confirmation before accepting the account deletion. this is possible with native authentication only. It should be replaced by sending a mail with a link to click to confirm. And a last confirmation on the web interface for good measure. this way, no need to restrict to native authentication.

By the reasons above, I disagree to this suggestion.

I'm sorry, I don't see the reasons above that would lead to disagreement with this.

Finally, I think we should restrict unsubscription to the lists where it is allowed, namely base unsubscription on the unsubscribe scenario, which is the standard mechanism for unsubscriptions. If you think it is unfair, then you probably should not allow to close owners unsubscription on your server in the first place (reminder: any scenario - like unsubscribe.closed - can be made unavailable by adding ".hidden" in the end of its name).

As I wrote in the comment at the beginning, this matters authorization instead of authentication.

Indeed. But it is a matter directly related to the current topic.
In the workflow used by @ldidry, the confirmation of account deletion is based on password. If the server uses external authentication, users don't have a Sympa-specific password.

That's why I suggest to use mail instead of password confirmation. In addition, it is also the usual mechanism in Sympa. I don't think we use password confirmation anywhere else. Which makes sense, as we never know which authentication mechanism will be used.

• replace password confirmation by email confirmation,

I also don't agree to it.

Edit: Insertion.

So we agree for everything, except allowing for third party authentication (the email confirmation is a consequence of it).

Anyone else having an opinion?

[ldidry]

Well, @dverdin, as you say, email confirmation allows users using external authentication process to delete their account. It sure will be better. The reason I used password is… that I don't know how to create email confirmation 😐

Using email confirmation will, as a bonus, simplify my code.

[ikedas]

@ldidry:

Using email confirmation will, as a bonus, simplify my code.

If dverdin's idea is adding another authentication with another factor (verifying possession of e-mail mailbox/account along with verifying knowledge of login password), it makes sense.

Notes:

• Why I suggested to add password verification is that removal of account is irreversable operation: User should be aware that they are truly willing to do it. Verifying password twice won't strengthen authentication by itself.
• e-mail confirmation itself is vulnerable authentication method and we should not rely only on it. Confirmation should be used along with another stronger authentication.

@dverdin, if you see I understood correctly, I'll agree to add e-mail confirmation (it may store a request into Sympa::Spool::Auth spool and authenticate it by Sympa::Request::Handler::auth handler). However, I'd like you to understand that the new feature will be available only with users authenticated by user_table by now.

And anyway, an option to activate/deactivate this feature looks required.

[ldidry]

e-mail confirmation itself is vulnerable authentication method

Well… you can ask to recover a lost password by mail, so asking for a password is not really a strong protection.

I mean, if an attacker has control of the mailbox of a user, he can ask for a new password, use the link in the password-recovery email, then delete the account with the new password.

[dverdin]

@ldidry:

Using email confirmation will, as a bonus, simplify my code.

If dverdin's idea is adding another authentication with another factor (verifying possession of e-mail mailbox/account along with verifying knowledge of login password), it makes sense.

Oh, no, I'm not that clever! ;-)
I just wanted to get rid of an unorthodox confirmation method to use the one usually employed in Sympa.

However, I understand that it is a very specific query that requires specific security.

Email confirmation is, indeed, the same level of security as password because you get or renew your email using the mailbox. So if you get access to the user's mailbox, its password can be considered lost. But as Soji said:

Verifying password twice won't strengthen authentication by itself

By asking for the password, he only wants the user to realize how important the operation he is doing is.
I think it is also a convenient way to prevent bad people to clear an account by simply finding an unlocked computer with an active Sympa session. A lot of systems do this: they use your current session until you ask for something private or drastic, then they ask for your password.

So the crucial part is not "how to check the user's identity." I think that web authentication plus email confirmation is indeed good enough to ensure that the person requesting the action is probably who he says he is.

The question would be : how to efficiently warn the user that he is about to delete all his subscriptions and list ownerships? Asking for a password works perfectly for native authentication. But it leaves the other authentication methods orphan, which is sad. I don't have the answer to this problem yet.
Genuinely, I would display large warning with red background. That kind of thing. Which won't work for people with sight problems.

[ikedas]

e-mail confirmation itself is vulnerable authentication method

Well… you can ask to recover a lost password by mail, so asking for a password is not really a strong protection.

I mean, if an attacker has control of the mailbox of a user, he can ask for a new password, use the link in the password-recovery email, then delete the account with the new password.

Indeed it's possible. From the beginning, e-mail don't have high secrecy: Transmission channels are often unencrypted; Accounts are occasionally shared among users; ....

Since e-mail confirmation is vulnerable, one measure is restricting its effective range, for example: Sending random tokens by each message to be moderated, instead of sending one token to approve all messages; Surely expiring outdated token; Using it in combination with the other authentication method; Not sending token without confirmation by user; and so on.

Currently, Sympa overuses e-mail confirmations (for example see #156). However, it doesn't mean that e-mail confirmation is the potent measure for authentication.

---

I suggest to release the next beta including PR #511, possiblly adding an option to activate/deactivate this feature. We would be better to begin with minimum feature.

[dverdin]

Since e-mail confirmation is vulnerable, one measure is restricting its effective range, for example: Sending random tokens by each message to be moderated, instead of sending one token to approve all messages; Surely expiring outdated token; Using it in combination with the other authentication method; Not sending token without confirmation by user; and so on.

Yes. e-mail confirmation must be focused on one precise action and limited in time. Like for one time tickets.

Currently, Sympa overuses e-mail confirmations (for example see #156). However, it doesn't mean that e-mail confirmation is the potent measure for authentication.

Maybe. Though honestly, we never had any problem with it.
But it is not a reason not to question the mechanism.

I suggest to release the next beta including PR #511, possiblly adding an option to activate/deactivate this feature. We would be better to begin with minimum feature.

Yes, the problem is deeper than expected. we need a bit of time to think it thoroughly.

[ldidry]

I suggest to release the next beta including PR #511, possiblly adding an option to activate/deactivate this feature. We would be better to begin with minimum feature.

Ok. I'll add an option, marked as "experimental", and disabled by default. I'll do it friday (my day dedicated to Sympa).

[ldidry]

Option added!

[ikedas]

Great job @ldidry!

[dverdin]

Very nice, Luc! Thanks!
As far as I'm concerned, this PR is as good as it could be. So I agree with its inclusion to 6.2.42.

[ilf]

Thanks for this issue and the implementation!

It's been two years, maybe we can finish the "experimental" phase.

I propose to enable this by default. Allowing users to delete their personal data is a legal requirement of the GDPR.

It it can't be enabled by default, I propose to add this at least to sympa.conf so admins are aware of it and can easily enable it.

Thanks, and keep up the good work!

[lucyferu]

one more year has passed and it's still not straightforward the possibility to delete your account. 😢

[racke]

one more year has passed and it's still not straightforward the possibility to delete your account. cry

You can delete your account when allow_account_deletion is enabled in the configuration.
It shouldn't be experimental any more though.