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