Been spending a lot of time in the beta feedback forum reporting bugs etc and came across what might be an interesting option for some missing local vaults is the possibility of a self hosted 1Password server - you can register interest here Self-hosted 1Password kick-starter | 1Password
5 Likes
I just filled the survey out and explained why I will be leaving 1Password unless something like that becomes an option.
Iāve never been able to get Face ID or Touch ID to work on my machines. Touch ID is a no-go if you use an Otterbox case which is mandatory for any device within reach of farm animals or used on a farm and face ID is so flakey that I can never depend on it so I gave up and disabled it entirely.
That indeed does sound bad. I have had no issues. It works flawlessly with my face. The only times it fails is when I have raindrops on my glasses. Is it possible that Face ID gets confused in your case because of hats, sun-glasses, rain-drops on glasses and stuff like that? An Apple Watch will help in those cases because if Face ID fails in a scenario like that an Apple Watch can unlock your phone (āmask modeā). Even without the help via the Apple Watch I had almost no issues and in combination with the watch: none. Then again, that does not help you at all. Sorry. 
Thanks for this! Have filled the survey.
Hope they bring a version that can be hosted on Synology or on a Mac with MacStadium. This will also bypass issues I have withe some of my clients not allowing access to 1Password.com. Also hope a self hosting service will be supported by version 7, which I intend to run for as long as it works.
Highly likely.
Watches and me do not get along. I tried a Wyze watch and a fitbit and in addition to not providing me the info I wanted watches, like jewelry, are often problematic when doing farm work. Lamb slime, manure, ditch water, dog slobber etc all play havoc with devices and especially those on my hands and arms. 
But itās good to know that if htat changes that a watch and face ID might actually work.
4 Likes
@OogieM continues to be the one of the most fascinating tech users I know. Also, I bet an Apple Watch could hold up to Lamb slime.
1 Like
You can setup multiple āfacesā with FaceID. So, if you wear certain hats or glasses that you notice cause you problems, setup one while wearing those accessories in addition to the one without.
Perhaps, but having spent eight years on the farm dealing with cow manure, Iām not sure anyone wants that on an expensive Apple Watch! 
4 Likes
Iāve been reading along with interest. I have been a long time 1PW user with the family plan, which is highly useful for (duh) sharing information with other family members.
I have been storing my vaults in 1PWās cloud for some time now, so the lack of local vaults isnāt necessarily a deal breaker for me. Iām not very happy with the move to Electron, but willing to give them some up front benefit of the doubt with their assurances that the back end is implemented in Rust and Swift. They have, in the past, seemed to know what they are doing as far as security goes. I will see how things pan out as their development cycle goes on.
What I AM confused about, however, is the assumed connection between the removal of local vaults and the shift to Electron. If the back end is implemented in Rust and Swift and only the UI is Electron, what is the limitation on local vaults? Couldnāt those just be done in the backend in Swift (as I would assume they are currently done in Swift or Objective C or whatever other language the Mac app is currently implemented in?
Iāve been wondering about that myself. They say āWeāve reached the end of what we can do with local vaultsā (or words to that effect). What does that even mean?
2 Likes
I doubt thereās any connection between the switch to Electron an the move to end local vaults.
2 Likes
Perhaps they have reached the end of what they can do with local vaults because that option kills their ability to sustain an absolute goal for pure cross-platform development.
ā
JJW
1 Like
Local vaults would require front-end code with the security smarts they want to keep in the backend-code. Electron-based UI is platform-agnostic. The locally running code necessary to support local vaults is platform-dependent. Theyād be back to supporting code for each platform, which they donāt want to do.
I donāt see any reason why local vaults would inhibit cross-platform development. I suspect that local vaults are a casualty of their emphasis on shared vaults (1Password for Teams/Families).
1 Like
Because the code base needed to access local vaults on Windows may require Windows specific code that cannot translate to macOS. And vice versa. Just guessing.
ā
JJW
1 Like
āThe next generation of 1Password apps sync exclusively with 1Password.com (including .cašØš¦ and .eušŖšŗ)ā - Dave Teare
ā1Password 7 will not be changing and can continue to be used with all currently available sync methodsā
Yes, it can be confusing but this has nothing to do with Electron. Iāve been using 1password.com for several years and do not have a local vault. However my data is cached locally for offline use. The option to have a local vault ends with v7.
2 Likes
I know lot of users are planning to migrate to the new Keychain on iOS15 and Monterey. Although, Iām not sure how secure it is, coz right now, we need atleast two steps of authentication to access passwordsā¦Macās login password, and password managerās password. With Keychain, its reduced to only only one since you can access keychain with macās passwordā¦
Which makes the question of why they got rid of them even more interesting.
Yeah. I meanā¦at some point, a āvaultā is just files on a disk, whether itās stored locally or in the cloud.
I can absolutely see that features that logically require a cloud wouldnāt work with local vaults - but v7 seems to have managed okay. If there are reasons tied to the Electron / Rust changeover, it makes sense. But if not, Iād really like to hear a better explanation of āwhyā.
And itās not backwards-compatibility. 1PW hasnāt been shy at all about breaking backwards compatibility with the release of new versions. You upgrade, you upgrade your vault, the old version canāt even access them anymore.
I think the removal of local vaults is simply a push to full SaaS, nothing more.
5 Likes
Presumptively true. While the shift to Electron for the UI can be argued pro and con with points on either side, the removal of local vaults seems (to me) to be an odd decision. I would tend to think that the code to maintain a vault on a local machine would not be that different from the server-side code that handles to vault so as to make maintaining local vaults not that difficult, but obviously I donāt know enough to really understand their issues.
@karlnyhus I would have thought that the code to maintain local vaults would not, in fact, require significant support in the UI compared to the back end implementation. I would have expected separation of that logic. Again without knowing the implementation details, of course, we cannot say for sure.
@DrJJWMac I am sure you are correct that the local vault code on Windows would be different than on Mac. However, I would think that much of the vault code is abstracted from the OS support layer, and there is certainly code that is platform dependent no matter what, such as using the underlying OSās preference system, for example, or the notification system, or security (unless the ability to use Touch ID is going away on the Mac, for example). I would have made a guess that the vault code is somewhat more generic until it gets to the point of actual file access which certainly would be platform dependent. I still donāt think that the shift to Electron is a compelling factor in eliminating local vaults. Only 1PW can truly answer this question, of course.