You there, Chrome? It's me, Firefox —

Chrome + Firefox = BFF with cross-browser video talks

Chrome-to-Firefox chats now possible with next-generation video spec.

The latest beta versions of Chrome and Firefox can make high-definition video calls to one another, thanks to a joint effort by Mozilla and Google to support WebRTC interoperability.

Mozilla and Google made the joint announcements yesterday, while demonstrating a video call:

Hey Chrome, this is Firefox calling!

WebRTC is a plugin-free, real-time audio and video communication specification. The technology and specification are in the early stages of development, which means simply supporting the current version of the spec isn't enough to ensure interoperability. Extra work must be done.

"RTCPeerConnection (also known simply as PeerConnection or PC) interoperability means that developers can now create Firefox WebRTC applications that make direct audio/video calls to Chrome WebRTC applications without having to install a third-party plugin," Mozilla said. "Because the functionality is now baked into the browser, users can avoid problems with first-time installs and buggy plugins, and developers can deploy their apps much more easily and universally."

Google noted that, "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."

You can try Chrome/Firefox cross-browser calls yourself at the WebRTC demo site. You'll need the current beta version of Chrome and Firefox Nightly for Desktop.

If you're a developer looking to include cross-browser video talks in an application, Google pointed out a few sources of information: "You can look at the source code of the AppRTC demo, a library that makes writing cross-browser WebRTC apps a snap, and a document detailing some of the minor differences between browsers."

33 Reader Comments

The demo appears to require a server in between hosting a web page to connect the two, but an addon in either Firefox or Chrome could probably handle this. As long as you knew the other person's IP address, you should be able to do a direct browser-to-browser call with no 3rd party in the middle.

Given Firefox and Google's track record for security, I'll pass. It's hard enough keeping all the trojans and spyware from a internet connected device. Now you can be spied on by your browser!Does anyone know how this can be disabled? Or should I start looking for a different browser.

So you're already using one of the two browsers you're castigating for having some kind of history of insecurity? You do realize that Chrome has one of the very best security records, right? I'm a Firefox user and even I'll admit to that. It consistently places at the top.

Privacy UI/UX for this feature is a challenge since this involves camera and microphone data. Security will be difficult due to the wish for applications to be able to provide useful interfaces, in conflict with the need to guarantee users are safe with regards to access to their camera and microphones. This design is being discussed with the security team.

So it would a stupid decision at this point to enable it for everyone...

Um, seriously, folks. Why does a browser have to be a video conferencing app? What do we gain from putting camera and microphone access, and yet another way of talking to the network, inside the same (crudely contained) security and reliability compartment as random Web pages?

The entire Web has garbage security, because people keep complicating it with things that break the model, with maybe 15 minutes of lip service to the serious security and privacy issues... and then patching hole after hole as the "corner cases" come up.

They've just about vaguely managed to evolve a sort-of-works security system to recover from the damage JavaScript and the DOM did ages ago (provided every developer, administrator, and user in the whole process remembers to do dozens of complicated things and nobody makes any mistakes). Do they have to keep fucking things up?

Oh, wait. That would compete with video calling services, like Skype. And Microsoft owns Skype.

From the article you apparently couldn't be bothered to read:For now, this is Chrome- and Firefox-only. As we noted in previous articles, Microsoft is going its own way with a proposed spec called CU-RTC-Web.

And in the articles, it mentions how Skype could become a Web App like Microsoft's other offerings.

Um, seriously, folks. Why does a browser have to be a video conferencing app? What do we gain from putting camera and microphone access, and yet another way of talking to the network, inside the same (crudely contained) security and reliability compartment as random Web pages?

I am conflicted here. This is a neat tool, especially because I've been wishing for a standards-based interoperable video conference protocol that would become commonplace and widely adopted so I don't need an Apple device to "FaceTime" my friends, some of which prefer GChat Video Calls or Google Hangouts or even Skype... all of which use different protocols.

On the other hand, I think of the days that iTunes was a really awesome music player and library because it did those two things (and mostly only those two things) really well.

