UX Help welcome

THIS IS A READ-ONLY ARCHIVE OF THE SQRL PROJECT FORUM

@FlorinaV, Looking through the PDF, I see some great ideas for usability, thanks for your efforts so far. A few of those things I had on my list too!

One thing I'd like to put on your radar is the necessity of users to understand the criticality of the domain verification step (not sure if that's the official lingo or not). In Steve's recent post he lays out the scenario where a man-in-the-middle could logon as you to another site.

Right now, the client says "Do you want to login to: sqrl.grc.com", and your cursor is flashing below asking for a "Password". There's a back arrow, but it seems unbalanced between "the url looks good" vs "the url looks fishy".

What's happening here is that by typing your password, you are giving permission to the owner of the page where you found the QR code to login to the specific domain of sqrl.grc.com, and the two might not be the same!

People are already complaining about having to type even the quickpass each time, but I think that there might need to be a checkbox next to the domain that says something like "I want to give the page I scanned the ability to log me in to sqrl.grc.com (yes-domain looks good / no-domain looks fishy)", and also require the quickpass.

So training the users there's two things going on. One is make sure there's no man in the middle, and the other is to make sure it's really you.


A separate topic, but on the same screen, I'll tell you about my first use of the SQRL client.... I scanned the QR code and got to the password page and I thought "I'm not giving my SQRL master password to grc.com!" Even though I KNEW that's not how SQRL worked, that thought crossed my mind. So I think that it would help if that screen had a little help button that would assure the user that the password to enter is their SQRL master password AND that although it's used to decrypt their identity, it never leaves their phone.
 
  • Like
Reactions: Mark_roudebush, silversword and FlorinaV
This is more of a security thing than a user-friendly thing, but the domain name needs to be MUCH more in-your-face, especially when using the fingerprint login. I'm attaching how it looks now, along with a mockup of something more along the lines of how it should look. I know a lot of domain names will be longer and will necessitate smaller text, but I think the text should be as big as feasible to make it more obvious and attention-grabbing for the user.

Also, I'm not sure what font you're using, but if it's Google's Roboto font, there are some ambiguous characters that might make spoofing attacks possible. I used Consolas Bold for this mockup, which is easily legible and doesn't have this problem.

266 267

EDIT: @sengsational 's post collided with mine, but it's about the exact same subject: the user must be given every opportunity possible to notice when the domain name is something other than he thinks it should be.
 
  • Like
Reactions: Mark_roudebush, FlorinaV, silversword and 1 other person
At first I thought you face rolled on the keyboard to make that, but it is actually a real site, amazing, how languages can be different, I do wonder what the name means, but this paragraph is off topic.

Is there a way to break up long urls and maybe add ... to the end of each line to indicate that it continues on next line, and is ... allowed in a url? can one add another type of break in that case to clearly indicate that the domain needed to be broken into multiple lines? I mean maybe " ... " and without quotation marks and put the whole url into quotation marks for people to see it is a whole thing.
 
kalaspuffar said:
Hi @shanedk

Well, the thought is good but the font in the generic biometrics screen cannot be changed to my knowledge.

And if you want to log into llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk it might not fit in the window if you make the font to large.

Best regards
Daniel
Click to expand...
I know it'll have to adapt, but as it is it's completely non-obvious. I understand very well the importance of checking the domain name and even I find myself overlooking it.

@Steve has a solution in the client where once it gets so long you show it like llanfairpwll[...]gogogoch.co.uk or something like that.
 
  • Like
Reactions: FlorinaV
sengsational said:
@FlorinaV, Looking through the PDF, I see some great ideas for usability, thanks for your efforts so far. A few of those things I had on my list too!

One thing I'd like to put on your radar is the necessity of users to understand the criticality of the domain verification step (not sure if that's the official lingo or not). In Steve's recent post he lays out the scenario where a man-in-the-middle could logon as you to another site.

