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.
2 Likes
(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.
2 Likes
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.
1 Like
I apologize if I sound nitpicky but I don’t think it’s a great comparison as the clipboard being insecure/sniffable is a much more prevalent issue than the issues with electron and people should be aware of it, both on android and desktop.
Most apps don’t ship EOL electron, and PG shouldn’t (and to my knowledge doesn’t) recommend poorly maintained apps anyway.
It’s still an issue to be behind chromium but at least it seems that the non-EOL versions of electron have severe vulns patched quickly.
I’d argue that it could still be worth a blog post (or similar) as it can be a problem for people with higher threat models. You don’t have to outright recommend against these apps, but it may be useful to mention the pros and cons somewhere.
3 Likes
I agree that it is an even bigger issue than this one, and the fact that even that issue is not worth fearmongering over proves that this Electron issue is not worth fearmongering over either. This is precisely my point 
I recognise this and have already moved past the idea of outright recommending against Electron long ago, as evident in some of my previous posts and my renaming of the thread (although it could have been better renamed lol). I think a blog post about Electron concerns would be a much better idea and leaves it up to the user to decide if they still want to use Electron or not.
This way, newer users will be making a much more informed decision regarding their desktop app usage rather than first being reliant on Electron and then finding out later that they are concerned with the security implications it brings.
Edit: I’ve made the title clearer to reflect a more realistic approach and added an edit to the original post to explain the change.
7 Likes
This is mentioned in the FAQ though
Not really sure what else you mean by “go around warning every GrapheneOS user of the dangers of the system clipboard”. It’s the second entry in their privacy and security section
1 Like
Off-Topic
For those who want to read about how websites and PWAs compare to native apps, here is a thread where the founder of Cryptee explains everything: Should I use native apps instead of PWAs? - #10 by johnozbay - Get Advice - Techlore Discussions
2 Likes
1 Like