Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Post History

66%
+4 −1
Q&A Allow completely pseudonymous user accounts

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 t...

posted 2mo ago by matthewsnyder‭  ·  edited 2mo ago by matthewsnyder‭

Answer
#3: Post edited by user avatar matthewsnyder‭ · 2024-03-23T23:36:03Z (2 months ago)
removed secure id option, it doesn't work
  • **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 and end up with one of two auth models:
  • 1. When you create an account, you are given a `secret ID phrase` (eg. passphrase like `batt throneless reopened liquidated`). The login form does not ask for user/pass, just your key. Accounts get a randomly generated display name (like `user36287483`). The user can go into their profile and update their display name and/or email if they wish. As an example, Mullvad uses this model successfully.
  • 2. The account creation form asks 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 changed after the IPO) and they seemed able to control the spam problem with a very small staff.
  • I personally like (1) because if the username is secret then it's the same as a password, so you're effectively making people remember two passwords, but maybe that's my own programmer bias. (2) has the (dis?)advantage that both username and password can be chosen by the user, and it's a more common and familiar method.
  • For the retrofit, I recommend:
  • 1. Create new DB column `username` and pre-fill with email
  • 2. 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".
  • 3. Modify auth code in backend to check `username` and `password` (or just `secret_phrase`) columns instead of `email` and `password` columns
  • 4. In all code paths that send email, ensure that it handles invalid emails gracefully (if it doesn't already)
  • **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:
  • 1. Create new DB column `username` and pre-fill with email
  • 2. 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".
  • 3. Modify auth code in backend to check `username` and `password` columns instead of `email` and `password` columns
  • 4. In all code paths that send email, ensure that it handles invalid emails gracefully (if it doesn't already)
#2: Post edited by user avatar matthewsnyder‭ · 2024-03-23T22:47:05Z (2 months ago)
  • **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 and end up with one of two auth models:
  • 1. When you create an account, you are given a `secret ID phrase` (eg. passphrase like `batt throneless reopened liquidated`). The login form does not ask for user/pass, just your key. Accounts get a randomly generated display name (like `user36287483`). The user can go into their profile and update their display name and/or email if they wish. As an example, Mullvad uses this model successfully.
  • 2. The account creation form asks 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.
  • I personally like (1) because if the username is secret then it's the same as a password, so you're effectively making people remember two passwords, but maybe that's my own programmer bias. (2) has the (dis?)advantage that both username and password can be chosen by the user, and it's a more common and familiar method.
  • For the retrofit, I recommend:
  • 1. Create new DB column `username` and pre-fill with email
  • 2. 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".
  • 3. Modify auth code in backend to check `username` and `password` (or just `secret_phrase`) columns instead of `email` and `password` columns
  • 4. In all code paths that send email, ensure that it handles invalid emails gracefully (if it doesn't already)
  • **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 and end up with one of two auth models:
  • 1. When you create an account, you are given a `secret ID phrase` (eg. passphrase like `batt throneless reopened liquidated`). The login form does not ask for user/pass, just your key. Accounts get a randomly generated display name (like `user36287483`). The user can go into their profile and update their display name and/or email if they wish. As an example, Mullvad uses this model successfully.
  • 2. The account creation form asks 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 changed after the IPO) and they seemed able to control the spam problem with a very small staff.
  • I personally like (1) because if the username is secret then it's the same as a password, so you're effectively making people remember two passwords, but maybe that's my own programmer bias. (2) has the (dis?)advantage that both username and password can be chosen by the user, and it's a more common and familiar method.
  • For the retrofit, I recommend:
  • 1. Create new DB column `username` and pre-fill with email
  • 2. 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".
  • 3. Modify auth code in backend to check `username` and `password` (or just `secret_phrase`) columns instead of `email` and `password` columns
  • 4. In all code paths that send email, ensure that it handles invalid emails gracefully (if it doesn't already)
#1: Initial revision by user avatar matthewsnyder‭ · 2024-03-23T21:34:58Z (2 months ago)
**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 and end up with one of two auth models:

1. When you create an account, you are given a `secret ID phrase` (eg. passphrase like `batt throneless reopened liquidated`). The login form does not ask for user/pass, just your key. Accounts get a randomly generated display name (like `user36287483`). The user can go into their profile and update their display name and/or email if they wish. As an example, Mullvad uses this model successfully.
2. The account creation form asks 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.

I personally like (1) because if the username is secret then it's the same as a password, so you're effectively making people remember two passwords, but maybe that's my own programmer bias. (2) has the (dis?)advantage that both username and password can be chosen by the user, and it's a more common and familiar method.

For the retrofit, I recommend:

1. Create new DB column `username` and pre-fill with email
2. 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".
3. Modify auth code in backend to check `username` and `password` (or just `secret_phrase`) columns instead of `email` and `password` columns
4. In all code paths that send email, ensure that it handles invalid emails gracefully (if it doesn't already)