Allow users to close their accounts and remove their username/profile

[RichardTaylor]

WhatDoTheyKnow users writing to us asking to close their accounts is becoming a notable fraction of support mail.

There may be an opportunity to reduce the administration workload by letting users themselves anonymise and close their accounts (the admin button for this operation was introduced via #3074 and https://github.com/mysociety/alaveteli/pull/4869).

There are a number of reasons though not to do this:

• Administrators currently ask users what they are seeking to achieve and act accordingly, for example sometimes unsubscribing from unwanted tracks is all that's needed to satisfy a user.
• We cannot automatically censor correspondence reliably to remove a user-name; if users contact us we can discuss and assess their needs and adjust the action we take accordingly.
• Some users who want to remove their name from the site change their mind after correspondence with the admin team who, where relevant, stress that making a FOI request is something positive, something to be proud of.

See also letting users unsubscribe from all email from the system: #4603

[garethrees]

Just copying @RichardTaylor's email here, as it provides good background insight for when we come to this issue:

Given the large number of requests to "close" accounts in the WhatDoTheyKnow support mailbox I thought I'd raise this issue.

As well as writing this email - which provides more background - I've started a ticket at:

https://github.com/mysociety/alaveteli/issues/5052

We don't currently let users close and anonymise their own accounts. The legal basis for this is we consider we're processing their information for our legitimate purposes - and are not doing so based on their consent. While we do change usernames and make our best efforts to remove names from correspondence we do so only after correspondence trying to deter users from wanting their name removed - stressing making a FOI request is generally something to be proud of.

We could automate that message - but I doubt it would have the same impact if it appeared in automated manner on a website, as it does when it comes in an email.

One issue with making the "close and anonymise" feature available to users would be that current the attempt by our system to remove names is poor - and usually it needs a human to look through and effectively redact PDFs, variations of names used etc.

All we could offer publicly is "close and attempt to anonymise"... (well we could offer other things to like username -> "name removed" and account suspension without affecting the content of correspondence; and also unsubscription from all emails (https://github.com/mysociety/alaveteli/issues/4603)

It's good to have a human admin look at the reasons for wanting an "account closure" and to take appropriate action - it may be all that's needed is unsubscription from tracks .. it may be that serious effort needs to go into effectively redacting many correspondence threads.

There's a chance enacting this feature might reduce the number of right to erasure requests too - which are an especially time consuming and annoying part of running the site.

[RichardTaylor]

Linking to: "Improve censor rules created by anonymise and close user account operation" #4922

[RichardTaylor]

Commenting to use the words self-service name / username removal to hopefully make this ticket easier to find.

[RichardTaylor]

Consider if following this process all requests by one user should still be collected together under one profile - such a collection of requests could aid re-identification of an individual. What's probably most important for an automated system is being clear what it does, and does not do.

[garethrees]

Should consider how to keep records of this happening. Currently we have a case ref for each manually handled RTE request.

[FOIMonkey]

+1 to this. Last year we handled 147 RtE requests from users, and only 57 from third parties. Allowing account closure would significantly reduce the admin burden of dealing with these requests.

If it couldn't be fully automated, I'd like to see it looking a bit like this. Taking you to a page that explained what happened if you closed the account - something akin to the standard offer, but without the need for an individual LIA (ignore the typo). Pressing the button could notify us of the user's intent, and send an acknowledgement. We could log the case at that point automatically. We can then sense check the request and press the button, which could also inform the user in the same way that hiding a SAR/personal correspondence does.

There could be a cooldown period to give the user a chance to change their mind. We could also split off C&A from just close, with a separate request process.

The more account closures we could deal with this way rather than having to treat as formal RtE cases, the easier things will be. A lot of users making RtE requests say that they have tried to find how to close their account before contacting us.

[garethrees]

Pressing the button could notify us of the user's intent, and send an acknowledgement. We could log the case at that point automatically. We can then sense check the request and press the button…

A structured form that generates a more-or-less one-click admin confirmation is a much better position than what we do now, and I think a great stepping stone to feel out any problems that we'd want to finesse before allowing the user to close their account themselves.

We could also split off C&A from just close, with a separate request process.

I think this would be a great move. In exploring RTE we've refined our understanding that there's a difference between the account name and name included in correspondence (more value in the latter wrt our legitimate interests). Closing would have the benefit of making it much trickier for a visitor to link someone's entire request history, while still preserving the full request content.

[mdeuk]

A structured form that generates a more-or-less one-click admin confirmation is a much better position than what we do now, and I think a great stepping stone to feel out any problems that we'd want to finesse before allowing the user to close their account themselves.

+1 on both close & anonymise and close options. There is some mechanics which would help us from a logging perspective that we can explore; but, the basic theory here is great.

I think, based on recent discussions, having an admin action the request is the best way to achieve what we are looking to do. This enables us to ensure a request is logged [^1], validated (e.g. sometimes there's things to check), a period of 'buyers remorse' is provided (e.g. we'll do $action-requested in $days time, unless you tell us otherwise[^2]), and that upon completion, any relevant censor rules, where applicable, are correctly enabled.

This is cheap, cheerful, and a significant improvement as it allows us to automate more of the processes.

In terms of buyers remorse - we want this to be as easy as possible for the user, but we know there is a risk of things not being understood well, or the user making the wrong request (perhaps they did want to anonymise, or actually do want to engage RtE in full). Having this period of time (which we could also call a cooling-off period) is a useful safeguard, both for the user, and for the support team. It is a useful 'value add' opportunity, with little actual time cost [^3].

[^1]: Yes, I know - I'm engaging in repetition here, but records are important - and it enables our transparency reporting to be generated 'on the fly'. There's automation for this, and we can potentially do more to build on this. 😃 [^2]: In essence, this would be an automated task which then workflows back to the team on the appropriate date. On WDTK, the Inbox Monster tool should be able to handle this. [^3]: I would envision it being a workflow of 'complete process on Alaveteli, click relevant closure option for case and an email pops out, automagically, on the relevant thread.

[HelenWDTK]

A structured form that generates a more-or-less one-click admin confirmation is a much better position than what we do now, and I think a great stepping stone to feel out any problems that we'd want to finesse before allowing the user to close their account themselves.

I've analysed support mail that we dealt with during 2022, and 77.5% of threads in the inbox involving RtE requests arrived via our current contact form. There is a great opportunity here to set out the options to users before they get in touch, which could significantly reduce our workload in dealing with these.