Chrome supports TCP & UDP sockets

http://blog.alexmaccaw.com/chrome-tcp-udp

by maccman • 14 years ago

104 32 14 years ago

blog.alexmaccaw.com

tinfoilhat• 14 years ago

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

dasmoth• 14 years ago

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...

dan85• 14 years ago

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

sowbug2• 14 years ago

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.

tonfa• 14 years ago

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

lysol• 14 years ago

Presumably the extension would use XHR polling or websockets to relay input and display to the browser. That's how it works with other web SSH clients.

Edit: ajaxterm

kodablah• 14 years ago

I believe it was native client with some elevated privileges.

sowbug2• 14 years ago

This is correct.

chubot• 14 years ago

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• 14 years ago

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

skymt• 14 years ago

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/permission_warning...

groby_b• 14 years ago

IIRC, extensions are considered trusted because the user has given up-front permission for whatever the extension wants to do.

In the case of sockets, the manifest needs the "experimental" permission. And I would assume (but have no idea if this is true) that once it's not experimental, there'll be a separate permissions flag for web sockets.

joewalnes• 14 years ago

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.

asadotzler• 14 years ago

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.

MatthewPhillips• 14 years ago

Also, the Overbite project which adds back in support for the gopher protocol.

zobzu• 14 years ago

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• 14 years ago

"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.

nextparadigms• 14 years ago

Some people have complained that Chrome apps "are just web links". This is a way for the Chrome team to show that Chrome apps can do something more advanced than what HTML5 allows today.

drivebyacct2• 14 years ago

The functionality can be exposed on any webpage. It's likely that Google is only allowing it via the Web App Store for further vulnerability testing and moderation ability over the Web Store Content.

about:flags and two clicks will enable NaCl TCP/UDP sockets and a third click will enable NaCl on any webpage with a prudent and applicable warning about the potential security risk.

willscott• 14 years ago

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• 14 years ago

> 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.

zzzzzzzzz• 14 years ago

Listening too? or just outgoing connections?

simfoo• 14 years ago

They mention p2p, so incoming connections are likely to be supported.

laxk• 14 years ago

It is still not implemented.

http://src.chromium.org/viewvc/chrome/trunk/src/chrome/brows... --8<-- int TCPSocket::Bind(const std::string& address, int port) { // TODO(penghuang): Supports bind for tcp? return net::ERR_FAILED; } --8<--

ktizo• 14 years ago

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...

biot• 14 years ago

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...

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• 14 years ago

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"

daemonize• 14 years ago

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• 14 years ago

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.

_urga• 14 years ago

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• 14 years ago

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.

Chrome supports TCP & UDP sockets

Related Stories