Right now, the client says "Do you want to login to: sqrl.grc.com", and your cursor is flashing below asking for a "Password". There's a back arrow, but it seems unbalanced between "the url looks good" vs "the url looks fishy".

What's happening here is that by typing your password, you are giving permission to the owner of the page where you found the QR code to login to the specific domain of sqrl.grc.com, and the two might not be the same!

People are already complaining about having to type even the quickpass each time, but I think that there might need to be a checkbox next to the domain that says something like "I want to give the page I scanned the ability to log me in to sqrl.grc.com (yes-domain looks good / no-domain looks fishy)", and also require the quickpass.

So training the users there's two things going on. One is make sure there's no man in the middle, and the other is to make sure it's really you.


A separate topic, but on the same screen, I'll tell you about my first use of the SQRL client.... I scanned the QR code and got to the password page and I thought "I'm not giving my SQRL master password to grc.com!" Even though I KNEW that's not how SQRL worked, that thought crossed my mind. So I think that it would help if that screen had a little help button that would assure the user that the password to enter is their SQRL master password AND that although it's used to decrypt their identity, it never leaves their phone.
Click to expand...
These are all very good points. Training the users has to be part of the app flow where needed according to the next step the user may take. I'll look into the flow next.
Regarding the password usage - from the usability standpoint, doesn't it make sense to use it only when logging into the app, and not be asked after, with each website that the user adds? Like Internet banking works for example - password once, all transactions possible after.
 
shanedk said:
This is more of a security thing than a user-friendly thing, but the domain name needs to be MUCH more in-your-face, especially when using the fingerprint login. I'm attaching how it looks now, along with a mockup of something more along the lines of how it should look. I know a lot of domain names will be longer and will necessitate smaller text, but I think the text should be as big as feasible to make it more obvious and attention-grabbing for the user.

Also, I'm not sure what font you're using, but if it's Google's Roboto font, there are some ambiguous characters that might make spoofing attacks possible. I used Consolas Bold for this mockup, which is easily legible and doesn't have this problem.

View attachment 266View attachment 267

EDIT: @sengsational 's post collided with mine, but it's about the exact same subject: the user must be given every opportunity possible to notice when the domain name is something other than he thinks it should be.
Click to expand...
This has to do with proper visual hierarchy on each screen and it is a UX feature, so very good point adding this topic here
 
FlorinaV said:
Please see the PDF at
Click to expand...

Been meaning to mention, it might be useful to load this into a google document so that we'll have change tracking/live status, note capabilities etc instead of a pdf.

I'm still thinking on general screen layouts, but before I put too much work in I've been waiting to hear from the lead @Mark_roudebush and his plans

Probably need need him to determine if he wants extra help etc as well and how to manage that.
 
  • Like
Reactions: FlorinaV
silversword said:
Been meaning to mention, it might be useful to load this into a google document so that we'll have change tracking/live status, note capabilities etc instead of a pdf.

I'm still thinking on general screen layouts, but before I put too much work in I've been waiting to hear from the lead @Mark_roudebush and his plans

Probably need need him to determine if he wants extra help etc as well and how to manage that.
Click to expand...
@silversword the Google doc: https://docs.google.com/document/d/1y7jCXlhBvCI0SLV6k0Mt6V1Izac1xEgy398daloxMsE/edit?usp=sharing
 
Last edited:
  • Like
Reactions: silversword
FlorinaV said:
These are all very good points. Training the users has to be part of the app flow where needed according to the next step the user may take. I'll look into the flow next.
Regarding the password usage - from the usability standpoint, doesn't it make sense to use it only when logging into the app, and not be asked after, with each website that the user adds? Like Internet banking works for example - password once, all transactions possible after.
Click to expand...
That makes sense, but from what I can gather from the app as it's been laid out so far, the password is doing two things...answering "is it you", and confirming that the domain is the one you intended to log into.

