Ah, sorry, I did get that part, and my idea goes a little bit further, but somehow I thought I wrote enough.

One thing is that this problem occurs because we have two independent channels that we must independently verify. I’m pretty sure this is a whack-a-mole game, and will never be possible to fix.

Another thing is that, since we don’t trust emails, we hesitate sending links over email. However, the problem here is easy to avoid if services send login links directly to user, and those emails are automatically authenticated by the system.

But I think with email login links you have one of several problems:

1. How do you know the email is for a session you actually initiated? In the extreme case, imagine maliciously triggering a login a link for 100,000 users. How many will click the link and get their account taken over? I bet it's nonzero (what's the minimum net you must cast to get access to one account?)

2. Or, what about various software that automatically previews links? A GET request is not secure for this purpose

3. But if you are instead suggesting a link takes you to an authenticated session (rather than authenticating an arbitrary session) now you have the problem that you must log into your email on the device from which you wish to access the account