Skip to content
This repository has been archived by the owner. It is now read-only.

Allow user to "Lock" editor via "Sign Out" to prevent unwanted access to Lockbox data #149

Closed
devinreams opened this issue Oct 9, 2017 · 15 comments · Fixed by #513
Closed

Allow user to "Lock" editor via "Sign Out" to prevent unwanted access to Lockbox data #149

devinreams opened this issue Oct 9, 2017 · 15 comments · Fixed by #513
Assignees
Milestone

Comments

@devinreams
Copy link
Member

@devinreams devinreams commented Oct 9, 2017

When letting a friend borrow my computer and browser, I need to be confident that the data in Lockbox is secure-able and control-able by me, so that I can prevent unauthorized access to my credentials locally.

For Alpha, this involves the option to "Sign Out" similar to other FxA reliers, as seen in this visual design: https://mozilla.invisionapp.com/share/MHEBCD4PK#/screens/264252691

Acceptance

  • When FxA is attached to Lockbox account, there is an option "sign out"
  • Datastore will always be "unlocked" and local for users that don't have FxA attached (just like Firefox today without a master password)

ToDo

  • implement "light" sign out vs. "full" sign out
  • implement "signout" backend message
  • implement user action (#442 )

Future considerations

  • Research questions specifically as it relates to locking via sign out & terminology research (what words do we find our target audience using?)
  • Lock / Unlock visual interactions to accompany sign out / sign in
  • Independent lock/unlock options from sign out/in should target audience require it
@changecourse

This comment has been minimized.

Copy link
Contributor

@changecourse changecourse commented Oct 11, 2017

I know that there's been some discussion about 'lock' vs. 'sign out' so I figured I'd post my perspective here...

I agree that lock/unlock is the literal action that is being taken, and thus a potentially good place to start (for alpha) but I do want to point out a few things:

  1. Both locking and signing out accomplish the same task, no? The main goal we have for this functionality is for someone who is using lockbox to be able to secure their entries behind their master password...

  2. We may not want to have separate but similar actions in the future, for account sign out vs. lock/unlock, I would argue, but instead have a singular approach that unifies the two end goals (for access or protection)

  3. Signing In/Signing Out is something that users would largely understand, because they encounter it in every instance where they are required to have an account... Locking vs. unlocking is something that would have a higher chance of user confusion when compared to the alternative of sign in/sign out.

3rd party password managers also follow a similar behavior, such as Lastpass, where there isn't dual options for both locking as well as signing out... and they have chosen to take a route (I believe) where signing in/signing out would be applicable for handling lock/unlock...

screen shot 2017-10-11 at 3 52 04 pm

@jimporter

This comment has been minimized.

Copy link
Contributor

@jimporter jimporter commented Oct 11, 2017

Both locking and signing out accomplish the same task, no?

They aren't the same. Signing out implies resetting any ephemeral state as well (like when you sign out of your computer). Locking implies that ephemeral state is maintained, but hidden.

We may not want to have separate but similar actions in the future, for account sign out vs. lock/unlock, I would argue, but instead have a singular approach that unifies the two end goals (for access or protection)

That may be, but we're not there yet. In any case, if I "signed out" of Lockbox, I'd expect to have to go through the first-run flow again so I could select the Firefox Account I wanted to use (much like what would happen if I signed out of Facebook). However, I wouldn't want to do that every time I wanted to secure my passwords.

Signing In/Signing Out is something that users would largely understand, because they encounter it in every instance where they are required to have an account... Locking vs. unlocking is something that would have a higher chance of user confusion when compared to the alternative of sign in/sign out.

I couldn't disagree more. There's already quite a bit of precedent for using lock/unlock as the terminology for this sort of behavior. When I tap my phone's lock screen, it says "Press home to unlock". Not only that, our project is called "Lockbox", so the metaphor at work here is that we are a storage container with a combination lock that the user can lock to secure their belongings and then later unlock (with the contents in exactly the same position as before) by entering their combination.

@changecourse

This comment has been minimized.

Copy link
Contributor

@changecourse changecourse commented Oct 11, 2017

That may be, but we're not there yet. If I "signed out" of Lockbox, I'd expect to have to go through the first-run flow again so I could select the Firefox Account I wanted to use (much like what would happen if I signed out of Facebook). However, I wouldn't want to do that every time I wanted to secure my passwords.

This is where I disagree... Mostly because I don't think we'd assume that multiple people would be using different lockbox accounts in a browser.

Are you posing that we have an experience similar to bitwarden, with explicit lock functionality, as well as sign out?

screen_shot_2017-10-11_at_4 17 25_pm

Locking prompts for master password, logging out prompts for user name and password.

My qualm here is that they are nearly identical in terms of outcome... the only difference is whether or not the user name is preserved, which I would argue we'd want to just bake into the login screen to account for...

@linuxwolf

This comment has been minimized.

Copy link
Member

@linuxwolf linuxwolf commented Oct 11, 2017

In thinking about this terminology difference for the last couple of weeks, and I'm of two minds.

To me, they mean different things, but I'm a special snowflake because:

  1. I'm a highly technical person that has almost 20 years of experience working on client/server application sets and almost 10 years working on security-oriented client/server application sets.
  2. I've been working on something like this project for the last 18 months, and eyebrow-deep in this specific project for about 9 months.

However. Using the anecdotal evidence of observing non-technical friends and family, the terms lock/unlock mean the same thing as sign out/sign in -- "I have to sign in (unlock) in order to get to my stuff again". To them there is no distinction in the term, and their eyes almost literal glaze over when I talk to them about those differences for more than 60 seconds.

For the foreseeable future of this application, there is no reason to have a distinction. Even when a off-device synchronization/backup feature is implemented, the distinction between locked and signed out is going to be lost on our target audience; besides there are better terms we can use -- be it "offline" vs. "online ", "disconnected" vs. "connected", or maybe even "local" vs. "cloud".

So with all that, I think using signed out will better match our target audience's notions. It might get eyerolls and sniggering from the highly technical that would deep down understand, but they're not who we're trying to change.

@jimporter

This comment has been minimized.

Copy link
Contributor

@jimporter jimporter commented Oct 12, 2017

This is where I disagree... Mostly because I don't think we'd assume that multiple people would be using different lockbox accounts in a browser.

I'm not sure we can assume that one Firefox profile = one user. Anecdotally, lots of people - including fairly technical ones - use one profile for multiple users, so this is something we may have to contend with in the medium term. In particular, Firefox makes it a lot harder to handle multiple real users under a single OS-level user account than Chrome does. Chrome, as I understand it, lets you pretty easily create a new browser instance running under a separate profile by clicking through a couple menus; Firefox requires you to know the correct incantations to supply via the command line. This might be more the responsibility of the Firefox team (or the Firefox Accounts team), but it's something I think we'll need to keep in the back of our minds.

Are you posing that we have an experience similar to bitwarden, with explicit lock functionality, as well as sign out?

This might actually be necessary, yes. At the very least, I wouldn't want us to poison the well, so to speak, for "true sign-out" so early in the game by referring to lock as "sign out". It would be really confusing if we changed the semantics of "sign out" after we have established users!

However. Using the anecdotal evidence of observing non-technical friends and family, the terms lock/unlock mean the same thing as sign out/sign in...

If this is true, then the more-precise terminology (lock/unlock) is equally comprehensible to non-technical users, so we should probably go with that because it also conveys the right information to more-technical users as well. Still, it would probably be helpful to examine this in a more scientific manner.

So with all that, I think using signed out will better match our target audience's notions. It might get eyerolls and sniggering from the highly technical that would deep down understand, but they're not who we're trying to change.

My worry is that we're going to make people more hesitant to click "Sign out" since it implies to me a loss of ephemeral data and a more-complicated sign-in process (e.g. going through the first-run flow again). I think anything that would make people less likely to lock their password store when they might otherwise want to be should viewed with extreme suspicion.

I also believe that we should be working to educate the less-technical users of our product so that they can understand the prevailing terminology and make informed decisions based on that. Since "lock" and "unlock" are the most-accepted technical terms and already well-established in end-user interfaces for securing/accessing private data, I think we should default to these names unless we have evidence that they're worse than other options for some reason.

I'd like to stress again that I'm open to alternatives, provided we have evidence that lock/unlock are less clear for our target audience. However, to my knowledge, we don't have that evidence yet, and I'd prefer we default to the more-precise terms for the time being.

For what it's worth, I discussed this with a non-technical friend and their first instinct was that "sign out" would force the user into a more-complex sign-in flow (i.e. entering the username as well as the password), since that's consistent with their experience on sites like Facebook. Obviously, this isn't statistically significant, but it does give me further reason to suspect that "sign out" is the wrong choice.

@hmcgaw

This comment has been minimized.

Copy link

@hmcgaw hmcgaw commented Oct 12, 2017

I've captured the questions and hypothesis from this thread (so far) into a research card which we can review when preparing for the next study: https://trello.com/c/4pplu9Za/56-what-are-lockbox-users-expectations-with-unlock-lock-and-sign-in-sign-out

@sandysage

This comment has been minimized.

Copy link
Contributor

@sandysage sandysage commented Oct 12, 2017

I think there are some great points here. Along with a slew of assumptions as Heather points out, in the Trello research card.

So let's explore this more with user research (a question or 2) in an upcoming effort to understand users' experience of Lockbox Alpha.

For today, let's just get Alpha released. What is the fastest path forward?

@sandysage

This comment has been minimized.

Copy link
Contributor

@sandysage sandysage commented Nov 6, 2017

This likely changes given the approach outlined for securing Lockbox with a FxA as scoped in #209. To be reviewed with the content team around the overall content strategy. Moving to in-progress.

@sandysage sandysage added in progress and removed backlog labels Nov 6, 2017
@devinreams devinreams added to do and removed in progress labels Nov 7, 2017
@devinreams devinreams changed the title Allow user to "Lock" editor Allow user to "Lock" editor aka "Sign Out" Nov 28, 2017
@devinreams

This comment has been minimized.

Copy link
Member Author

@devinreams devinreams commented Nov 28, 2017

Latest design reflects a dropdown in the main editor only to "Sign Out" which effectively locks:

1_1_0_lockbox_home_-_authenticated_profile_doorhanger

... and then requires FxA auth to happen again when browser action clicked:

d_1_1_0_default_-_locked_state

https://mozilla.invisionapp.com/share/MHEBCD4PK#/screens/264252691

@jimporter

This comment has been minimized.

Copy link
Contributor

@jimporter jimporter commented Nov 28, 2017

Latest design reflects a dropdown in the main editor only to "Sign Out" which effectively locks

Now that FxA is optional, what are we going to do to let users without FxA secure their passwords? Will the datastore always be unlocked for them? If they have some way of locking the store, then we should probably stick with "Lock/Unlock", since there's not really anything for them to "sign in" to.

Signing in makes some sense for FxA, but even there I think lock/unlock makes more sense, since it fits in better with the "Lockbox" metaphor.

@linuxwolf

This comment has been minimized.

Copy link
Member

@linuxwolf linuxwolf commented Nov 28, 2017

Now that FxA is optional, what are we going to do to let users without FxA secure their passwords?

We will nudge them to sign up for FxA and improve their security.

Will the datastore always be unlocked for them?

Yes, it will always be "unlocked"; it will also always be local for them.

@devinreams devinreams mentioned this issue Nov 29, 2017
2 of 2 tasks complete
@devinreams

This comment has been minimized.

Copy link
Member Author

@devinreams devinreams commented Dec 6, 2017

@linuxwolf @sandysage to confirm your discussion: this will not be part of the 0.1.4 release and will be related to #384. Please correct me if wrong. 🙃

@sandysage sandysage added backlog and removed to do labels Dec 8, 2017
@sandysage sandysage changed the title Allow user to "Lock" editor aka "Sign Out" Allow user to "Lock" editor via "Sign Out" Jan 2, 2018
@sandysage

This comment has been minimized.

Copy link
Contributor

@sandysage sandysage commented Jan 2, 2018

I edited the top level description to better encapsulate the decisions and notes from this thread.

@linuxwolf

This comment has been minimized.

Copy link
Member

@linuxwolf linuxwolf commented Feb 2, 2018

Re-opened, as it depends on #442 for user-facing actions.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants
You can’t perform that action at this time.