Matching sub-domains [No plans for this]

AGAlumB

As you noted, it's already possible to associate a Login with different websites by adding multiple URLs. That's not only very discoverable (as opposed to an unintuitive settings screen) but it also ensures that people aren't running into confusion (or phishing attacks) because of something wholly disassociated from the Login they're actually using which they'd set at some point. You can already accomplish what you're trying to do by adding the URLs you want to specific Logins. That ensures that you actually do want to have those specific login credentials (as opposed to any you save for a given URL ever — or those in a shared Login) are intended by you to be used across those sites. And it is easy for the user to change that URL list for a Login at any time right from within that Login, immediately before or after using it (and deciding a change is necessary), without having to search for obscure settings or as us where to find them. Pretty much anyone can do that, and as such that's a benefit to all 1Password users. It's possible we'll add more flexibility in the future, but we try to focus on working on things that benefit the most 1Password users without being to the exclusion of others.

Telokis

Thank you for answering so quickly! I have to admit that it's easy for a tech enthusiast like me to forget that people may not be so at ease with technology and config options.

But regarding your point, it seems a bit counter-intuitive to me: you say that people could unintentionally be phished because of the settings but, on the other hand you say that it's very intuitive to add domains to a specific login.
Since someone from the team also stated that it's very rare for the majority of people to have more than one login per site, I feel it's even less safe this way, then.
Maybe I wasn't too clear but the URL equivalent setting has to be set manually by the user, there is none by default (and if there are, they are ones the 1password team chose like the apple.com one). Ans since it's not a very discoverable option, we don't run into the issue of people doing mistakes.
By the way, I'm not really sure that the majority of people even know what is a URL or a domain anyway.

It's possible we'll add more flexibility in the future, but we try to focus on working on things that benefit the most 1Password users without being to the exclusion of others.

That's exactly why I thought the settings was a good idea. Nothing changes unless you want it to change.

Do you think the same way regarding the "URL Rules" section I talked about as well?

AGAlumB

@Telokis: As a nerd, I think both are interesting ideas, but I would hate for 1Password users to have to deal with something like that (apart from the few who would want to). When you say "URL rules", unless I'm misapprehending your meaning, that's what I was referring to here:

it also ensures that people aren't running into confusion (or phishing attacks) because of something wholly disassociated from the Login they're actually using which they'd set at some point.

It's settings that potentially impact the behaviour of all saved Logins which are completely divorced from the actual Login items. We've been trying to avoid and reduce stuff like that, like the old "Show logins which closely match the current web page" (or something — I can never remember the exact verbiage since we changed it so many times) which was removed in version 7, which caused untold confusion for users of all technical backgrounds, including us.

So I think it's important to take a step back and look at the problem trying to be solved, how it's affecting people, and just how big that impact is before tacking on options. Often they're not the answer, as they introduce more problems (bugs, confusion, etc.) Any option we add, people are going to use it whether or not they need to or even understand what it does. So that's absolutely something we need to consider as well.

Telokis

@brenty Thank you, I think I get your point, now. Moreover, since this feature already has a working solution, I'd say it's good enough (even though I still think it's not optimal because I probably won't be able to explain to my grand parents what a domain is. I would have liked to be able to configure it for them from some settings in the family account).

Regarding URL Rules, I don't think it applied to the quote you stated since the option doesn't seem to exist at all inside 1P.

To quote myself, here is the part about it:

Regarding the original issue of this thread, couldn't you implement something similar to what LastPass does with its URL Rules like you can see in this screenshot ?
Basically, it allows users to specify custom rules telling it how to treat the different websites URLs. It even allows port and path matching.
The good thing about an account-wide configuration is that it doesn't affect users not interested in this feature at all. Moreover, if one site needs exact matching once, it will need exact matching everytime.

This could only make matching more restrictive, not less. It basically allows the user to say "Hey, when I am on the domain https://drive.google.com, I want 1P to consider it as an exact match." Meaning https://mail.google.com data would never show up on https://drive.google.com and the drive data would never show up on any other google.com subdomain.

The way LastPass does it also allows it to match port and even the path. Those two are even more niche, though!

AGAlumB

@Telokis: Hey, I'm sorry for being so bad at making my point on this topic, and I appreciate you bearing with me while I try! :lol: I agree with you: what we have now isn't optimal either. I think there's definitely room for improvement. It's just really tricky because any change we make will impact millions of 1Password users, so we really need to think things through carefully. Perhaps the only thing worse than not having a feature you want is us giving it and then taking it away because we did not foresee a negative outcome. :scream: But perhaps we'll be able to come up with something that can help even more people in the future. :)

intripidsilence

