Codeberg/Community
54
325
Fork
You've already forked Community
12

Remove email requirement for sign up #2091

Closed
opened 2025年08月17日 19:12:14 +02:00 by An-anonymous-coder · 4 comments

Comment

Email relies on insecure, outdated protocols, such as SMTP. It was never designed to be used in the context of authentication, and certainly shouldn't be used for sensitive communications in comparison to secure communication protocols such as the Signal Protocol or SimpleX Chat Protocol. Furthermore, requiring email for sign ups provides a privacy risk, since email is usually tied to a lot of personal information. While email can be made "less bad" in terms of privacy and security, the best course of action is to remove the requirement altogether.

What does this mean for server load?

Anyone can create an email address. That means that any mass sign up risk that is present without requiring emails is still present even if you require emails. The best email requirements can provide is an unreliable method to ban unsavory users. Again, these users can just create another email to trivially evade the ban. There's much more reliable methods to ban users than by checking emails and prevent mass sign ups. Removing the requirement for emails would benefit some of the server infrastructure, such as the email servers. It makes creating an account very low maintenance and little human oversight needed.

What about contacting users?

When I first brought this issue up, one of the concerns presented was communication with users. That is a valid concern, but not one that requires an email to solve. There is no shortage of communication methods. As mentioned before, Signal and SimpleX Chat are some of the gold standards in terms of these protocols.

In the simplest case, Codeberg could provide a built-in method of contact. If a user is warned or punished, they will still be able to access this menu to discuss or appeal the issue. This provides granular control over how communication standards are met, as well as not needing to rely on a third party service like email. However, designing a contact service from scratch is cumbersome to maintain, so there is a trade off.

Another option would be to instead, on sign up, require any arbitrary form of contact. There could be a drop down menu with options such as Email, Phone Number, Signal, SimpleX Chat, Custom, etc. At least one of these must be provided to sign up. This removes reliance on email while still providing a way to contact the user. Of course, it would be better to just pick one method of contact across the whole service and stick to it, but that should not be email.

Next generation accounts

Many projects such as Mullvad VPN, IVPN, KYCnot.me, SimpleX Chat, Session, and more require no information to use, not even a password. They randomly generate an account number which is used to login. If this seems odd, remember that most cryptocurrencies do the same thing. This is the gold standard for privacy and anonymity, and combining it with passkey authentication makes it even more secure.

While this is a bigger step from only requiring a username and password, it is where Codeberg should try to be headed. If a user does not want to provide a method of contact, that is their choice and they hold full accountability for the consequences. This is a scenario in which having a built-in contact method becomes useful. In any case, email should not become the scapegoat for communication, authentication, etc. The risks are far too high.

### Comment Email relies on insecure, outdated protocols, such as SMTP. It was never designed to be used in the context of authentication, and certainly shouldn't be used for sensitive communications in comparison to secure communication protocols such as the [Signal Protocol](https://signal.org/docs/) or [SimpleX Chat Protocol](https://simplex.chat/docs/protocol/simplex-chat.html). Furthermore, requiring email for sign ups provides a privacy risk, since email is usually tied to a lot of personal information. While email can be made "less bad" in terms of privacy and security, the best course of action is to remove the requirement altogether. # What does this mean for server load? Anyone can create an email address. That means that any mass sign up risk that is present without requiring emails is still present even if you require emails. The best email requirements can provide is an unreliable method to ban unsavory users. Again, these users can just create another email to trivially evade the ban. There's much more reliable methods to ban users than by checking emails and prevent mass sign ups. Removing the requirement for emails would benefit some of the server infrastructure, such as the email servers. It makes creating an account very low maintenance and little human oversight needed. # What about contacting users? When I [first brought this issue up](https://codeberg.org/Codeberg/Contributing/issues/61#issuecomment-6528922), one of the concerns presented was communication with users. That is a valid concern, but not one that requires an email to solve. There is [no shortage](https://privacyspreadsheet.com/messaging-apps) of [communication methods](https://eylenburg.github.io/im_comparison.htm). As mentioned before, [Signal](https://signal.org/) and [SimpleX Chat](https://simplex.chat/) are some of the gold standards in terms of these protocols. In the simplest case, Codeberg could provide a built-in method of contact. If a user is warned or punished, they will still be able to access this menu to discuss or appeal the issue. This provides granular control over how communication standards are met, as well as not needing to rely on a third party service like email. However, designing a contact service from scratch is cumbersome to maintain, so there is a trade off. Another option would be to instead, on sign up, require any arbitrary form of contact. There could be a drop down menu with options such as Email, Phone Number, Signal, SimpleX Chat, Custom, etc. At least one of these must be provided to sign up. This removes reliance on email while still providing a way to contact the user. Of course, it would be better to just pick one method of contact across the whole service and stick to it, but that should not be email. # Next generation accounts Many projects such as [Mullvad VPN](https://mullvad.net/en/vpn), [IVPN](https://www.ivpn.net/en/), [KYCnot.me](https://kycnot.me/), [SimpleX Chat](https://simplex.chat/), [Session](https://getsession.org/), and more require no information to use, not even a password. They randomly generate an account number which is used to login. If this seems odd, remember that most cryptocurrencies do the same thing. This is the gold standard for privacy and anonymity, and combining it with passkey authentication makes it even more secure. While this is a bigger step from only requiring a username and password, it is where Codeberg should try to be headed. If a user does not want to provide a method of contact, that is their choice and they hold full accountability for the consequences. This is a scenario in which having a built-in contact method becomes useful. In any case, email should not become the scapegoat for communication, authentication, etc. The risks are far too high.

