Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Comments on Allow completely pseudonymous user accounts
Parent
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:
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 userN 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 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 or Workplace 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.
Post
Yes, please!
I think this is a great idea. Generally, I think requiring email verification is dumb. For this site it's doubly so. You did a great job enumerating all the reasons and I agree with them all.
The biggest one is removing barrier to entry. Arguably the biggest problem of this site right now is having few users. It's obvious how this will address that directly. Moreover, during StackOverflow's early period of explosive growth, lots of people used this feature. It helped fuel that growth by allowing people to "try out" the community for just one or two questions.
In the industry, there's an idea that trial accounts should get a lot of information to maximize commitment, so that users customers are retained due to the sunk cost fallacy ("I already did all the work of verifying my account, might as well use it"). And of course, you can use that info to nag them later. For CD that doesn't make sense. Firstly CD doesn't spam. Second, I think the corps do it not so much for the spamming, but so they can have a side income from selling that contact info to advertisers - not really a viable (or desirable!) path for CD. A lot of people know this practice and get suspicious about insignificant accounts that demand excessive personal information or verification.
Besides the excellent privacy/safety related points you brought up, I think it should be possible to have a different identity on every site. It's kind of disturbing how you can look up a StackOverflow profile, then see what they post about on workplace, religious sections, politics, personal finance, legal, interpersonal... Anyone who is active on multiple Stack sites is punished by becoming a juicy target for stalking. I get seeing a post about coding and wanting to see what other coding stuff they talk about. But I see no benefit whatsoever to linking activity between sites. People should be able to opt out of that. You can DIY it by just creating a sockpuppet for each site, but for non-tech savvy people (who are also the ones who are at greater risk for cyberstalking) it's hard to make alt accounts. Remember, all the big email providers these days require phone verification, and allow only one account per phone number.
The most common concern is that without the email, spammers will make millions of accounts and post ads. IMO this doesn't hold water in 2024:
- You can limit how many accounts an IP can create, filtering out the majority of spammers without a private VPN or botnet
- New accounts are already reviewed more closely
- When spammers make many accounts, the patterns are usually very obvious (usernames similar, similar origin IPs, similar creation time, quickly makes a few posts and all get downvoted with similar flags)
- A serious spammer can easily obtain throwaway emails
On the internet, the bad guys are more competent than the average innocent user and email verification is a fig leaf without a domain whitelist, aka "Oh, you don't use Gmail? Screw you!".
Moving on now from "should we do it?" (absolutely!) to "how should we do it?":
If you'll pardon the criticism, I think your question is a bit confusing because you've mixed the problem description with your own proposal for a solution. IMHO it would be better if you posted your solution as a self answer, and edited your question to merely advocate for allowing it without explaining how. In any case, I think we can simplify the solution further:
The account creation form can ask for username, display name, password, and email. The email is optional. Display name is mandatory but a random one like user36287483 appears as a suggestion (centralizing the pattern of throwaways improves user privacy). The username is not seen by any other user. As an example, Reddit allowed this (at least until recently, dunno if they'll change it after the IPO) and they seemed able to control the spam problem with a very small staff.
For the retrofit, I recommend:
- Create new DB column
usernameand pre-fill with email - Modify signup/login/etc forms in the frontend; add a note like "if you created your account before Mar 23, 2024 use email as your username".
- Modify auth code in backend to check
usernameandpasswordcolumns instead ofemailandpasswordcolumns - In all code paths that send email, ensure that it handles invalid emails gracefully (if it doesn't already)
2 comment threads