Shouldn't 1Password automate the repair of 1Password data files [No]
Comments
-
Which makes me think..... couldn't, and shouldn't, this be automated in some way? I don't think it's the sort of thing the user should have to know or care about.
0 -
Hi @Thack,
No, 1Password data files aren't supposed to require maintenance in the first place, which is why this is only a manual process. 95% of the times, users never had to do this.
If the file needs to be repaired, that is a bug either caused by our apps or the sync services and we need to fix those kind of things. Automation isn't always a good thing, prevention is a much better solution for us.
Once in the while, we do add migrations into the app to automate the fixes for the data files. Sometime, the fixes are not required or cause any concerns, so we would just add them to the repair process. If we suspect that in the future the fix might help, we can tell the user to try the repair as an option and see if it'd make any differences.
0 -
OK, we would all agree that the vault should never require maintenance, and that if it does it's because of a bug in 1P or the sync services. No argument there. However, you seem to be saying that you mustn't allow "invisible" repairs to take place, because then you'd never find out about the bug. In other words, you are choosing to allow a bug to inconvenience the user, even though that could be avoided.
In my industry (telecommunications) this wouldn't normally be acceptable. The standard approach is to log all the relevant details and then initiate recovery, so that service continues. The crash report is then studied by the vendor. This is becoming ever more common in the software industry, and you will probably have seen that large parts of Windows do this, including attempting to restart crashed applications.
So, how about you put an automatic bug reporting system into 1P (obviously with user opt-in) so that every time a repair is needed, the relevant information is sent to you, but it also repairs it automatically where possible?
0 -
@Thack
Your analogy is flawed. You're talking about service recovery, not data repair. A better analogy would be Windows detecting a corrupt registry entry and automatically fixing it you before sending a fault report to Microsoft.The problem with automatically correcting data is that if the fault isn't precisely what the repair routine was expecting then you can end up damaging the data further.
0 -
@RichardPayne
Of course, it's just an analogy. But why would it be any different from the user initiating a repair? They know even less about the fault than the software itself.0 -
Because typically, they'd come here an ask for advice. They initiate the repair based on the advice of the more knowledge staff here. Randomly running a repair whenever you have any sort of problem is not a good idea and, thankfully, most users are too unsure of themselves to do it.
0 -
I find the arguments unconvincing, and I wonder just how many users would come here anyway. Still, I've said my bit! :-)
0 -
We don't want the user's vault to remain out of service until the user can contact 1Password technical support and get help. That would be an big inconvenience and could be a real disaster. So we have two goals: (a) notify 1Password of the fault so it can be investigated, and (b) get the user's vault back in service promptly.
I think @Thack is on the right track, but would suggest a slightly different flow. Run the sanity check (but not the repair). If vault damage is detected put up a dialog that (1) tells the user a fault has been found, (2) asks for permission to attempt an automated repair and report it to 1Password, and (3) tells the user that if the auto repair doesn't bring the vault back into service, the user should use the main app's Backup > Restore 1Password vault from backup...
0 -
@bkh - that sounds like a very good flow. I would definitely support it. The big problem with 1Password - and all other similar apps - is that by design all your eggs are in that basket. Without 1P and your vault working, you are completely stuffed: you can't log into anything at all. Even my username and password for this forum is stored in 1P! Plus emails, Facebook, everything.
Because of the extreme effect of losing access to your vault, we really can't afford to leave the user without service until they contact 1P support or find this forum. It's really no good at all. The flow @bkh advocates would be an excellent way of dealing with it.
Honestly, @AgileBits, do you appreciate what a disaster it would be for a non-technical user to find that they've lost access to their vault? Feedback to the customer, with clear instructions on the steps to take, is essential.
And yes, I know none of this should be necessary if 1P and Dropbox are both bug-free, but you can never rely on that. When I was a Reliability Engineer we put a lot of emphasis on "graceful failure" and "resilience". They are essential, in my opinion, for this type of application.
0 -
Remember that you can always recover and use one of the automatic backups if you need urgent access to your keychain.
That actually brings up another potential problem with automatic repair (although granted, not with @bkh's suggestion if the user is diligent on checking the integrity of their data) which is when a corruption is repaired silently and goes unnoticed for long enough to drop off the bottom of the backup queue. Better to be alerted to the problem immediately while you still have plenty of valid backups.
If Agilebits were to do something akin to @bkh's idea then I'd expect the last step to be a field by field comparison between the the repaired keychain and the last backup, with a report detailing any differences presented to the user.
0 -
@RichardPayne writes:
Remember that you can always recover and use one of the automatic backups if you need urgent access to your keychain.
Indeed, although I think a lot of non-techie users might struggle with this. Once again, automatic error detection followed by a series of prompts would be a massive help to the user, as well as being a big comfort. On this subject, I don't think the user should necessarily have to think about, or worry about, backups. They are there to recover from a failure, and the recovery strategy could easily begin by attempted repair, followed by restoration from backup, with user prompts along the way.
That actually brings up another potential problem with automatic repair (although granted, not with @bkh's suggestion if the user is diligent on checking the integrity of their data) which is when a corruption is repaired silently and goes unnoticed for long enough to drop off the bottom of the backup queue. Better to be alerted to the problem immediately while you still have plenty of valid backups.
Yes, I fully support that. I don't advocate a silent repair: I advocate an automatic repair after the user has been prompted so that service can continue with the minimal disruption, much as @bkh articulated so well. And a field-by-field comparison after recovery seems like a great idea.
At the moment 1P is not nearly "idiot-proof" enough. You can never cater for every idiot, but you can move a long way in that direction, and I strongly advocate 1P does this.
0 -
When you make an idiot proof invention, nature invents a better idiot. ;)
0