As to the "is it you" (or "is it still you", because you could set your phone down), some minimal password probably should still be required. The idea seems to be that the user can set-up quickpass for any number of characters (even one character), or they can use the fingerprint reader. So the first site, you put in the whole master password. From then on (up to the configurable timeout), the shortened password can be used. One temporary problem with the current Android client is that it doesn't honor the timeout and quickpass disappears too soon. But that will get fixed.

As to the "is the domain the one you indended", Steve's point, and a good one, is you can't make it completely automatic or there would be no domain confirmation, which is a critical step for air-tight security. In the "what-if thread" I suggested that the "password fatigue" could be reduced by keeping a list of domains that had already been successfully used. This way, if a new domain showed-up, the app could put the user through a more rigorous process, whereas domains that had been used before, let them slide easier. I figure that if they already fell for a spoofed domain earlier and it's in their list, they're hosed anyway, nothing we can do. But if it's a domain they've used before, we should be able to let them slide without too much fuss.
 
  • Like
Reactions: FlorinaV
sengsational said:
In the "what-if thread" I suggested that the "password fatigue" could be reduced by keeping a list of domains that had already been successfully used. This way, if a new domain showed-up, the app could put the user through a more rigorous process, whereas domains that had been used before, let them slide easier. I figure that if they already fell for a spoofed domain earlier and it's in their list, they're hosed anyway, nothing we can do. But if it's a domain they've used before, we should be able to let them slide without too much fuss.
Click to expand...
... and I neither dislike nor discount this idea. It's a good one. But to function smoothly it would require some form of inter-client "cloud" communications. Like the way LastPass glues all of its clients together. It may be that, in time, the world will decide that we need the many additional features that only such inter-client glue can provide. But I don't see how to do this without introducing a 3rd party, or a great deal of additional complexity for the typical end user.
 
  • Like
Reactions: silversword
Hi @FlorinaV

I've read through your feedback, and first of I like to thank you for your time and analysis. Good work so far.

Secondly, I want to apologize that I've not answered sooner, but I have much on my plate at the moment. Will probably have more time when we approach summer. My wife is on the last part of her studies to become a nurse, so that has the highest priority of my side projects.

Now some answers to your PDF:

The first page of the PDF talks about the onboarding experience, and that is completely lacking UX I know. First-time users are having to read much text and then have to choose by creating a new identity, importing an identity with their camera, or if that is impossible, they can fall back to type in the identity by hand. Not the easiest way to import an identity but you can at least use the application independent on device features.

The next screen talks about the creation and rekeying process, and you are right that explaining that the user needs to wave their camera around a bit to get a unique identity might be better worded. Moreover, the step where we explain that the creation process might take some time might not be necessary.

Next screen also has wording problems for new users and should just be fixed. A password strength indicator could be added but requiring users to choose a strong password is something I don't like. Yes, you only choose one strong password but it's your choice, and you need the device to use the identity.

Next question about what "seconds" stands for. Each value in () are quantities for the input. So the first field you supply numbers of characters in your quick pass, next you have numbers of seconds spent to encrypt/decrypt your password and last is minutes your password should be kept on the device.

Next screen with all the buttons needs reworking. I had another grouping in mind, but we could discuss that. Showing the identity name instead of a dropdown when you only have one is a good option and should be easy to fix. When it comes to rekeying, that is an ultimate option you use when you think your identity has been compromised, so you want to change it with a new one. It's not something you should do lightly, then again it does not have anything to do with the login flow.

Next screens question "Why not have a list of sites to log into?" Well first of I don't want to keep a list up to date. People probably not want to save a list of login sites. Lastly, we need the information in the URL to do the actual login function. The URL has a unique value that we use to encrypt and log in. So we need a new link for every login. That's why you log in using a QR code and your camera. Alternatively, if you want to log in on the device, you click a link on the website. Adding an option to enter a login URL manually could be an option but would be very cumbersome and might produce errors depending on how long the link will become.

