New / "Draft" Items Added to 1Password.com Don't Sync Until Saved?

Several times I have clicked the little "+" button and started a new item, generated credentials including a password, and switched to the site to enter them and ensure they were accepted. However, when I forget to switch back to the 1Password app on Windows (often!) that information is not saved as an entry and is not available on my other devices. However, if 1Password is "killed" or crashes, the unsaved item does show up and is available on other devices!

I understand the reluctance to "commit" information that isn't complete, but certainly storing and sync'ing new items is better than risking their loss forever, even if marked as a draft. I was using version 4.x of 1Password for Windows and didn't have a 1Password.com account and I never remember this being a problem.

Also, I should add, the interface for 7.x is makes this sort of error infinitely more likely. The non-obvious (and, initially, hard to find) buttons to "Save" or "Cancel" means I sometimes don't realize an entry isn't saved.

Is there a setting or option or even a command line switch I can use to ensure draft items sync or otherwise greatly reduce the risk I can't find or access new logins?


1Password Version: 7.3.657
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: Cloud

Comments

  • We actually do save any in-progress edits under several circumstances, @Just_A_User, but we need to be very careful about that. We were reluctant to do this at all because we can't safely make any assumptions about the changes you've made. We are overwriting data by saving those edits and we don't know if you wanted that data overwritten.

    Imagine you're doing what you described. You've edited an item, you generated a new password, but you haven't changed it on the site yet. You get distracted with something else, never save that edit or complete the password change, then you shut down without saving. In that case, 1Password is going to save that edit. This is fine because you have item history or the previously used passwords section to recover that old password, but it would still be a jarring experience. Maybe you've completely forgotten that you had even started making that change. All you see is that you tell 1Password to fill and you can't sign in. Even if this was saved as copy noted as a draft, next time you sign in to that site, you're presented with two items that match and no certainty which is correct. Maybe you changed the password on that site, but didn't intended to change the username as well and only got around to doing so in 1Password. In that case, the proper data is split between two items.

    Whatever we choose to do in this case, all choices have the potential to look like data loss under some circumstances. To make matters more complicated, folks using standalone vaults don't even have access to Item History, so their only choice is to restore a wholesale backup of their entire vault and pull the proper data from there.

    It's worth remembering the advice of our teachers in this case. When assigned a paper or essay, every last one of my teachers admonished their class to save early and save often. Yes, Microsoft Word saves drafts, but there is no program I'm aware of that saves them often enough or in all cases. It only took me losing work once to learn to Ctrl + S more often. I'd say that admonishment applies even more emphatically to 1Password given the type of data you're dealing with. You can even use that same shortcut – Ctrl + S (then Ctrl + E, if you've more edits to add). The only way we can be certain you want to save that data is if you tell us. Otherwise, for every person who is upset an in-progress edit wasn't saved, there's going to be another that would be angry if it were.

    Ultimately, we decided there were adequate backup systems in place to save that edit in most cases. If you terminate 1Password, we will save that edit. If you didn't want it saved, you can recover. There are still good reasons not to do that as well, but we felt this was a decent compromise. We wait as long as we can for you to decide what to do with that edit and, when we are forced to make the choice between discarding and saving, we save.

    For what it may be worth, I personally feel the best solution here is relying on the browser extension to make these changes for you. When you sign in to a new site for the first time, it should prompt you to save that item. When you change your password, it should prompt you to update that site's Login item. When using the browser extension, changes are made on the site and in 1Password roughly simultaneously, so there's less risk of a discrepancy between site and your app. Plus, even if you're not prompted to update the item when changing a password, a Password item will be saved with the new password so you can update it yourself and, thankfully, such cases are rare. This leaves much less room for error than editing in the app.

    Obviously, this only covers Login items specifically and we still have to make that choice between saving and discarding in-progress edits for other item types, but I still think relying on the extension will make a big difference for most folks. After all, Logins are used far more often than any other item and they're also the item types where the most danger exists from unintended saves (and unintentionally discarded edits). The less we have to make that choice for you, the better, and the browser extension can help.

    Of course, I'm happy to pass your feedback along to the team, but we definitely have been reluctant to save in-progress edits without you telling us to do so up until now. I hope this at least helps you understand why this is a difficult choice, and why I don't want to make any promises that will change. It's something we've spent a lot of time thinking about and we're not totally opposed to changing this system, but when it comes to changing your data for you, we do treat that as something that needs a particularly good justification. This isn't something we'd change lightly or without extensive thought and that means it's unlikely to change any time soon.

  • Just_A_User
    Just_A_User
    Community Member

    First, thanks for the thoughtful response @bundtkate! And obviously I chose 1Password because of its product, which includes the focus on security, but also design.

    I completely understand the concerns above. But, let's start with the specific issue--starting a totally new login, populating it to some extent, and then not returning to the app. I can't see any reason why a "Draft" version of the item isn't saved. There isn't a previous or original state with which your new item will be inconsistent. So, I have trouble thinking of a "bad" situation that arises from storing and sync'ing the unsaved entry.

    For everything else, it seems that all the considerations raised abstract away from the UI--this really is a UI problem, after all. The data problems are far easier (you can always store the unsaved changes in a new copy of the item and only "overwrite" the old item once saved or delete the newer, changed copy if those changes are discarded). But, if the UI had the functionality (I don't think it does today, even for the "dirty" / changed and unsaved items you already store) to note something is a "Draft" or contains unsaved changes, the user could not only use the information that is there but also rectify the state of the data as well. And, to be frank, I fail to see how a solution like this would violate any of the considerations or issues above--you store more data but the functionality is the exact same as it is today,

    The design considerations and limited solutions described above seem to hew to an overly rigid set of principles around the sanctity of anything stored in the vault--but life is messy and lives in shades of gray. And thus the best way for a product to work is not, in my view, to pick the minimalist solution and foist unnecessary responsibility on the use ("save early and save often"). Instead, there are definitely solutions that affect none of the core functionality you describe above and don't completely leave the rest out in the cold.

  • Under what circumstances are you being left out in the cold, @Just_A_User? I don't meant that as an attack on your position – I see where you're coming from – but under the current system, that data will ultimately be saved by the time you need it elsewhere, at least based on what I'm imagining. Either your in-progress edit will still be in progress, or 1Password will have closed and the data will be saved and synced. Perhaps I'm focusing more on an issue that isn't concerning to you – losing that in-progress edit – and less on the idea that if that edit isn't saved and 1Password doesn't close, your in-progress edit won't be available elsewhere. Is that the aspect that most concerns you?

  • Just_A_User
    Just_A_User
    Community Member

    @bundtkate Sorry, maybe I misunderstood or have been less than articulate--neither would be unusual!

    Let me describe a scenario. I am on my laptop and need to sign up for a website. I go to the 1Password Windows App and hit the "+" button--I was going to say I create a new "Login" but that's not really what that does, now that I think about it. So, a blank "Login" item is presented for me to fill in. I fill in the information I have and generate a password. But, I don't know if this password meets the site's "recipe"--so I copy the password switch back to my browser and paste it into the form. It works! But, now I start using the site ... And forget to go back to 1Password and hit "Save" on the newly created item. I then go home, try to login to the site, and ... The login item isn't there. It's still sitting unsaved on my laptop. That seems like the wrong answer.

    Now, in another example, if I were changing my password and generating a new password for an existing login, never hit save after generating the new password, but changes the password on the webpage anyway... What would happen? I think I'd lose the new password until / unless I saved it, and I also wouldn't be able to see the newly generated but unsaved password if I opened 1Password on another device. But, to be honest, I am not 100% sure about that. If that is what happens (the unsaved data isn't available on other devices) then that also seems like the wrong answer, though.

    Are those scenarios and my concerns in both clearer now? I am both worried about losing the unsaved changes or login, but that's more acute if I can't even see if it exists on anything but the original device.

  • That makes total sense, @Just_A_User, and you might maybe have noticed I started to ponder it about halfway through my last reply. :lol: You bring up an interesting point and not one I've heard before. I was thinking that the item would sync once your app auto-locks, but turns out that's not the case – it remains available in edit mode next time you unlock (so it isn't lost), but it doesn't sync.

    It's always interesting to see what new things I learn when folks ask about this sort of stuff. As you might have gleaned, I stick to my browser extension for Logins and I'm fairly meticulous about saving anything else. I'll give my partner the stink eye if he bothers me while I'm saving something in 1Password. He knows I only do that with stuff I feel is really important and that I'm not to be disturbed. As a result, I've never once had an issue with new items not syncing, but your concern makes sense and I understand where you're coming from. I can still see potential problems here. For one, I'm not sure it's possible to treat new items differently from existing items (it could be, too – I genuinely don't know off-hand) and we're always going to have customers with different opinions on in-progress edits that are shaped by their typical workflows. I don't know that there's explicitly a right answer here, but there certainly is a best answer and your angle is definitely one it's important to consider when deciding what that is. We do have some pondering to do about some largely unrelated issues I could see having an impact here, so I really appreciate you took the time to share, particularly now. I'll make sure to share this perspective with the team so that we have it in mind as we make decisions moving forward. :+1:

    On a personal note, thanks for bearing with me on this topic. One peril of working so much with a single one of our native apps is I have a tendency to become entrenched in the issues that have come up before, so it sometimes takes me a bit to recognize a new perspective. Text communication is always a challenge, particularly when we have to make efforts to more fully discuss a topic in longer posts rather than having a short back-and-forth like we might in person. It's easy to get forests and trees mixed up. I really appreciate you taking the time to clarify and being so kind and understanding about it. I know this sort of stuff can be frustrating and really appreciate you being so patient with me. :chuffed:

  • Just_A_User
    Just_A_User
    Community Member

    @bundtkate No thanks required! The message you sent before this last one made it clearer that we were something I wasn't communicating clearly--I always forget these are complex products and complex issues and whatever is in the forefront of my mind isn't necessarily clear (or even known!).

    I also try to craft my messages to allow for this uncertainty, but that doesn't always work.

    In this day and age I think it's not uncommon for consumers / customers / users to reach out and to be told that the user should change how they do things to conform to the product, that their concern or use case isn't a correct one, or some other bland reply meant to promise nothing and deliver less (after being thanked for sharing the feedback and promising to "pass it along"). 1Password has always felt different in that respect, so I was (correctly) a bit skeptical that was the message I should be hearing.

    One thought on a solution for these issues--why doesn't the "Edit" button or the "+" button create a totally new item (a copy of the existing item or a blank item, respectively) and the new item is periodically saved (and that saved version sync'ed!) with a flag that it is a "Draft" or "Unsaved." With the right UI tweaks / updates it would be very clear to users which item is the last saved version and which item includes additional, unsaved edits. Nothing is lost and nothing is ambiguous.

    I know this is out of place here, but I should also flag that the iOS app has completely different behavior for new items: if the app is closed or crashes it doesn't sync the unsaved item. So maybe this is a good opportunity to both revisit some of these edge cases and harmonize the behavior across platforms? Just a thought.

  • Haha. "These are complex products" indeed. No truer words have been spoken today. Much though I try to be as in the know as I can be, there's a limit to my knowledge for sure, and it is sometimes hard to follow exactly what's tripping folks up. Especially when we all tend to use 1Password so differently. Heck, even when I ask our development team directly why we don't do a specific thing, I sometimes get an answer I can't quite follow. Funny enough, one such case was when I asked why we don't handle things as you propose when I first reached out to double-check my understanding of how we handle in-progress edits generally. What I was able to gather is that the need to encrypt things on save presents a challenge for the idea of "drafts" generally. I think I touched on the potential usability issues that having multiple items that will match the same site might present earlier, particularly when the proper info may be split between "draft" and not, so that's one concern as well, though perhaps not one that should rule out the idea entirely.

    I'll sound like a broken record a bit, but this just has a lot of use-cases to consider and most potential changes come with as many concerns as we have now, just different ones that might impact folks who do things in a different way. It may be the reality is that someone somewhere is going to have to be unhappy with how this works. With something as important as your password manager, though, that's a tough reality to accept. While I can't say that we will make a change like this and can think up reasons not to, that doesn't mean we're not genuinely considering your perspective. It's just a tough call to make when it seems like all options have trade-offs. I hope I don't sound like I'm putting you off here – I'd never say anyone's use-case is invalid at all – but one use-case is rarely the whole story so we almost never can just greenlight a change without some pondering. So I'm going to (reluctantly) say that we will keep your feedback in mind, but I can't promise anything. I try to do better than that when I can, but I hope you understand why that's about the best I can offer right away here. It just so happens to be a particular function where it's safest to maintain the status quo until we've considered things thoroughly. It has its issues, but it's the devil you (and we) know and there's something to be said for that.

    On the subject of asking users to conform, too, I agree that shouldn't be the end of it, but I still like to let folks know how they can change their habits to better fit how 1Password works today. It's easy to read that as "You should do things this way because that's how we want you to", but in reality my hope is I'm suggesting something folks haven't considered that might genuinely help. Might be we make changes that bring y'all back to your old ways, or my suggestion just flat out won't work for the person I'm giving it to, but there's value in offering some immediate relief, even if it ain't perfect. I'm glad you seem to read those suggestions (at least from us) in the spirit they were given, otherwise I'd probably be in big trouble. :wink:

This discussion has been closed.