Live data from Hacker News

Basic Electron Framework Exploitation

contextis.com

31–40 of 138 posts

Re: Basic Electron Framework Exploitation

#31
post #8

At this point in time, it's reasonably healthy to assume that everything has backdoors. The only place where information can be kept safe and hidden is deep within our minds. Any method used to share said information with another human being is subject to surveillance and backdoors. Only share what you don't mind being read by the state and it's friends.

For some reason, the key to my mind’s backdoor is beer.

[deleted]

Re: Basic Electron Framework Exploitation

#32

At this point in time, it's reasonably healthy to assume that everything has backdoors. The only place where information can be kept safe and hidden is deep within our minds. Any method used to share said information with another human being is subject to surveillance and backdoors. Only share what you don't mind being read by the state and it's friends.

This is actually good advice. Anything you want to keep secret should stay in your mind. Anything else gets progressively risky.

Re: Basic Electron Framework Exploitation

#34
post #22
post #3

Electron is the new Flash. Change my mind. ¯\_(ツ)_/¯

It makes cross-platform desktop development much easier. VSCode, Discord, and (the new) Slack are written in Electron, and those absolutely excel, even at the cost of a bit extra memory usage. There's a circlejerk of Electron hate, but there's a reason it's so popular, the ease of development outweighs its weighty memory drawbacks for many companies and individuals. Edit: Not to mention that it uses Node.js, HTML, CS…

I don't know why people complain about performance. VSCode is my primary experience with Electron and it runs extremely well. It handles large files just as well as Notepad++.

edit: Just to be clear I don't suggest notepad++ is best at large files. EditPad is clearly the winner in that category. But I do mean to say VSCode and N++ are on par with each other.

Besides, VSCode provides an incredible amount of functionality. So what if it uses as much RAM as my browser. I routinely run multiple browsers, each with multiple windows.

Re: Basic Electron Framework Exploitation

#38
You could say the same about (for example) a Python-based QT app. Or any scripting-language based application or framework.

It's also true to say something like "Rails can be back-doored by modifying the code and redistributing it to unsuspecting developers!"

Actually, you could say the same or similar things about many applications, including binary distributes. With some analysis you can figure out what conditions a jump instruction is using, and modify it to always jump where you want. Cheat Engine lets you analyse game memory at runtime and substantially modify behavior.

Re: Basic Electron Framework Exploitation

#39
post #22
post #3

Electron is the new Flash. Change my mind. ¯\_(ツ)_/¯

It makes cross-platform desktop development much easier. VSCode, Discord, and (the new) Slack are written in Electron, and those absolutely excel, even at the cost of a bit extra memory usage. There's a circlejerk of Electron hate, but there's a reason it's so popular, the ease of development outweighs its weighty memory drawbacks for many companies and individuals. Edit: Not to mention that it uses Node.js, HTML, CS…

> It makes cross-platform desktop development much easier.

For the developer, while the user has to deal with horrid battery and memory consumption.

Devs are paid well enough that "easy" shouldn't be a top priority.

Re: Basic Electron Framework Exploitation

#40
post #20

I feel like the headline is a bit click-baity but I don't want to jump to conclusions. > Tsakalidis said that in order to make modifications to Electron apps, local access is needed, so remote attacks to modify Electron apps aren't (currently) a threat. But attackers could backdoor applications and then redistribute them, and the modified applications would be unlikely to trigger warnings—since their digital signatur…

I'm still trying to figure it out too: > I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash? Yeah, I think that's the problem they're describing. It sounds like the Mac setup will require binaries -- like the Electron runtime itself -- to be codesigned, but if the first thing your codesigned binary does is to read an unprotected JS file off disk and execute it, there's…

What makes this unique to electron as opposed to any other application that doesn't run as a completely closed binary (not that binaries can't be backdoored, of course)?
Post reply on HN