Hacker News new | past | comments | ask | show | jobs | submit login
WebRTC is almost here, and it will change the web (venturebeat.com)
146 points by denismars on Aug 13, 2012 | hide | past | favorite | 91 comments



Since Skype is moving to fully centralized service that can be even more easily wiretapped by Governments around the world (not just US), I'm very excited about the "revolutionary" (literally) capabilities of this protocol, as people will be able to speak 1-on-1 without interference, if the communication is also encrypted. Does being encrypted or not depend on that specific WebRTC client, or does it come encrypted by default like SPDY?


Don't make the mistake of thinking that because the communication channel is "encrypted", it is secure. SSL can already be compromised (so much for trusting encrypted transport) and the WebRTC client code could be compromised (always a problem).


Can you please provide links on how SSL can be compromised?


It's not SSL per se, but the Certification Authority system that is weak. If you get one of the root CA certs, you can make any SSL cert a valid SSL cert for any domain name.


It's correct that if root CA is compromised you can make fakes.

To protect against this attack browsers should warn when certificate changes, there even is a long standing bug for firefox in mozilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=471798


The fact that you can bungle WebRTC or SSL/TLS implementation doesn't make it useless for transport security. But of course security building blocks never guarantee properties of the entire system alone. Just like using AES doesn't make or break your security.


Encryption is mandatory. Currently, the implementation uses SRTP, but the proposal is eventually to use SCTP over DTLS over UDP. [http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00...]


Look, you're kidding yourself if you think that WebRTC is going to liberate you from the prying eyes of government surveillance. As a developer, I'm very excited about the possibilities that WebRTC enables (websockets just can't cut it in many instances), but computer science is not a panacea for political apathy. P2P is nothing new, and anybody who cares to secure their online communications can already do so with ease, everyone else is happy enough to self document their activities on Facebook.


Please explain how I can have a secure online conversation with my mother easily. (Easy for me, easy for her). Is it going to involve setting up my own trusted server somewhere? Is it going to involve downloading some large undocumented project and have to build myself (on my box and her box)? Is it going to require troubleshooting arcane protocols, firewalls, and xml files?

I haven't seen an easy way to have secure email (without teaching the other side of the conversation cryptography), secure voip/voice (without the trouble above), or secure chat (without using my own server).

I'm not saying easy ways don't exist; I'm saying I don't know what or where they are.


> Please explain how I can have a secure online conversation with my mother easily. (Easy for me, easy for her).

Pidgin with OTR -- configure and verify keys once, use whatever protocol you want. It is doable and not very difficult right now, the problem really is that no one cares.


That's assuming the clients are not compromised, hardware is not compromized, and "whatever protocol" is not susceptible to man-in-the-middle attacks.


If the hardware is compromised then all bets are off. No protocol is secure when running on compromised hardware.


Not really, you can have good enough security without perfect technology.

Cost to acquire or develop and reliably productize (and risk divulging) targeted attacks for OTR would likely exceed the value your adversaries could extract from your chat with your mom.


Apple's FaceTime is end-to-end encrypted, "the FaceTime conversation stream is encrypted from end to end, and each FaceTime session has unique session keys for each user".


Source? According to wikipedia "As of June 2011, it is not yet known to have been ratified by any standards body, and the extent of work by Apple with regard to this promise is unclear as Apple has not released technical specifications for the service. FaceTime is not currently supported on any non-Apple devices. While FaceTime is based on open standards, Apple's FaceTime service requires a client-side certificate. In other words, while the protocol might become an "open standard", access to Apple's FaceTime service is controlled by Apple.". This means that encryption keys are owned by Apple, and not by users.


> Apple's FaceTime is end-to-end encrypted

And one should trust Apple's or your word because...?


Don't just focus on one attack method. Look for the weakest link in the chain. If you get a totally secure computer system & internet connection, there could be a microphone in your room recording what you say. Easy to use crypto won't help there and only give a false sense os security.



No offence but I don't think the government could possibly care less about you or the conversation with your mother. There is a long list of far more important and interesting people for them to worry about.

How about using whatever is the easiest, most enjoyable and trouble free setup for her to use.


I didn't downvote you either, but I call this response the narcissistic defect of security / privacy analysis. The "I'm not interesting / I've got nothing to hide / X is not interested in me" level of analysis which is about as shallow as you can go in considering privacy / security.

Because looked at from a societal level, more secure citizen communications means a society less able to be manipulated / blackmailed / spied on by bad actors, both domestic and foreign. It doesn't matter if this particular mother never says anything interesting / compromising in communications with her child, because there are many other situations where they will. Their child might be a politican, councillor, businessman doing signficant overseas deals, political activist, dissident.

Your logic is faulty on a number of levels:

* assumes only the US government is a potentially bad actor. This is simply not the case.

* assumes the political / technical climate will never become more hostile to milder expressions of dissent between citizens.

* assumes the parent poster's communications with his mother does not contain any interesting information to any potentially bad actors

Ultimately though, with all the theorizing aside, the parent is simply wanting a solution that provides secure communication with family members which is a very uncontroversial, reasonable goal to have.


Consider all your communications, and think about the most ambiguous statement you've ever made regarding illegal activity, whether it was a joke or not. You have to be naive if you don't care in the slightest whether the government has all your IM history. At best, they'll realize you're not a criminal and ignore you. However, at worst, you'll be made a target of some investigation, they may very well find some other ambiguous or over-broad statute you're in violation of, and then it's off to court.


For my part, I used to be an active member of a political party that while completely legal and not advocating anything illegal, due to its position on the far left meant that a lot of people I associated with used to be under surveillance by the Norwegian security services, and many of them were denied entry into the US for years and years.

At the time I was involved, it was less controversial, and so I might have "escaped" surveillance, but I regularly met people who were more than once taunted on open streets by high level people in the security service who'd joke about personal details of their life that they had obtained through surveillance that in no way were relevant to the security services (e.g. asking about the fight some guy had with his wife the previous night).

There are plenty of people today that are in close enough proximity to the types of people and groups who are the subject of security services interests these days that would have every reason to assume that their conversations with their mothers would be monitored just because of either who they are, or who their friends are, or even because of the groups their friend peripherially belongs to.

It's not a situation that is particularly fun to be in, and I understand very well why third parties in situations like that would prefer not to have to think about whether or not someone is listening in for their own gratification.


I didn't downvote you. And I agree they aren't interested in my conversations with my mother. However I think they are very much interested in listening in to conversations involving foreign relatives, military relatives, rich relatives, criminal relatives, etc.

But none of that is my motivation. My motivation is purely technological. I want secure services as a matter of principle. Since I have yet to find such a thing, I use whatever is easiest, just like everyone else.


It will make it a lot harder. Right now governments have backdoors in apps like Skype, and all Skype's traffic is now routed through Microsoft's servers.

With WebRTC governments would have to perform man-in-the-middle attacks, which is pretty damn hard for P2P-style connections.


Yet another HTML5 "Game Changer" which has already been available as part of the Adobe Flash Platform[1] for the best part of three years.

Just saying :)

