Maybe it works for you, but I'm still utterly confused about how to login. But hey, I only have about 25 years of coding and online experience.
To be fair, it's not SO's fault.
On the login page they list a bunch of common providers you can login with if you already have an account with them: Google, Yahoo, AOL, Facebook, etc. Click their icon, type in your credentials.
If you don't have an account with one of those or don't wish to use them then it has a big register link to sign up with a myOpenID account.
It may have actually been useful if it leveraged DNS SRV records so you could login as foo@bar.com and it would query SRV _openid.bar.com for the URL.
Then one day I was signed out -- the cookie finally timed out, or was cleared somehow, etc., and I arrived at the login page, and was totally stymied. I always sign up for new services using their_domain@my_domain.tld, and that hadn't been possible here, apparently, because asking for a reminder with stackoverflow@my_domain.tld failed.
Ah, I must have registered with an account at any of these half-dozen sites. Well, I have accounts at all of them -- sometimes multiple accounts for different purposes -- all using different email addresses. I had no recollection at all of which I had chosen; I was totally stymied.
After a few days of trying different ways of getting in, I finally figured out the right one (still don't recall), and then could set stackoverflow@my_domain.tld as my backup email, so now I'm covered... but it was the worst sign-in experience I've ever had.
That was an absurd statement. Why don't you rather tell us what confuses you about the login process?
Now I open Firefox. I try to login to OnStartups, because it doesn't know who I am. I click on Yahoo, go through the authentication process. Guess what: it says it can't find that account on OnStartups (wrong answer), but finds it on StackOverflow, and asks me if I want to link it to my new account. What???
It's almost as bad as the experience I described with multiple Google accounts: http://blog.fairsoftware.net/2010/11/15/the-10-step-google-l...
Something for other HNers to keep in mind if they are considering openID for their next project (flee, flee!)
In fact, when it comes to security, I assume most developers are about two steps away from handing out root on request.
But OpenID is easy to screw up. Practically everyone has enormous problems with their implementations. (This goes seven times over for yours truly.) Which is (yet another) knock against choosing OpenID for anything important, versus systems which evidence exists can be implemented correctly. It is possible to bork username/password, but it is possible to implement it mostly correctly, too. I do not think it is possible to implement OpenID correctly. (For what it's worth, StackOverflow's is the best implementation I've seen from the user's perspective.)
I do think the no-login approach is exactly right, but their implementation seems a little buggy.
If anything on a site is ever confusing, it's always the site's fault, not the user's. So don't feel bad.
It's a pretty fundamental part of usability, design, and business in general. Blaming your users is never a good idea.
Sometimes providing a perfect user experience is equivalent to solving the halting problem and not recognizing this is as big a problem as believing that all problems are the user's fault.
Users had complaints about Windows UAC doing this for every instance (not just downloads).
Right. This misunderstanding was the entire point of my post. Distinguishing between the "safe" downloads and the "unsafe" downloads is an instance of solving the halting problem.
Also, I was thinking of the Chrome "Run Application" dialog, not the UAC.
Nitpicking specific examples and then saying "oh, well this disproves it" proves nothing. 99 out of a 100 times, blaming the user isn't the right move. For the sake of brevity, I used ever and always.
Personally, I prefer keys (long, randomly-generated passwords stored in a file or device) to passwords, but I don't know of any reasonable way to authenticate to a webapp with a key.