note: I am not a codeberg infra manager and do not wish to be.

Keep in mind high-end companies like Google and Microsoft still use email. I don't see any security issues with email. Also, we can't just send SMS to phone numbers, etc. since CB doesn't have those.

I oppose this suggestion.

*note: I am not a codeberg infra manager and do not wish to be.* Keep in mind high-end companies like Google and Microsoft still use email. I don't see any security issues with email. Also, we can't just send SMS to phone numbers, etc. since CB doesn't have those. I oppose this suggestion.

@An-anonymous-coder Maybe make emails optional instead of removing that feature altogether.

@An-anonymous-coder Maybe make emails optional instead of removing that feature altogether.

@horsey_guy wrote in #2091 (comment):

@An-anonymous-coder Maybe make emails optional instead of removing that feature altogether.

From the OP:

Another option would be to instead, on sign up, require any arbitrary form of contact. There could be a drop down menu with options such as Email, Phone Number, Signal, SimpleX Chat, Custom, etc. At least one of these must be provided to sign up. This removes reliance on email while still providing a way to contact the user. Of course, it would be better to just pick one method of contact across the whole service and stick to it, but that should not be email.

@horsey_guy wrote in https://codeberg.org/Codeberg/Community/issues/2091#issuecomment-7322761: > @An-anonymous-coder Maybe make emails optional instead of removing that feature altogether. From [the OP](https://codeberg.org/Codeberg/Community/issues/2091#issue-2189425): > Another option would be to instead, on sign up, require any arbitrary form of contact. There could be a drop down menu with options such as Email, Phone Number, Signal, SimpleX Chat, Custom, etc. At least one of these must be provided to sign up. This removes reliance on email while still providing a way to contact the user. Of course, it would be better to just pick one method of contact across the whole service and stick to it, but that should not be email.

I'm inclined to close this, this is technically not a easy task and the case presented here why email should be avoided does not resonate with me and the usage of email addresses in Codeberg is quite different than is being shown here (I could go into detail, but I do not wish to have a debate about this). Adding other methods of communication is not possible for Codeberg and this will not change with any amount of discussion on the topic. Feel free to contact me personally (https://matrix.to/#/@gusted:matrix.org) if you disagree with this decision.

I'm inclined to close this, this is technically not a easy task and the case presented here why email should be avoided does not resonate with me and the usage of email addresses in Codeberg is quite different than is being shown here (I could go into detail, but I do not wish to have a debate about this). Adding other methods of communication is not possible for Codeberg and this will not change with any amount of discussion on the topic. Feel free to contact me personally (https://matrix.to/#/@gusted:matrix.org) if you disagree with this decision.
Gusted locked as Resolved and limited conversation to collaborators 2025年09月24日 23:39:05 +02:00
This discussion has been locked. Commenting is limited to contributors.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure

Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers

Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support

This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#2091
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?