

Chrome supports TCP & UDP sockets - maccman
http://blog.alexmaccaw.com/chrome-tcp-udp

======
asadotzler
I checked with our (Mozilla) networking folks and here's what I learned.

This is for Chrome extensions only, not for web content. Mozilla has had an
API available to extensions for this for a long time. That is how Chatzilla
works, for example.

The Web API team has created a raw socket API for _web content_ that will be
used for the Boot to Gecko email client and other non-HTTP applications. For
security reasons, this requires an extra permission to be granted by the app
store and/or by the user.

~~~
zobzu
I think it's important to note as those sockets are NOT standard. Albeit with
Nacl and the chrome store it seems that what Google wants, is that users do
everything via their extensions, and via their store (bypassing the standard
web while thinking they're on it)

~~~
rictic
"everything" seems unfair.

Firefox has had sockets for a while and has also chosen to make them available
to extensions only. Even Java Applets back in the day supported sockets only
if you jumped through a bunch of hoops (if I recall correctly. it's possible
you could only do socket communication with JNLP or something).

As far as I know, NACL is extension/app only as a way of controlling risk to
the client.

~~~
cbsmith
Depends on what you mean by "jumped through hoops". You could open up a socket
to communicate with the host the applet came from (lots of fun defining what
that meant ;-) without being signed. If you were signed... all best might be
off.

------
willscott
It's worth noting that while this is becoming available in chrome now, the
WebRTC APIs that both Chrome and Firefox are working on (and will likely start
showing up in the 3-6 month time frame) is also likely to provide p2p message
passing support.

There's a group of people beginning work on porting some of the traditional
p2p constructs like DHTs into the browser, for those interested:
<http://joincollage.com/webp2p>

~~~
azakai
> the WebRTC APIs that both Chrome and Firefox are working on (and will likely
> start showing up in the 3-6 month time frame) is also likely to provide p2p
> message passing support.

And most importantly, the WebRTC APIs will be standardized and available on
the web, not just for browser extensions.

------
joewalnes
Here's a plug for an existing plugin that brings these capabilities to
standard web-pages. Works in Chrome, FireFox and Safari.

<http://sockit.github.com/>

Note that this was a research project. It works, but there's no security, so
once installed, any malicious web-page could use your browser to connect to
TCP/UDP end-points.

------
dan85
Does this mean that one could make a p2p client in NaCl? (as told in the
article)

~~~
sowbug
Native Client is orthogonal to the APIs mentioned in the article. These APIs
are available only to certain kinds of Chrome extensions, and are currently
enabled only if several Chrome flags are enabled. If those conditions are
satisfied, it should be possible to make a P2P client in JavaScript.

------
biot
It's nice to see Google repurposing Microsoft's project name of "Canary". I'm
reminded of this classic Reg article:

[http://www.theregister.co.uk/2002/10/23/were_being_spanked_b...](http://www.theregister.co.uk/2002/10/23/were_being_spanked_by_nokia/)

The codename for the Microsoft phone was "Stinger" until everyone called it
"Stinker". Choice quote:

    
    
      (Microsoft hates the "Stinker" moniker so much, that it's 
      rebranded Stinker as "Canary" - perhaps unaware of the bird's
      history as a sacrificial and disposable early warning system for
      miners. When the Canary dies - you clear out fast).

~~~
lazylland
Aside: What a blast from the past .. "Three years ago, a ballistic Bill
identified the phone consortium Symbian as enemy number one and this year
singled out Nokia for particular attention" and mentions of handsets like "
Siemens S55, Sony Ericsson T68i .. Nokia 7650"

------
chubot
So he mentions security concerns, but then doesn't explain why they don't
apply to this scheme? I assume websockets added the handshake for a reason.

Or maybe is because chrome extensions already have a weak security model and
you have to put trust in the author not to sniff all your data and upload it
to a server.

~~~
ori_b
Extensions are pretty much trusted, as far as I know.

~~~
skymt
Not entirely. Chrome has a permissions system for extensions: an extension
needs to declare any sensitive or intrusive APIs it wants to use in the
manifest file. Some permissions are even displayed to the user before the
extension is installed.

[https://code.google.com/chrome/extensions/manifest.html#perm...](https://code.google.com/chrome/extensions/manifest.html#permissions)
[https://code.google.com/chrome/extensions/permission_warning...](https://code.google.com/chrome/extensions/permission_warnings.html)

------
jorangreef
Why are sockets still not a standard web api after all these years? Is a
socket in a browser app granted socket permission more dangerous than a socket
in a native app? How do sockets in iOS and Android work? Why does the web
still not have sockets?

~~~
justincormack
Because a Facebook ad could start poking around inside your corporate firewall
looking for security vulnerabilities... you can lock down app installs much
more than someone accidentally agreeing to allow socket permissions.

------
daemonize
interesting how something so trivial as sockets (but in the context of a http
browser) can stir so much talk of decentralization. maybe if people pull their
heads out of their asses about web and embrace native apps again...

~~~
geluso
Agreed. A P2P program with a browser? Come on! We /already have/ wonderful P2P
programs. I sense browsers becoming awfully bloated. And for who's benefit?
Google's.

------
tonfa
Wasn't there an ssh client extension already? How did it work if raw sockets
weren't available?

~~~
kodablah
I believe it was native client with some elevated privileges.

~~~
sowbug
This is correct.

------
zzzzzzzzz
Listening too? or just outgoing connections?

~~~
laxk
It is still not implemented.

[http://src.chromium.org/viewvc/chrome/trunk/src/chrome/brows...](http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/api/socket/tcp_socket.cc?view=markup)
\--8<\-- int TCPSocket::Bind(const std::string& address, int port) { //
TODO(penghuang): Supports bind for tcp? return net::ERR_FAILED; } \--8<\--

------
ktizo
By combining the browser p2p technologies that are being introduced with the
local storage stuff, you could presumably write a web app that serves itself
and maintains persistent connections and functionality between users, even if
the host is taken down.

Now that could be very useful...

------
tinfoilhat
xss + tcp and now udp websockets. match made in heaven.

~~~
dasmoth
This isn't anything to do with websockets.

These are raw, unadulterated sockets -- but only available to Chrome
extensions, not normal web pages. I'm pretty certain Mozilla extensions have
been able to create sockets for a while, and the sky hasn't fallen yet.

Edit:
[https://developer.mozilla.org/en/XPCOM_Interface_Reference/n...](https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISocketTransport)

