Don't strip subdomains

[normal elm]

When storing an identity in Cloaked, any url stored in the Website field gets automatically reduced to its parent domain. For instance, I access a lot of internal services available via Tailscale at addresses like https://service-name.tailnet-name.ts.net, but these all get stored as just https://ts.net. I've seen the same thing with public resources served on subdomains as well.

As a result, the extension offers a dozen different identities when trying to sign in to one of these. If I ignore Cloaked's suggested identities, it then offers to update one of the existing ones after I've logged in. This makes for a confusing and clunky login process and makes it far too easy for a user to inadvertently overwrite the incorrect identity.

Cloaked should offer a way to explicitly associate an identity with a fully-qualified domain name and not just the parent domain.

[hollow stump]

“How to treat subdomains” is always a challenge in the password manager space (and there can be wrinkles depending on specific product features/flow).

On the flipside: If you associate strictly against subdomains, you can end up in a situation where your accounts simply don’t appear at all when you expect them.

Here’s an example:

Before I came here to lead the extension, I was in charge of an extension with similar password management functionality at a different startup.

One of our features was an SSO-like “autologin” feature, where the security risks inherent to “clicking all buttons and entering all text for you on any site” caused us to design the feature so that it matched subdomains exactly.

It turned out that we faced challenges with this on a number of sites. Chase came to mind as particularly challenging — they served each input within its own iframe from a totally unique subdomain, with each one being rotated on every page load. The username field might’ve been in an iframe from “secure05a.chase.com” while the password field might be served in an iframe pointed at “secure4bf.chase.com”.

This is an extreme example, but simpler cases abound throughout the Internet — There is often a “login.example.com” page that exists within its own flow for a site, but in addition to that, there might be simple login modals served on “example.com”.

We could probably improve on the current behavior by recording the maximum possible information while retaining the current behavior against TLDs, but how we might use that extra subdomain information isn’t perfectly clear.

It’s also not obvious that the subdomain alone is relevant in these edge-cases — some sites use paths, query params, and even anchors to serve a similar function you’d expect from subdomains.

[tepid pendant]

Thanks for all the feedback! I have passed this all onto @round badge and the team who will look into this in more detail!

[normal elm]

Thanks for the added insight on the complexities here. I know a certain other password manager I'm using tracks a set of "global equivalent domains" to tie things like apple.com and icloud.com together, and it allows users to define their own equivalents as well. That password manager's UI also makes it easy for a user to associate new websites and URIs with a credential - either manually, or at logon ("hey you just logged in to login.example.com with your example.com creds, would you like to add that website to the credential?"). It also lets the user select how that credential should be matched - a base domain, a host, a complete URL, some sort of regex wizardry, etc.

For example: https://bitwarden.com/help/uri-match-detection/

Of course, Cloaked won't be able to offer anything like that if it won't even store the full host (let alone the rest of the URL).

Cloaked is the first password manager I've used in a long while that doesn't let me control how credentials are matched to resources. The only thing I can do to avoid being annoyed by the extension constantly suggesting incorrect creds is to disable autofill for entire base domains and just manually copy/paste creds when I need to log in.

[hollow stump]

Obviously as someone with a background in dev, I'm a power user of most of the software I use. I can definitely appreciate having something more configurable like this.

Although I don't have unilateral control of which features we develop and how, I can bring it up with the design department. As a general trend, design has prioritized simplicity over configurability whenever the two come into conflict, especially since new trial users can already get overwhelmed and confused with current UI as it stands. I feel like it'd be a strong bet that they'd want to think up a solution here that won't involve adding additional components to the default flow on all platforms.

tracks a set of "global equivalent domains" to tie things like apple.com and icloud.com together

For what it's worth, our codebase has hints of this feature as well!

A couple of thoughts on this:

1. This is a resource-intensive manual process that can be difficult for a small startup to do on its own without calling in outside contractors.
2. If you bring in outside contractors, you have to really trust both their intentions and judgment. If a contractor happens to map a phishing domain to your credentials (whether intentionally or unintentionally), our software can become a liability that reduces your security. "First, do no harm" is I think a pretty core principle for all security/privacy software.

[cold shell]

being able to add multiple domains to a single login is a pretty core feature of Apple Keychain, 1Password (the two that i've used), where it shouldn't be so controversial to implement something like this right? If we're talking about simplicity and user-friendliness, Apple would probably be the hallmark of that, and even they have this in there

[tepid pendant]

Within the Cloaked Dashboard and App under the identity you wish to use a subdomain with you can add one there. This is all feedback that goes to the team and they will look into ways to improve this for our users going forward. At this moment I cannot provide an ETA on when this will be added. @round badge and the Dev team would be able to provide more of an update on this. If I find out or hear anything before hand I'll make sure to share with you all.

[round badge]

Yep it's definitely something we'll look into developing shortly

[cold shell]

I think the point of adding a subdomain is that Cloaked would be triggered to fill in the same login info into multiple websites. As of now, you are able to add secondary websites, but it doesn't trigger a login

[hollow stump]

This is correct. That section was implemented as part of a feature to enable attaching arbitrary information to a cloak. There wasn't any explicit decision made not to prompt on-page according to this information, but anything along those lines was just outside the scope of the feature at the time it was written.

Right now, the only value you gain by specifying that you're attaching a URL rather than general text is:

1. Whatever you enter is validated as a URL.
2. Whatever you enter will become a clickable link.

[hollow stump]

How/when/why this feature would be implemented is a matter for discussing with the team, but agreed that it would be useful (and almost a "no-brainer").

[lost radish]

Hi @round badge , this post goes back to January, is there an update on this request? (subdomains); it is very annoying to manage around (copy/paste) Cloaked for this feature that most pwm provide.

[odd verge]

Agree with this including Apache urls as well that have an IP as the url.