The question about export options. The Android system uses the share function to send files between applications. Moreover, if you want to save it on the device, you might use an app for that. Then again if you want to export your identity of the phone, you will be required to send it at some point. So of the three options, I see it like this. If you have a new device, then show the QR and export the identity with an image to the camera. If you want to make it permanent then, print it to paper. For any other use, you might share it but this is less secure and only used for the times when you can't securely export the identity.

The last question: YES, that's a bug :(

Again thank you for your feedback and don't take any of my answers the wrong way. I appreciate your feedback, and I'm happy to have you working with us on this project. Some of the feedback I will translate to actionable tasks on Github as soon as possible other we need to discuss further.

Hopefully, we'll get some answer from @Mark_roudebush soon. Otherwise, I might change the lead on this so we can progress.

Best regards
Daniel
 
  • Like
Reactions: Mark_roudebush, silversword and FlorinaV
The entire SQRL project is in a really odd space in that it is basically a reference implementation / proof of concept but with enough polish and attention to detail to put many products to shame. Also, how do I label this as being off topic as this (and what I replied to) have nothing to do with Daniel Persson's Android Client.

Steve said:
But I don't see how to do this without introducing a 3rd party, or a great deal of additional complexity for the typical end user.
Click to expand...
There is something about the simple elegance of a completely stateless client model that quite appeals to me. But, that having been said, if stateful client sync was desirable, would it be possible to synchronize using some sort of peer-to-peer sync along the lines of Resilio (Formerly BT (formerly BitTorrent)) Sync? (Though I will confess my ignorance as to if the p2p clients cited find each other through a 3rd party.)
 
Steve said:
But to function smoothly it would require some form of inter-client "cloud" communications.
Click to expand...
True, if we wanted to go cross-client with it.

I was just talking about keeping a non-synchronized list on each device primarily for the purpose of being able to focus the user's attention on domain validation when it's really needed.

The bad guy's look-alike domain would get more scrutiny because it would be a first timer. I have very little faith in the average user scrutinizing each letter in the domain every time. But if something different happens in the client when a new domain is encountered, the user just might raise an eyebrow; there may be hope.

I'm loath to suggest features because I know how well thought-out the design is, and all I know so far is what I've experienced with the Android client (equal focus to all domain validations), but it just seems like shining a spotlight on any new domain would be a good idea. I suppose the bad guys would then try to infiltrate the list, hmm. See, that's why I leave designing this stuff to the experts, hehe!
 
Dave said:
simple elegance of a completely stateless client
Click to expand...

The more I think about it the more I agree let's just move forward and release the official GRC ultimately secure, technically implemented and rigorously documented reference client.

Get that client into the world, and let the world create custom implementations against the official SQRL spec for other use cases. We can forever nitpick and debate the minutiae of these ultimately v1 protocol clients, to only forever mire the SQRL protocol in pre-release obscurity looking for perfection. There is no 1-perfect client for 6.5+ billion people.

#FiveYearsIsLongEnough
 
  • Like
Reactions: Gristle
Hi all, sorry for the delay in getting back here. Work has required extra attention lately. I've chatted a bit with Florina and let her know I had some notes coming as well. Florina, I captured your thinking into my doc as well mostly for my own benefit. I hope that's okay. I usually work and share thinking, flows, mocks and such using Google Gallery becuase it has a great comment feature that puts comments(and answers to questions) directly on the page item you're speaking to. I realized though that you need to add contributors individually by email. It would be great if we could do that especially as we get into mocks. For now I've also added this round to Dropbox here . These pages are tall but if you use the dropbox controls to view and zoom, they should work.
 
kalaspuffar said:
Hi @FlorinaV

I've read through your feedback, and first of I like to thank you for your time and analysis. Good work so far.

Secondly, I want to apologize that I've not answered sooner, but I have much on my plate at the moment. Will probably have more time when we approach summer. My wife is on the last part of her studies to become a nurse, so that has the highest priority of my side projects.

Now some answers to your PDF:

