User account: Privacy page - delete account [UI]

[techtolentino]

Design file here

Notes / design needs

• what does user see after deleting account? (i.e., confirmation modal?)
• are they redirected to login page?
• is account deleted instantly? does it take some time?
• is the user emailed, regarding account deletion?

Related to Qiskit/qiskit.org#270 , https://github.com/Qiskit/platypus/issues/264

[techtolentino]

@JRussellHuffman - similar here, please see the design needs from above; we need to know what the user might see/experience when deleting their account...

Thanks

[JRussellHuffman]

I copied over the interactions here into the MVP figma page that hopefully answers most of this.

1. After deleting, they are shown a modal with confirmation (or error, if there was one)
2. redirected to either the login page or the qiskit.org home page. I'm inclined to say the qiskit.org home page because they will no longer have an account to login with on the login screen. But I'm open to discussion.
3. Is there a legal requirement here? I don't think it legally needs to be instant, and I like the idea of letting them undo it or change their mind, if it was deleted in error. I would recommend deleting it after mayeb 48 hours, but I don't have any data t back that number up. This could tie in to the next point about email
4. Yes I think we should email them. If we don't delete the account instantly, that email can include a message about "didn't meant to delete your account? Undo it here", which cancels the deletion. If the deletion is instant, I think a courtesy email still makes sense.

Adding @lerongil, do you have any thoughts regarding deletion and if we should email them?

[techtolentino]

@JRussellHuffman Notes on account deletion:

• it's best practice to require a user to type in some sort of string, for confirmation (e.g. "CONFIRM")
• how should we delete certain parts of the data, because of export regulations

[JRussellHuffman]

Do we have an idea of what certain parts of the data need to be deletable? If not, we could use a generic pattern like this:

"select all" would effectively be the same as deleting the entire account.

[Tansito]

The data that we would store for a standard user:

{
    "_id" : ObjectId("xxxxxxxxxxxxxxxxxxxxxxxx"),
    "email" : "user@email.com",
    "previousEmails" : [],
    "firstName" : "David",
    "lastName" : "García Valiñas",
    "type" : "student",
    "country" : "US",
    "picture" : "",
    "oAuthTokens" : [ 
        "ibm:XXXXXXXXXX"
    ],
    "createdAt" : ISODate("2021-12-14T14:19:27.818Z"),
    "updatedAt" : ISODate("2022-01-17T15:50:15.987Z"),
    "__v" : 0,
    "lastOnline" : ISODate("2022-01-17T00:00:00.000Z")
}

Apart from that a user has a relationship with loginanalytics, progress and session. Tables that store when the user makes a login acction, the progression of the user in the different courses and the session of the user respectively.

If a user wants to delete its account the current logic marks that user with a new param called deletionRequested to true and 7 days after he requests his deletion ONLY the data from user is deleted but the data from loginanalytics, progress and session continues being there.

@lerongil @pandasa123 @JRussellHuffman I hope this information can help us to advance in the GDPR to understand if we are going to need to modify something or this is enough.

PD: additionally but not directly related with the account deletion it seems that if the user doesn't login in the application in 5 years the user is deleted from the database following the same logic as I explained before.

[JRussellHuffman]

Let me make sure I understand. Everything in the json above is the user material, but not loginanalytics, progress and session, right? The discussion is about deleting certain parts of the data. Would they be able to delete some material without user, or just the entire thing? And would we need to surface the loginanalytics, progress and sessiondata to be deleted as well?

Because we have such little information on the user, I find it surprising that we should let them delete just certain part of the data. If we are legally required to let them delete individual pieces of data, then let's do what we are legally required to do. From a UX perspective, it's going to be a bit strange no matter how we do it (if i'm understanding the above correctly).

[pandasa123]

We could do deletion by overwriting PII with junk data. Retain the userId and the non-PII attributes (email domain, type, creation date, etc) so loginAnalytics, progress, and session are preserved with context

@Tansito I think the user object would need a few more attributes once we ship onboarding questions

[Tansito]

Answering some questions from @JRussellHuffman :

Let me make sure I understand. Everything in the json above is the user material, but not loginanalytics, progress and session, right?

Yes, those tables have their own structure but what it's important for this discussion I think is that they have a relation with the user through the userId, basically.

The discussion is about deleting certain parts of the data. Would they be able to delete some material without user, or just the entire thing?

Taking account the current logic only the user is deleted, the data from the table described above, nothing more.

And would we need to surface the loginanalytics, progress and sessiondata to be deleted as well?

In those tables we are not storing personal or sensitive data so initially I would say no but I'm not sure. Something to confirm with legal I suppose.

And answering @pandasa123 too:

We could do deletion by overwriting PII with junk data. Retain the userId and the non-PII attributes (email domain, type, creation date, etc) so loginAnalytics, progress, and session are preserved with context

To be honest I never thought on that solution but if it's valid we can totally go for it, really interesting.

@Tansito I think the user object would need a few more attributes once we ship onboarding questions

Good to know, we didn't see this info. The current data that we are managing is the basic structure that Mathigon provides us. I didn't see yet how we can extend it but we will find a way, thanks Sanket to point it!

[JRussellHuffman]

Thanks for the super thorough response @Tansito. Given all of the discussion, what items do you recommend the user be able to individually delete? I can mock up a screen that shows those individual items as deletable.

[Tansito]

Confirm this @pandasa123 but from my experience I don't think we should let the user select what it's going to be deleted, we should delete the information that GDPR requires. What I would do is go to legal with this info (plus the additional fields that are not added yet) and confirm what data should be removed if the user wants to delete his account and in what time should be that processed (I suppose that not all the data is required).

Another good point to clarify with legal is if we can do the idea from @pandasa123 to replace user info with mock-data, I never did that and I don't know if it's possible but good to know.

[JRussellHuffman]

Updated the desigs to include the "type delete" pattern, which can be found here: https://www.figma.com/file/SOnOgCGQIWx4oAlSFhIsIX/1972-User-account?node-id=2404%3A8709

Carbon has specifications for this pattern here: https://www.carbondesignsystem.com/community/patterns/remove-pattern/. The only issue I see is that the primary button requires a disabled state, which I"m not sure we have. I'm open to discussing the text or anything else here.

screenshot:

[Tansito]

Confirmed with @pandasa123 we will try to go with the junk data approach for the deletion process. Trying to obtain information from IQX about how they did it in case we can obtain interesting information.