Hacker News Reader

Comment by stingraycharles | Hacker News Reader

Why would they need a node process? Are there things an Electron app needs to do that isn’t possible from the Chrome runtime? And more importantly, why would they need to directly link with the DOM?

Sorry I am not very familiar with Electron.

View on HN

Well, one very simple example is access to filesystem. You can't do that from Chrome but can from node. In this particular case for example WhatsApp could have a cache of the images and videos attached to a conversation, without having to obey the limits of local databases imposed by PWAs.

The way I author my Electron apps to avoid this is to have a HTTP/Websocket server spin up at a random port, and then use that process to open an Electron window, with Node integration disabled.

This then becomes exactly the same as writing a web app, with anything that cannot be done by the renderer (Ex: file access) being done by the 'server'. Always wondered why this was not an officially strictly recommended way of doing this.

Correct me if I misread. You're leaving ports open on a customer machine, which has its own potential for security issues, even if you bind to localhost.

Wasn't there a Mac app that recently got a lot of flack for this?

IIRC the app you're talking about is Zoom's mac client.

Yes that's correct. And AFAIK the consequence was that any browser tab capable of running javascript could make HTTP requests to localhost and access the webcam.

Electron comes with a renderer/server architecture out of the box?

https://www.electronjs.org/docs/tutorial/application-archite...

It does, but:

> Electron exposes full access to Node.js both in the main and the renderer process.

Latency. The electron IPC is way faster than using web sockets and the ability to have node modules in the renderer makes some task actually feasible. I've worked on apps that were quite possible to do with electron but were completely out of question in more classic environments like Cordova or in Android/iOS web views.

Just remember that authentication and origin checking is completely up to the websocket server. Any random page in a browser can talk to your websocket cross origin, and it's up to your server to check the "Origin" header to make sure it's actually your app on the other end.

Yes and no. Recently browsers started assuming that a response without CORS headers it unsafe unless from the same origin. So even though you can make a request if it fails preflight it will not even reach your server.

You can try this by opening a console on any webpage and trying to do fetch requests or add img tags to the page that are loading resources from localhost.

If you base it origin couldn't that have false positives too? Like say other, less privileged apps?

Just in case, you may want to listen on localhost and use MTLS or TLS+preregistration between the client and the server.

Or just use unix domain sockets and named pipes, and then you don't have users complaining that you've used some random port that they want to use for some reason.

But really for stuff like file system access just use the node APIs, don't shuffle this stuff through any hand rolled IPC.

Because not everyone is making an app that talks to the internet with Electron.

> without having to obey the limits of local databases imposed by PWAs

If you're shipping your own Chromium, shouldn't it be trivial to remove those limits?

Wait, are you telling me there are TWO javascript engines in a typical Electron app?

ermagerd

Since bridging Node.js with the DOM is basically the whole point of Electron, it's a little tough for me to answer this question. Yes, there are things Electron apps need to do that you can't do from standard Chrome.

That obviously depends on what your Electron app wants to do.

Let's say you're writing an IDE in it. How would you invoke compilers & debuggers, cache filesystem/type information, state, etc. without breaking out of the browser sandbox somehow?

Reply on news.ycombinator.com