The first page of the PDF talks about the onboarding experience, and that is completely lacking UX I know. First-time users are having to read much text and then have to choose by creating a new identity, importing an identity with their camera, or if that is impossible, they can fall back to type in the identity by hand. Not the easiest way to import an identity but you can at least use the application independent on device features.

The next screen talks about the creation and rekeying process, and you are right that explaining that the user needs to wave their camera around a bit to get a unique identity might be better worded. Moreover, the step where we explain that the creation process might take some time might not be necessary.

Next screen also has wording problems for new users and should just be fixed. A password strength indicator could be added but requiring users to choose a strong password is something I don't like. Yes, you only choose one strong password but it's your choice, and you need the device to use the identity.

Next question about what "seconds" stands for. Each value in () are quantities for the input. So the first field you supply numbers of characters in your quick pass, next you have numbers of seconds spent to encrypt/decrypt your password and last is minutes your password should be kept on the device.

Next screen with all the buttons needs reworking. I had another grouping in mind, but we could discuss that. Showing the identity name instead of a dropdown when you only have one is a good option and should be easy to fix. When it comes to rekeying, that is an ultimate option you use when you think your identity has been compromised, so you want to change it with a new one. It's not something you should do lightly, then again it does not have anything to do with the login flow.

Next screens question "Why not have a list of sites to log into?" Well first of I don't want to keep a list up to date. People probably not want to save a list of login sites. Lastly, we need the information in the URL to do the actual login function. The URL has a unique value that we use to encrypt and log in. So we need a new link for every login. That's why you log in using a QR code and your camera. Alternatively, if you want to log in on the device, you click a link on the website. Adding an option to enter a login URL manually could be an option but would be very cumbersome and might produce errors depending on how long the link will become.

The question about export options. The Android system uses the share function to send files between applications. Moreover, if you want to save it on the device, you might use an app for that. Then again if you want to export your identity of the phone, you will be required to send it at some point. So of the three options, I see it like this. If you have a new device, then show the QR and export the identity with an image to the camera. If you want to make it permanent then, print it to paper. For any other use, you might share it but this is less secure and only used for the times when you can't securely export the identity.

The last question: YES, that's a bug :(

Again thank you for your feedback and don't take any of my answers the wrong way. I appreciate your feedback, and I'm happy to have you working with us on this project. Some of the feedback I will translate to actionable tasks on Github as soon as possible other we need to discuss further.

Hopefully, we'll get some answer from @Mark_roudebush soon. Otherwise, I might change the lead on this so we can progress.

Best regards
Daniel
Click to expand...
Thanks for that Daniel, I love that Florina is jumping in. It will be great to partner!
 
  • Like
Reactions: FlorinaV and kalaspuffar
Hi @Mark_roudebush

To be clear, the last note was not meant as any criticism. I have been extremely busy at work lately too.
I want us to progress so we can improve the user experience before we release the project to the world.

When it comes to using Google Gallery that sounds like a great idea, and if you want to use that tool then we can request access on person to person basis. Just important that we have a visual aid that we can comment on and that we can work together to collect, refine and finalize ideas.

I am looking forward to seeing what we will create together.

Best regards
Daniel
 
kalaspuffar said:
Hi @Mark_roudebush

To be clear, the last note was not meant as any criticism. I have been extremely busy at work lately too.
I want us to progress so we can improve the user experience before we release the project to the world.

When it comes to using Google Gallery that sounds like a great idea, and if you want to use that tool then we can request access on person to person basis. Just important that we have a visual aid that we can comment on and that we can work together to collect, refine and finalize ideas.

I am looking forward to seeing what we will create together.

Best regards
Daniel
Click to expand...

No harm done at all Daniel. I guess clarifying my intent due to this communication being remote might help. Any questioning I've included in my notes and work was truly about questioning things to find opportunities. I know all of you have put a lot of thought into your decision making and work.

I do think it would be good if I could share Gallery and perhaps some Google docs at some point. Please share (DM if you'd like) a personal email. I'm guessing a google related account will be best.
 
You must log in or register to reply here.
Top Bottom
Back