Make sure you also tell Tumblr, Facebook, and Twitter about their vulnerability too. 
Exactly why we have the option in site settings. Itâs quite reasonable to expect a site administrator to review login settings.
Also, the default isnât an exposure. All it says is that someone created an account with that email. It could be an unverified, never-logged in email.
My point here is very simple, show me one popular website on the entire Internet that follows a strict no-emails-can-ever-be-disclosed policy.
1 Like
Years ago I missed a renewal payment to my site host.
When I tried to login to the ACP I got an
âInvalid Loginâ message.
I carefully checked my spelling and case but several repeat attempts continued to fail.
Much confused I eventually called support and was told the reason was because of a lapse in payment.
It didnât make sense to me at the time how this could be considered an invalid login.
But after thinking about it, it kinda sorta did.
IMHO I would prefer a generic non-specific message, but as long as there is a configurable option I donât see there being a problem for like minded Admins.
Wasnât Discourseâs mission statement to not follow the trodden path and finding better ways to do things? 
AnyhowâŚ
@dustinmoris raises a valid issue, but itâs based on the assumption that Discourse will be used heavily on sites where merely exposing the fact that you are a member is a critical privacy concern. Such sites do exist without a doubt, but they are a minority and perhaps Discourse just isnât the right platform for them â yet.
1 Like
My point here is that this setting has nothing much to do with the root problem that there is email disclosure when you register accounts. Nobody ever complained about this before and its a very common practice. In fact it is so common I have never seen a modern website that does not have this âvulnerabilityâ
The behavior of âsilentlyâ allowing people to register accounts with incorrect/already registered emails and just doing nothing at the end of the process is odd and not something that should be a default.
For the super privacy conscious there are already 3 super common solutions
- Donât give third party sites your email address, use throw away accounts
- Use gmail + addressing eg: sam.saffron+someguid@gmail.com
- Site operators can implement SSO and use whatever crazy auth system they want
- If someone wants to work through a âenable_tin_foil_hatâ site setting I am open to it, but the core team are not going to work on this until a paying customer asks for it
Oh I think you got that point across quite well, but the whole discussion here got super intense super quickly, and weâre suddenly spending more time on bickering than on thinking about if and how something useful could come from all this. And thatâs a shame. 
2 Likes
It got intense cause a brand new user told us we are ânarrow mindedâ and âdiscriminatoryâ
Then the same new user said that site settings do not matter cause âno one will ever user itâ
It just struck a huge nerve with me and made me super upset.
I felt like a condensending disappointed adult decended upon us to teach us the errors of our way. We agonized quite a lot about these defaults you know.
3 Likes
Not quite, we deleted unverified accounts after 7 days.
I donât think anything useful can come of a âno email shall ever be disclosed, even upon account signupâ discussion @elberet. I mean, can you really point to any other site on the Internet that works this way??
Off the top of my head? Nope. But Iâve read some news the other day about an open source project thatâs intended to drive whistleblower sites⌠I didnât check it out (or read past the articleâs blurb), but not disclosing the usersâ email addresses might be a pretty big deal there.
I am fine with adding a mode like this, but someone else is going to have to work on it, it would actually be nice to get rid of forgot password strict and replace with an encompassing term that defines a âemail never disclosed but registrations can be a bit of a pain in the assâ mode.
1 Like
Me neither, until now. I just signed up (again, by accident) at Hipchat, and instead of the confirmation email they promised, I got this:
Hi *****,
It looks like youâve tried to create an Atlassian account for ***** @ *****.
However, an account for that email address already exists.You can reset your password if youâve forgotten it.
If you didnât try to create an account for ***** @ *****, donât worry - we havenât done anything, and you can safely ignore this message.
Feel free to contact us if youâve got any questions.Cheers,
The Atlassians
This would be a pretty neat feature for Discourse if you ask me!
2 Likes
Er⌠what? That feature already exists
We could make this a bit easier by jumping them over to âreset passwordâ at that point, I guess, but feels like a bit of a micro-optimization cc @neil
NoâŚ?. this is the opposite⌠itâs about never saying âemail has been takenâ and instead making it impossible to misuse the sign up process to see if there is an account using a specific e-mail address. Atlassian only discloses that in the âconfirmationâ email that is sent, not in the web interface.
I see, so the disclosure is only via email, not in the UI. Well, there is an existing site setting to disable the UI disclosure, of course, and thatâs off by default ⌠but there is no direct email response handling.
It seems to me the direct email only makes sense in the context of zero UI disclosure, though. Which is not our default.
Which site setting is that? I thought there only is one for the forgot password dialog, but that the sign up process would always disclose if an email address is being used already.
Youâre right @michaeld that we donât have a setting to hide âEmail has already been takenâ. I like what Hipchat does.
1 Like
Hmm, no, we do have this setting forgot password strict and have had it for a long while
I guess we could enhance it to also work that way on account creation, but I donât want to add another settingâŚ
3 Likes
How about using the existing one for both the forgot password and signup processes, and eventually renaming it to âdo not disclose email addresses in useâ ?
4 Likes
@neil this one should be unified so we get coverage in both places.
3 Likes