I still don’t understand why you cannot give advanced features like this to power users who enable the feature which is off by default. That would affect zero users out of the gate and provide a very simple support answer for those who turned it on but did not understand it - to turn it off.

Telokis

@intripidsilence From what I understood (I've been reading lots of threads about this) they don't want 1P to be able to work in a way that would do things without the user specifically telling him to do it.
It's not that they don't think it's useful, it's more like they are not 100% convinced by the solution and, so, want to think about it more. (Even though I still found this issue brought up in a 2014 thread, I think)

I have to admit that I still don't really understand how a setting for "Equivalent domains" could potentially harm users since it also is a voluntary thing from the user end.
(And, by "Equivalent domains", I refer to the possibility to teach 1P that two domains share the same logins. Retroactively)

The "URL rules" I talked about is a little bit annoying to me since there doesn't seem to be any way to make 1P behave this way. I saw something about "lenient matching" while looking for solutions but I think it's obsolete information.

@brenty May I try to summarize your position regarding what I am suggesting regarding the "Equivalent domains" setting? (Please tell me if I missed or misunderstood an argument)

• You don't really like having options/settings that may alter login informations for the user without him seeing through the details and implications.
• Having a (probably) complicated interface to configure such an important thing could confuse the "mainstream" user and potentially make him do unintentional mistakes.
• Someone with bad intentions could potentially trick a user and make him add totally-safe-website.hax as an equivalent domain to google.com which would obviously be very ultra bad news.
• There already is something available to address this specific issue and, even though it is not necessarily optimal, it works and doesn't seem to grow the "attack space" too much if used by non-initiated users.

Please tell me if I'm being too insistant here. Let's say I'm used to discussing issues on github! ;)

By the way, even though it was the original subject of this post, I still think you didn't comment about the "URL Rules" proposal I talked about (I agree that some arguments overlap, though). This would basically allow the user to specify strict matching rules for specific concerns like the port, the subdomain or the path of the website.

intripidsilence

Yes my point is similar. If the feature is a non-default option I don’t see how it causes issues with the larger user base who will never even see it most likely.

AGAlumB

@Telokis: I think that's a fair summary. Thank you. :)

The old "lenient URL matching" option you referenced would have had the opposite effect to that being discussed here: it ignored subdomain completely and showed all matches for the domain as being equally relevant. Caused a lot of confusion, so we removed it. It's just one of many real world cases where having options in this area can be more trouble than it's worth to the vast majority of users. A lot of people checked that, forgot, and ran into a lot of confusion and frustration as a result. We could never find wording that made what it did crystal clear to everyone either, so that certainly didn't help. I'm glad it's gone, and we're going to be extra careful before introducing anything even remotely like that again.

I really appreciate the points you're making here in advocating for your use case (and ours as well, to an extent). URL rules, though obviously a different use case technically, really ends up in the same place with similar concerns. Rather than saying "no, never", we'd just make sure we're not putting something out there that we need to yank right back if and when we do something like this. :)

AGAlumB

Yes my point is similar. If the feature is a non-default option I don’t see how it causes issues with the larger user base who will never even see it most likely.

@intripidsilence: I'd love it if that were the case, but in the real world that's not how things go. With millions of users, if even 1% gets themselves in trouble with something like that we'll be in trouble too. :crazy:

Telokis

@brenty I've tried using the current system for associating a login to multiple domains and I have some feedback to give you from an UX perspective, if I may. I had a lot of them to do and it was very tedious:

• I have a gigantic screen and the "Edit" button is very very far. It's small and in the extreme bottom right of the screen which made me do a lot of big mouse movements. Even though I have a good sensitivity, sometimes I even had to lift my mouse. (Plus the location of the button is really counter-intuitive, I think.
• By default, everything had only one website address. When I select the second input below the filled one, I can type and it's fine. But I have to unfocus the input for the third to appear. This was definitely the most annoying issue I had.
• The "Website" text is an input and is selected when I use the key to move from input to input.
• Would it be possible to consider a copy settings to... or something? I litterally had to do the same thing more than ten times. This is very error-prone and time consuming. (That's why I like the global setting of LastPass, by the way)

This is my feedback from updating tens of logins to add multiple websites to all of them!

I think I know the answer but I still want to ask the question just to be sure:
Is there any way to make 1Password strictly match subdomains in the current version? (Even the dirtiest hack would do!)

I've seen here and there that you are thinking about enhancing the UX/feature set regarding URL matching in general. How high priority would you say this is for the 1Password team?

craig_francis

@Telokis as to your last comment, 1Pasword on a Mac should split the logins into two sections, those that are a perfect/strict match, then those which are close matches.

My issue is that this doesn't happen on iOS, and with the new iOS 12 password filling feature, this is now very problematic on one of my websites... let’s say www.example.com has a single login, yet it won’t auto select that (or put it at the top, when looking at the list), because I have lots of logins for other sub-domains, like admin.example.com.

AGAlumB

@Telokis: I'm not sure that the problem of you and I having too much data is something 1Password can help with (quite the contrary, perhaps!) but you're right that for the specific workflow you're describing there's room for improvement. We'll see if there's something we can do to make the flow more flexible in the future, without making it unnecessarily complex and more error prone. Thanks for the feedback!

Is there any way to make 1Password strictly match subdomains in the current version?

No.

How high priority would you say this is for the 1Password team?

Not high. It comes up only occasionally, and while there are certainly folks who would appreciate that functionality, we're squarely in the minority. Most users expect to be able to use a login across a domain. Many also expect to be able to use them across different domains, but that's a potential security risk, and they can set that up manually if they really want to.

AGAlumB

@craig_francis: We do not have control over iOS UI at all. You can, however, tap the "1Password..." button as mentioned previously to access 1Password's UI, and you can see subdomains there:

And just a reminder, this is a discussion about 1Password for Mac. Feel free to join or create a discussion in the appropriate category if you have questions regarding other platforms. Cheers! :)

schmalli

I just wanted to underline that especially when working in a big team this problem is very annoying. :'(
It seems obvious to me that the best matching login in terms of the host should be preferred.

Lars

Welcome to the forum, @schmalli! Thanks for weighing in on this subject. I don't have anything new to add as a reply to what's already been said earlier in this thread, but I will certainly make the developers aware of your position on this. :) :+1:

