Problem #1
God algorithms, God solutions etc, God methods etc often add unnesecarry complexity with very little benefit. There is no God, get over that...
Shipow: Even if I don't support religions, I'm pretty ok with the idea of an omnipotent mind as it stay in the context of narration. And I guess that even someone very trustfull will never imagine God as web/app designer ;)
Problem #2
Lack of evidence for decisions... I could understand iteratively improving a design because nobody gets "sign up", "sign in"... if it EVER happened! Jeff even admits there is little evidence against "sign up" / "sign in", and the link seems to be to some stackoverflow o similar upvoting thread (thus promoting over-simplification, lack of engagement and pack mentality common on such services)... The truth is "sign up", "sign in" is not confusing, unless you do not speak english, then you have bigger problems than "sign up", "sign in"... You know like using any of the interface...
Shipow: As a non-native english user, I've been a countless time in front of the wrong view because I clicked too many times on the wrong link. I'm not reading all links, I just click quickly on the first link that I can think to be the register one. So for this one I would say that it cost nothing to use something more identifiable.
LCowles: As a usability enhancement how about one form with one button, if the username is in the system it logs you in, if not it starts the signup process?
Problem #3
Social logins are not always appropriate. OpenID worked just fine. E-mail the older brother is a terrible solution that forces many to create separate emails and clog the internet because XYZ idiot convinced their boss 1 emails == 1 person (it's not, I have over 13 email addresses, I know some people who share one, expect differences). Also lots of users are waking up to privacy & security. They do not always want to share these details. Especially before they start using a service. Not having social details just means your users have to fill in the fields you need, which for most services is just a point of contact, a username and a password. Businesses want more details, but this has nothing to do with the User Experience... A Better solution would be requiring less details to sign up rather than finding ever more inventive ways to get people's details.
Shipow: Ok, but I guess you will make your journey better if you wouldn't have to check 13 emails address continuously :)
LCowles: Believe it or not no lol. I did get it down to 2-3 at one point, but I find it's easier & faster than scrolling IMAP filters to just have accounts setup for the intent I work with. I Run a small business so many hats are worn, many subjects covered lol.
Problem #4
"Tell the user when their email doesn't exist". Right so not only are we assuming all users only have one email, which we can use to identify them, we now have something else to worry about as this message not coming up, will mean hackers can gather data for social engineering attacks. I am a much bigger fan of the simpler to implement and more secure "Your username or password is invalid". If the user cannot take care of these two bits of data (in Jeff's article they cannot sign up with the same email address). Also by ignoring e-mail as a sign-up / in method and ommitting it from forgotten password screen, you are providing your users with an alert that someone is trying to access their account by sending them an email based upon their username. This is far more useful than Jeff's solution.
Shipow: Agree
Problem #5
Working with browser password manager is poor security plain and simple. https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion & google for other examples. Also password reveal... Just don't go there. I would even go as far as to say password inputs should not allow scripting to get or set the value...
Shipow: Even with password field you can access to the password, so that won't change nothing from my POV.
LCowles: I Know about this, I was saying it would be a good idea for browser vendors to restrict get or set the value and it is entirely do-able with JS to restrict getting and setting, although as it is JS, so it is no more secure... (needs browser support) what would be nice is browser password and encryption support without SSL, not sure about the implementation though.
Problem #6
passwords... Just don't do this... 8 char length minimum, fine, sensible maximums I can accept if needs be (I believe most form inputs can only transmit a certain amount of data anyway...) But rather than worrying about 10,000 commonly known passwords, have a policy, have an indicator encouraging users to set a strong password and force use of SSL. Once transmitted of course hash the PW and verify the hashed password. More important is to have a hidden field, which adds a var from the server only after keydown events on username and password (thus disrupting automated attacks and security threats to the user). Yes this will affect #UX, but not as badly as being hacked! Also block parts of DOB, words from hobbies that are publicly displayed on profile, "password" and "p455w0rd" etc, but checking against 10,000 details is just silly!
Shipow: I saw a cool datavizualisation for phone SIM password, it was incredible, I'll try to take a picture, but I'm pretty ok to educate user here. Like you said it's worst to be hacked for the UX. A policy is about reading a full text paragraph, i don't like that idea. 10.000 seems to be overkill. But avoiding stupid patterns with a one liner message sounds cool.
Problem #7
Rate limiting I am fine with, but 3... no, make the limit higher, circa 10 is my suggestion as the chances of guessing an 8-char in 10 guesses without public profile details rules out all but advanced social engineering (some problems should not be stopped, as they would make the web too restrictive!)
Shipow: I think that 10 is more usuable than 3 too.