Hacker News Reader

You may think that, but does not appear to be so. The response is a 302/3 redirect which automatically puts it outside the bailiwick of the attackers scope.

Provided that is the attacker is not using same domain origin, scheme, port etc. Which if they were you would perhaps have greater problems.

That said, we will all be testing that feature most thoroughly.

View on HN

Unless you actually set the address bar (i.e. window.location) to localhost:25519 I don't think this is going to work. I've used ajax with REST APIs that return 302s and you will receive the body of the destination page as the return value to the ajax call. The page in the window (window.location) is not going to change. And this is of course if localhost:25519 returns the proper CORS headers in the first place to allow the ajax GET to even occur.

I think the only way this could work is if you set the window.location to localhost:25519 when starting the SQRL authentication. That will result in harder UX problems to solve but it does seem feasible.

Regardless, having reviewed FIDO and the W3C Web Authentication API, it seems to me that SQRL doesn't have a chance of seeing any wide adoption once those two are available. They have the dual advantage of standardization and platform control that are nearly impossible to overcome by external offerings.

Reply on news.ycombinator.com