THIS IS A READ-ONLY ARCHIVE OF THE SQRL PROJECT FORUM
SQRL client feature comparison | Page 3 | SQRL Forums

SQRL client feature comparison


Steve, I gotta say, this CPS thing is the coolest idea I've seen in a long time. It is nuanced enough that it's going to be difficult for a non-techie person to understand, but once you get it, damn, it's very very cool!
 
It's fun to see you "get it", Gristle. And you're right... it is really the kick-ass techie goodness of SQRL.

I doubt that non-techies have any need to understand it, though. The techies WILL get it, however, and they'll tell others that "this thing is damn secure!" That'll be enough. ;) ... because it's also "damn easy to use!" :)
 
  • corrected and modified 2nd line of synonyms
  • 3 WebExt was erroneously "yes", now "no"
  • inserted "Recreate password" after "Change password", see footnotes (3) and (4)
  • for 20 - 27, there is no distinction beween mandatory and optional anymore
  • changed 26 from 'Warn MITM attack' to 'Allow cross-device login'
  • rephrased and extended footnotes
 
OP changes:
  • corrected remark "where 81 and 206 denote ..."
  • corrected typo in synonym list (no-SQRL := no SQRL)
  • added two NOTEs at the end of the OP
 
26|Req(2): Allow cross-device auth.

Can you explain the definition of this requirement?
The Android client has MITM warnings which can be verified by using the demo pages tooling.

We strive to make the Android client feature complete and to my knowledge, the only thing we lack is the "open file" option but I'm working on that one. Just need to figure out what MIME-Type a SQRL file is identified as on Android. :)
 
Can you explain the definition of this requirement?
The Android client has MITM warnings which can be verified by using the demo pages tooling.
On April 1st I changed 'Warn MITM attack' to 'Allow cross-device login'. You are saying I should change that back?

I could not and cannot produce an MITM warning on the demo pages.

In fact, I am still struggling with the "noiptest" and "cps" options a client can set. Not setting "noiptest" can cause an MITM warning, and so can "cps" if the IPs differ?

If I change the text for 26 back to 'Warn MITM attack', then I can set this feature to 'yes'. Then 27 'Warn non-CPS auth.' is 'yes' or 'no'?
 
In fact, I am still struggling with the "noiptest" and "cps" options a client can set. Not setting "noiptest" can cause an MITM warning, and so can "cps" if the IPs differ?

If I change the text for 26 back to 'Warn MITM attack', then I can set this feature to 'yes'. Then 27 'Warn non-CPS auth.' is 'yes' or 'no'?

Not really clear on the first question. But when the Android client uses same device login we don't send "noiptest" and establish CPS connection. In this case we will show warning if CPS is not available.

When it comes to logging in using QR Code on a different device and probably network we send "noiptest" and don't warn about MITM.

CPS is not practical or needed for different device login so that is not something you should have in the list of features.

If I understood your wording you could set YES on both rows.
 
The Linux column seems to be lacking in features. this is sad because I use Linux at home. of course, i also use android, so i could stick to the android client for authentication .. but still ...

is the table being kept up to date?
 
Steve's client works under Linux with WINE.

That's nice, but not enough. WINE has security issues. I would preferentially desire to avoid installing WINE on my Linux systems.

The situation right now seems to be that no one is interested in developing a FULL Linux implementation of SQRL. I would love to take on a project like this, but I am sure that this is not a one person job, nor should it be. I also think I do NOT have the necessary skills to to this effectively.

If anyone does decide to take this on, I would be willing to help.

Of course, until adoption of SQRL becomes more widespread, it might be a mute point.

I can always use the Android Client - which is nice, although still lacking one critical feature (in my opinion) - using alternate IDs.
(yes I know not everyone here thinks this is a critical feature).
 
I can always use the Android Client - which is nice, although still lacking one critical feature (in my opinion) - using alternate IDs.
The Android client DOES support Alt-Ids, and @kalaspuffar recently also implemented the Nullbyte-Separator, so this should be fully functional.
 
That's nice, but not enough. WINE has security issues. I would preferentially desire to avoid installing WINE on my Linux systems.

The situation right now seems to be that no one is interested in developing a FULL Linux implementation of SQRL. I would love to take on a project like this, but I am sure that this is not a one person job, nor should it be. I also think I do NOT have the necessary skills to to this effectively.

If anyone does decide to take this on, I would be willing to help.

Of course, until adoption of SQRL becomes more widespread, it might be a mute point.

I can always use the Android Client - which is nice, although still lacking one critical feature (in my opinion) - using alternate IDs.
(yes I know not everyone here thinks this is a critical feature).
I agree. I think wine will work for now. I'm sure someone can write one eventually.

Is the SQRL client open sourced yet? I haven't been following the news on the forums because of life. If it is maybe cross compiling will help.
 
Is the SQRL client open sourced yet?
The GRC SQRL client is not likely to be open source. And even if it were, it is written in Windows specific assembly with Windows specific APIs in mind. It is not portable code. Maybe one day someone will write and release a client in an open source framework with a portable language. The Mac really needs someone to specifically target it as a platform and make a platform specific client for it.
 
The GRC SQRL client is not likely to be open source. And even if it were, it is written in Windows specific assembly with Windows specific APIs in mind. It is not portable code. Maybe one day someone will write and release a client in an open source framework with a portable language. The Mac really needs someone to specifically target it as a platform and make a platform specific client for it.
Daniel's (@kalaspuffar) Android client is open source: https://github.com/kalaspuffar/secure-quick-reliable-login