Poll: Should the Android client remember Alt-IDs?

  • New Wordpress Plug-In Forum
    Guest:

    Just a note that we have a new forum to contain discussions relating to the Wordpress plug-in which Daniel Persson originated and has been making great progress on. You'll find it under "Server-Side Solutions."

    /Steve.

Should the Android client remember your Alt-IDs?

  • Yes, it should remember all my Alt-IDs and also which site they belong to

    Votes: 1 5.9%
  • Yes, it should remember all my Alt-IDs but NOT which site they belong to

    Votes: 3 17.6%
  • It should ask me which one to remember, so that I can choose only to remember non-critical ones

    Votes: 6 35.3%
  • No, remembering Alt-IDs should be left to the user

    Votes: 7 41.2%

  • Total voters
    17

ahauser

Well-known member
Feb 22, 2019
82
24
Following the prior discussions on remembering Alt-IDs, I thought I would post a poll regarding this topic.
Looking forward to getting in as many votes as possible. Thanks!
 

PHolder

Well-known member
May 19, 2018
918
124
I voted for "ask". But I want to clarify what I mean. It is implicit in doing ANY option, that it will need to remember some of the sites you use the client with. (Because if you ever say yes, it has to remember which sites you've said yes to.) So the option to the user needs to be nested in some way:

Remember sites you access via SQRL: [ NEVER | ASK | ALWAYS ]
.... then if the user selects ASK or ALWAYS:
........ Remember Alternate-IDs you use with sites: [ NEVER | ASK | ALWAYS ]
 

kalaspuffar

Well-known member
May 19, 2018
269
91
Sweden
coderinsights.com
Hi everyone

I vote for keeping this functionally out, maybe add it to a pro version with other none essential functions. But adding a feature that will remove privacy is not something I would like to see in the regular Android client.

It might also build extra complexity and more code paths to test which adds development time.

Best regards
Daniel
 
  • Like
Reactions: Gristle and Dave

shanedk

Well-known member
May 20, 2018
317
86
I REALLY don't understand how this feature would "remove privacy," as long as it's stored in S4.
 

Vela Nanashi

Well-known member
May 19, 2018
633
107
I voted for ask, but my view on it is more complicated:

I think there should be an option to enable the function, or leave it disabled, the enable could have options for if the list is going to be global or per site or ask every time :) That way the users have maximum control of how it works for them.

I would not want the feature enabled for most things, but perhaps if I used a alt-id a lot I would want it.

The reason it is a privacy concern is if the identity gets stolen (the S4 file) and its password cracked, then all those alt ids will be revealed and any site list too, and it would allow the attacker to much faster compromise the user in every place they have used the identity.

A list encrypted to the private/public key that is unlocked by the rescue code and only accessible via it could be a safe way to store things so that it can't be compromised if the identity file is stolen and cracked, since rescue code won't be in any password list or particularly memorable, unlike what the passwords users will probably/usually use will be. But rescue code should not unlock convenience functions, since then people will be likely to keep it in their phone or something silly like that.
 
  • Like
Reactions: Gristle

Gristle

Well-known member
Feb 16, 2019
341
70
Post removed due to harassment from PHolder
 
Last edited:

ahauser

Well-known member
Feb 22, 2019
82
24
... clients must support it to strongly discourage creation of multiple identities, but it's not part of a typical user flow, so it should not be presented to them by default.
For everyone who's not aware: That's exactly how it is currentlty implemented in the latest version of the Android client. The Alt-ID feature (as well as others like disable/enable/remove account) are hidden within an "advanced functions" dropdown area and therefore not readily accessible during the login flow.

To the point about whether the app should store it, I believe Steve's recommendation was the the SQRL client retains no statefulness, otherwise syncing between clients becomes an additional expectation for users.
Yeah, but remembering something without storing it will get difficult. So it should be clear to everyone that we are inevitably leaving statelessness-town when we implement features like that.
 

sengsational

Well-known member
Feb 17, 2019
115
34
Novice users expect state to be maintained in an application. We already manage state of QuickPass.

I know I'm in the abject minority here, but I think that we should save not only alt-id's, but also ALL domains that have had a successful authentication. The purpose of the latter is so that if a new domain comes along, we can make the user jump through more extensive hoops to make sure the domain is not spoofed. I've mentioned this before, but it bears repeating: if a user is asked to validate a domain with a level of insistence every time, it will become automatic, and they will do whatever it takes to get past it, without even thinking about it. If you make it occasional and ONLY when needed, there's a much better chance they'll pay attention when their attention is really needed.

The objection is typically, "yeah, but then what about the user's other devices?" Well, we already let them change the password on one device and not the others. We tell them (remind them), "there's no cloud sync because that's needing to trust someone". It's up to you to keep your clients in sync or know they're not in sync. Another objection is that the alt-id can be another level of security (somehow a bad guy gets your master password and your unlocked device, ok, I suppose it could happen), then they try to log in, but you've got an alt-id of something unguessable...that's the "another level of security". But if most people use "1" or "alt", there's not much security there (guessable). But if you ARE trying to get more security, let the saving be optional. It's as simple as a "remember on this device" checkbox when an alt-id is entered.
 
Last edited:

Gristle

Well-known member
Feb 16, 2019
341
70
Post removed due to harassment from PHolder
 
Last edited:

Gristle

Well-known member
Feb 16, 2019
341
70
Post removed due to harassment from PHolder
 
Last edited:

PHolder

Well-known member
May 19, 2018
918
124
thus need a client to sync a database across to other clients
No, not necessarily. Sure that would be an advantageous feature, but I suspect that people who use more than one client use them in repeated circumstances. And if each client remembers what it's given, then any sync process is the user. So the user decides they need to do something on the mobile device for the first time, they provide the data from the desktop device themselves, and now both devices have the same information. Since these are not changeable, it's basically an "input once remember it forever situation." The situation around rekeying is actually worse, IMHO.
 
  • Like
Reactions: Dave

Gristle

Well-known member
Feb 16, 2019
341
70
Post removed due to harassment from PHolder
 
Last edited:

shanedk

Well-known member
May 20, 2018
317
86
The Alt-ID is just a small bit of text the user inputs into a field. I think they can handle it.