For those down-voting me; I find this attitude very strange. If the tools were present in another widely deployed runtime, but were heavily under utilised then why are people getting so excited about them this time around?

I guess some people just love to hate Flash.

[1] http://labs.adobe.com/technologies/cirrus/


Well, stop saying. This is like arguing about the features of a lake when everyone else is playing in the ocean. Flash is proprietary and it doesn't run on mobile. These are both near show-stoppers in, and of, themselves. Combine the two and well, it doesn't matter what else it does.

Until flash runs on mobile and/or is an open standard, it won't be relevant to the future of the web most developers (myself included) want to build.


Exactly this, the fact that its available in open standards is a game changer for me.

The fact that it has been possible with various other technologies for years is not news (for me)


About that ; You can code ActionScript Flash/Flex and run the compiled applications on Google Android, Apple iOS and on BlackBerry Tablet OS.

This is possible through the use of the Flex SDK that is under the open source Mozilla Public License, for some time now.

As for the lake/ocean analogy attempt, not so much.


I guess some people just love to hate Flash.

Yes. Flash has performance and implementation issues. And developers can't do anything to improve the situation.


"issues"

That is being far too polite for what in all likelihood is the most insecure piece of software in history. Not joking. The frequency of security updates over the last decade is a disgrace. And that is without even talking about the appalling state of affairs on the Mac platform where it is still ridiculously buggy. I mean why has it taken this long to be self-updating ?


> The frequency of security updates over the last decade is a disgrace.

Would you have preferred they only released security updates once a year?


I'm guessing he would have preferred it if Flash didn't have more bugs than an entomology lab.


It's important that rapid, even numerous, security updates are never seen as a bad thing, because that would provide incentive to choose the obvious alternative for the sake of appearance, despite the actual reduction in security.


I completely agree with you. However, the updates are the symptom, and the OP was remarking upon the disease.


I merely intended to point out that if he intends to remark upon the disease, he should do so.


Ah, then I find that a wise and valid admonition.


Reliability, security, performance. Don't take my word for it http://www.apple.com/hotnews/thoughts-on-flash/


