UX Help welcome

[Mark_roudebush]

@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.

1. Can you explain "CPS (client provided session), which we rarely will on mobile devices"? How is the mobile vs. web experience different?
2. When we say "is this website.com where you want to sign in?", could we render this page and have it be a visual comparison? Just a thought, not necessarily pushing the idea. This seems like a big burden and people will stop reading and start clicking.
3. This is extremely vulnerable to typosquatting attacks as well right?

 

[Mark_roudebush]

Added initial ideas for welcome screen re-work on Google document:
https://docs.google.com/document/d/...c1xEgy398daloxMsE/edit#heading=h.ss2sa1bas6b0
New SQRL Login Screen v1


@Mark_roudebush let me know if you want me to keep going with the "create Identity workflow"

Thank you, first off Silversword. I definitely want all eyes and ideas to help push things. I can see though that this singular forum thread for all topics is become very difficult to track. Being remote with only asynchronous communication is going to add to the inefficiency and I know we all have other full-time obligations. Let me ask you to pause for the moment while I coordinate some process with Florina. I want to make this efficient while getting everyone's input and feedback and moving us forward. I'll report back after Florina and I have chatted. Thanks

 

[kalaspuffar]

1. Can you explain "CPS (client provided session), which we rarely will on mobile devices"? How is the mobile vs. web experience different?
2. When we say "is this website.com where you want to sign in?", could we render this page and have it be a visual comparison? Just a thought, not necessarily pushing the idea. This seems like a big burden and people will stop reading and start clicking.
3. This is extremely vulnerable to typosquatting attacks as well right?

1. The mobile and desktop function is similar but the application on mobile have more choices.
On desktop you can be hijacked if the application don't have a connection to the browser. On mobile we have more security but we implemented the same solution. So if you click a sqrl link on your mobile the website will connect to a webserver running in the application in the same manor that we do on desktop. And the redirect will be initiated from the app.
When you scan the QR Code you are even safer because you side load the login flow which was the original intent but the requirement of validating the login domain is crucial.

2. You could render something but that could be spoofed as well. You could check certificates and show the company name that issued it. And so on. A lot of features could be added here if we want but that would be a question for later implementations.

3. Yes

 

[PHolder]

Can you explain "CPS (client provided session), which we rarely will on mobile devices"? How is the mobile vs. web experience different?

CPS can only work when the SQRL client is on the same IP device as the website being authenticated (because it uses a secondary connection to localhost port 25519 between the browser and the SQRL client.) This means that CPS will not be used if you are using the QR Code reading function on a mobile SQRL client to scan the SQRL QR Code from another device. Here are some scenarios (that all assume a future where SQRL is widespread):

1. You're at work and want to log into your shopping account to make a quick purchase (presumably on your break, which is allowed by your employer.) You're not allowed to install any software on the work PC, so you use the SQRL client on your personal mobile phone. The mobile phone is on the public PSTN so has an IP address supplied by your carrier, whereas your work desktop PC is on the corporate LAN with firewalls and proxies and all those great things companies do to track and control corporate assets.

In this case, there is no way your IP addresses are the same between the two devices. If configured, you should be warned about possible spoofing. The client should know this a likely scenario, so will flag to the server that the IP address matching function has to be disabled. There is no way for the SQRL client on the mobile device to be able to connect to the desktop PC directly to use CPS and to cause the browser to redirect. You will ABSOLUTELY NEED to make sure you are authenticating to who you expect (no typos, no clicking on links from emails, all the usual advice) or else you may be subjected to some sort of phishing attack and log someone else into your account.

2. Working from home, using your mobile, which is also on your carrier and not on WiFi.

The same scenario as #1. You MUST verify you got what you expected by checking the URL.

3. Working from home, using your mobile, which is on your WiFi and your WiFi AP is using a NAT so all devices appear to be a single IP address.

This scenario won't require the option to check IP addresses to be compared to be disabled, so the client could enable it when it knows it is on WiFi. (If it assumes WiFi means from home... there are other scenarios where it will have a different IP address.) CPS will still not work because there is not localhost link between the mobile and the other device.

4. In an Internet Cafe or on Hotel WiFi, using another device. This case, it's similar to #1. You will likely have a different IP address than the other device... because the WiFi supplier may have multiple IP addresses to give out customers on the network, rather than a single one which usually happens with home users.

 

[Steve]

Can you explain "CPS (client provided session), which we rarely will on mobile devices"? How is the mobile vs. web experience different?

Mark: The recently completed and published "What If?..." page in the "SQRL Essentials" section has a number of use-cases that touch on this. You might find it useful to scan through the Q's and looks at the A's that are of interest. (And thanks for all of your work on this!)

 

