My original email to 1password security, edited slightly to keep some personally-sensitive info private:
Hello! Prompted by https://twitter.com/1Password/status/1429812863464509451?s=20 I'm writing to learn more. (Thank you for prompting!)
For background, you should know that I'm a multi-year personal/family 1password user, plus I led the company-wide (~35 people) adoption of 1password at my prior company, plus I've been pushing for company-wide adoption of 1password at my new company (~30 people). Both companies are software companies, my schooling was in computer science, and my role is VP Engineering. So I have both a personal and a professional interest in this, and a pretty-deep understanding of the issues. If this were just for personal use, I probably wouldn't have bothered to write to you, but I'm also responsible for this decision in my professional life, so I want to be more-careful about it.
I did read https://dteare.medium.com/behind-the-scenes-of-1password-for-linux-d59b19143a23 but it doesn't really address how secrets are kept safe as they pass through Electron. Even if it is just a "skin" it will still have unprotected credentials, including (presumably) my 1password account password. So I don't think it matters, much, that it's just a skin.
From there, my basic understanding of Electron is that it's an extremely difficult platform to keep secure. The top of the Electron security checklist makes it very clear why:
It is important to remember that the security of your Electron application is the result of the overall security of the framework foundation (Chromium, Node.js), Electron itself, all NPM dependencies and your code. As such, it is your responsibility to follow a few important best practices:
- Keep your application up-to-date with the latest Electron framework release. When releasing your product, you’re also shipping a bundle composed of Electron, Chromium shared library and Node.js. Vulnerabilities affecting these components may impact the security of your application. By updating Electron to the latest version, you ensure that critical vulnerabilities (such as nodeIntegration bypasses) are already patched and cannot be exploited in your application. For more information, see "Use a current version of Electron".
- Evaluate your dependencies. While NPM provides half a million reusable packages, it is your responsibility to choose trusted 3rd-party libraries. If you use outdated libraries affected by known vulnerabilities or rely on poorly maintained code, your application security could be in jeopardy.
- Adopt secure coding practices. The first line of defense for your application is your own code. Common web vulnerabilities, such as Cross-Site Scripting (XSS), have a higher security impact on Electron applications hence it is highly recommended to adopt secure software development best practices and perform security testing.
Those first two bullets seem nearly impossible. It isn't just that you have to use a recent Electron framework during dev; you also need to get that shipped out to your users ASAP. How will you ensure that your users will always be running the latest Electron framework? What's the expected turnaround time from when a vulnerability is announced until updated software is in your users hands?
And then how do you ensure that you really know what's in all your NPM dependencies, and whether they are secure? Supply-chain-style NPM attacks are an ever-growing problem, and npm audit isn't a solution. How do you be sure you know what you're shipping, and whether it was developed with any security awareness at all? How do you do that, over time, with update after update after update, across your package ecosystem?
In my role and my company, we take the protection of our own network and our assets very seriously. We're pretty paranoid about it. Giving a third-party vendor our most-precious secrets requires an enormous amount of trust. I've had that trust largely because of your whitepapers and long history of not being hacked. But choosing to use a framework like Electron - even if you've gone over-the-top trying to secure it - makes me doubt that trust.
Also, FWIW, my experience with Electron apps is that they're never as nice as native ones. Once "security" is established, then the next major differentiator for a password-management tool is its UX, and choosing to use Electron feels like another major hurdle to having great UX. I'm willing to wait and see how it actually works, but my assumption is that 1password 8 will be worse than 7, in this regard. This also hints at decision-making more focused on engineering efficiency than on making great products. If that's where the priorities lie, then it's hard for me to bet on 1password for the long term.
I would love to know that I'm wrong on both these points, and I'd love to be able to trust this new version. I look forward to hearing your feedback.
Sincerely, Nathan
Hi Nathan,
Thanks for emailing us - I saw your tweet and thought "this requires a bit of a longer thought", so very happy you sent us this message! Having been a long-term technical 1Password customer too, I would have the same questions.
As David's pointed out in his blog post, and the point I want to make here, is that our use of Electron is a bit atypical. This doesn't completely remove all risks from Electron, but it does make a lot of the problems that usually come with the territory a lot more manageable. Electron's security guidelines in particular make a couple of assumptions about Electron apps that don't quite hit the mark for how we use Electron.
When releasing your product, you're also shipping a bundle composed of Electron, Chromium shared library and Node.js. Vulnerabilities affecting these components may impact the security of your application. By updating Electron to the latest version, you ensure that critical vulnerabilities (such as nodeIntegration bypasses) are already patched and cannot be exploited in your application. For more information, see "Use a current version of Electron".
The guidelines here talks to any user of Electron apps - there are some very poorly maintained Electron apps out there in the world. It's easy to ship and forget with desktop applications - especially if you've only got a small team who are essentially "packaging a web app". This is part of how Electron gets its bad reputation. But that's not what 1Password 8 is, nor how we build it - we have a team of dozens of engineers working on 1Password 8 daily, including a handful of security engineers like myself. Automations warn us about security events in Electron and dependencies, and automation helps us stay up to date. We're always tracking extremely recent versions of Electron in our releases - to the point that we're one of a select few closed source applications on Linux that works well on Wayland today (which has been a recent addition to Electron).
Since 1Password 8 is the lifeblood of what we do, and keeping up to date with Electron is essential in that, that's a process we are going to maintain going forward.
Finally, I should say that one common problem of Electron applications is that they process unfiltered web content directly. Just some primary examples like Slack and Visual Studio Code use Electron to directly display web content and web interactivity to users. While 1Password 8 certainly processes untrusted content that we must be careful with (can you always trust who you share vaults with?) our architecture enforces that the Electron layer is limited to HTML, CSS and JavaScript that we packaged in the app. This limits our exposure to classes of vulnerabilities that plague the Chromium project, as well as other Electron apps that depend on Chromium for displaying that untrusted web content. Vulnerabilities affecting Electron that pose a direct risk for your passwords are conceivable, but have to be quite spectacular vulnerabilities to work in our architecture. Spectacular vulnerabilities like those are very rare, also conceivable in other UI frameworks, and would be red alert events that prompt immediate action from us just like it would be in 1Password 7.
Evaluate your dependencies. While NPM provides half a million reusable packages, it is your responsibility to choose trusted 3rd-party libraries. If you use outdated libraries affected by known vulnerabilities or rely on poorly maintained code, your application security could be in jeopardy.
One thing I can definitely attest to is that managing NPM dependencies can be messy - it's an ecosystem one has to put up with. But this piece also speaks to the large number of apps whose stack is "JavaScript all the way down". That isn't true for 1Password 8. Since Electron is only the UI layer, the number of npm dependencies we need to maintain is very small. Speaking from working on 1Password.com - the amount of dependencies that need to be maintained in 1Password 8 is miniscule in comparison. The UI layer's dependencies are something we feel well in control of. (I should add that even for a rich web application such as 1Password.com, we're doing quite well :) ).
This does mean that a lot more dependency management work goes into our Rust layer. Luckily, Rust is an ecosystem with a different culture of correctness and cohesion. That still needs to be managed, but that is no different from any other desktop application technology stack.
Adopt secure coding practices. The first line of defense for your application is your own code. Common web vulnerabilities, such as Cross-Site Scripting (XSS), have a higher security impact on Electron applications hence it is highly recommended to adopt secure software development best practices and perform security testing.
We already have a track record of secure coding practices, something that me and my colleagues help enforce in the company. For some examples please visit out our Security Assessments page 0 and stay tuned for reports on 1Password 8 there.
You might also be interested in a talk from my colleague Mitch about how we made Electron do what we want 1.
--
Having said all that, you might still say that Electron has more security disadvantages than some other UI frameworks. Superficially, it can look that way. But there's some overlooked advantages of using Electron as well. Most notably, it allows us to focus our engineering efforts into one app. That also means our security engineering efforts - instead of having engineers for three platforms, we can improve one technology stack at once. From an engineering process perspective, that's a huge win. It also means we can iterate more quickly by updating one technology core - meaning that it's easier to release frequent updates with security enhancements and hardening, as well as new security features. No desktop app left behind.
Furthermore, the community around Electron allows us to get more speedier insights into potential security issues, and offers great tooling. This is something we're also contributing back into 2.
Fundamentally I think Electron suffers from a reputation problem at the technology level. There's some merit to that reputation, but I think we've come up with a way that manages to avoid nearly all of that bad reputation from applying to us. That's also a way that does give us with the advantage of allowing us to greatly improve the process by which we build 1Password 8, which should make it an even more secure app.
This is a fantastic answer - thank you very much! I have a much clearer sense that you've made this decision with eyes wide open, that you've aggressively addressed the risks that arise from it, and that you might even be right that this is the better option. I will share my feedback on twitter and with my company.
(On the usability side, I'll wait until I get a chance to get my hands on v8.)
Thanks again, Nathan