That is the sort of PR that doesn't get held back by facts. Also, to pretend that Steve Jobs was some sort of unilateral source of fair reasoning on the matter is either disingenuous or very short sighted. I hope it isn't both.

But please, do not take my word for it: http://truegryc.blogspot.pt/2010/05/response-to-thoughts-on-...


Look I'm not claiming Steve Jobs is exactly unbiased :) But the "real" reason given in that article can't be right: Apple's stance appears driven by their business need to protect the iPhone platform against the threat of a cross-platform competitor.

Remember the first iPhone didn't have an app store! It had a full(ish)-featured web browser that people were expected to write "apps" for. Apple continues to encourage developers to write web apps for the iPhone. They can hardly be threatened by a feature they actively promote and enable.


I see your point but when the text was produced, the app store was already going at full steam. The app store locks in the consumer when there isn't another clear path to that sort of content. The sort of content they pushed out of the plat by referencing the lack of capacity to use "touch"... give me a break, stuff like that was repeated ad infinitum. That and the other stuff on there doesn't qualify as "real" either, does it.

To the downvoter, you are a pitiful fanboy.


Well, it's usually very hard to copy other people's flash code that you might see somewhere. With webRTC/javascript, all you really need to do is "view source". This, plus mashups with other web APIs, makes webRTC a much more powerful platform than flash.


Less space than a Nomad. No Wireless. Lame.


Cool. Will help with polyfill-ing :)


"This is the most significant step forward in web browser connectivity since 2004, when Google launched Gmail and AJAX was coined."

Microsoft --> AJAX[1]. And yes, I know that they aren't saying that Google --> AJAX but it kinda leaves that impression.

----

http://garrettsmith.net/blog/archives/2006/01/microsoft_inve...


Microsoft invented XMLHTTP, an ActiveX object, not XMLHttpRequest, that is similar but not proprietary, and a part of Ajax. And Ajax is a term invented by Garrett - and not Microsoft - that includes several W3C formats.


"AJAX" the term is a meaningless bit of inaccurate noise (it is wrong in almost every way). No idea what your bit about XMLHttpRequest was, given that was nothing more than a formalizing and cross-platform implementation of Microsoft's COM object (which itself was originally written for Outlook Web Access).

Like the GP that bit about AJAX was just all wrong. Garrett is so astonishingly irrelevant in all of this, as is the AJAX me-too title. Google was very important, but only insofar as they legitimized the technique and made a lot of people realize that this crazy web thing was a lot more powerful than people often thought. And it wasn't gmail -- it was Google Suggests. That was an atomic bomb on webapps that proved that highly dynamic pages were possible and preferable.

Me - using XmlHttp(Request) since 2001.


AJAX as a term and design idea was coined in 2005[1], which is what intent of the quote (though it too is technically inaccurate]. The quote you listed is talking about coining the term, not inventing the technology.

If you read the article you linked, it also says this:

"Finally -- 6 years later -- Jesse James Garrett of Adaptive Path coined a catchy phrase: the term Ajax was born."

[1] http://www.adaptivepath.com/ideas/ajax-new-approach-web-appl...


Even this is a naive understanding of how WebRTC will change the web. Resiliency and decentralization in ways we've never seen before!

For more information, check us out at http://WebP2P.org and join in #webp2p on Freenode!


At the moment, NAT means that lots of connections have to go through a central server, at least to set up the connection. With IPv6, that need should vanish (providing you aren't firewalled by your router).

The two things combined should remove a lot of middlemen.


Actually check out the webrtc talk from googleio. They use the NAT device's IP to get around this. http://www.youtube.com/watch?v=E8C8ouiXHHk


Exactly. Almost everyone is behind a router so there is no way this is going to be as useful as stated in the article.


P2P firewall traversal is pretty common these days. Checkout STUN/ICE/TURN.


I stand corrected :). I was just reading up on STUN, it is a very interesting solution.


Every example I'm aware of for WebRTC right now uses STUN. It's part of ROAP and it's possible in JSEP (and easier, with ROAP-via-JSEP library).

Nah, everyone is just claiming this to be awesome and just happened to forget about NAT routers....


IPv6 does not mean the end of NAT, and WebRTC ROAP or JSEP already have ICE style STUN/TURN traversal mechanisms.

