Feature Request: Natural support for mail forwarding services e.g. Sign in with Apple, Sneakemail

TLH

Warning: The winning feature of a Families account is post-mortem support. Skip this if you're in mourning.

My passwords are not the only type of credential that my executor will require. My contact-unique email addresses will be necessary too. It would be good if I could record the contact-unique email addresses in 1Password so that the executor will have all the credentials in one place.

Background:

Sign in with Apple and Sneakemail are two examples of mail forwarding services. The user generates a unique email address for every contact. If afterwards the user receives unwanted email at that address, perhaps do to a data leak, the user can generate a new unique email address and disable the compromised one.

Specifics

Mail forwarding is useful in circumstances where no password is required, such as a pre-sale information request. Two fields are required:

• the contact's name
• the contact-unique email address

A URL field will be used very often, too, but it is not required.

Distasteful Workaround

There is a 1Password type with the appropriate field count, namely "Password." I can hijack "Password" for the purpose of recording contact-specific email addresses: I can put the email address in the Password field. I can warn the executor "Hey buddy if you're looking for an email address and you don't see it, look under 'Passwords'", but it's a speed bump, and I won't be there to answer the executor's questions.

Request

Please consider adding a Contact type to a future release of 1Password.

Thanks for reading 8-)

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Mail forwarding services such as Sign in with Apple and Sneakemail

Ben

Hi @TLH

Thanks for taking the time to write in with this request. I'm trying to envision how Login items don't already serve this purpose. They have a username field, an (optional) password field, and an (optional) website field. :) I also do the "unique email per service" thing, but I've rolled my own instead of using Apple's or otherwise, largely because those weren't available when I started but continue because it still gives me more flexibility. That's really neither here nor there, but what is important is that I've never felt the need for any sort of different record type, so I'm curious to find what is different about my situation than yours where yours gives need for that. When I sign up for a service I use my unique email address as my username, generate a unique password using 1Password, and then save that into a Login item which also captures the URL of the service into a website field. I also title the item according to which service it is for, and if I plan to have multiple accounts for that service I also tend to include the unique email address in the title. Have you considered doing that, and if so, what are the downfalls for your use case?

Ben

TLH

I'm trying to envision how Login items don't already serve this purpose. They have a username field, an (optional) password field,

My experience with Login items has been that the Password field is mandatory, not optional. When I open a New Login form on iPadOS Safari, the “Save” button is disabled until I type something into the Password field. If I use “n/a” as a dummy password, it has been my experience that later on I will see warnings about re-used and easy-to-guess passwords.

I agree that when I create an account with a service, that the 1Password Login type is well-suited.

My use case is for occasions where no account is created.

In general, the use case is for sites where one can signal an interest, merely an interest:

• “In return for your 10%-off-single-use-coupon, I am willing to receive notifications from you of sales on king-size pillowcases.”
• “I applaud your undertaking. You may send me progress reports.”

That sort of thing.

A relationship with no credential.

Ben

My experience with Login items has been that the Password field is mandatory, not optional. When I open a New Login form on iPadOS Safari, the “Save” button is disabled until I type something into the Password field. If I use “n/a” as a dummy password, it has been my experience that later on I will see warnings about re-used and easy-to-guess passwords.

That is indeed the case on iOS, but is not the case on Mac. I'm sorry to say the experience isn't consistent across all of our apps. But if you have access to a Mac you can create such Login items:

Hopefully as we move toward a more consistent experience with the next generation of 1Password apps this is something where the behavior will be standardized.

A relationship with no credential.

Gotcha. At the moment I think the best here would still be Login items, so that you can see them if you were to attempt to open 1Password on said sites as-if to fill on them. I'll talk this use case over with the team and see if there are ways in which we can do better for the future. :+1: Thanks for sharing.

Ben