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.

Comments on Allow completely pseudonymous user accounts

Post

Allow completely pseudonymous user accounts

+6
−1

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

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

2 comment threads

Users are stupid (11 comments)
General comments (1 comment)
Users are stupid

The user would be told to record this, as without it access to the account would be impossible.

Best be aware that some users will still fail to do this. And even those that do, yeah, it can be annoying keeping track of this, especially if the location or format they stored it in, later ceases to exist or be accessible.

samcarter‭ wrote 9 months ago

TopAnswers has a similar mechanism. Instead of storing PI, the user gets a pin on sign-up. This works reasonable well. Most users seem perfectly capable to store their pin.

TopAnswers is a niche community with technical topics. Codidact has more communities.

trichoplax‭ wrote 9 months ago

I don't think it's a question of intelligence. Most people still occasionally need to reset a password. If implemented, I'd expect the default to still be to use an email address (which makes password resets easy), with the unique id only approach requiring clicking on a link and reading a warning before signing up.

Will most users who go to the trouble of taking this route also be likely to use a password manager, allowing them to store their unique id in the username field?

matthewsnyder‭ wrote 9 months ago

This maxim is common on commercial sites. IQ is a bell curve so indeed most people are not very smart, and the same thing goes for knowledge and tech-literacy. Unsurprisingly, it is often more profitable to "target" (perhaps rather "grift" or "scam") a large mass of poorly informed users than a small group of savvy people.

I don't think this marketing strategy should be applied to CD. I'm not stupid, and neither are other users I see here. I don't understand the vision for this site as collecting a bunch of "stupid users". Asking the average person to securely record an ID is not unreasonable either, they've been doing it just fine for decades with passwords, phone numbers, addresses and many other things.

trichoplax‭ wrote 9 months ago

I think many people can handle securely recording an id, but I would want it made very clear that unlike with a password, there is no way to reset the id if they do lose it. This way a user can make an informed decision whether to accept that risk.

Some users may be confident that they can remember the id and therefore happy to accept the risk. Other users may want to post something from a disposable account and therefore not need to remember the id.

Andreas witnessed the end of the world today‭ wrote 9 months ago · edited 9 months ago

Even experts make mistakes. It’s stupid to design a system such that an honest and simple mistake can have grave consequences.

I also never referred to low IQ as my idea of stupid. Everyone is stupid sometimes. My level of IQ is amongst a small minority of humans on this planet, but it doesn’t prevent me from being absolutely stupid all the time. ;)

samcarter‭ wrote 9 months ago · edited 9 months ago

Grave consequences? Worst case the user loses some imaginary internet points, creates a new account and can subscribe their previous posts to get notifications about new comments/answers. Not much harm done, so I wouldn't call the consequences grave.

matthewsnyder‭ wrote 9 months ago

Ah, that's a good point about IDs - you can't reset them. I realize now it works for sites like Mullvad because accounts inherently have little state. As samcarter‭ says, a CD account is not that valuable, but still, it would be a bit annoying to lose access to your post history.

I do agree that we shouldn't put in footguns. Probably user/pass is the best option here after all. Besides, a lot of other sites use it, so everyone knows it.

Canina‭ wrote 9 months ago · edited 9 months ago

matthewsnyder‭ With my proposal, you'd still get a username. It would just be disconnected from everything else about yourself and your account, and not be very memorable. (A GUID is one way to do that. There are other possibilities.) And the idea is to offer the option of being anonymous even against people with full access to the Codidact database; some people would clearly benefit from the ability, some wouldn't feel the need for it at all, and a lot of people would fall somewhere in between those extremes on a continuum. Some might feel that the benefit outweighs the risk, and some would feel that not being able to recover an account having lost knowledge of their username would outweigh the privacy gain. Certainly the UI would need to make this trade-off clear; I already covered that in my proposal.

Adding the ability to be anonymous doesn't remove the ability to not be.

matthewsnyder‭ wrote 9 months ago

I get that - at first I thought your proposal could be improved by getting rid of the user/pass too, and making it just GUID. But then after this discussion, I realized just a GUID is not as good as a user/pass, so there's no point making reinventing the wheel and making it worse.