Chrome supports TCP & UDP sockets(blog.alexmaccaw.com)
blog.alexmaccaw.com
Chrome supports TCP & UDP sockets
http://blog.alexmaccaw.com/chrome-tcp-udp
33 comments
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)
"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.
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.
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.
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.
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.
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.
Also, the Overbite project which adds back in support for the gopher protocol.
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
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
> 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.
And most importantly, the WebRTC APIs will be standardized and available on the web, not just for browser extensions.
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.
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.
Does this mean that one could make a p2p client in NaCl? (as told in the article)
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.
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:
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).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"
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.
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.
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.
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.
Extensions are pretty much trusted, as far as I know.
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...
https://code.google.com/chrome/extensions/manifest.html#perm... https://code.google.com/chrome/extensions/permission_warning...
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?
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.
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...
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.
Wasn't there an ssh client extension already? How did it work if raw sockets weren't available?
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
Edit: ajaxterm
Listening too? or just outgoing connections?
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<--
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<--
They mention p2p, so incoming connections are likely to be supported.
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...
Now that could be very useful...
xss + tcp and now udp websockets. match made in heaven.
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...
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...
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.