The article is about making a local client in HTML/Javascript for a program doing the heavy lifting in Python. I feel like your response is just a knee-jerk reaction to seeing the work "websockets".
For a local client, yes, scaling would not be a concern; there is one websocket per client.
But this same method could be used for remote clients as well; I have a websocket-based "dashboard" for a project I'm working on that will potentially have to scale to thousands or more of remote clients. For a case like that, scaling is indeed a concern.
For example, the very simple websocket server used in the article won't scale well beyond a certain point because it spawns a new thread per client; something like gevent (which is what my dashboard uses) will scale much better. (Also the server in the example just exits on any exception; you need more robust error handling for something that needs to handle remote clients.)
This is an idea in the right direction! HTML5/Javascript/CSS stack is great for making UI. So much effort has been poured into making this stack great that it makes all the sense in the world to make it a standard GUI stack.
Now we need a good connector library so that we can program in any language of our choice and use the web stack for seamless display. Web sockets are a good start but we could do better.
Is there anything preventing other applications from connecting to the web socket server and messing up with the application state? Or is that possible "by design"?
With websockets, it's actually up to the server to implement the cross origin detection. The library used in this application does not implement any protection.
So it's possible for any page on the net (eg evil.com) to connect to your socket and exfiltrate any data.
Make sure all tabs are closed and never visit any sites with advertising on it while this is running.
The websocket server needs to check the "Origin" header from the client. The code then needs to know what is expected (eg localhost or 127.0.0.q).
If the origin header is something like "evil.xyz.com", then it needs to reject the connection.
Yes, I understand how origin verification is done. Nothing stops any other local app to make make a WS connection to this app's server and pretend it is making valid requests while, potentially, executing destructive actions or stealing data.
I understand that the generic answer will be along the lines: "well, if you have local access, you're never safe", but there is zero protection here. Anything local can connect to it and impersonate the "front end".
Even if it's just restricted to the local machine, any application that seemingly should have nothing to do with the network is going to arouse plenty of unneeded suspicion if it starts listening on a port or creating connections. Several years ago I remember coming across an application written in Python that did something similar, and its forums had users complaining that their firewall had detected something or that it was otherwise not working. I downloaded the executable, analysed it to discover the above, and decided to find an alternative instead.
Well Websockets sit atop HTTP last time I looked, what would be the point of using HTTP over domain sockets? I must be missing something - I thought the main reason so many protocols are implemented atop HTTP these days is because traditionally many corporate firewalls block nearly everything else.
You still need the HTML served somewhere - running a HTTP server on domain socket is a reasonable way of serving the that if it's at all dynamic, and since you've already got the socket open why not reuse it and do websocket over it too? Once the socket has transitioned, there's no overhead.
Why would a firewall care about anything listening on localhost?
Not sure about now but it used to be very common for adware/spyware to setup a local HTTP proxy and reroute all traffic through that.
There's also the "why is this app that has nothing to do with the network, doing something with networking?" angle to consider. Some malware would try to hide by injecting itself into other innocuous processes.
The DomTerm terminal emulator (https://domterm.org) also uses WebSockets. The "server" is written in C, and handles pttys, command processing, help, and more. It uses libwebsockets (https://libwebsockets.org/) in the server. JavaScript in the browser (or something browser-like such as Electron) handles the GUI, including xterm/ansi escape sequences, menus, panes, buttons, etc.
There's a Python library for this called "remi"[1]: REMote Interface library. It's amazing how well it works. We've been playing around with it on repl.it because we have a lot of users asking for GUI.
I recently built a TicTacToe game[2] in it in the fraction of the time it would take me just to setup a webapp. It's pretty impressive and goes to show how badly setup the web is for apps.
>I recently built [a simple app built on a platform for building simple apps] in the fraction of the time it would take me just to setup a webapp
Ok, sure
>It's pretty impressive and goes to show how badly setup the web is for apps
That conclusion really doesn't seem to follow for me. Someone else wrote a library that does all of the setup work, and then you didn't have to do that work, so you concluded that something else wasn't well set up?
Even if you pulled in angular or react it's still really hard to get something like this going. Especially for novices, these frameworks suffer from inversion of control and are pretty weird way to program. Once you get it it's pretty powerful tho.
I've been working on something similar in Kotlin called http://kweb.io/. It works but is still pre-1.0. You can manipulate a remote DOM as if it was local to the server and attach event listeners. Feedback welcome.
Nice strawman argument, but you undermined your own argument:
Electron apps are not generic browsers that run random content from the web: they are fully debug-able projects, and the developers have full control over what is deployed.
You know, like ANY compiled project that is shipped as an .exe/.dmg.
On HN, please don't reply in the flamewar style, even if another comment is annoying. It just leads to a downward spiral. Plus your refutation will be much more convincing if it's simple, factual, and civil.
I've been something of a full stack developer for about 10 years now, my bread and butter being Python and c#, with a background in c++. The handful of times I've tried writing a web based UI for python and c# applications have been exercises in frustration.
Web is a cancer on tech. A giant, bloated, broken mess, built emergently, without any cohesiveness or vision. Simple applications come with hundreds of external dependencies, many of which regularly release breaking updates. It is simply impossible to consistently find up to date documentation on best usage for many of these libraries because of the speed with which the space moves, not necessarily toward anything good. Not to mention the incredibly dangerous nature of such a loosly typed language like JavaScript.
In my opinion, the whole system needs to be burnt to the ground to make way for something cleaner, safer, and more secure.
Then again, maybe I'm just biased by my preference for backend coding.
My use case is the same, but my local ui is composed of angular + websocket. It seems to me that when the browser (Firefox) tab containing the websocket is inactive, the websocket doesn't run. Not sure if it's because of any bug in my app or because of Firefox.
I've recently started on this approach as well for hooking up a computational backend in Java to D3 based visualizations in the browser. Netbeans has several good introductory websocket examples that are a good starting point for setting up the socket connection.
39 comments
[ 3.5 ms ] story [ 89.5 ms ] threadBut this same method could be used for remote clients as well; I have a websocket-based "dashboard" for a project I'm working on that will potentially have to scale to thousands or more of remote clients. For a case like that, scaling is indeed a concern.
For example, the very simple websocket server used in the article won't scale well beyond a certain point because it spawns a new thread per client; something like gevent (which is what my dashboard uses) will scale much better. (Also the server in the example just exits on any exception; you need more robust error handling for something that needs to handle remote clients.)
My money's on sed and /etc/network/interfaces.
Now we need a good connector library so that we can program in any language of our choice and use the web stack for seamless display. Web sockets are a good start but we could do better.
So it's possible for any page on the net (eg evil.com) to connect to your socket and exfiltrate any data.
Make sure all tabs are closed and never visit any sites with advertising on it while this is running.
[1]: https://github.com/Pithikos/python-websocket-server/issues/1...
I understand that the generic answer will be along the lines: "well, if you have local access, you're never safe", but there is zero protection here. Anything local can connect to it and impersonate the "front end".
I guess flutter has really spoiled me; my expectations from a UI framework are just too damn high now xD
https://blogs.msdn.microsoft.com/tonyschr/2004/03/30/drivers...
Even if it's just restricted to the local machine, any application that seemingly should have nothing to do with the network is going to arouse plenty of unneeded suspicion if it starts listening on a port or creating connections. Several years ago I remember coming across an application written in Python that did something similar, and its forums had users complaining that their firewall had detected something or that it was otherwise not working. I downloaded the executable, analysed it to discover the above, and decided to find an alternative instead.
Why an app exposing itself to a local GUI process would listen on anything but localhost?
I wonder if websockets can work on Unix domain sockets; it's the normal way for non-websockets programs of a similar architecture.
Not sure about now but it used to be very common for adware/spyware to setup a local HTTP proxy and reroute all traffic through that.
There's also the "why is this app that has nothing to do with the network, doing something with networking?" angle to consider. Some malware would try to hide by injecting itself into other innocuous processes.
I recently built a TicTacToe game[2] in it in the fraction of the time it would take me just to setup a webapp. It's pretty impressive and goes to show how badly setup the web is for apps.
[1]: https://github.com/dddomodossola/remi
[2]: https://repl.it/talk/share/Tic-Tac-Toe-in-remi-a-cross-platf...
Ok, sure
>It's pretty impressive and goes to show how badly setup the web is for apps
That conclusion really doesn't seem to follow for me. Someone else wrote a library that does all of the setup work, and then you didn't have to do that work, so you concluded that something else wasn't well set up?
electron + ES6 + html5 + no package installs + linux/macos/windows portable = why bother with anything else?
Electron apps are not generic browsers that run random content from the web: they are fully debug-able projects, and the developers have full control over what is deployed.
You know, like ANY compiled project that is shipped as an .exe/.dmg.
Nice try though.
https://news.ycombinator.com/newsguidelines.html
Web is a cancer on tech. A giant, bloated, broken mess, built emergently, without any cohesiveness or vision. Simple applications come with hundreds of external dependencies, many of which regularly release breaking updates. It is simply impossible to consistently find up to date documentation on best usage for many of these libraries because of the speed with which the space moves, not necessarily toward anything good. Not to mention the incredibly dangerous nature of such a loosly typed language like JavaScript.
In my opinion, the whole system needs to be burnt to the ground to make way for something cleaner, safer, and more secure.
Then again, maybe I'm just biased by my preference for backend coding.