To be fair, MS wants their protocol to become adopted as the standard because they see problems with the WebRTC spec as proposed, and have tried to suggest changes aimed at addressing those shortcomings. And unlike last time, they don't just want it to be the de facto standard like IE6.

Should content be able to enable/disable camera and microphone, or should this access be controled only via Chrome? Do we need a separate chrome UI for enabling a website to control camera and microphone via its own UI, or do we have a UI for controlling the camera/microphone that avoids "permissions" prompts. Clickjacking with in-content UI (see Flash experience) People might not understand that microphone/camera data is being sent to a third party ("do you want to allow this *website* to have access to your camera/microphone"). Web pages that are in background tabs/windows still need camera/microphone access. should this turn off with tab focus loss?

First-party vs third-party access

Can an embedded iframe request permission? What would the UI look like? Does the user understand what we are asking them to decide in these scenerios?

Firefox UI must always indicate that camera and/or microphone is active how to tell them wich tab is asking or using this?

But what could possibly go wrong? In the requirements they state it should be able to traverse very restricted firewalls. But isn't there a reason there are very restricted firewalls? Should we poke holes in these just because people want to chat?

Should content be able to enable/disable camera and microphone, or should this access be controled only via Chrome? Do we need a separate chrome UI for enabling a website to control camera and microphone via its own UI, or do we have a UI for controlling the camera/microphone that avoids "permissions" prompts. Clickjacking with in-content UI (see Flash experience) People might not understand that microphone/camera data is being sent to a third party ("do you want to allow this *website* to have access to your camera/microphone"). Web pages that are in background tabs/windows still need camera/microphone access. should this turn off with tab focus loss?

First-party vs third-party access

Can an embedded iframe request permission? What would the UI look like? Does the user understand what we are asking them to decide in these scenerios?

Firefox UI must always indicate that camera and/or microphone is active how to tell them wich tab is asking or using this?

But what could possibly go wrong? In the requirements they state it should be able to traverse very restricted firewalls. But isn't there a reason there are very restricted firewalls? Should we poke holes in these just because people want to chat?

Note: This use-case adds requirements on support for fast stream switches F7, on encryption of media and on ability to traverse very restrictive FWs.

I downvoted you because your points have been inane. You cite track records for "keeping all the trojans and spyware from a internet connected device", then focus on usability (notifications and click-jacking) concerns. You say that "it would a stupid decision at this point to enable it for everyone", where "it" is a feature found only in beta and nightly versions of these browsers. You cite (patched!) vulnerability counts, then state that when the count goes down, it doesn't correspond to risk anyways. You point to concerns with the implementation, but the list you copy/pasted is made by the very people doing the implementation, and the contents are them brainstorming how the current implementation can be exploited so those approaches can be mitigated.

You don't sound like you actually want to engage with anyone here, you just sound like you want to prove your vague assertions about security correct without pointing to anything specific. Your last post gets closest to relevant for this conversation, but of course shows that the thing that you're asserting is being ignored is exactly the thing that is being closely looked at.

You don't sound like you actually want to engage with anyone here, you just sound like you want to prove your vague assertions about security correct without pointing to anything specific. Your last post gets closest to relevant for this conversation, but of course shows that the thing that you're asserting is being ignored is exactly the thing that is being closely looked at.

You have good points there and I actually agree with you if I was looking at it from that side.

It all boils down to a trust issue. You and a lot of other people trust the people that build these browser to protect you and build some super magic stuff so you can't be hacked.

But the problems they state can be looked at all day without actually being able to do anything to prevent them.

Java has been looked at for many, many, many years by armies of smart people and we all know how that is going lately. Same happened to flash, activeX, javascript, pdf, etc, etc.

So I won't be bothering people anymore with this, you'll remember my warning at some point in the future.

Um, seriously, folks. Why does a browser have to be a video conferencing app? What do we gain from putting camera and microphone access, and yet another way of talking to the network, inside the same (crudely contained) security and reliability compartment as random Web pages?

The entire Web has garbage security, because people keep complicating it with things that break the model, with maybe 15 minutes of lip service to the serious security and privacy issues... and then patching hole after hole as the "corner cases" come up.