(4 months ago I had a demo working using ROAP and STUN before they switched to JSEP. I'm literally in the middle of upgrading it to the new API.)

The "setup" for the connections in the central server is trivial with a tiny websockets server and a few messages shuttled back and forth.


For reference for others:

NAT (Network Address Traversal): exposing only your router's ip address and hiding your own to outside traffic [https://en.wikipedia.org/wiki/Network_address_translation]

ROAP (RTCWeb Offer/Answer Protocol): main voice protocol [https://en.wikipedia.org/wiki/RTCWeb_Offer/Answer_Protocol]

JSEP (JavaScript Session Establishment Protocol): protocol for setting up P2P connection [https://en.wikipedia.org/wiki/JavaScript_Session_Establishme...]

Following are all technologies for punching through NAT...

ICE (Interactive Connectivity Establishment): [https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...]

STUN (Session Traversal Utilities for NAT): [https://en.wikipedia.org/wiki/STUN]

TURN (Traversal Using Relays around NAT): [https://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT]

(Disclaimer: I know nothing of these technologies, I just looked them up on wikipedia myself)


Holy acroynm city batman.


"Through an open standards approach, WebRTC integrates browser-to-browser communications directly into the fabric of the Internet."

Why is this source credible?


While this tech is exciting for a wide variety of reasons, this blog post completely misses the point for me in its efforts to hype this.

> imagine it amplified by secure, real-time transmissions of audio and video

Ok, I'm imagining it. And I'll still be imagining it in 12 months time, because WebRTC does nothing to fix the outstanding issues in setting up secure communications.

> Skype, Cisco, and Polycom will all see their conferencing technology commoditized.

Really? Surely you could have said that Cisco / Polycom would be destroyed by Skype, but that didn't happen. Why would in-browser conferencing, which will almost certainly be a worse experience than Skype, which is itself a far worse experience than dedicated conference hardware/software, commoditize conference technology?

And for that matter, why did the wide variety of already-existing browser-based conferencing tech not do this?

Personally I'm more excited about ideas like P2P downloading, and using DHTs to disseminate information.


> Why would in-browser conferencing, which will almost certainly be a worse experience than Skype

What would give you that impression?

A site that lets you automatically join a conference call just by visiting a page seems far more usable than Skype.


Because a general purpose device (in this case, the browser) generally falls behind in a few ways compared to a specific purpose device (in this case Skype). A few examples:

Stability: For Skype to break, you need to either crash Skype or the entire computer or O/S. For your in-browser conferencing, you just need the web browser to crash.

Connectivity: Skype has put huge amounts of work into punching through firewalls, and has many settings dedicated to that. Furthermore it's a common enough option on SOHO/consumer routers to let it through. P2P browser connectivity just isn't there yet.

Security: Our firewall at work is configured to allow Skype through. I doubt it's configured to let browsers open direct raw socket connections to any IP and port they please. I can't even begin to imagine how a network administrator is supposed to lock these capabilities down, other than completely disallowing them.

UX: Again, Skype is a dedicated program so it can do a lot more. It can keep a little overlay window open in the corner of your screen so you can look at a web page or document but keep an eye on your call. It can hook into the O/S to ensure your microphone is selected and unmuted. It can tell your music player to pause when a call comes in. None of this is possible with a browser (yes, you could add APIs, but where do you stop - are browsers going to become the next JVM, creating a cross-platform API that plasters over the differences between O/S's?)

My last point is mildly tangential: Why would P2P in-browser conferencing disrupt Skype / Polycom when it has literally zero perceivable difference to the end-user compared to regular client-server in-browser conferencing (other than the fact that with P2P you will be able to connect to fewer people than in the client-server model)?


from http://www.webrtc.org/running-the-demos#TOC-Demos : Justin Uberti (Chrome-webrtc team member) has sent in a App Engine based 1:1 video calling app. http://apprtc.appspot.com/ source code: http://code.google.com/p/webrtc-samples/source/browse/trunk/...

after source code reading (and chrome dev console output observing) you have to realize: 1. there is need of 'signaling server' 2. session encryption keys are exchanged through that server

yes, anyone could setup their small server and call through it an make sure tls / ssl cert of their server is intact etc. that will not be a case for avg Joe. not to mention tat browser itself will be an attack vector.


This is very interesting, especially the peer-to-peer browser stuff. With all the attacks on pirate sites lately, it would be interesting to have a new playground for new P2P apps. Joe Soap would be able to get onto P2P by just opening a web page.


Just in time for Google Fiber here in Kansas City. Excellent timing.


Is no one here worried about (again!) audio/video codecs and presence implementation? As far as I've read webrtc specs there are no specifics, they've left implementation details in the hands of implementors.

I fear that Microsoft will push something skype-specific, Google (and possibly Mozilla) vp8 and xmpp/jingle, who knows what Apple will do with Safari. And different clients/browsers won't be able to communicate between themselves.


vp8/xmpp/jingle are open standards with open implementations, and Safari is a Webkit browser with a pretty good track record. Whatever Apple's problems, it doesn't seem too uncomfortable with using stuff that is BSD licensed.

Nobody can force Microsoft to support open standards, without the leverage of popular adoption and demand. So it makes no sense to wait on Microsoft to support open standards before trying to use them.

So if browsers can't talk to each other, whose fault is that? If Microsoft decides to be the odd man out, it's Microsoft's fault. If everyone else allows open standards to be suppressed as they wait for Microsoft, then they will be responsible for a world where Microsoft controls everything. Is that really what you are looking for here?

Anyway, these days Microsoft has shifted more support away from things like Silverlight, so I think there is a good hope that things will not be just like the bad old days.


VP8 is BSD-licensed. It's not supported in Safari and Apple has said they have no plans to do so.

That's because this whole codec thing is about patent licensing, not copyright licensing, so the fact that the code is BSD-licensed for copyright purposes is irrelevant.

The result is that for the HTML video tag, for example, it's Apple and Microsoft that don't support VP8 and Theora, and Mozilla and Opera that don't support H.264, all for patent licensing, not copyright, reasons. The corresponding situation with WebRTC is still in flux.


You haven't forgotten HTML5 <video> element, have you?


I can't tell what they mean by this: "If all goes according to plan, over 50% of all web browsers will support this capability in the next three to four months."

There are only five browsers that count, so why didn't they just say "three of the five major browsers?" Or, if they mean more than 50% of browser installations, are we really at the point where we can get 50% of all browser installations updated within a couple of months?


Yes, I think Chrome and Firefox can achieve that within 3-4 months.


Chrome + Firefox are around 60% of current browser installations and both currently self-update so that is likely where he got that figure.

It does neglect to mention that not all Firefox browsers do self-update so that would need to be factored in.


for a great multi-user demo of webRTC check out https://bitly.com/webrtcio

and it's resulting library, webRTC.io


Here comes the glorious HTML5 revolution, reinventing things that were around for decades, but now that it's "a standard" and "in javascript" it changes everything. First it was sockets, then it was WebGL now P2P. I wonder what revolution we will have next - a standardized file system access.


Actually yeah. It does make a difference if it runs in a browser.


I remember this demo from march, got me all excited :)

live streaming video to a webpage, from your phone, that's incredible

http://dl.dropbox.com/u/3531958/iphone/webrtc-opera-mobile-1...


I just started learning more about WebRTC and it looks like an interesting foundation for numerous startups. New technology among others to help solving specific tasks.


These capabilities open the door to a new wave of advanced web applications.

I have read this line as:

These capabilities open the door to a new wave of advanced web security issues.


which should make it about 2016 when we can use it in IE


Actually you can use it in IE right now using Chrome Frame. Read this for more detailed info - https://groups.google.com/forum/#!msg/discuss-webrtc/tKoh1wr....


But when Windows 8 comes out, Chrome Frame will stop being a valid solution, at least for IE's "[Metro|Windows 8|Modern]-style UI" version.


sigh

Okay 2016 when we can use it in Trident.


Most def. the way things are trending, this is the new big thing. Look Out, the Revolution Sez Go!


And when you screw off the wheel it can double as a mop!

What exactly does it help to have your video-feed drive around on a broomstick?

I can see the entertainment value for a couple days. But when it's time to get work done again I sure as hell don't see people preferring a video broomstick next to their desk over a plain old skype-window...


Not sure what you're getting at by "drive around on a broomstick." To be sure, the article is more breathless than it needs to be. WebRTC seems to my untutored eye to be a boring, practical, good idea.

Skype is a proprietary service which (last I checked) still requires you to locally install their binary, and is completely under the control of one company... as a risk-averse person I wouldn't bet the farm building on top of any technology which requires me to swear fealty to Skype or Facebook, because who knows what will happen in a year?


Nice post. WebRTC is great!


very interesting


>This is the most significant step forward in web browser connectivity since 2004, when Google launched Gmail and AJAX was coined

That's not quite right. Microsoft invented XMLHTTP, the interface which XHR is based on, in '98 or '99 for Outlook Web Access.


Notice that he said "AJAX was coined" in 2004 not that the technology was invented.


In the parent's defense, the rest of that paragraph and the chart below it downplay Microsoft's role in favor of Google's, which could be viewed as "not quite right".


Indeed, myself and others were doing [A]VBAX apps in IE before the term "AJAX" hit the mainstream. Not always async, and using VBScript in the browser instead of Javascript, but loading XML from the server and doing XSLT to build the DOM. It actually was pretty nice, at the time. IE5. You couldn't do things like that in any other browser for years.


Yes, XHR was available back then. But it wasn't Ajax. Ajax was invented in '04.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: