Hi. I'm a feature developer for 1Password, and I want to clarify a few things. I've already posted this elsewhere, but I've seen multiple threads spreading misinformation that our technical decisions are being driven by VC funding. This could not be farther from the truth. We have been working on these changes long before we received any form of outside investments.
Over the past few years, we've been working on consolidating 1Password's business logic into a single Rust-powered core that could be shared across all our apps. This has many advantages: feature consistency across platforms, faster development cycles, and better security. When building the front-end for the desktop platforms that would take advantage of this new core, Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac. We actually did build a native Mac app initially alongside the cross-platform Electron app, but we eventually decided that having two separate versions of the macOS app (one in Electron, one in SwiftUI) would cause a lot of needless development churn and hassle for both customers and our support team.
I can understand your frustrations about Electron and our subscription-based model, but I hope you find my explanation reasonable. Please stop spreading misinformation.
Hi, long-time user, customer, and word-of-mouth recommender of 1Password for the nine years my Hacker News account has been active (give or take a few months). This is a big announcement that I'll have to chew on to understand what this means.
Can you quantify the "needless development churn and hassle for both customers and our support team" in some way? Presumably, 1Password 7 and its ancestors used native macOS APIs, which meant some degree of that given you had to do something different on Windows and/or Linux. I don't know what your support team has had to endure, but as a long-time sample size of 1, I've been incredibly satisfied with the way you've designed and engineered the macOS application (and the iOS app too!) to date; I'd be hopeful that whatever tradeoffs y'all will be making moving to Electron, the "native" feel of the macOS client wouldn't be sacrificed. Is there anything you can speak to there that I should prepare for with 1Password 8?
> Can you quantify the "needless development churn and hassle for both customers and our support team" in some way?
Sure, happy to elaborate on that! Since we were rebuilding our app from the ground up, it was a significant slow-down on development to create a user interface for both Electron and SwiftUI, requiring two separate teams of platform developers for every feature we needed to implement. There were also concerns by the documentation and support teams that we would need two separate sets of instructions for many common tasks, due to small differences in layout and look between the applications. Eventually, we had to make the tough decision to focus on a single common framework for desktop. This will allow us to ship features across every single platform far quicker than we could before.
> I'd be hopeful that whatever tradeoffs y'all will be making moving to Electron, the "native" feel of the macOS client wouldn't be sacrificed.
We've tried our very best to keep the experience the same so that the transition from 7 to 8 is smooth, and from my point of view 1Password 8 feels right at home on macOS - I especially love our new translucent sidebar. That being said, this is still in an early access stage, so there are bound to be hiccups and UI issues that need to be resolved. Please let us know if you run into any problems or have suggestions on how we can improve. And thank you for being a long-time user!
This is such nonsense that I can't let it go unremarked. I can count on the fingers of zero hands the number of times 1Password has shipped a "new feature" between major releases. There are no new features needed, it's a password manager. However, I would need to borrow some extra hands to count the number of features you've removed, features that loyal paying customers of many years depend on. 1P7 doesn't even let you keyboard navigate to the Generate Password button for goodness sake - something that I was able to do in every version up to that point.
Absolutely nothing about any decision AgileBits has made in the last 4 years has had anything to do with what customers (that's us, the people that used to give you money) want, and everything to do with nickle and diming the suckers dry.
UI consistency between different operating systems is NOT a user-focussed feature. When I'm on a Mac, I want my apps to behave like a Mac app. When I'm on Linux, I want my apps to behave like a Linux app. If you _actually_ believed that all apps should look and behave the same on any OS, why does the Android version look and behave nothing like the Mac app?
You've removed features with every major release, and this is just smashing the final nail into 1Password's coffin. You've ruined what used to be the best password manager on any platform.
I mean looking at this I can see why people came to the conclusion that this was primarily a move that VC funding caused even though AgileBits seem to vehemently deny this.
The funny thing is, they were doing just fine for years with just their own money. Now that they have sooo much more money, they suddenly can't afford separate developers for different platforms... they should be able to hire 10x more people now.
The primary issue with having two separate teams for the same platform was not money, it was time. To be clear: we wanted to build a native app in parallel with our cross-platform Electron solution, and we had the developers to do it. But unfortunately, having an additional team that needed to implement the UI for every single new feature was a significant slow-down, and we collectively realized that we could not meet our deadlines nor maintain this long term.
I'm sorry for not being more clear earlier as to why we couldn't support two separate teams for the same platform. Hopefully this clears up any confusion.
I don’t understand why two teams means slower. Are you keeping the total number of engineers the same? If you are saying 2x engineers on electron complete tasks faster than 1x on electron and 1x on native, you are basically agreeing with OPs take.
You take money to provide software. But then you become lazy and greedy and want 1 size fits all. End result is your users having clunky, high latency experience.
I think he’s saying 1x on both Electron and Swift UI was making it too hard to ship either version to an acceptable standard because each was slowing the other down due to inconsistencies, difficulty staying in parity and double communication.
Unfortunately, it’s normal in software development for multiple platforms to increase development complexity when feature and UX parity is prioritized.
Maybe I'm missing something, but i pay for those teams with my client purchases. I have a mixed computing environment and have purchased versions 3, 4, 5, 6 & 7 for three platforms.
I'd like to believe this isn't primarily profit motive. What gives me pause is how I write regularly asking for separate vaults for trivial passwords and passwords that could lead to financial ruin. The profit motive wants to keep 1Password simple to use, at the expense of security. I've been forced to buy a second password manager for sensitive passwords.
I'm sorry you feel that way. I'd love to know more about your issues with our current vault implementation in more detail, so I can pass along your feedback to the rest of the development team.
> What gives me pause is how I write regularly asking for separate vaults for trivial passwords and passwords that could lead to financial ruin.
Just to clarify, what solution are you asking for? Do you want a local vault option to store sensitive passwords? Or something else?
I am very unhappy that 1P is moving to Electron for macOS for the reasons people here have reiterated a million times. I am actively looking for alternatives now.
As much as I'm "meh" on Electron, I rarely use the actual 1Password App. On the other hand, I use the Firefox extension 30+ times a day, and that's about as far from a native app as you can get. So I think I'm fairly unlikely to notice a huge issue, and will instead be pleased that consolidating on Electron gives them greater feature velocity.
On the other side, I use the 1Password app extensively and make heavy use of all the different categories (secure notes, Windows MSDN licenses, etc). I’m extremely disappointed to see this turn into yet another sub-native browser-in-a-window experience.
You'd get rid of a working solution because of an implementation decision? I _love_ 1P, and I use it on Mac, Windows, Linux, and iOS, and it makes perfect sense that they standardize on Electron.
> You'd get rid of a working solution because of an implementation decision?
Yes, because the implementation decision has implications for both performance and UX. I’ve used 1Password since version 3 (2013!) and gotten friends and family to do the same, but I think I’m done when 7 stops working.
> I've already posted this elsewhere, but I'm seeing some misinformation that our technical decisions are being driven by VC funding. This could not be farther from the truth. We have been working on these changes long before we received any form of outside investments.
That's worse, not better.
At least being forced to by investors makes sense. The current direction of travel being voluntary means you've just got a bad nose for building security.
>would cause a lot of needless development churn and hassle
The hassle of doing what your users are paying you to do? Any child can hack a UI together in HTML but there's a reason no one (usually) pays for that.
I'm a feature developer for 1Password, and I want to clarify a few things. I've posted this already in another thread, but there seems to be some misinformation being spread that our technical decisions are being driven by VC funding.
Our decision to built the macOS app in Electron was absolutely not driven by VC money. For the past few years, we've been working on consolidating 1Password's business logic into a single Rust-powered core that could be shared across all our apps. This has many advantages: feature consistency across platforms, faster development cycles, and better security. When building the front-end for the desktop platforms that would take advantage of this new core, Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac. We actually did build a native Mac app initially alongside the cross-platform Electron app, but we eventually decided that having two separate versions of the macOS app (one in Electron, one in SwiftUI) would cause a lot of needless development churn and hassle for both customers and our support team.
I can understand your frustration about Electron, but I hope you find my explanation reasonable. Please stop spreading misinformation.
With respect, I disagree with your conclusion about a SwiftUI version causing hassle for customers. Every time I use an Electron app, I get the distinct feeling that its developers are prioritizing their experience over my own. We the users subsidize faster development cycles with wasted CPU and memory, laggy interfaces, and strange, non-native UX.
> We the users subsidize faster development cycles with wasted CPU and memory, laggy interfaces, and strange, non-native UX.
I can absolutely attest to that with a relatively underpowered computer (4 gb of RAM). I can barely use 2 electron apps after which my computer grinds to a crawl (I’m running VSCode and Slack mostly). I have stopped using the discord desktop app and exclusively use the website now.
Thank you for letting me know your concerns. Just to clarify: when I said that a SwiftUI version would cause hassle for customers, I was referring to how releasing two separate versions of our app - one in Electron, and one in SwiftUI - would be confusing for non-technical users. I should have phrased that better, my bad.
Sorry for the confusion. With 1Password 8, we re-built the entire app from the ground up. We didn't have a working SwiftUI solution that we could just pick up and use - we had to re-architect the entire frontend from the ground up. So when we made the decision to stop working on the SwiftUI app, it was far from being complete.
That Electron is an unpleasant experience and is a resource pig that makes Java look svelte? No, that is not misinformation.
That AgileBits has been doing everything it can to force people to the subscription model and that this push to subscriptions very coincidentally lines up with two rounds of VC investment for over $300M over the past couple of years? No, that is not misinformation.
It may have been easier for the dev team to use Electron as their cross-platform toolkit, it is not easier for the users to put up with the attendant bloat and reduced performance.
The ones who should stop spreading misinformation regarding the forced subscription all seem to be working for AgileBits.
That’s reasonable logic but for me with a company subscription and previously having been an individual purchaser with my backup in iCloud rather than on 1 pass servers, it doesn’t really tilt the balance - I also hate electron with a passion and will be looking to stay on 7 for as long as possible with a high likelihood of shifting to a different provider due to the forced shift to cloud storage after this.
There's a reason people prefer one over the others. You can't have one front-end for all these different platforms. Well, you can, but then it's a compromise for at least 2 out of these 3 platforms.
So you had the beautifully engineered experience of macOS to draw native user experiences from, and then you just threw it out because you wanted parity?
That doesn't make the macOS experience better, it makes it worse.
Hi, I work for 1Password. I can understand your frustration that we're phasing out local vaults. Luckily, I have some good news: we're currently running a survey to gauge user interest in self-hosting options. If you're interested, go to https://survey.1password.com/self-host/ and let us know your thoughts. Thanks!
Hi. I'm a features developer for 1Password. You raise a very good question (one that I used to have myself, before I started working here). I would recommend you read our security whitepaper (https://1password.com/files/1Password-White-Paper.pdf) if you want details, but the TL;DR is that we don't know your account password and our servers only store your encrypted information (which we cannot read), and communication is done over HTTPS with an additional layer of encryption via the SRP (Secure Remote Password) protocol. You also might enjoy this blog post: https://blog.1password.com/what-if-1password-gets-hacked/
>the TL;DR is that we don't know your account password and our servers only store your encrypted information (which we cannot read), and communication is done over HTTPS with an additional layer of encryption via the SRP (Secure Remote Password) protocol.
I understand that my data is safe with you guys at rest. I'm sure your security protocols are top notch. But it's all about attack surface. Things can and do go wrong on the internet all the time. Bits get flipped, certs expire, DNS cache gets poisoned, employees get phished, and MITM is an omnipresent threat. I'd just rather avoid all of that.
It's really simple. It just doesn't consider anything unexpected happening.
Compromised algorithms are unlikely. But not impossible. Quantum computing enabling brute force attacks is unlikely in the immediate future, but not impossible. Certificate pinning compromise during transport is not implausible for state actors.
And in those scenarios and others, having the vault stored remotely on someone else's machines is inherently less secure than not.
Hi. I'm a feature developer for 1Password, and I want to clarify a few things. First of all, our decision to built the macOS app in Electron was absolutely not driven by VC money. For the past few years, we've been working on consolidating 1Password's business logic into a single Rust-powered core that could be shared across all our apps. This has many advantages: feature consistency across platforms, faster development cycles, and better security. When building the front-end for the desktop platforms that would take advantage of this new core, Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac. We actually did build a native Mac app initially alongside the cross-platform Electron app, but we eventually decided that having two separate versions of the macOS app (one in Electron, one in SwiftUI) would cause a lot of needless development churn and hassle for both customers and our support team.
I can understand your frustration about Electron, but I hope you find my explanation reasonable. Please stop spreading misinformation.
>Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac.
This is the source of your mistake. Users don't desire to have the same UI across different OS environments, it's only an app's developers that care about that. Cross-platform UIs are inarguably a worse user experience than UIs tailored to the conventions and designs of each OS.
A Mac app that doesn't actually feel or behave like a Mac app is not a good Mac app. The same is true with tvOS apps like YouTube and Prime Video that don't actually feel or act like good tvOS apps.
I wholly agree with this, I choose Macs and use basically exclusively "good" Mac apps since I want everything I use to just feel right. On the occasion I use Windows or Linux, I want the UX to feel akin to what other applications on those platforms use.
Kinda a random thought, but is it at all possible to build a native 1Password app using their API [1]? I haven't read Agile Bits' ToS, but I would be interested in working on / following a Mac-centric client.
> Users don't desire to have the same UI across different OS environments
Um, speak for yourself. I personally don't like having the docs showcase completely different UIs to the one I'm using. I also like having an app i can run on Linux, which has been happening a lot more since Electron became a thing (no sane company wants to write apps in GTK, and much as Qt is a great toolkit it requires expertise most SaaS vendors don't have).
You're speaking as if it's fait accompli that 1password made a mistake picking electron. It is not, and I am fairly certain they did not.
There's an argument to be made the other way around:
Maybe if you choose to use multiple platforms you should just deal with the multiple approaches to UI? Why should the single platform citizens suffer from a UI that's inconsistent with the rest of the platform?
To stretch it to an absurd case:
Imagine Slack decided that the shortcut to copy text will be Ctrl+C on all platforms. And Windows users who occasionaly use a mac would rejoice because it would save them from having to think which button to press.
Anecdote, but, my workstation is Linux, my work laptop is macOS, my personal computer is Windows where I run Linux VMs. I run 1Password across all these operating systems. Having a consistent interface is nice and it means I don't have to relearn the UI three times.
> Users don't desire to have the same UI across different OS environments, it's only an app's developers that care about that.
I guess we'll have to agree to disagree on that. I personally enjoy having consistent user interfaces across the apps that I use, and there are many other people that would say the same, so I would avoid making broad assumptions. From our perspective, consistent user interfaces are a win-win for both the development team and the majority of end users. That being said, I'll take your feedback into account.
This is a curious response. I would have used the same reasoning as an argument against Electron (or similar unified development systems): they are not consistent with all of the other native apps that people use.
I don't know if your reasoning is that looking like a web app means it is consistent with those apps, or that the apps look the same across platforms, but neither of those arguments are compelling to me. I chose the platform I am on because I think the interface is a good one that makes me more productive.
And I have never found an Electron app (or web app in general) that is as high quality as good native apps (on any platform). There are just so many compromises, and I am not even considering resource usage here. Everything just feels a little slip-shod.
Thank you for that well-written explanation of your concerns. Your frustrations are shared by many users in this thread, and I'll do my best to pass them forward to the rest of the dev team.
> I guess we'll have to agree to disagree on that.
This is such a bizarre claim. I know Agilebits understands Mac users.
To be brutally honest, I've heard this line from a lot of software shops after they decide tailoring their apps to the native platform is too expensive or inconvenient for them. Suddenly they all find that their users don't care about their native platform - I suspect if I went looking for the discussion from back when Adobe did this, I'd see the same phrasing.
> I guess we'll have to agree to disagree on that.
Let's be clear about this: you are the seller, we are the customer. You can't `agree to disagree` with your customers.
If you don't agree to what some your customers are telling you, then they won't be your customers, and you won't lose just these customers but also all the others who observe your behavior. It is a modified case of repeated prisoner's dilemma. If I observe that you tend to defect on other instances, I will less inclination to cooperate. In other words, your reputation will suffer.
On the consistent user interfaces, the consistency of an app with other apps on the same platform is much more important than the consistency of that app across platforms. Even if you use multiple platforms, you switch much more frequently between apps on the same platform than between different instances of one app across platforms.
I don't have super strong feelings about native v.s. cross-platform UIs, but I think I (and maybe others) think about this question from the "reverse" direction. I expect a given service / app / functionality to work the same everywhere, no matter the platform. This is true of tools I use through my terminal or tools I use in GUIs. Other approaches feel to me like they make using the product more difficult - I may not be able to help someone else on another OS use it, it may mean that an obscure platform has more bugs than a unified approach, etc. I understand why native may make sense, but I do not think it is a given.
But how can you justify removing the ability to have a local vault?
Why would anyone think for a second that it would be a good idea to force people to store every password for everything in their life in your cloud without an opt out?
That, even more than Electron and the subscription model (both which do bother me), is an absolutely deal breaker. I've paid for every version of 1Password since v3 in 2009, but I'm done with it now.
The original article goes into great detail as to why we're moving away from local vaults.
That being said, we are looking into gauging user interest in self-hosting. Please take a look at our survey [1] if you want to share your thoughts. Hope that helps!
I don't want self-hosted, and I definitely don't want subscription based. I, 1Password user for many years, want the local vaults!
1Password 6 is great, and I'll keep using it until it quits working on my devices, but no more after that! I used to recommend 1Password so much to people it was borderline evangelizing, but I quit recommending it once the subscription was pushed over the other options, and now that local vaults are going away I'm actively recommending against it to anyone that asks.
Guess I'll be moving to Bitwarden or Keepass myself; time to research!
Thank you for pointing me to that thread. I'll make sure to respond there as well.
I did (incorrectly) assume that the parent was talking about Electron, so that's my bad. That being said, our decision to move away from licensing is absolutely not being driven by VC funding, so the parent comment is also spreading misinformation. We were building a subscription-based model all the way back in 2014, and we're phasing out licenses for the host of reasons that were mentioned in the original article.
In my experience the impact of VC money isn't directly seen by engineers but is rather a subtle top down shift in direction. Growth matters more, revenue matters more, existing users matter a bit less versus future users, features that impede this are removed, etc. Feature direction shifts slowly but surely.
The goal of a VC company is to either grow big or die. That's it. Risky bets at the expense of existing users are expected if current growth does not meet expectations. Worst case everyone quits the app and you go bankrupt. VCs expect that 9 time out of 10 so no big deal as long as the 10th makes it big.
Hi, I didn't mention Electron in my comment, it was purely about the move to remove single time purchase and local vaults. I don't like the direction where the product is heading, therefore I want out.
The short answer is no. People often have misconceptions about Electron apps based on their experiences with a poorly written one. I've had my own fair share of bad experiences with Electron-driven apps. But the way we've utilized Electron is far different than most applications.
Our Electron app is really only a thin client over a Rust-driven backend that handles all our business logic. We only invoke Typescript when we need to render the UI; everything else goes through Rust. We even run some Swift code too, for deep integration with the operating system.
Memory is still an issue with Electron, but we're getting better at reducing the footprint. We've put a lot of work into optimizing this app, so I recommend you give it a shot; I think you'll be pleasantly surprised by how performant and responsive it is.
I think you might have a misunderstanding of how our browser extension works. Just like our desktop app, your password is only in memory if you copy it to the clipboard, fill it in the browser, or reveal it within the app. Your passwords are always stored encrypted on both the desktop app and browser extension, and we make an active effort to keep secrets out of memory. I hope this clarifies things.
Turns out that yes, I thought that the vaults were encrypted as a whole, but according to the security white paper that changed at some point. So you can decrypt individual passwords.
Over the past few years, we've been working on consolidating 1Password's business logic into a single Rust-powered core that could be shared across all our apps. This has many advantages: feature consistency across platforms, faster development cycles, and better security. When building the front-end for the desktop platforms that would take advantage of this new core, Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac. We actually did build a native Mac app initially alongside the cross-platform Electron app, but we eventually decided that having two separate versions of the macOS app (one in Electron, one in SwiftUI) would cause a lot of needless development churn and hassle for both customers and our support team.
I can understand your frustrations about Electron and our subscription-based model, but I hope you find my explanation reasonable. Please stop spreading misinformation.