151–160 of 230 posts
Earlier quoted context omitted.
SMS clutter is worse for me. Harder to delete in bulk.
My SMS inbox is almost entirely login codes and other automated stuff so I'm quite happy just to leave it all there
Fuck magic links. What a horrible login flow. Am I the only person taht doesn't have my email open in another tab?
So far, I have been careful enough, but it's only a matter of time until this bites me.
MagicLinks are a mobile nightmare. Mobile email clients use their own browser and cookie jar which consume the session cookie you're trying to put into the user's main browser. This results in users 'never staying signed in' and a lot of frustration. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
It's actually pretty insane: there is a setting on Android to always use the main browser (Chrome) to open links, I've turned it on, and yet the Gmail app still opens the links in the embedded Chrome browser — which has different cookies, different history that apparently is not synced with my other Chromes, and even looks sli-i-ightly different than "normal" Chrome, somehow. I've no idea why it is so difficult for a…
That is quite insane indeed.
And on top of that, Android keeps using Chrome as embedded browser. Even if you installed another one. MSHTML all over again.
MagicLinks are a mobile nightmare. Mobile email clients use their own browser and cookie jar which consume the session cookie you're trying to put into the user's main browser. This results in users 'never staying signed in' and a lot of frustration. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
It's actually pretty insane: there is a setting on Android to always use the main browser (Chrome) to open links, I've turned it on, and yet the Gmail app still opens the links in the embedded Chrome browser — which has different cookies, different history that apparently is not synced with my other Chromes, and even looks sli-i-ightly different than "normal" Chrome, somehow. I've no idea why it is so difficult for a…
Another relatively new problem with magic links specifically on mobile is that your email client will likely open the link in an embedded browser which is typically isolated from the main browser app and doesn't share the cookies with it. There are some workarounds for this but they don't seem very secure, plus they add some complexity. E.g. once the backend validates the magic link click, it logs the user in also in…
The way I've implemented in one of my own projects [1] but that I'm not fully happy with (and the way that Amazon.com does it) is to do what you suggest: create a record on the backend when the login attempt begins and have your frontend keep checking that record until there is a result like email verified/not-verified/timed-out. When the user clicks the magic link in the email, update that record with their choice t…
Wouldn't an even better middle ground option be defaulting to magic links, with the magic link destination both logging in and notifying the user that if they user want to switch [back] to a different web browser or device they can use their email and $TIMELIMITEDCODE? (Perhaps with the notification disabled if the browser which opens the magic link shares a cookie jar with the browser session which requested the magic link, and perhaps including a "You recently tried to access using $RequestOriginatingBrowserName on $DeviceID" to hint they might want to get out of their mail client)
Offers both the magic bit and a non-magic way to escape from the sandbox that is less likely to be a vector for speculative phishing attacks.
MagicLinks are a mobile nightmare. Mobile email clients use their own browser and cookie jar which consume the session cookie you're trying to put into the user's main browser. This results in users 'never staying signed in' and a lot of frustration. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
It's actually pretty insane: there is a setting on Android to always use the main browser (Chrome) to open links, I've turned it on, and yet the Gmail app still opens the links in the embedded Chrome browser — which has different cookies, different history that apparently is not synced with my other Chromes, and even looks sli-i-ightly different than "normal" Chrome, somehow. I've no idea why it is so difficult for a…
I hate them. Force me to go to my mailbox while I have a good password manager and just want to use that instead. I get the idea, but this should be an alternative, not a default. Also sends loads of single use emails that will remain for ever in users mailboxes.
I'm mildly surprised that one of your complaints is that these fill your email. It seems simple enough to delete them?
I have virtually unlimited space for email, but they still show up in searches, and I'm certain I'll never want to look at them again.
I hate them. Force me to go to my mailbox while I have a good password manager and just want to use that instead. I get the idea, but this should be an alternative, not a default. Also sends loads of single use emails that will remain for ever in users mailboxes.
Earlier quoted context omitted.
Yeah. So one possiblity would be to confirm on the other device, where you're already logged in, that you're the one who photographed the QR code.
If you need to be already logged in the device that reads the QR code, then the QR is no longer encoding a magic link. It is more similar to doing the 2nd part of 2FA (after skipping the 1st) but adding unnecessary complexity in between. If we expect the user to be already logged in on a device that they have at hand, why give them a QR code instead of simply a PIN code or a notification to confirm the new login?
Earlier quoted context omitted.
I'm mildly surprised that one of your complaints is that these fill your email. It seems simple enough to delete them?
Gmail app buries delete in a couple places in favor of archive. I routinely find I need to open a message to delete it, although the notification has an "archive" quick action button. Gmail made delete extra steps. I have virtually unlimited space for email, but they still show up in searches, and I'm certain I'll never want to look at them again.