Feedback on Subdomains

rwinch

When I have passwords for different sub domains of the same parent domain, all my password entries are shown and sorted by sub domain. For example, if I had password entries for a.example.com b.example.com c.example.com and visit c.example.com 1Password would prompt me to fill out a.example.com b.example.com c.example.com passwords in that order (appears alphabetical).

I think it would be useful to make it easier to find the correct domain in this context. Perhaps, the extension could only show an exact match on the domain if it is found with an option to show sub domains as a second level click. This not only helps the user select the right password, but helps to keep your password safe from accidentally submitting to the incorrect domain.

Cheers,
Rob

PS Glad to see Linux Support in 1Password!

---

1Password Version: Not Provided
Extension Version: 0.8.0
OS Version: Ubuntu 16.04.1 LTS
Sync Type: Not Provided

beyer

Hey @rwinch,

Welcome to the 1Password for Chrome beta!

I apologize because I'm not positive what our ultimate goal will be when matching domains, but I think a nice compromise might be a smarter sort method. In my head, I believe that this order would be great:

1. Items that match the domain and are marked as a favorite
2. Items that match both the domain and subdomain
3. Items that match the domain

Many users have Login items that they use across multiple subdomains, which can be an issue when doing exact matching. I figure having a smarter sort method could be helpful for them, and anyone that needs a Login for a particular subdomain.

What do you think about that?

--
Andrew Beyer (Ann Arbor, MI)
Lifeline @ AgileBits

rwinch

Thanks for the fast reply @beyer!

I think a smarter sort would be a huge step in the right direction. I'm not sure if it is implied, but could the sort be modified to:

1. Items that match both the domain and subdomain are marked as a favorite
2. Items that match the domain are marked as a favorite
3. Items that match both the domain and subdomain
4. Items that match the domain

Although not necessary, it might also be nice if there was a visual indication on how much of the domain matched. For example, if I was at c.example.com, then the entire entry for c.example.com would be green and bold (or something like that). The b.example.com would only have example.com green and bold.

beyer

@rwinch: I like it, let me see if I can convince everyone else. :) :+1: I can't promise when or how we will change sub/domain matching, but I like this idea the best so far.

Thank you so much for providing this feedback. I hope you have a great weekend!

--
Andrew Beyer (Ann Arbor, MI)
Lifeline @ AgileBits

dteare

Thanks for the feedback, @rwinch! I appreciate it.

The issue you're describing is one we've been iterating on for over a decade now, so it's near and dear to my heart! :)

One of the ideas we played with long ago was to show how well a saved login matched the current domain. In one iteration we showed the "strength" of a match by displaying bars like you'd see for signal strength on a mobile phone. Here's how things looked on Mac circa 2010:

This is not identical to what @beyer was saying with his "marked as a favorite" suggestion, but it's on the same wave length. We had it this way for a few years and I personally liked it, but the vast majority of users didn't understand what these strength bars were about so it resulted in a lot of confusion. I expect similar issues with logins magically appearing as favourites and then losing that status when navigating to a different page (it will make sense to us but it will be magical and unexpected to most).

We've toyed with many other ideas as well, including the current approach on Mac where we show the set of best matches first and then hide the rest under a More menu. This has several benefits and indeed that's why we continue to use this approach on Mac today, but it's not perfect. I routinely see users ask why things are sorted the way they are, as well as requests to just remove the More menu entirely to avoid the extra click required to get to the additional logins.

With our new extension we're recreating everything from the ground up so we have a chance here to experiment with an entirely new design. One of the things we wanted to simplify in this design was to change the domain matching process into a binary decision: either a login matches the current domain and appears within the fill tab, or it doesn't. And we are trying to avoid any magical colouring, favouriting, or sorting and instead simply sort by title.

It's nice and simple, clean, and easy to understand. So far I've been enjoying it immensely.

Now the thing is, what are power users like yourself and I supposed to do on those sites that have tons of logins saved? That's where search comes in. I've used this at least a hundred times on sites that have more than 10 logins and I think it works pretty well. What I love most about it is search is integrated directly with the fill tab so you simply start typing and the list automatically narrows down to those logins which match your search criteria and the current domain that you're on. There's no switching contexts or hot keys required. Simply start typing what you're looking for and 1Password will highlight it for you. And the search includes all the login's URLs as well so there's no need for any special naming conventions, either, which gives another ++ to the simplicity of this entire approach.

Hopefully that helps explain where we're coming from and with any luck you'll come to love the search as much as I do.

rwinch

Thank you for your response @dteare

