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

Parent

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 moderator attention?
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)
Post
+7
−0

I'm not opposed in principle, but I don't think the amount of work is likely worthwhile. I imagine this sets you up for weird bugs far into the future.

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

This seems good enough to me. If you're concerned, it'd be easier to suggest a couple disposable email services on the sign-up page than to deal with all the corner cases of some people not having an email address.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Codidact Mail (1 comment)
Codidact Mail

Or we can start The Codidact E-Mail Service. :D

Not a serious suggestion.