Firefox and Chrome Can Talk To Each Other 121
The Firefox and Chrome teams have announced that their respective browsers can now communicate with each other via WebRTC for the purpose of audio and video communication without needing a third-party plugin.
WebRTC is a new set of technologies that brings clear crisp voice, sharp high-definition (HD) video and low-delay communication to the web browser. From the very beginning, this joint WebRTC effort was embraced by the open web community, including engineers from the Chrome and Firefox teams. The common goal was to help developers offer rich, secure communications, integrated directly into their web applications. In order to succeed, a web-based communications platform needs to work across browsers. Thanks to the work and participation of the W3C and IETF communities in developing the platform, Chrome and Firefox can now communicate by using standard technologies such as the Opus and VP8 codecs for audio and video, DTLS-SRTP for encryption, and ICE for networking. To try this yourself, you’ll need desktop Chrome 25 Beta and Firefox Nightly for Desktop. In Firefox, you'll need to go to about:config and set the media.peerconnection.enabled pref to "true." Then head over to the WebRTC demo site and start calling."
Re:This Is A Big Step (Score:5, Insightful)
Firefox: ~44MB
Chrome: ~96MB
IE: ~20GB and counting
Re: (Score:1)
IE is too much integrated within windows to have a clear vision of its consumption...
Re: (Score:2)
It was meant to be a joke, but apparently noone got that.
Putting the pressure on Microsoft - nice! (Score:2)
Re:Putting the pressure on Microsoft - nice! (Score:4, Informative)
Why do I feel like getting safari on board would be even harder than Microsoft ? Remember, old Steve Jobs' determined fight to not use VP8 - which is the core codec for this ?
Re: (Score:3)
Re: (Score:2)
Isn't VP8 more processor-intensive than H.264? I would think it was pretty reasonable for Apple to be concerned about battery life.
Re: (Score:2)
That's not what Google seems to say, unless you consider the "High" profile of H.264, which Apple also does not support. Anyway, it's all moot if your phone or tablet doesn't have a VP8 decoder in hardware. Letting ARM do the work will kill your battery.
Re: (Score:1)
What if you have hardware help for the H.264 codec but not for VP8?
If you want to comunicate with someone that doesn't use skype, WEBRTC now gives you the choice. Will it be less efficient than skype or ichat ? Maybe, but who cares ? Once support for this feature is in firefox, chrome, and opera users will be there. And it's much easier to tell someone to use firefox than telling him to open an account with skype or ichat.
Browsers are the common denominator, everybody uses them. Services like facebook, skype or ichat not so.
Re: (Score:2)
And now my browser can turn on my camera and mic. Yay.
But I'm sure there will never be any cross site vulnerability that lets a compromised site in another tab listen in on my conference session. That will never happen.
Re: (Score:1)
"And now my browser can turn on my camera and mic. Yay."
As if Flash didn't already fucking do that? What's your malfunction?
"But I'm sure there will never be any cross site vulnerability that lets a compromised site in another tab listen in on my conference session. That will never happen."
It's fully encrypted, you moron. The only vulnerability that will allow what you speak of basically requires someone to be at your computer, or someone fucked up the encryption implementation.
Re: (Score:2)
As if Flash didn't already fucking do that? What's your malfunction?
If you find Flash to have an acceptable track record of security and performance, then I'm not the one with a malfunction.
t's fully encrypted, you moron. The only vulnerability that will allow what you speak of basically requires someone to be at your computer, or someone fucked up the encryption implementation.
You probably would have called me a moron if I suggested that a script from one website on one tab could snag my email credentials on another tab, and yet bugs like that have cropped up repeatedly. I see no reason why this will be any different... it certainly won't make browsers less complicated.
Re: (Score:2)
>You probably would have called me a moron if I suggested that a script from one website on one tab could snag my email credentials on another tab, and yet bugs like that have cropped up repeatedly. I see no reason why this will be any different... it certainly won't make browsers less complicated.
I could see some risk of this in firefox but I don't believe Chrome has ever been vulnerable to it, indeed that's the entire REASON why chrome runs each tab in it's own separate process.
Re: (Score:2)
So let's say Chrome is fine - there is still IE, Firefox, Opera, Safari, and hundreds (thousands?) of Webkit-based Android and iOS mobile variations. Even if iOS people tend to update, remember that Android phones, in general, don't get updated.
Re: (Score:2)
VP8 has considerably less hardware support, making it much much more battery consuming than H264 (the accelerated version that is)
Re: (Score:3)
Re: (Score:2)
More to the point, VP8 doesn't make any sense here. All modern hardware comes with H.264 hardware decode capabilities, and it has for some time.
For that matter, virtually every piece of new hardware comes with a real-time H.264 hardware encoder too, specifically designed for recording video and real-time teleconferencing.
I like the open ideals of VP8, but just like WebM, this ship has long since sailed. Using VP8 means no one has hardware support for it at a time when the quality-equivalent H.264 codec can
Re: (Score:3)
Now if they can get Safari and Opera on board
You mean this Opera, from a year ago?
http://dev.opera.com/articles/view/getusermedia-access-camera-privacy-ui/ [opera.com]
I'm not sure if the TFA demo would work in Opera if it didn't specifically sniff for Firefox and Chrome, but be as it may, incomplete or not, getUserMedia() was part of Opera Stable already a year ago. Someone else with more insight into WebRTC will have to say why Opera doesn't work here.
Re: (Score:2)
The problem is that Opera does implement getUserMedia, but not peerConnection. They can do the part of RTC that accesses cameras and microphones, but not the part that sends it over the network.
Re: (Score:2)
The problem is that Opera does implement getUserMedia, but not peerConnection. They can do the part of RTC that accesses cameras and microphones, but not the part that sends it over the network.
A-ha! That explains it. Hopefully someone will mod you up.
Still, "getting Opera on board" should be no big deal. They pretty much started the whole thing.
Re: (Score:1)
There are some things I like about Opera, and I personally use it for several things (though Slashdot is not one of those things), but realistically its market share is not enough to be compelling when it comes to deciding whether a given new web technology works in enough browsers to be worth adopting. If it works with the big four (Firefox, Chrome, IE, and Mobile Safari -- and Mobile Safari only joined this list within the last
Re: (Score:2)
Opera's market share is stable, but it's measured in tenths of a percent.
It's over 1% worldwide, and it's still a major player in the former USSR. It's losing to Chrome, though, while Firefox pretty much remains constant.
Mobile Safari appears to be the only _mobile_ browser with a market share worth talking about so far
There's well over 200 million Opera Mini/Mobile users, and the number doesn't seem to be decreasing...
Re: (Score:2)
I'm sure Opera support will be along shortly, since they're one of the three partners (along with Google and Mozilla) supporting the WebRTC initiative.
From the http://webrtc.org/ [webrtc.org] front page:
"The WebRTC initiative is a project supported by Google, Mozilla and Opera. This page is maintained by the Google Chrome team."
no need of skype (Score:1)
Re:no need of skype (Score:5, Interesting)
Other than finding each other to start the conversation, I agree. The one thing Skype still has going for it is the directory services.
More to the point it will open up the ability to write skype-like apps for many website, forums, etc.
The security and privacy aspect that skype used to provide has been eroded since Microsoft took ownership, and started routing all calls through their own servers, and refusing to answer questions about monitoring. (One half suspects that Microsoft's ownership was government funded).
Re: (Score:2)
I'm sure Facebook is eager to solve that problem.
XMPP (Score:1)
Could any XMPP client implemented in the browser pull this off?
I don't know, but if so, that would cover all of Google's chat network.
Re: (Score:2)
Some XMPP clients are starting to add video, but for some reason, the world is rushing towards the browser for everything.
I think its because a generation has grown up knowing nothing but web development tools, and have no technical skills outside of that area. It was easy to get into simple web page development, and progress step by step to greater and greater levels of complexity, using additional technologies to server pages in ever more complex ways, asp java, ruby, xml, php, etc.
Don't get me wrong, th
Re: (Score:2)
"but once Gmail chat works conveniently, without having to install a plugin, it will become a serious threat."
That will never happen. Google has the propensity to want to install shit on your computer (google video adapter #1 and #2, anyone?) so it can farm your ass for advertising eyeballs.
Which makes Google completely fucking useless to me, now and forever, except for their e-mail, which really isn't all that great either.
Re: (Score:2)
And way worse for us. This everything-online shit needs to stop.
Question: (Score:4, Insightful)
So will webRTC kill Skype?
(please say yes, please say yes...)
Re: (Score:1)
Yes, for all non-Microsoft non-Apple users.
Re: (Score:3)
What? There's nothing here about OS. It's a browser feature, and both of the browsers listed run on Microsoft and Apple platforms.
GP was right. This is unlikely to kill Skype for the vast majority of users, which means it won't really kill it for non-MS non-Apple users either.
That's because all the companies that still use Exchange and AD and run Windows damn near everywhere will still be forcing their employees to use things like Lync, Skype, etc. And Apple users will mostly be using iChat and unable to talk to non-Apple users. Safarri may not even pick up this tech, and IE will probably be using MS's twist on it, CU-RTC-Web. So, eve
Re:Are you KIDDING me? (Score:5, Informative)
Its hard to tell if you're kidding or not, but on the off chance you aren't, web browsers have been opening sockets to arbitrary end points since the day they were invented.
Re: (Score:2)
Yeah - when the user tells the browser where to go.
Javascript being able to run off and talk to whoever it wants? And that being an expected pattern?.. That's different.
Re: (Score:2)
Yeah - when the user tells the browser where to go.
Its always worked this way. You may tell the browser where you want it to go, but the web page returns content that fetches other content from other sites. (ads, page parts, images, etc) You don't need java script to see this happen. Step into your browser's control panel and turn off Java Script. You barely notice a difference in page presentation.
Re: (Score:1)
"Step into your browser's control panel and turn off Java Script. You barely notice a difference in page presentation."
Suddenly slashdot, reddit, digg, and fark are all fucked (especially slashdot.) What bullshit are you talking about, again?
Oh, you're a JavaScript shill, judging by your comment history.
Re: (Score:3)
Funny, I'm posting this with Firefox and Java Script turned off.
Works fine. In fact I dare say its a little bit faster.
Re: (Score:2)
It's called XMLHttpRequest and it's been around for a good while. More recently, we got webSockets.
Re: (Score:2)
XMLHttpRequest is bound by the same origin policy. It *cannot*call everywhere you want it to, only your domain.
Re: (Score:2)
That is not true.
It can call anywhere, it will just not receive a response if the server does not have any CORS-headers set up.
But anyway, you don't need something as fancy like that. You can do a lot of stuff with just a simple form-POST or loading of an image or sourcing a javascript file from a different domain (there is even a protocol for that).
Re: (Score:2)
https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest [mozilla.org]
XMLHttpRequest.mozSystem -- Read only -- boolean -- If true, the same origin policy will not be enforced on the request.
It is false by default in every release of the browser I could get my hands on.
Re: (Score:2)
And still CORS headers work just fine in Firefox :-)
Re: (Score:2)
Ok, my bad, I didn't know about the CORS headers.
Thanks for the info.
Re: (Score:2)
<script>
var e = document.createElement("script");
e.src="http://wherever/whatever";
document.appendChild(e);
</script>
Working fine in IE since 1999, and in every browser ever since - not Netscape 4.x though.
Re: (Score:2)
http://en.wikipedia.org/wiki/WebSocket [wikipedia.org]
Re: (Score:2)
And redirects.
And frames.
And autoload.
And on, and on, and on.
Re: (Score:2)
Re: (Score:2)
lol, i laughed at json as well. It's too efficient! Burn it!
Re: (Score:2)
Chrome 64-bit? (Score:1)
Is Chrome 64-bit yet? At least in the beta version??
Re: (Score:3)
Re: (Score:1)
It is on mine too; but not my Windows system used for work..
Wow (Score:1)
Re: (Score:2)
We've got it - it's called Camfrog, and it kicks the shit out of anything these web-standards idiots could ever think of.
Re: (Score:2)
You are trying to be ironic, but actually, you can. WebRTC isn't Web-only.
There are (or will be, I keep forgetting) libraries which will allow you to use an API to do the same things you can do from within the browser. So it will be easy for people to build video- and audio-chat into desktop applications and mobile apps.
A browser is for browsing (Score:4, Insightful)
Just as a car is for driving. You could try and make a car fly as well, but it will fly only for a few seconds before gravity kicks in.
Same goes for software. Years of experience learned me to prevent this kind of 'additional functionality', also called "function creep". Next to that, I can think up tons of vulnerabilities, such as implanting 'bugs' on pages, analog to a hidden electret mic, or pre recorded spam calls.
Note that I really support this type of innovation, but please, not in browsers.
Re: (Score:2)
Instead of shitty, subversive, closed binaries, its just an open standard with two projects writing two compatible codebases.(redundancy means less failure), both of which are open.
this is a solution for horribly implemented technology at current.
Re: (Score:1)
Re:A browser is for browsing (Score:4, Insightful)
Re: (Score:2)
That's what Netscape thought when they released Communicator, and we all know how well that went.
Re: (Score:2)
The reason this stuff is happening in browsers and the web is because that's where the companies who care about and support inter-operability are at.
Interoperability is only part of it.....the temptation of hooking your customer in a SAAS subscription is huge.
End-to-End Encryption (Like ZRTP)? (Score:3)
I've been working on a SIP router and using Linphone and Jitsi for testing. I've been working on getting ZRTP (key exchange/validation method for end-to-end encryption using SRTP) working through FreeSWITCH. I haven't gotten the config incantation right yet, but I think I'm close. Seeing this article led me to poke around in WebRTC a bit to see if I should be testing it as well.
I found some info about WebRTC using SDES-SRTP, and maybe that DTLS-SRTP is the new direction, but I haven't figured out how they handle key exchange, or even if they are intended for end-to-end without a trusted MiTM. Does anyone know offhand if WebRTC supports end-to-end? How is key exchange/verification handled with new peers?
Thanks for info or links.
Re: (Score:2)
Seems like all that would be needed was a shifting random minimum bit rate to mask an encrypted VBR stream from speech pattern analysis.
Re: (Score:2)
Until NAT is dead (long live IPv6) this thing is not going to be as big as it could be.
Secondly, with regard to port 80, I recall when RoadRunner (TimeWarner Cable) shut off all inbound traffic to port 80 for its residential network. It started when the Code Red virus was making the rounds. Supposedly it was temporary, but if you called to complain, they'd recommend you upgrade to "business class" which was (and is) a ton more expensive.
A friend says they eventually lifted the block but I have never forgive
Re: (Score:2)
Re: (Score:2)
The WebRTC protocol supports NAT-traversal based on existing protocols. It works as well (or bad) as things like Skype and so on in that regard.
Re: (Score:2)
I should clarify. I just meant that NAT-traversal will only work through a third party, even if you just wanted to direct-dial*. Of course, this is the most likely scenario anyway. Though, if you're a Syrian family member who wants to direct connect to a remote computer to a family member in another
country, you may not want to go through a third party.
-l
*(Technically, you could poke a hole in your firewall and point it at your box, but then it's only your box, not your wife's, kid's, IPad, whatever...)
Re: (Score:2)
I have. No need to sigh! But you can block port 80 entirely or you can filter protocol TCP on port 80. I believe they did the former, not the latter.
If you're talking about browser communication, none of the articles linked said they were using UDP and I wasn't familiar with RTP until I looked it up after you mentioned UDP. So yes, if they don't need a TCP listener on 80, yeah it could work if you're browsing as a privileged user or have [x|r]inetd set up to forward the connection.
-l
Finally (Score:2)
HTML5 is supposed to be a standard, no? Interoperbility is long overdue. That should have been done in the first place.
Re: (Score:3)
WebRTC is not "HTML5". It's an ECMAScript API, and you can use it in any ECMAScript environment with the API, including any HTML version, and hopefully, in the future, desktop applications.
Re: (Score:2)
yeah an just an API so ... imagine a socket API that does not allow you to connect to a server because the underlying protocols are not yet compatible. THAT would be useful.
Don't get me wrong: webrtc is a good thing (well would be better if they chose H.264 for interoperating with the rest of the world) but networking and protocols are now getting over 30 years old and its time that when an standard API is proposed, the interop work is done before so application developpers can really thrive doing their bus
Re: (Score:2)
The IETF working group has not yet choosen the video-codec. VP8 is just what Firefox and Chrome are using to talk to each other. Even if VP8 is mandatory and H.264 was not. That does not mean that both parties talking to each other can't negotiate H.264 when they both support and prefer it.
Zero-day (Score:2)
Firefox and Chrome (Score:2)
Talk to each other? They virtually are each other!
Re:So...? (Score:4, Funny)
The devs probably just got tired of having to download different application/plugins or use flash-interfaces for their favorite live-chat porn sites.
Re: (Score:2)
Re:So...? (Score:5, Informative)
It is a protocol and API developed at the IETF and W3C for real time communications (RTC) by companies like Google, Mozilla, but also Microsoft.
It's called WebRTC, but it isn't specific to the web. There are also or will be libraries for people who want create desktop or mobile app(lication)s.
You can use it to easily build applications that need some kind of realtime communication like audio- or video-chat.
It uses a peer2peer protocol like VoIP or Skype and encrypted by default.
The peer2peer protocol can also be used for other data and supports NAT-traversal and going through relays.
Re: (Score:2)
i tried to read the high level material, but its really not very clear
would it be possible to use this to write a peer-to-peer collaborative application in javascript that just ran
in the browsers of the peers and didn't require a central server for conrdination, say by passing svg?
Re:So...? (Score:5, Informative)
In short yes:
http://www.html5rocks.com/en/tutorials/streaming/screenshare/ [html5rocks.com]
Re: (Score:2)
"It is a protocol and API developed at the IETF and W3C for real time communications (RTC) by companies like Google, Mozilla, but also Microsoft."
Microsoft? Isn't their role to wait until WebRTC starts to catch on and then introduce their own version in a transparent attempt to undermine the standard?
And no, I'm not being facetious - it seems like MS does that with every useful open web technology.
Re:So...? (Score:4, Informative)
Microsoft? Isn't their role to wait until WebRTC starts to catch on and then introduce their own version in a transparent attempt to undermine the standard?
They've already done that. CU-RTC-Web is their little spanner in the works of compatibility.
"I see that Microsoft decided to wait until the W3C and IETF [standards groups] were close to done before putting together a proposal that, if accepted, would explode most of the current works and create maximal delay on this work," said Cullen Jennings, a Cisco representative on the W3C's Web Real-Time Communications Working Group.
http://news.cnet.com/8301-1023_3-57494622-93/how-corporate-bickering-hobbled-better-web-audio/ [cnet.com]
Re: (Score:3)
I recall chatting with some of the Opus developers on IRC about the time this came out. Evidently the story is quite overblown: as I recall this is more a dispute over how "deep" the specification goes (MS [if I'm remembering this correctly] wanted the specifications to specify deeper hooks to the OS or something of the sort) than an outright incompatible difference of opinion.
The context of the conversation at the time was more to do with .opus files in the tag (something Google hasn't even bothered to [google.com]
Re: (Score:3)
(MS [if I'm remembering this correctly] wanted the specifications to specify deeper hooks to the OS or something of the sort) than an outright incompatible difference of opinion.
MS wants to block the standard from specifying a common codec. They intend to retain the opportunity to Balkanise online communication by using proprietary codecs that will not be available to all users (eg, Linux), or which will require licensing fees per user.
I get the impression that the differences of opinion aren't quite as incompatible or maliciously anticompetetive as, say MS's "OOXML" vs. "ODF".
Same leopard, same spots.
Re:So...? (Score:5, Funny)
An excuse for bloat.
I'm going to rip all of this crap out of Firefox and make it just a light, efficient web browser. I shall call it "Phoenix".
Re:So...? (Score:5, Funny)
Re: (Score:2)
I believe that currently they are more compliant than Firefox.
Re: (Score:2, Interesting)
Not according to HTML5test.com [html5test.com], they aren't.
Checking caniuse.com [caniuse.com] and filtering to current browser versions shows FF18 tied with IE10 on HTML/CSS for W3C Recommendations and Proposed Recs. at 100%, with FF18 1% ahead on the Candidate Recommendations and 1% behind for Working Drafts. For the other/unofficial categories, FF18 leads IE10 by a wide margin.
Since those last two categories don't really count for much since they're subject to potentially massive changes, the best you could say is IE 10 is -almost-