They've just about vaguely managed to evolve a sort-of-works security system to recover from the damage JavaScript and the DOM did ages ago (provided every developer, administrator, and user in the whole process remembers to do dozens of complicated things and nobody makes any mistakes). Do they have to keep fucking things up?

Does EVERYTHING have to be a Web page?

Yes... Desktop apps are dead, everyone wants hardware and OS agnostic services available when ever they need them, that was one of the main reasons the Internet was created.

To be fair, MS wants their protocol to become adopted as the standard because they see problems with the WebRTC spec as proposed, and have tried to suggest changes aimed at addressing those shortcomings. And unlike last time, they don't just want it to be the de facto standard like IE6.

Considering they haven't said a damn thing like that, or, it's just their traditional not developed here attitude.

Why is the tiny picture-in-picture reverse in firefox but not in Chrome? What's up with that?

Just another example of Firefox's shitty code.

Maybe you should look closer at the video/image. Firefox is on the left. Chrome is on the right. Like most video conferencing systems the remote person has most of the screen and your self view is the smaller image.

To be fair, MS wants their protocol to become adopted as the standard because they see problems with the WebRTC spec as proposed, and have tried to suggest changes aimed at addressing those shortcomings. And unlike last time, they don't just want it to be the de facto standard like IE6.

First off, I'm not buying that MS is that altruistic. I still remember the OOXML vs. ODF thing.

Yes. First, both browsers prompt you if a site wants to use the camera, so it's always opt-in like many other web APIs (geolocation, fullscreen, etc).

In Chrome you can set "Do not allow sites to access my camera and microphone" in Content Settings to turn it off and never prompt you again (you can then use the exceptions list as a whitelist if you want to).In Firefox, you still have to turn it on in about:config in the first place, so it's not clear yet what the blanket disable method will be.

To be fair, MS wants their protocol to become adopted as the standard because they see problems with the WebRTC spec as proposed, and have tried to suggest changes aimed at addressing those shortcomings. And unlike last time, they don't just want it to be the de facto standard like IE6.

Considering they haven't said a damn thing like that, or, it's just their traditional not developed here attitude.

To be fair, MS wants their protocol to become adopted as the standard because they see problems with the WebRTC spec as proposed, and have tried to suggest changes aimed at addressing those shortcomings. And unlike last time, they don't just want it to be the de facto standard like IE6.

First off, I'm not buying that MS is that altruistic. I still remember the OOXML vs. ODF thing.

It's not exactly altruism to point out that the underlying frameworks (SDP, etc.) WebRTC hinges on are not ready for the WebRTC use cases yet, nor can they all easily be changed to fit WebRTC's demands. After all, MS is not going to gain anything with their alternative if it became the standard; they just wouldn't have to support WebRTC in their browser and other internet-facing applications. They'd still have to support their own new standard, which might even be technically superior and easier for other browser vendors to implement in a compatible way than the SDP-based approach. I think they have a decent argument, though I personally think WebRTC can work and should be used; it's mostly a matter of better coordination among the relevant standards bodies and developers. We just have to herd those cats. If nothing else, it would probably spur wider adoption of the new Opus audio codec as a de jure and defacto standard for podcasts, VoiP, and other internet audio uses. I'd love to see that displace mp3 and whatever Skype is using now, maybe live music over voice chat would be less painful. Microsoft's alternative doesn't mandate the support of freely available codecs like VP8 and Opus. I don't really think this is the same situation as their shenanigans with the ISO certification process to keep their Office lock-in for governments that wanted to use open standards in productivity software. Unlike the OOXML specification they rammed through approval, it really looks like MS is doing this one right and trying to "give away" their work on the alternative standard.

Given Firefox and Google's track record for security, I'll pass. It's hard enough keeping all the trojans and spyware from a internet connected device. Now you can be spied on by your browser!Does anyone know how this can be disabled? Or should I start looking for a different browser.

So you're already using one of the two browsers you're castigating for having some kind of history of insecurity? You do realize that Chrome has one of the very best security records, right? I'm a Firefox user and even I'll admit to that. It consistently places at the top.

Well they pay millions of dollars for finding security holes so no surprise there.