If there is a lack of active exploitation of Electron apps then it is the job of application developers to consider the security of Electron, and it is not the job of application users to consider the security of Electron.
If we were to tell everyone to avoid Electron-based desktop apps when there is not and has never been any sort of active exploitation, that is the exact same fear-mongering as cybersecurity professionals telling every person on earth to avoid charging their phones at airports. i.e. a complete waste of time for the past 15 years which ultimately served nobody.
Since Privacy Guides is written for application users and not application developers, then it would follow that no writing on this topic is necessary.
Electron is known to have very bad defaults, and a very large attack vector. Imagine making your app have the same amount of vulnerabilities as a browser that is known to get hundreds of CVEs monthly. Only to be left at the mercy of app developers to update their app individually, or your device ends up being a cesspool of RCEs.
Has there been a documented case of a service provider stealing users’ private keys because they used a web app? Because it’s not recommended here Common Threats - Privacy Guides for that reason
I don’t think we should wait until there is an Electron vulnerability being abused in the wild before PG takes a stance against it, that’s a reactive approach rather than a proactive one. Not using Electron is massive attack surface reduction which aims to eliminate the impact of any vulnerabilities that may eventually be used or are currently being used but not reported.
Application developers aren’t doing much in securing their Electron applications either. I have not found a single provider that actually updates Electron every time there is a new release, meaning most Electron software will be many versions behind Chromium. It’s not like Electron itself keeps up with Chromium releases at the same pace as they are released either. We’re not going to chase around every developer to see if they are implementing good security practices for their Electron applications.
You shouldn’t be looking at it from an Electron POV but a Chromium one. There are very likely RCE vulnerabilities that have been patched in Chromium many versions ago but some developer is on an outdated Electron version (can be outdated without being EOL) which makes their app susceptible to RCE as well. Just because Electron hasn’t been exploited (in the wild) yet does not mean that it is difficult to do so.
Actually, I think the language used on that page might bridge the gap between what y’all are seeming to advocate for (explicitly discourage or admonish Electron use) and what @Jonah seems supportive of (promoting better alternatives, but not outright recommending against Electron). The wording on that page seems to be a balance between the two:
[In the context of E2EE] Therefore, you should use native applications over web clients whenever possible.
The above highlights a risk, and recommends an alternative. Without explicitly saying ‘don’t use X’ or ‘X = objectively bad’
I wonder if a similar format would be appropriate and agreeable in the context of Electron? [1]
As an aside, I also wonder what people would prefer to see used instead? (without ignoring the thing that makes Electron popular in the first place). [2]
Side Note
I don’t think the linked example (webapps and e2ee) is completely comparable. The warning given isn’t about web apps generally, it is specifically made in the context of E2EE and in the context of privacy FROM service providers. Which is an important distinction. Anyone who seeks out E2EE, wants (and assumes they will have) protection that doesn’t depend on the service provider. E2EE exists in large part to eliminate (or reduce) the need to trust that the service provider won’t be malicious or compromised. So it’s extremely important in the context of E2EE to at least note that the guarantees and certainty you might normally assume E2EE provides, can be more fragile and less certain in the context of a webapp.
I’m not sure if there is anything comparable to the above with Electron, where the main argument seems to be that electron apps are often outdated or behind Chromium. It’s a real and relevant consideration, but categorically different and not nearly as fundamental as a warning about a system that many people logically assume is zero-trust, is actually not fully zero-trust in one particular context.
(I have no strong personal perspective on electron, I see pros and cons, I’m insufficiently informed on the subject, I’m just seeking to bridge the gap between the two positions in this discussion), ↩︎
As a Linux user its hard not to be aware that any extra friction for developers can often lead to developers just deciding it’s not worth it to support a smaller OS. ↩︎
So to be clear, you are suggesting that the language is not strong enough? And the warning should be stronger than a warning about a form of encryption most people assume to be zero trust not actually being zero-trust in a certain context?
Can you articulate that argument? (it sounds disproportionate and illogical to me, but its likely there is something I’m not fully appreciating or understanding).
The only way to achieve zero trust is to check the source code for backdoors and do it every single time the code changes. Then you should either use reproducible builds or build everything yourself, but nobody is doing that, so there is no zero trust.
Using web E2EE is only an issue if the web server gets compromised, which is very unlikely for something like Proton services.
Meanwhile, Electron is actively hazardous without any unlikely scenarios like the web servers of Proton getting compromised.
The point that was brought up about PG recommending against web-based E2EE wasn’t to support the argument for removing Electron. It was brought up to combat the idea that security measures should be reactive rather than proactive.
It wouldn’t have made sense for GrapheneOS to start working on forensic exploit mitigations only after the Cellebrite docs were leaked. This would have been reactive security and wouldn’t have benefitted GrapheneOS users as the damage would have already been done.
The GrapheneOS team were not waiting for “real-world” exploitation of Pixels before they started working on their mitigations. This is proactive security and the end result was successful protection against Cellebrite before their capabilities were ever revealed.
In a similar sense, PG is being proactive when they recommend against web-based E2EE. Not because there have been previously successful attacks on the servers of any service provider but to protect against a future attack. (I assumed a malicious actor outside the service provider as the provider themselves could just push out an app update that undermines encryption.)
It makes sense that PG should take a proactive appraoch regarding Electron as well, seeing that the security deficiencies of Electron are numerous and well-known.
if there is no way for the server to remotely push code and the only provided code is on the application, at least there always is a way to verify a compromise post factum. With a web app it’s too easy for the attacker to compromise a portion of the userbase in a way that is almost impossible for anyone to ever know about.
I was combating your stance that PG should not tell people to avoid Electron as there hasn’t been any active exploitation yet. I wasn’t talking about whose responsibility it is to consider the security of Electron.
Anyway I replied to that point earlier as well:
Application developers aren’t doing much in securing their Electron applications either. I have not found a single provider that actually updates Electron every time there is a new release, meaning most Electron software will be many versions behind Chromium. It’s not like Electron itself keeps up with Chromium releases at the same pace as they are released either. We’re not going to chase around every developer to see if they are implementing good security practices for their Electron applications.
It shouldn’t be the responsibility of PG readers to make sure that developers are following good security practices when developing. However, it should be the responsibility of PG itself to highlight the lack of security practices and issue a warning so users are at least aware.
I don’t necessarily agree with this… It is always the users’ responsibility to ensure that their system is secure, and this entails the security of each individual app too, ensuring everything is up-to-date and not relying on EOL dependencies etc.. It’s annoying but required as apps get dropped all the time, developers have other things to do in life, etc.
What part of “post factum” did you not read/understand..?
I think you are looking at (or choosing to frame) this in an extremely black and white way. It’s frustrating (and not very constructive) to try to discuss when everything is treated as a binary.
(Maybe unintentional) but this feels like a strawman. It’s not really releveant whether it’s likely or unlikely for “something like Proton” because it is a general statement made about an entire category of applications (E2EE services delivered as webapps) not a statement made about Proton. Choosing one well established service that you consider unlikely to be compromised as your example, isn’t representative of the whole category.
(also if the argument is that Proton is so big and so responsible that their servers won’t ever be compromised (which is a assumption I don’t believe Proton would ever make), it seems that it should follow that they should also be capable of keeping their electron apps up to date and secured to their own standard)
The only way to achieve zero trust is to check the source code for backdoors and do it every single time the code changes. Then you should either use reproducible builds or build everything yourself, but nobody is doing that, so there is no zero trust.
Technically true in black and white terms, but not a reason to dismiss the point. I’d prefer not to discuss in black and white terms, I don’t feel it is useful. There is a meaningful difference between the hypothetical you’ve described and the hypothetical risk attached to e2ee webapps. Security is almost always a spectrum, both risks can exist, but still not be equivalent risks.
If my understanding is correct (admittedly I’m very much a non-expert here), all that would be required to expose a malicious update for a traditional foss application is that a single user or researcher, at some point discovers malfeance. Because updates are broadcast, not targetable at individuals. Whereas for a webapp, the possibility to exists to ship different updates to different users. A malicious update could target a subset of users, or could target a single individual. The likelihood of this ever being discovered seems many orders of magnitude less likely than an update shipped to all users.
What you are suggesting would be more akin to GrapheneOS telling their users to never use the system clipboard because they haven’t yet added clipboard access restrictions. Obviously completely unworkable advice for most people who use their devices like a normal person, in the same way that “avoiding Electron” is completely unworkable advice for most people when most Electron apps have no viable alternatives.
When GrapheneOS does add clipboard access restrictions then people will be more secure, but in the meantime there is no need for anyone to go around warning every GrapheneOS user of the dangers of the system clipboard.
Causing needless panic over Electron, or malicious clipboard access, or any of these other theoretical-only security issues is totally against what we are trying to do, which is to provide practical and actionable advice about improving your privacy and security.
There are many Electron apps that 1) we recommend, and 2) people should use, so simultaneously recommending that people avoid Electron apps will do nothing but confuse people for, as far as I can tell, virtually 0 practical gain.