[Mark_roudebush]

Mark: The recently completed and published "What If?..." page in the "SQRL Essentials" section has a number of use-cases that touch on this. You might find it useful to scan through the Q's and looks at the A's that are of interest. (And thanks for all of your work on this!)

Perfect. I'll dig into this, thanks Steve.

 

[kalaspuffar]

Hi @Mark_roudebush, @FlorinaV and @silversword

I've added comments to the initial audit on Google gallery. Not sure if it will notify you on updates as I never used the tool before so I wanted to notify you here.

Looking forward to your answers and future discoveries as we continue work on the UX.

Best regards
Daniel

 

[silversword]

@kalaspuffar Not sure what "Google gallery" is, there's no such thing unless you're referring to https://material.io/design/ . Didn't see any annotations on the Google Document: https://docs.google.com/document/d/1y7jCXlhBvCI0SLV6k0Mt6V1Izac1xEgy398daloxMsE/edit#

@Mark_roudebush I'm on hold till you need further input.

 

[Mark_roudebush]

Hi @Mark_roudebush, @FlorinaV and @silversword

I've added comments to the initial audit on Google gallery. Not sure if it will notify you on updates as I never used the tool before so I wanted to notify you here.

Looking forward to your answers and future discoveries as we continue work on the UX.

Best regards
Daniel

Thanks, Daniel!
I've got a couple of docs started that I will share soon. I have one fundamental question that I keep going back to. Is it true that users will create a single SQRL account but then create one or more "identities" for websites? And it's the identity that acts as the login? This core concept is tripping me up. Thanks for any clarification.

 

[sengsational]

Mark, Users just create one identity. They don't have to worry about any "identity per web site" stuff. We could tell them that, under the covers, SQRL manages a separate "thing" for each web site, but not sure it's necessary.

 

[Dave]

Thanks, Daniel!
I've got a couple of docs started that I will share soon. I have one fundamental question that I keep going back to. Is it true that users will create a single SQRL account but then create one or more "identities" for websites? And it's the identity that acts as the login? This core concept is tripping me up. Thanks for any clarification.

The SQRL identity that the user creates, sits on the users device. At each site the user visits, that identity is used to (deterministically) generate an identity unique to that site. That identity is both unique and reproducible because it is generated based on site's domain name: example.com. "Alternate identities" for any site can be created by simply taking whatever the user typed (say, XXX) and slapping it on to the end of the domain name and generating an identity as if it were for that domain: example.comXXX.

 

[kalaspuffar]

Hi @Mark_roudebush

What Dave*2 have mentioned is correct. The user needs only one identity for all login needs. A way to authenticate the same person everytime.

Using more than one identity could be seen as an edge case when the person needs to login as someone else like a spouse, or as a different role within a company.

An account in my mind is what you create on the server side and you have the possibility to lock, unlock or remove this account from the application.

Hope this post made things clearer or just ask again. Language could be a barrier but I'm trying my hardest to be clear in my communication.

Best regards
Daniel

 

[Dave]

Using more than one identity could be seen as an edge case when the person needs to login as someone else like a spouse, or as a different role within a company.

As a concrete example, I am both a member of my chorus and the webmaster. I would typically log on to the chorus web site as just me. But, when I needed to do administrative stuff, I would log in using an alternate ID of, perhaps, "webmaster".

An account in my mind is what you create on the server side and you have the possibility to lock, unlock or remove this account from the application.

Hope this post made things clearer or just ask again. Language could be a barrier but I'm trying my hardest to be clear in my communication.

You are doing exceptionally well. This would be more an issue of terminology than one of translation/language. Since SQRL is an entirely new model, this is not surprising. For what it might be worth, I completely agree with your conceptualization of an "account" being what gets created on the web site. When the user goes to a web site, the user's identity for that site is presented and the web site looks to see if that identity has an account on that site. The first time the user goes to the site, there is no account associated with that identity so the user clicks Create Account (or whatever) so, the next time the user visits, the web site recognizes the returning identity as the owner of that account.

 

[Mark_roudebush]

I agree with Dave, Daniel, I think my confusion is more about nomenclature and the new concept. Definitely not a language barrier.
I'm getting there, thank you, everyone. I'll keep asking as suggested. When creating an experience for a, well, anything. It's important to be able to write that experience in clearly and concisely. After all, if it's hard to explain in verbal or written form, we're going to fail in UI form.

