5 ms·

As a user the problem I run into with some frequency is passwordless login where the waiting session loses its “waiting” status because I switched the active ap

As a user the problem I run into with some frequency is passwordless login where the waiting session loses its “waiting” status because I switched the active application in iOS from my browser to my email and back again. When I get back, the page for whatever reason (refresh after being backgrounded?) requires a new auth attempt. A wrinkle in this complaint is that in most scenarios I don’t especially want a browser tab to be able to hold onto a persistent session while it’s closed due to privacy reasons, regardless of where that session state is held (and I realize there are a number of options).

londons_explore 4y ago
> (refresh after being backgrounded?) This is a problem on low memory devices - the page gets forced to refresh because the system ran out of RAM. The iPhone 13 only has 4GB of RAM, and with many apps requiring 2+GB, it is frequent a web page can't stay loaded in the background. Most android devices have 8GB plus RAM, so shouldn't hit that issue, although it still happens on very low end devices.
- IggleSniggle 4y ago
  They can take my iPhone 7 and its 2GB of RAM over its dead body.
couchand 4y ago
A simple workaround for the implementation is to redirect you to a URL with the code hashed as a query parameter.
- IggleSniggle 4y ago
  Yes, I was thinking about that, as something like a TOTP. But that needs to be done via DNS-over-HTTPS or DNS-over-TLS or else the code can be sniffed by a MITM since the URL is sent in the clear, at which point you’re back to the problem of persistent TLS anyway. Edit: In fact, nevermind. My thinking on that was flawed. I think you’re right, that should be fine, as long as the DNS is encrypted.
pritambaral 4y ago
This took me a bit of time to realise, but well-designed software can avoid this problem rather simply: Combine the Magic Link with a short-code that can be manually typed into the browser session attempting to login. This short-code can then be prominently displayed in the email header and/or early on in the email body, so a user can simply read it off the notification that the email would generate. No need to switch apps from browser to email.

londons_explore 4y ago

> (refresh after being backgrounded?) This is a problem on low memory devices - the page gets forced to refresh because the system ran out of RAM. The iPhone 13 only has 4GB of RAM, and with many apps requiring 2+GB, it is frequent a web page can't stay loaded in the background. Most android devices have 8GB plus RAM, so shouldn't hit that issue, although it still happens on very low end devices.

IggleSniggle 4y ago
They can take my iPhone 7 and its 2GB of RAM over its dead body.

couchand 4y ago

A simple workaround for the implementation is to redirect you to a URL with the code hashed as a query parameter.

IggleSniggle 4y ago
Yes, I was thinking about that, as something like a TOTP. But that needs to be done via DNS-over-HTTPS or DNS-over-TLS or else the code can be sniffed by a MITM since the URL is sent in the clear, at which point you’re back to the problem of persistent TLS anyway. Edit: In fact, nevermind. My thinking on that was flawed. I think you’re right, that should be fine, as long as the DNS is encrypted.

pritambaral 4y ago

This took me a bit of time to realise, but well-designed software can avoid this problem rather simply: Combine the Magic Link with a short-code that can be manually typed into the browser session attempting to login. This short-code can then be prominently displayed in the email header and/or early on in the email body, so a user can simply read it off the notification that the email would generate. No need to switch apps from browser to email.