Removing useless form details

steerio

Hi,

Having discovered that 1Password stores all sorts of form fields that were useful for registration that are not needed for logging in, I decided to clean everything up. It's a great endeavour, and I already bumped into obstacles in the beginning.

As I started removing the "web form details", it silently removed my actual username and password as well, and I've locked myself out of one service already. Thankfully I was quick enough to put my phone in airplane mode and restore the password by hand.

So it seems like signup details and login details are just mashed together in a big heap. Do you have a recipe for a proper cleanup, or can you please add a "clean up this mess" button or something? I really only want to keep the username and the password everywhere, and forget all the signup details.

---

1Password Version: 6.0.1
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Dropbox

steerio

Okay, I've found a solution. When editing form details, little icons to the right show which fields are the actual login and password ones.

Among other stored information I've found even my preferred checkout time for the booking I was in the process of making when I signed up to a hotel booking website. I guess you can understand why I don't want to keep all this data around.

littlebobbytables

Hi @steerio,

The web form details can be quite important so removing of entries may have adverse effects. I'll explain a bit as to what happens.

When you save a Login item from within your browser it records all the fields present on the page as they were at that moment in time. We use the fields as a fingerprint to identify if the page you're trying to fill is the same as the one recorded. When they match we do what we call Fill by HTML attribute and we use all the information stored in the web form details. If the fingerprints don't match we fall back on Fill by HTML designation and we will only fill the username and password as stored in the Login item. Removal of a single entry in the web form details section would cause 1Password to fall back to the second approach.

One example where this is bad is any login page that has three or more fields that need information entered. These kind of pages can only be handled by Fill by HTML attribute which means the fingerprints have to match.

If you saved a Login item from a registration page then one way to clean it up whilst still getting the usefulness of the web form details section would be to create a new Login item from the site's login page, one that will only have information in the fields you fill. Another possible route would be to delete the value in an entry rather than deleting the entire field although the site may expect a legal value so something to be aware of.

I don't know if either of these help at all so I'll be interested to read your thoughts regarding this :smile:

steerio

Hi @littlebobbytables (lovely XKCD reference),

thanks for the insight. I inspected these fields a little bit, and have found that the ones saved from signup pages have field names that do not match at all with the HTML input field names of login pages. Therefore, the plugin can't possibly rely on field names.

The fingerprinting you mean would thus mean that the plugin only works on signup pages.

In fact, in the case of some items the names were totally off (the field tagged as username, containing my email address had the name firstName or street, etc), yet the login worked.

Based on this I was assuming that the browser plugin simply looks for the first password type field, fills it with the password, then adds the username to the closest text type field. But reality might even be simpler, because (prior to me removing anything from the web form data) I've seen search fields on a login page being populated with extra data (despite them surely be called search or query or something, definitely not username).

The fields I've removed today are all signup related ones, i.e. my name, address, and whatever I was doing on that particular site at the given time. In the future I will decline to save the login details to 1Password on signup; I will sign off, sign in again, and save then. That will record the form details (and also the URL, that I always have to fix by hand) properly.

All my logins seem to be working perfectly.

steerio

In fact you could come up with something like <link rel="login" href="https://o-hai.com/login"> as a recommendation to sites that want to be 1Password-friendly. And some data-x attributes on input fields to identify login input fields.

That would rock, as it would allow you to save the login URL even from a signup page, and to avoid saving extra debris.

chadseld

As you discovered, the fields designated as username and password contain the real data and are not duplicated elsewhere. That designation determines what is shown at the top of the login detail view. So don't delete those :)

Petersilie

Saying that you should delete the username and password fields in the web form details is all very well, but surely this in non-obvious and it seems imperative to protect the valuable username and password data. As it stands it is possible to delete the password field in the web form details without realising that this will also delete the password completely from the whole entry. There is no delete warning, nor is the password entered into the list of previously used passwords. Sure the at least one of these, or preferably both would be the correct thing to do to ensure against your users losing important data.

MrC

I've brought this issue up before. 1P is using essentially hidden side-affect behavior, and it is a bit dangerous. I've been bitten by it.

Drew_AG

Hi @Petersilie,

Thank you for taking the time to send us your feedback about that! We certainly don't want customers to accidentally lose data when editing Login items, and perhaps we'll be able to make this clearer in a future version.

Thanks again, and please let us know if you need anything else. Cheers! :)

Petersilie

The most important thing regarding web form details it that it needs is proper documentation! I played around with it because I couldn't get the behaviour I wanted, lost some data in the way described above, managed to recover it from a backup. Then i dived a bit deeper trying to figures it out. However even after lots of searching for the documentation and on these forums, I am still not able to make the relevant login item behave the way I want.

There seems to be an underlying assumption in 1P that the login information aways consists of two items, that fall roughly into the description of username and password. In my experience this is frequently an incorrect assumption. I had hoped that the web form details feature is a way around some to the problems this creates, however it's current implementation seems dangerous (see above) and lacks transparency (no documentation, no interface for Fill by HTML attribute or Fill by HTML distinction). So for me the 1P experience is still too frequently one of copy and paste. Not was was intended, I'm sure.

khad

@Petersilie, I understand what you mean.

While we never want to give folks rope to hang themselves with, we also have never recommended modifying the contents of the web form fields. (There may be very rare instances where we directed someone to do so to solve a specific problem, but we would never want anything related to the web form fields to be in some kind of tutorial in our documentation.)

If you delete the password, the password will be deleted. The password in the web form fields is the password. It appears at the top of the Login item precisely because of its designation as the "password" within the web form fields.

We don't have a warning for that. You are right. We also do not have a warning if you want to delete the password from the top of the Login item. We do not place warnings any time you edit the contents of one of your items.

In the same way, you can technically also delete all your data by poking around in Finder and deleting files. We have seen people lose data by doing that as well, but I'm not sure what we can do. Some folks will always find a way to delete things that ought not be deleted. At least the Library folder is hidden in Finder. Maybe we need to hide the web form fields.

Petersilie

I definitely agree that if you don't want people to edit the web form fields then they should NOT be accessible when you hit the edit button.
I have not argued that I found advice to edit the web form fields, I was saying that when everything else failed that seemed a reasonable way to proceed given the way the user interface presented the data.
The fact that the password field in the web form fields is the same field is a) counterintuitive and b) not at all signposted in any way. It is entirely possible to create web form fields without the password field using the "Save new Login" command. The fact that this web form field action then gets screwed up completely if I enter the password later is regrettable, but also not obvious.
My point is that you are expecting the user to know what data storage schema you are using, but failing to communicate the relevant information in your user interface.
I would have thought that deletion of a password should definitely be made harder or less irreversible, in whatever circumstances. I can understand not wanting to interrupt the editing process with alerts, but adding any password that has ever been saved, to the previous passwords list seems a sensible, non-disruptive and easy fix to make, and I can't understand why this isn't happening already.

ag_kevin

Hi @Petersilie ,

That's great feedback. I'm not sure if there's anything else left to say on the matter, but I can promise we'll keep that in mind when making enhancements the editing screen in the future.

Cheers,
Kevin

Petersilie

I look forward to that, but in the meantime maybe you should consider some documentation on the whole "web form details" section, to minimise the number of users who lose information. Because looking a this and other threads referred to above I'm not the only one this has happened too and this is a new complaint either.

ag_kevin

That's a good idea. I'll send your request along.

Cheers,
Kevin