Now the thing is, what are power users like yourself and I supposed to do on those sites that have tons of logins saved? That's where search comes in.

This is quite useful information. I'm sure I will start using this trick. Thanks!

One of the things we wanted to simplify in this design was to change the domain matching process into a binary decision: either a login matches the current domain and appears within the fill tab, or it doesn't

What scares me is that my password from a.example.com might accidentally be submitted to c.example.com. What's more concerning is the UI makes submitting the wrong password easier than submitting the correct password.

One might respond that it shouldn't matter you are submitting the wrong password to the different sub domain, because it is a part of the same parent domain. This is not true. A sub domain resolves to its own IP address and thus is a separate entity (browser same origin policy acknowledges that sub domains are distinct). I have many sites where a.example.com and c.example.com are submitting to totally different entities and I don't want one to know the other's password.

One example of this is where a corporation brands a third party site and allows it to partake in a sub domain. For example, vendor.my-company-i-work-for.com should not receive the password for email.my-company-i-work-for.com

Another example of this are where sub domains are given to third parties for free based upon a parent domain. I see this with PaaS solutions that allow developers to deploy code to app.the-pass.com With the current setup a malicious user might try and phish your password at appp.the-pass.com to try and steal your password.

I realize that there are instances where the same password is shared across sub domains. However, I think that 1Password should make the user think twice about submitting a password to the incorrect domain. For me a large part of the value in a password manager is to ensure that my password is only submitted to the site it is suppose to. I'd really love for 1Password to help me (and others) submit the correct password to the correct site.

Thanks for receiving my feedback and keep up the great work!
Rob

beyer

One of my favorite parts about working on this project (besides being a huge Linux fan) is the fact that I get to soak up the wealth of knowledge and experience Dave holds.

The examples you raise are certainly valid in my opinion, and they are a good "selling point" to keep the More menu we have on the Mac. With the More menu, users at least need to take at least one additional action to fill a Login item that doesn't match the current subdomain. This is the classic usability vs. security dilemma that we face every day. The more restrictive we make filling, the harder we make 1Password for many users. I can confirm what Dave said; we have customers that write in every day asking about the More menu and wondering why only some of their Login items are listed. A classic example is how Google changed all of their sign-in domains to use https://accounts.google.com, which causes a lot of confusion for users that created a Login item back when you might sign in at https://mail.google.com.

I understand in the current context, we are dealing with what I'd call the "1Password Power Users", but 1Password for Chrome is going to be used by many types of people. Chromebooks are extremely popular, especially in the educational market, so we need to also look at how our decisions are going to affect our "non-power users".

That being said, I don't disagree with you. In fact, I have an additional security concern to add to this conversation. One thing I would like, but we don't currently do, is to take the port number into consideration on filling. I could not only have different Login items for a separate subdomain but what about different ports? Port 80, 443, 8080, etc. could technically all be a different Login page, and I almost never want to fill on port 80 (the standard for HTTP). Like everything, there are good reasons for why we do and don't do some of these things, half of which I, unfortunately, don't know the complete history. Luckily, even our founders (wave to Dave) are still actively involved in everything we do.

One possibility is to expand our filling preferences, but I can't guarantee what the future holds. Either way, I greatly appreciate you bringing up this issue. Passionate users create passionate developers, and we all benefit from that.

--
Andrew Beyer (Ann Arbor, MI)
Lifeline @ AgileBits

greew

Hi there :)

Currently the plugin doesn't distinguish between subdomains.

I'm daily working on both a.example.com, b.example.com and c.example.com and when I open any one of these, I have to select between the three, even though they all have the full domain including subdomain defined in the website section.

Is this something you'll be looking into?

---

1Password Version: Not Provided
Extension Version: 0.8.5
OS Version: Ubuntu 17.04 - Chrome Version 60.0.3112.90
Sync Type: Not Provided

beyer

Hello again @greew,

Great question! This is a topic that I can't cover nearly as well as @dteare has in this thread. I've merged your post here so you can hear directly from one of our founders (also known as my boss). ;)

Please let us know what you think and I'll be sure to pass your feedback along. I hope you have a pleasant weekend. :)

--
Andrew Beyer (Ann Arbor, MI)
Lifeline @ AgileBits

wagner_n

I've been suffering from the same problem greew reported. I'm currently using 1Password for Mac, Windows and iOS. All of them match the subdomains accordingly, except the Chrome plugin.

AGAlumB

I hear you. And it can also depend on your settings, which adds another layer of complexity. But I'm sure that Dave and Beyer can come up with a clean solution here, some ideas of which were discussed above. Cheers! :)