This is a staging forum for AgileBits, not an official support forum. Visit http://discussions.agilebits.com instead.
Vault confusion, and suggestion for improvements
<div class="IPBDescription">Organization of items, login vs other types</div>I am new to 1Password, still in evaluation phase, but I'm a "power user" of computers. I settled to evaluate 1Password, since the security philosophy (openness and transparency) seemed much better than some competitors'. I mailed Agile about a couple of issues I had, and I received excellent responses -- first class customer service! However, I do have further questions regarding organization and "Vault confusion", but I think it is best to proceed with those in a forum rather than by mail. The thread http://forum.agile.ws/index.php?/topic/765-basic-organizational-question/ was very close covering similar concerns, but I chose to make a new thread:
[size="4"][b]Vault confusion[/b]:[/size]
I fail to see the purpose of things like a Generic Account, and even a Bank Account! What added value is there to a separate category named Generic Account? Its only "feature" is a lack of url! Why? To me it is just confusing. I could just as well use a login item with an empty url. Why do you have the Generic Account? Why do I have to choose between a Login item and a Generic Account, especially since I can't convert from one type to the other?
And the Bank Account? All it does is add some relatively arbitrary fields. I could just as well have this info in the note section of a Login item! What's the difference? What's the purpose? These pre-set and fixed fields don't really DO anything, they are not part of something automatic or dynamic; it's just dead data. If the fields are there only for convenience so I don't have to type them in a note, it would be simpler and more streamlined if you allowed a Login item to carry any number of arbitrary fields, preferably by letting the user add fields from some template (in addition to custom defined fields), only for the sake of convenience!
(Credit card and Identities, on the other hand, are different, since these fields are used to auto-fill forms.)
In addition, anyone who has a bank account will also have an URL to this bank and a way to log in to the bank. So, to me it seems that the only logical conclusion is to have the bank account as a Login item. Right? Then, why do you have the separate category Bank Account? To me it is just confusing and unnecessary clutter.
Agile staff have suggested to create several items for a single bank contact. I fail to see the usefulness of that, while I do see big problems duplicating information that manually must be kept in sync. Why not simply allow a Login Item to have arbitrary many fields, such as SWIFT or IBAN numbers etcetera?
In addition, a record for a bank will often include a special PIN code used only for phone support. We certainly don't want a separate vault item for that! I think that it would be far easier to have ONE vault entry for this bank! Auto login would only be done if there is an url, and then it would use the first url and the first user-id/password pair defined in the record. The PIN code should also be displayed as bullets by default, thereby hiding it from prying eyes, but revealed in standard manner by holding the option key down.
Another example:
I have an Apple ADC account, which happens to be the same as my iTunes account, since both use my Apple ID. This also happens to be used to log into the Apple bugreporter, and it also happens to be used to log into the Apple forums. Apple intentionally uses Apple ID for different purposes.
In 1password, it was very unclear to me how to treat that. I settled for different types: one Login item for bug reporter, another for Apple ID management (because different urls), and yet another item - an Account item - for iTunes! I still don't know if this is the best method or not. But 3 or 4 items using the same Apple ID means creating copies of the same info! Something tells me it is NOT how things should be! But I don't see that 1Password can be used to treat these more coherently?
I have imported 132 items from CiphSafe, and in the end I even let things like phone codes etcetera remain as Login items, leaving the url field empty, since I don't see the point in making these phone items some kind of Generic Account. What IS the point?
In addition, a phone will have, not only a PIN code, but also one or two so called PUK codes. I can either store them as a comma-separated list in the password field, or in the note section, but a more logical place would be if multiple passwords was allowed, since this makes it possible to display them all as bullets by default, thereby hiding them from prying eyes.
As for the vault item called Software, also that should be migrated with Login: usually, a software vendor will have a forum for this software, and it is fully natural to login to the forum site from this vault item. Hence, it should have a forum url and password for login, and then another field for its license etc.
[b]Username vs email confusion in autosave[/b]:
Even the autosave function in 1Password got confused when I registered for this particular forum: It took the email as the username, whereas it should have taken the username I had given, and then it should have placed the email address as a field in the Login item (which it currently can't but that is how I see it should have worked).
[size="4"][b]SUGGESTION[/b] (feature requests):[/size]
If a vault item lacks all fields (or whose fields are empty), but does contain a note, 1Password should simply treat this vault item as a note, and thereby use a note icon. Vault items with a non-empty url field and a non-empty user-id/password fields should be treated as a login item. Any vault item should be able to have more than one "password", so that they can all be displayed as bullets, hiding them from prying eyes. If the item has a non-empty url field, the first user-id/password pair is the one to use for login. Then other "passwords" might be codes for telephone service, or PUK codes for the phone, or the code for a cryptocard used to login to the bank, etc.
Thereby, we don't need any confusing and cluttering Generic Accounts, or Bank Accounts. And information about an entity (such as a bank) is kept in one place without duplication.
The remaining issue is how to treat multiple urls: In the case of my Apple ADC account (one Apple ID and one pw), maybe it would work by allowing multiple urls in a vault item, and a single pair of user-id/password. If so, the (first) pair of user-id/passwords should be use to auto-login to the web site that matches the url.
--
With the Best Regards!
Sorry for the length of this post, but I hope it clarified the issues and my ideas better than what a short post would have achieved.
[size="4"][b]Vault confusion[/b]:[/size]
I fail to see the purpose of things like a Generic Account, and even a Bank Account! What added value is there to a separate category named Generic Account? Its only "feature" is a lack of url! Why? To me it is just confusing. I could just as well use a login item with an empty url. Why do you have the Generic Account? Why do I have to choose between a Login item and a Generic Account, especially since I can't convert from one type to the other?
And the Bank Account? All it does is add some relatively arbitrary fields. I could just as well have this info in the note section of a Login item! What's the difference? What's the purpose? These pre-set and fixed fields don't really DO anything, they are not part of something automatic or dynamic; it's just dead data. If the fields are there only for convenience so I don't have to type them in a note, it would be simpler and more streamlined if you allowed a Login item to carry any number of arbitrary fields, preferably by letting the user add fields from some template (in addition to custom defined fields), only for the sake of convenience!
(Credit card and Identities, on the other hand, are different, since these fields are used to auto-fill forms.)
In addition, anyone who has a bank account will also have an URL to this bank and a way to log in to the bank. So, to me it seems that the only logical conclusion is to have the bank account as a Login item. Right? Then, why do you have the separate category Bank Account? To me it is just confusing and unnecessary clutter.
Agile staff have suggested to create several items for a single bank contact. I fail to see the usefulness of that, while I do see big problems duplicating information that manually must be kept in sync. Why not simply allow a Login Item to have arbitrary many fields, such as SWIFT or IBAN numbers etcetera?
In addition, a record for a bank will often include a special PIN code used only for phone support. We certainly don't want a separate vault item for that! I think that it would be far easier to have ONE vault entry for this bank! Auto login would only be done if there is an url, and then it would use the first url and the first user-id/password pair defined in the record. The PIN code should also be displayed as bullets by default, thereby hiding it from prying eyes, but revealed in standard manner by holding the option key down.
Another example:
I have an Apple ADC account, which happens to be the same as my iTunes account, since both use my Apple ID. This also happens to be used to log into the Apple bugreporter, and it also happens to be used to log into the Apple forums. Apple intentionally uses Apple ID for different purposes.
In 1password, it was very unclear to me how to treat that. I settled for different types: one Login item for bug reporter, another for Apple ID management (because different urls), and yet another item - an Account item - for iTunes! I still don't know if this is the best method or not. But 3 or 4 items using the same Apple ID means creating copies of the same info! Something tells me it is NOT how things should be! But I don't see that 1Password can be used to treat these more coherently?
I have imported 132 items from CiphSafe, and in the end I even let things like phone codes etcetera remain as Login items, leaving the url field empty, since I don't see the point in making these phone items some kind of Generic Account. What IS the point?
In addition, a phone will have, not only a PIN code, but also one or two so called PUK codes. I can either store them as a comma-separated list in the password field, or in the note section, but a more logical place would be if multiple passwords was allowed, since this makes it possible to display them all as bullets by default, thereby hiding them from prying eyes.
As for the vault item called Software, also that should be migrated with Login: usually, a software vendor will have a forum for this software, and it is fully natural to login to the forum site from this vault item. Hence, it should have a forum url and password for login, and then another field for its license etc.
[b]Username vs email confusion in autosave[/b]:
Even the autosave function in 1Password got confused when I registered for this particular forum: It took the email as the username, whereas it should have taken the username I had given, and then it should have placed the email address as a field in the Login item (which it currently can't but that is how I see it should have worked).
[size="4"][b]SUGGESTION[/b] (feature requests):[/size]
If a vault item lacks all fields (or whose fields are empty), but does contain a note, 1Password should simply treat this vault item as a note, and thereby use a note icon. Vault items with a non-empty url field and a non-empty user-id/password fields should be treated as a login item. Any vault item should be able to have more than one "password", so that they can all be displayed as bullets, hiding them from prying eyes. If the item has a non-empty url field, the first user-id/password pair is the one to use for login. Then other "passwords" might be codes for telephone service, or PUK codes for the phone, or the code for a cryptocard used to login to the bank, etc.
Thereby, we don't need any confusing and cluttering Generic Accounts, or Bank Accounts. And information about an entity (such as a bank) is kept in one place without duplication.
The remaining issue is how to treat multiple urls: In the case of my Apple ADC account (one Apple ID and one pw), maybe it would work by allowing multiple urls in a vault item, and a single pair of user-id/password. If so, the (first) pair of user-id/passwords should be use to auto-login to the web site that matches the url.
--
With the Best Regards!
Sorry for the length of this post, but I hope it clarified the issues and my ideas better than what a short post would have achieved.
Flag
0
Comments
-
Hello, Harald, and welcome to the forums! Thanks for the detailed feedback. I'm going to try to keep this as short as possible, but there are several points I want to address specifically. Since this is so long, I'm going to have to break it into two posts.
[quote name='Harald' timestamp='1294653594' post='18698']
I fail to see the purpose of things like a Generic Account, and even a Bank Account! What added value is there to a separate category named Generic Account? Its only "feature" is a lack of url! Why? To me it is just confusing. I could just as well use a login item with an empty url. Why do you have the Generic Account? Why do I have to choose between a Login item and a Generic Account, especially since I can't convert from one type to the other?
[/quote]
This is one on which I might agree with you. There does not seem to be much added value, but I think it was added back when we were trying to introduce custom fields, meaning, you could start out with just a basic item and make it whatever you want it to be, even if it's not really a login.
[quote name='Harald' timestamp='1294653594' post='18698']
If the fields are there only for convenience so I don't have to type them in a note, it would be simpler and more streamlined if you allowed a Login item to carry any number of arbitrary fields, preferably by letting the user add fields from some template (in addition to custom defined fields), only for the sake of convenience![/quote]
That's the plan, eventually.
[quote name='Harald' timestamp='1294653594' post='18698']
In addition, anyone who has a bank account will also have an URL to this bank and a way to log in to the bank. So, to me it seems that the only logical conclusion is to have the bank account as a Login item. Right? Then, why do you have the separate category Bank Account? To me it is just confusing and unnecessary clutter.
Agile staff have suggested to create several items for a single bank contact. I fail to see the usefulness of that, while I do see big problems duplicating information that manually must be kept in sync. Why not simply allow a Login Item to have arbitrary many fields, such as SWIFT or IBAN numbers etcetera?
In addition, a record for a bank will often include a special PIN code used only for phone support. We certainly don't want a separate vault item for that! I think that it would be far easier to have ONE vault entry for this bank! Auto login would only be done if there is an url, and then it would use the first url and the first user-id/password pair defined in the record. The PIN code should also be displayed as bullets by default, thereby hiding it from prying eyes, but revealed in standard manner by holding the option key down.[/quote]
I don't understand where you're getting "duplicated data." The Login, Credit Card, and Bank Account are very distinct. First, not every Bank Account has a card associated with it, and not every card is a "bank account." So these two must be separate. As for Logins and Bank Accounts, those also are very different. The only thing you need to login to a bank website is your username and password, and those are not fields in the Bank Account item, so where is the duplication of data? The Bank Account template is meant to be an informational record so that you can get that information (routing number, PIN, account number, etc.) off a sticky note and secure. Your login on your bank's website is a separate entity from the details of your actual account with the bank.
In addition, the PIN code is already displayed as bullets and can be displayed by holding the Option key.
[quote name='Harald' timestamp='1294653594' post='18698']
I settled for different types: one Login item for bug reporter, another for Apple ID management (because different urls), and yet another item - an Account item - for iTunes! I still don't know if this is the best method or not. But 3 or 4 items using the same Apple ID means creating copies of the same info! Something tells me it is NOT how things should be! But I don't see that 1Password can be used to treat these more coherently?[/quote]
Another upcoming feature (we hope) will be user-defined domain equivalency, so that you won't need to have multiple logins for different domains if they are the same account. As for the iTunes account item, you don't need that if you don't want it. It's for people who want it who may only use their account in iTunes and not as a login anywhere else.
[quote name='Harald' timestamp='1294653594' post='18698']
I have imported 132 items from CiphSafe, and in the end I even let things like phone codes etcetera remain as Login items, leaving the url field empty, since I don't see the point in making these phone items some kind of Generic Account. What IS the point?[/quote]
The point is to have a secure database. The Logins vault is syntactically reserved for online web form logins, and other secure data typically belongs elsewhere. That's not to say that you can't store your information as a login item if you want to, though.Flag 0 -
[quote name='Harald' timestamp='1294653594' post='18698']
In addition, a phone will have, not only a PIN code, but also one or two so called PUK codes. I can either store them as a comma-separated list in the password field, or in the note section, but a more logical place would be if multiple passwords was allowed, since this makes it possible to display them all as bullets by default, thereby hiding them from prying eyes.[/quote]
You can store extra information in the All Fields area at the bottom of any Login item. Then just collapse that area to hide it from prying eyes.
[quote name='Harald' timestamp='1294653594' post='18698']
As for the vault item called Software, also that should be migrated with Login: usually, a software vendor will have a forum for this software, and it is fully natural to login to the forum site from this vault item. Hence, it should have a forum url and password for login, and then another field for its license etc.[/quote]
This is one with which I highly disagree. Software licenses are a thing of their own. We have several features dedicated just to the managing of your software licenses, such as the following:
* When you create a new license item and type the name of the software, if it is already installed, 1Password will grab its icon and version number.
* If you drop an application onto 1Password's icon in the dock or in Finder, 1Password will automatically open a new item with the name, icon, and version number.
* You can launch an application by clicking on its icon in the Software License detail view.
I think this is the most distinct of all the vaults with a very clear purpose, and I've never heard that it would be useful to combine it with a forum login. What if there isn't a forum? You are going to create a Login just for your software license? What if the forum is for more than one piece of software?
[quote name='Harald' timestamp='1294653594' post='18698']
Even the autosave function in 1Password got confused when I registered for this particular forum: It took the email as the username, whereas it should have taken the username I had given, and then it should have placed the email address as a field in the Login item (which it currently can't but that is how I see it should have worked).[/quote]
This is a per-site problem. Please let us know on which website this occurred and we'll see if we can fix that in the future.
[quote name='Harald' timestamp='1294653594' post='18698']
If a vault item lacks all fields (or whose fields are empty), but does contain a note, 1Password should simply treat this vault item as a note, and thereby use a note icon.[/quote]
Why not just create a note? Someone who intentionally creates an account and only stores a note in the account probably did so for a reason. Maybe they want to come back later to fill in the rest of the fields.
[quote name='Harald' timestamp='1294653594' post='18698']
Vault items with a non-empty url field and a non-empty user-id/password fields should be treated as a login item. Any vault item should be able to have more than one "password", so that they can all be displayed as bullets, hiding them from prying eyes. If the item has a non-empty url field, the first user-id/password pair is the one to use for login. Then other "passwords" might be codes for telephone service, or PUK codes for the phone, or the code for a cryptocard used to login to the bank, etc.[/quote]
The complexities of form-filling make it very difficult for us to submit a login with just username and password data. Typically, if we haven't saved the name of the form fields, the login attempt could easily fail.
[quote name='Harald' timestamp='1294653594' post='18698']
Thereby, we don't need any confusing and cluttering Generic Accounts, or Bank Accounts. And information about an entity (such as a bank) is kept in one place without duplication.
The remaining issue is how to treat multiple urls: In the case of my Apple ADC account (one Apple ID and one pw), maybe it would work by allowing multiple urls in a vault item, and a single pair of user-id/password. If so, the (first) pair of user-id/passwords should be use to auto-login to the web site that matches the url.[/quote]
See above for these.
In review, a couple of the things you brought up will change in the future. Others are what they are for a purpose, and likely will not change (Software licenses, Notes, etc.). Again, we appreciate the time you spent on this. It shows that you care about our software and want it to be better, and we love that! We want it to be better, too.Flag 0 -
I just want to thank you for the thorough and good response, I really appreciate that!
I am delighted to see that we agree on some points, which indicate a potential for improvements in this area, of an already good product, and that a few things are already "in the pipeline" . For a couple of points, however, it revealed a lack of understanding from my side: namely that the Software category is much more "active" than I was aware of, and that some extra fields (under All fields) in a Login item are actually used actively to direct 1Password precisely how to login -- in my case there were no extra fields since all my items (except the new one for Agile forum) were imported from CiphSafe.
As for my desire to automatically treat an item as a note if there is only note info, stems very much from the issues I had when importing from CiphSafe. Manually converting Login items to other vault categories is really tedious -- zillions of copy/paste! And even if I did all that work, I don't see what good it would do me.Flag 0 -
[size=2][quote name='Harald' timestamp='1294742502' post='18773']
[/size]As for my desire to automatically treat an item as a note if there is only note info, stems very much from the issues I had when importing from CiphSafe. Manually converting Login items to other vault categories is really tedious -- zillions of copy/paste! And even if I did all that work, I don't see what good it would do me.
[/quote]
If you choose the "Generic Text" option when you import, you can decide whether an imported item should be a Secure Note or a Login. Maybe export all your notes from CiphSafe separately and import them that way, that is, unless you're already done with the transition.
Glad to be of help!Flag 0
