I enjoy that you offer up a quite complex, confusing, often insecure, and error-prone methodology with this phrase.

Seriously, this sort of thing is not complex, not at all.

- I'm logging in from a new computer. Maybe a computer I don't trust enough to log in to my email (which controls nearly everything, as you note). Not all services are that important or need the same level of care as email.

- I'm a user that has greylisting enabled on my mail server, potentially delaying the email for several minutes.

Confusing:

- I'm a user that has never seen/used this authentication workflow. While user/pass is annoying, it is widely understood. Sometimes "ease of use" is really just "what I'm used to". Thanks to facebook and Google authentication, the "Login with..." button is now "what I'm used to". I've never seen the authentication method you've described in 20 years of web use, except as a password reset method.

Error-prone:

- Implementation would have to be done by me on all of my sites. There is no off-the-shelf plugin for this for Drupal or Wordpress or Mediawiki, which run 90% of the websites I am responsible for. I could develop it but I am certain I would make mistakes in said implementation. I should be clear that I think any form of authentication is error-prone, unless it's already written and well-tested. User/pass and optional email is already written and well-tested for every site I maintain.

Security:

- It forces login to email to login to your site. This increases the risk of a user logging in from an untrusted computer or in an untrusted location to an incredible degree.

- Also, one can easily add security questions, or other second factor, to a password reset form, to make it more secure than your solution. Password resets are rare; happening every year or two, most likely. Logins are daily. One cannot impose those security questions on daily login form without paying the same annoyance price as user/pass (higher because it is unfamiliar). Cookies can mitigate this somewhat, but it doesn't solve multiple devices, and security-conscious environments that don't maintain cookies on logout.

If you believe this is an acceptable workflow for authentication, I won't try to stop you. But, it simply isn't a solution for my sites. I don't like user/pass, and I want something better, but I don't believe what you've described is something better. It's a neat idea, but not a solution to logins.

Neither are password-reset emails…

This is no more or less secure than sending password-reset emails; any additional security intended to protect in the case of password resets can be applied to login as well (e.g. SMS or landline contact, knowledge of shared secrets of varying security).

No, it's essentially the same thing as having a password-reset email sent to one, which is already the case for just about any account anyway.

> You're putting the responsibility of security on the email provider, which you can't control.

Your email provider is already capable of visiting a site, claiming to be you & claiming to have forgotten your password, then intercepting the password-reset email and resetting your password (about the only sites which require more than this are banks).

You can extend any flow which is secure against an evil email provider resetting a password to be equally secure against an evil email provider logging in. Obviously you could add an SMS code, which would then require subverting your mobile provider as well as your email; ditto a landline call.