

Google Chrome To Have Real-Time Communications Capabilities - dkd903
http://digitizor.com/2011/06/21/google-chrome-webrtc/

======
kragen
I've been looking through the spec. It's full of things that make me groan in
agony, but at first glance, it seems like it might actually be sufficient to
build a Skype competitor as an extension or web app.

Some problems:

0\. The separation between audio and video streams and other data happens in
the browser, not in your own JS code, which is the root of most of the
problems that follow.

1\. There's a .send() method on connections, which allows you to send
arbitrary data to the peer. But it suffers from a variety of arbitrary
restrictions: they recommend that browsers rate-limit it; although it's UDP,
out-of-order packets will be discarded before you get a chance to look at
them; packets over 504 bytes get rejected with an error. I suspect that the
most sensible response to these problems in the end might be to encode other
data as audio or video streams in order to get it across the internet, but I
am not yet sure that this is possible.

2\. Only STUN and TURN are supported; you still can't connect to a person with
a real internet connection unless you have a STUN server to nanny you through
it. And of course the API isn't sufficient to allow you to implement STUN.

3\. You can't bootstrap a connection to a peer without already having a way to
communicate with the peer, such as COMET through a website. You already know
the IP address and port where they were five minutes ago before you restarted
your browser, and also their public key? Too bad. You need a website to
bootstrap the initial negotiation, and if the website is down, your app can't
connect. (In my skimming I haven't been able to find the spec of how the
initial negotiation works.)

4\. As I mentioned earlier, I'm not sure encoding other data as audio or video
streams is possible. (I found an API for recording, but not one for playback.)
If it isn't, that means you're entirely at the mercy of the browser's
encryption and authentication algorithms to protect your communications; you
can't write DH and AES and HMAC-SHA256 in JS on top of the provided API. Which
means that the spec needs to get the protocol exactly right, and if and when
weaknesses are found in the protocol, it's up to the browser vendor, not the
JS app, to fix them.

Basically what it amounts to is that WebRTC doesn't amount to providing APIs
for _writing_ a Skype clone into browsers. It amounts to providing a
scriptable Skype clone in browsers, with virtually all the important decisions
about trust models, fault models, and the like already made for you.

I found this very disappointing, because what I want to build is something
_better_ than Skype. It also has the practical problem that writing a spec for
such high-level capabilities takes longer and has more risk of a fatal flaw
than writing a lower-level spec.

I haven't bothered offering these comments to the Google guys because they
aren't really a matter of "Hey, I think that if this API had an extra
parameter, it would achieve the goals you have set without breaking XYZ;" it's
more a matter of "What you are working on building is not what I have been
wishing for. Why don't you work on this other similar project instead?"

 _But_ look what we did with XMLHttpRequest and progressive document rendering
and the DOM. It might still be possible to turn this shit sandwich into
something awesome, if they don't cripple it too badly.

~~~
nl
You might be (more) interested in the P2P _communication_ APIs currently being
added to Chrome. Details are scanty to say the least, but allegedly they will
provide P2P UDP sockets.

See for example [http://groups.google.com/a/chromium.org/group/chromium-
revie...](http://groups.google.com/a/chromium.org/group/chromium-
reviews/browse_thread/thread/67651882fafb45d4) and
<http://code.google.com/p/chromium/issues/detail?id=51198>

~~~
kragen
Very much! Thank you! I had no idea.

------
tomp
At first, I thought that Google Chrome was preparation for Chrome OS... but
now it seems like Google is building an OS right into Chrome browser.

~~~
notatoad
aren't those two things the same?

~~~
InclinedPlane
No. One is an OS that hosts just a browser, the other is a browser that hosts
an OS within another OS.

~~~
notatoad
i don't mean that chrome os is the same as chrome the browser. i mean that
building everything you need into a browser, and preparing to launch a
browser-based OS are the same task.

------
joejohnson
Does anyone know if this library will have encryption features built in?

------
MatthewPhillips
I can't find any documentation on the proposed APIs web developers would write
to, does anyone have anything?

~~~
kragen
[http://www.whatwg.org/specs/web-apps/current-
work/complete/v...](http://www.whatwg.org/specs/web-apps/current-
work/complete/video-conferencing-and-peer-to-peer-communication.html)

<http://www.webrtc.org/reference>

------
sktrdie
Is it just me or is Chrome getting a bit bloated? I hope it doesn't lose its
lightness and speed that made it famous.

~~~
ryandvm
Chrome is gaining features, yes. However, since with each release the Chrome
team manages to eke additional performance out of it, I think it's a little
premature to decry it as "bloat".

------
wccrawford
Really slim on details.

