Recent content by PHolder

I think we've reached a point where there needs to be a list of options people do or don't want, and a UI to allow/disallow them. I envision a framework where a SQRL app could integrate into it which would allow things like: 1. Indicate to your other devices which device is currently in use...

Yeah, I think that is a consequence of how the plugin works? In essence two parts of the screen provided by two different plugins (maybe one of which ships built in.) I did do this, some time ago, but I agree this is a band-aid and not a fix...

Yeah, I think @Steve does layout calculations once, at the beginning, before opening the window. I don't know how Windows works in this aspect, but hopefully it sends a message to an app saying "you need to redo your calculations because the DPI changed."

I feel like you're playing both sides of the street. On the one side you think SQRL is DOA because __x__. On the other side you say do people really want __x__. I think people would really like it to just work, without them ever having to use their brain even once. "Just work and just keep...

In a word, yes. The sites are not going to directly track you with your IDK. They're going to associate that with their internal tracking ID and map one to the other whenever you sign in. In their view you are therefore the same person everywhere, no matter how they convinced you to authenticate.

The reverse of this is true also. If you were to move your site (or it's authentication URL) for any reason (say you got booted from your host, and you moved from mysite.foo to mysite.bar) then it would be broken for SQRL and it would not for standard hashed userID and password.

No offense, but this seems pointless. I'm not going to your site just because you have SQRL enabled.

I think the answer here is up to the server, if it believes a client is being too big of pain in the buttocks then it can penalize that client more and more. At some point it would stick it on a list of bad actors, which it could eventually expire out of. If the bad actor keeps moving to...

I can, but it requires hosting your own server for it, or more likely, trusting a third party for that purpose.

My two cents worth would be that there could be an eventual extension to the protocol, or even outside of it that the server could optionally challenge the client with a proof of work to continue. That way, if the server doesn't feel under attack of any kind, then it can proceed as it always...

This has nothing to do with the protocol. It has everything to do with the client having a memory. The popular belief, among the SQRL leadership is that the client should not have a memory for a number of reasons, most specifically the KISS principle. Others would be free to build a SQRL...

I believe your issue is that you should not be escaping the & in this case. Athough if you have it mostly working, maybe not... Still, you don't need to escape it in that case, so that would me one less thing that could go wrong.

Steve's implementation is for Windows, and that is why he is not making it readily available for anyone. He delivers it as a Windows virtual machine image, which means potential licensing issues. It wouldn't really be suitable for Docker, I don't think.

I think it's early days for that code yet, cause I see some hard coding, such as: displayQRCode("sqrl://192.168.6.11:8080/sqrl?nut=5hqZKuHyq5t6y2ifoW3wPw", true);

Can you provide the link to the source of the code. I assume it's a project on Daniel's github, but I don't want to make assumptions. Also this discussion probably belongs elsewhere than under the Android app... for now, failing anywhere better, under the development topic.