AGAlumB

@schmalli: You should be able to tell from my screenshot that I'm experiencing the same thing. ;) But you and I are squarely in the minority. If we can find a way to make it easier for our use case without negatively impacting the majority of users, I'm sure we will. :)

Unknown

This content has been removed.

craig_francis

Hi Sbarnea, I wouldn’t hold your breath, I’m on the iOS beta, and there are very few releases at the moment... and what is being tested are very minor bug fixes that don’t relate to 1Password providing iOS with the full domain.

These are the last set of release notes from the 28th March:

[NEW] You can now find your trashed items in the Categories list! View and restore trashed items, or simply empty the trash. {apple-issues#2085}
[IMPROVED] Updated our translations with the latest from our incredible translators on Crowdin.
[IMPROVED] Improved workflow when signing into accounts that require multi-factor authentication (MFA). {apple-issues#3311}
[IMPROVED] The tags view now indicates when the current vault has no tags. {apple-issues#3113}
[IMPROVED] The tags view now indicates when the current vault is from a suspended account. {apple-issues#3113}
[FIXED] Fixed an issue where the nested tag list would not stay on screen. {apple-issues#3330}

Lars

@sbarnea - no worries - we understand. If another solution better fits your needs, as long as it's not sticky notes on your monitor or reusing the same three or four passwords everywhere, we'll be happy you found something that works for you.

Lars

@craig_francis - thanks for copy/pasting the recent release notes. If anyone watching this thread is interested in a continually-updated version, all release notes for beta versions of every platform for which there is a 1Password app can be found here Just remember to click "Full Changelog" and then check the box marked "show betas." Cheers! :) :+1:

Unknown

This content has been removed.

jamwheeler

+1

I have a login for login.stanford.edu

I have several other servers that live under the *.stanford.edu namespace. I have to login to login.stanford.edu several times per day, and every time, I have to select the correct credentials from a list of several other logins. At point, I got so frustrated, that I just removed the domain name from the other credentials.

I think it would be ideal to add some setting under Advanced Settings where power users can decide to enforce strict domain name matching for starts, and then possibly including wildcards, and regex expressions.

AGAlumB

I'm not going to repeat everything already discussed above, but in your example if there's a specific Login item you prefer (at least in the sense that you use it most), you may want to set it as Favorite so that it is conveniently at the top of the list. :)

maciekish

Hi, any news on this? I host a lot of services behind a reverse proxy separated by subdomain.

littlebobbytables

Hi @maciekish,

There is no new news I'm afraid. While I could easily be wrong I do not anticipate any changes in the immediate future. It isn't meant as a not going to happen, just that no decision has been made yet.

qqhann

this is an ongoing issue that it's difficult to solve in a way that benefits the small number of people like you who have twenty or thirty logins all for the same domain

For slack users? Are slack users minority?? :(

AGAlumB

Yep. Most non-nerds have never even heard of it, even if the rest of us use it extensively -- if not excessively. :lol:

Unknown

This content has been removed.

ag_ana

@sbarnea:

Thank you for taking the time to chime in! We would obviously be sad to see you go, so hopefully we will manage to find a solution that doesn't involve you coding anything yourself :)