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.
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?
@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.
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: firstname.lastname@example.org
- 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.
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.
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.
Me neither, until now. I just signed up (again, by accident) at Hipchat, and instead of the confirmation email they promised, I got this:
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.
This would be a pretty neat feature for Discourse if you ask me!
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.
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…
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” ?
@neil this one should be unified so we get coverage in both places.