Let me take a pass at this part…
As a user, you will create your SQRL identity. This single identity in visual form is a long gibberish of characters. You'll only have one SQRL identity but the system will use it to create unique logins at every site you visit. Unlike passwords, you'll never see or need to manage this behind the scenes process. Unlike passwords, SQRL guarantees that every single site will be a unique way to authenticate you. We've all been told to create unique passwords for every website we visit. When you're using SQRL, that's the only option. SQRL never associates your email or your single, master SQRL password with any website login. Because of this, if a website is breached there is no information to lose. It's up to you if you want to later share your information with a website. That has nothing to do with your SQRL login. SQRL uses "the power of cryptography" (thanks Sengsational) to make this happen for you.

Please tell me where I'm wrong or not getting "it".

 

[PHolder]

I feel like you'd want to tackle explaining the concept of a SQRL identity something like this:

A SQRL client manages an online identity for you. While the identity is a singular thing, it is combined with the URL of the sites you authorize the SQRL client to identify you on. This means that it computes a unique identifier for each site you use the SQRL client with. To prevent misuse of your online identity, and to prevent it from be accessible if your PC is attacked, your SQRL client protects your identity with a password, and requires you to provide it before allowing you to use your SQRL client. The password is only used locally to unlock your SQRL identity, it is never transmitted to the sites you visit, and it is not part of your identity--you may update your password whenever you feel the need, without informing any site. The identifier that the site is given is a mathematical value, known as a public key. The public key is tied to a private key which your SQRL client creates just for that site, and never shares with it. When the site wants proof of your identity, it sends a secure random value (one that never repeats, preventing replaying login by an attacker) that your SQRL client will use to compute a signature with the private key. Since the private key and the public key are mathematically related, the website can verify that the correct private key was used, without it ever having been transmitted to the website. This bit of mathematical manipulation means the website never has any secret to keep... it's called a public key because it doesn't need to remain private.

 

[AlanD]

At some point it may also be relevant to mention that, for some sites, but only some sites,, you will need to provide "real-life" identifying information and link it to your SQRL ID. For example, if you use SQRL to sign on to a shopping site, they will need to know your real name and address to deliver the goods.

 

[Dave]

At some point it may also be relevant to mention that, for some sites, but only some sites,, you will need to provide "real-life" identifying information and link it to your SQRL ID. For example, if you use SQRL to sign on to a shopping site, they will need to know your real name and address to deliver the goods.

Good point, Alan! I had a similar thought... but... forgot where. Yes, any site could insist on a verified email address - or even a physical address, for that matter - as a condition of membership. But that would be entirely up to and part of the web site and it's raison d'être. It would have nothing to do with SQRL and nothing about a site using SQRL for authentication prevents them from doing so.

 

[Mark_roudebush]

Thanks guys. Let me ask you. There's a lot of new concepts and a lot of technical concepts with SQRL. If you imagine a person you know who is not technical, we all know many, do you think that they would understand those explainations? I personally find the details you've been sharing in the past few pages of this forum fascinating. It's an amazing creation. Will the average person think so? What part of SQRL would get the average person excited without losing them. I say that not from the perspective that they won't get it but I'm more interested in what would get them motivated to do the download and stick with us through ID creation and then make the choice to not use their pw manager and instead use SQRL. What are those points?

 

[PHolder]

Well I think the selling feature depends on who you are.

If you've ever had a password "stolen" or "leaked" then you will probably really care about the fact that SQRL absolutely solves that problem forever. (Well, as always, it solves it for those sites who adopt SQRL.)

If you already use a password manager, you may appreciate that SQRL is slightly easier to use, and that it doesn't keep any of your security data online. (This is also a bit of a downside for some users, because the requirements to backup and sync data now fall to them.)

If you're a nerd and/or technology lover, you may well have already used SSH, and SQRL is like a shinier version of the public/private key abilities already built into SSH.

If you need your hand held through every step of a change... an evolution to SQRL is no doubt going to be discomfiting... there seems no way around it but to have lots of ways to show it's not really harder... it's just different than what you already know... (so videos, text, and a friendly app, and t-shirts )

 

[Gristle]

If you imagine a person you know who is not technical, we all know many, do you think that they would understand those explainations?

It all boils down to what matters to the person. For me, the simplest thing I could say to excite a non-technical person is that SQRL logs into websites for you, and you don't need to remember or even create a username and password, and the sheer simplicity of logging in, literally just tapping login, and magic! You're logged in securely!

If that isn't enough to excite them, then I doubt anything else will. The wow factor is truly when they see it in action, so I firmly believe this will all be driven by word-of-mouth and press coverage.

When I compare this to "you should use a password manager, be sure to make different passwords for each site, and Oh! Also don't forget to use two factor authentication, but not SMS codes because those are insecure" their eyes glaze over in frustration.