
WebTCP: Making TCP Connections From Browser - yankoff
http://artemyankov.com/tcp-client-for-browsers/
======
cstejerean
This is definitely a cool hack, but please be mindful of the security
considerations of deploying something like this on the internet. Running an
open proxy that allows any client to perform arbitrary TCP connections
bouncing through your servers is a bad idea.

First, you need to worry about the security implications of each internal
server that you expose intentionally. Just how much damage can someone with
direct access to your Redis instance cause? Better read
<http://redis.io/topics/security>, and repeat this for every other service you
want to expose.

Second, you are going to effectively need a whitelist of allowed connections,
either in the proxy, or at the firewall level (which most people are going to
forget to configure, if they even know how). Without that you are going to
allow arbitrary bypass of your firewall for internal services, as well as
effectively running an open proxy for anyone looking to bounce their malicious
traffic through your server.

~~~
aidenn0
Yeah, just look at all the havoc caused by anonymous FXP in the '90s

------
chewxy
So, TCP over HTTP, which is a protocol built on top of TCP. Does anyone see
that this is rather silly?

If you want a client-side app that uses TCP, why must you do it over the web?
The appeal of write-once-run-everywhere?

~~~
sneak
It's not TCP over HTTP, that would require a TCP stack. It's the io bytestream
from a specific TCP connection, shuttled over HTTP.

It's not entirely bogus, just mostly so. I really dislike this whole "the
internet == the web" way of thinking, though.

~~~
javajosh
On the contrary, this sort of things allows us to write clients in a uniform
way. It will be nice to be able to debug the redis client in a jsfiddle. :)

~~~
sneak
By this argument, "uniformity" means we should then port the linux kernel to
javascript so that we can debug it in jsfiddle.

Down that path lies madness.

~~~
javajosh
What's wrong with writing a kernel in JavaScript? This would actually be quite
valuable as a pedagogical tool.

------
flux_w42
I think this is a great idea. From the moment I heard of WebSockets I was
disappointed it was only a thing between the sockets-capable-web-server and
the client and not a real TCP connection to wherever you want. This solves
stuff :) However, I think that you should keep an eye on the possible security
implications (ex. fooling the same origin policy, using your websockets proxy
as a hub to attack other systems on the internet, ...)

~~~
dwj
Doesn't websockify do this better?

~~~
yankoff
It looks like with websockify you have to run a server with their wrapper to
make it work

~~~
dwj
It looks like this also requires a server with a wrapper. The difference is
that websockify is more efficient.

------
drblast
This is just what I need to complete the in-browser app I'm building to
navigate and read these new hypertext pages I'm creating. I've developed a
markup language that will let you reference any of these documents from any
other. The app that lets you view them is going to work in any browser that
supports WebTCP, too, for the ultimate in cross-platform compatibility!

------
seats
If more web services supported CORS, pure client side apps would be way easier
to do and less kludgy than via proxy.

<http://en.wikipedia.org/wiki/Cross-origin_resource_sharing>

------
eungyu
Nice hack (although I would put this in the category of 'workaround'). The
idea is cool, but I can already imagine all sorts of debugging nightmares with
this approach. To begin with, how do we find out where the connection is
broken (Is it the client socket or the proxy socket)? Bad connections have
different reasons (in C terms: ECONNRESET, EWOULDBLOCK, ENETUNREACH, etc); are
these specific reasons propagated verbatim? What about flow control between
proxy and client?

There is always a chasm between whipping up a cool hack and making something
usable. This hack needs a long bridge in between.

------
y0ghur7_xxx
This is an awesome hack. We really need real TCP connections from the browser.
Until then this looks like a great workaround. I eagerly await the day we can
use the browser for everything we do (did?) with Desktop apps.

~~~
angersock
We built a simple proof-of-concept library that lets you use a web app as the
GUI for native code, if anyone would be interested.

~~~
lisper
Yes please!

------
smagch
You may want to take a look at browserver

<http://news.ycombinator.com/item?id=4366555> <http://browserver.org/>

------
saljam
Chrome (and I believe Firefox too) has a TCP socket API, but it's only exposed
to Chrome apps and extensions.

