Post History

Allow completely pseudonymous user accounts

(I realize that this proposal might ruffle some feathers. Please read through it in full before knee-jerk voting. Also, I use "anonymous" in the proposal text for simplicity, but it would really be more *pseudonymous* than anonymous.)

One part to the EU/UK GDPR is that personal data must be *necessary*. (This is sometimes referred to as the data minimization requirement.) This is codified in [GDPR article 5 section 1.c](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN#art_5):

> Personal data shall be: (...) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’)

Aside from legal requirements, I would argue that not keeping more data (especially but not exclusively personal data) than actually *necessary* is worthwhile in itself. Organizations change; data breaches occur; software bugs happen. The best-protected PII is that which isn't ever seen or stored.

Currently, Codidact requires an email address to sign up; and the email address is used as the primary account identifier for sign-in purposes.

**I propose to remove the requirement for an email address.**

I can hear the "wait, what?!" already. Surely a unique identifier is needed?

Well, yes. But that doesn't mean that the unique identifier needs to be an email address, or that an email address is necessarily the best choice for such a unique identifier.

 * An email address isn't necessarily limited to one person. It's not entirely uncommon even these days for a family to have a shared account (although the practice *has* become less common with phones effectively forcing users to sign up for an email account in order to use the phone).
 * A vulnerable person in particular might not feel comfortable divulging their email address, even if that is the only piece of PII that is being asked of them.
 * One person can have any number of email addresses. For someone who knows how, it's fairly trivial to set up a throwaway email account which cannot readily be traced back to a person, use that during the sign-up process, and then throw away the password.

Suppose instead that during the sign-up process, the person signing up can choose one of two methods of doing so:

 * Sign up with an email address
 * Sign up anonymously

(Again: I use *anonymously* here, but it would actually be *pseudonymously*.)

Signing up with an email address would be the same as it is today. I'm not proposing any changes there.

Signing up anonymously would generate a random sign-in name; for example a GUID/UUID. *The user would be told to record this, as without it access to the account would be impossible.* They would also, just like today, be asked for a password; the display name could be generated, such as user*N* where *N* is the account ID once the account gets created.

**Since such an account does not have an email address,** there would necessarily be some differences in user experience post-signup.

**Signing in** currently asks for an email address and a password; this would need to be **generalized** slightly to asking for an account identifier, whether that is this GUID/UUID, email address, or something else. Whatever is used here should not be exposed anywhere else; a random person on the Internet shouldn't be able to try to sign in as someone by entering `@123` (where 123 is the publicly visible account ID) in the account identifier field, for example.

**Email 2FA** obviously wouldn't work, since there's nowhere to send an email. **Email moderator message *notifications*** wouldn't work, again since there's nowhere to send the email. Same thing with **email subscriptions**. More generally, **anything that involves sending an email to the user would need to be blocked** but on-site notifications would still function as they do for anyone else. (TOTP 2FA would still work because that isn't tied to an email address in any way.)

**It lowers the barrier to creating an account.** This could be of interest for spammers, but quite frankly I don't think Codidact is seeing enough spam that this needs to be a major showstopper. Signing up without an email address could also require completing a CAPTCHA of some kind, re-raising the bar a bit. (Again, it's not like throwaway email addresses isn't a thing already, let alone for spammers.)

Still, some communities might want the slightly higher bar; so there should be a setting for communities to **disallow anonymous accounts from participating** on that community. I believe this can be done by simply not granting the [Participate ability](/abilities/everyone) on those communities. If this setting is turned on for a community and someone with an anonymous account visits that community, a top bar on the page could inform them of this; they would still be able to read (same as if they weren't signed in at all), but they wouldn't be able to interact with the community content in any way that is visible to other visitors.

**This would enable participating** (on willing communities) without Codidact ever seeing *any* PII for the user. In this day and age of data breaches, **I think this could be a differentiator** that sets Codidact apart from other, similar sites; perhaps *especially* so if communities like [Politics](https://proposals.codidact.com/posts/290755) or [Workplace](https://proposals.codidact.com/posts/290053) take off. There would be no need to trust that Codidact would safeguard one's PII effectively in perpetuity, because one never needs to share one's PII.

Also, **there should be a way to transition an account** between the two states; either adding an email address to one that doesn't have one, or removing the email address from an account that already has one.

I realize that this is a fairly big proposal, and it would probably need to be implemented in stages. I'm not proposing an implementation order, timeline or dependency graph of any kind here; I'm proposing a goal.

Thoughts welcome.