Thursday, May 16, 2013

Google Hangouts testing WebRTC-based, pluginless implementation?

A sharp-eyed Toby Allen recently brought the following code to my attention:

Qg.prototype.init=function(a,b,c,d){"pi1");var e=window.location.href.match(/.*[?&]mods=([^&]*).*/);if(e=(e==m||2>e.length?0:/\bpluginless\b/.test(e[1]))||Z(S.Xd)){t:{var e=new Ad(Uc(this.e.l).location),f;f=e.K.get("lantern");if(f!=m&&(f=Number(f),Ka(Og,f))){e=f;break t}!Fc||!(0<=ta(dd,26))||webkitRTCPeerConnection==m?e=-1:(Pg.da()?(f=Pg.get("mloo"),f=f!=m&&"true"==f):f=q,e=f?-3:0==e.hb.lastIndexOf("/hangouts/_/present",0)?-4:1)}e=1==e}e?Rg(this,q):Sg(this,a,b,c,d)};

That's an excerpt from the Google Hangouts javascript code. It's a bit obfuscated (either by design; or, more likely, because it's the output of another tool), and I haven't taken the time to fully dissect it. But the gist of the code appears to be to test for the presence of a "mods=pluginless" string in the URL; and, if one is present, to check whether the browser supports the use of WebRTC's RTCPeerConnection API (or, at least, Google's prefixed version of it). It then looks like it calls one of two different initialization functions based on whether such support is present.

Alas, with this preliminary analysis, I couldn't get Hangouts to do anything that looked plugin-free, even on a recent copy of Chrome Canary. But it's pretty clear that the Hangouts team has started playing around with a WebRTC-based implementation.

The downside is that they're checking for Chrome's specific prefixed version of RTCPeerConnection rather than attempting to use a polyfill like most WebRTC demos on the web nowadays. So it appears that this functionality, when it's deployed, is most likely going to be Chrome-only -- at least, initially.

1 comment:

  1. Ohhhhhhhhhhhhhh, spooky!!! MY NAME is also ADAM ROACH.