5 ms·

Google Chrome To Have Real-Time Communications Capabilities

64 points by dkd903 15y ago

wccrawford 15y ago
Really slim on details.
tomp 15y ago
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 15y ago
  aren't those two things the same?
  - InclinedPlane 15y ago
    No. One is an OS that hosts just a browser, the other is a browser that hosts an OS within another OS.
    - notatoad 15y ago
      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.
sktrdie 15y ago
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.
- ltamake 15y ago
  No, it's still really light and fast. Prefer it to Firefox to this day. It's gaining features and it's able to do more things than other browsers, but that doesn't make it bloated.
- ryandvm 15y ago
  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".
- william42 15y ago
  As has been mentioned, Google's not going to put in features if it slows down Chrome--they care about speed too. The other problem with adding features, interface bloat, doesn't apply as much either, since most of these features are available for webapps to use, and replace the requirement for Flash, which is the main thing making browsers slow.
- kylemaxwell 15y ago
  Weight and heft aren't the same thing as bloat. Alternately, one person's bloat is another person's muscle.
- nl 15y ago
  Google is pretty aggressive in making sure the binary stays as small as possible. Examples Mar 9 2011, "Binary Size Reduction Task Force": http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/7b30efc17901bb97?pli=1 http://groups.google.com/a/chromium.org/group/chromium-dev/b... Sep 21 2010, "chrome binary size treemap": http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/aaefd56a3adc44c5 http://groups.google.com/a/chromium.org/group/chromium-dev/b... and http://neugierig.org/software/chromium/bloat/ http://neugierig.org/software/chromium/bloat/
kragen 15y ago
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.
MatthewPhillips 15y ago
I can't find any documentation on the proposed APIs web developers would write to, does anyone have anything?
- kragen 15y ago
  http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html http://www.whatwg.org/specs/web-apps/current-work/complete/v... http://www.webrtc.org/reference http://www.webrtc.org/reference
joejohnson 15y ago
Does anyone know if this library will have encryption features built in?

64 points by dkd903 15y ago

Really slim on details.

tomp 15y ago

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 15y ago
aren't those two things the same?
- InclinedPlane 15y ago
  No. One is an OS that hosts just a browser, the other is a browser that hosts an OS within another OS.
  - notatoad 15y ago
    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.

sktrdie 15y ago

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.

ltamake 15y ago
No, it's still really light and fast. Prefer it to Firefox to this day. It's gaining features and it's able to do more things than other browsers, but that doesn't make it bloated.
ryandvm 15y ago
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".
william42 15y ago
As has been mentioned, Google's not going to put in features if it slows down Chrome--they care about speed too. The other problem with adding features, interface bloat, doesn't apply as much either, since most of these features are available for webapps to use, and replace the requirement for Flash, which is the main thing making browsers slow.
kylemaxwell 15y ago
Weight and heft aren't the same thing as bloat. Alternately, one person's bloat is another person's muscle.
nl 15y ago
Google is pretty aggressive in making sure the binary stays as small as possible. Examples Mar 9 2011, "Binary Size Reduction Task Force": http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/7b30efc17901bb97?pli=1 http://groups.google.com/a/chromium.org/group/chromium-dev/b... Sep 21 2010, "chrome binary size treemap": http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/aaefd56a3adc44c5 http://groups.google.com/a/chromium.org/group/chromium-dev/b... and http://neugierig.org/software/chromium/bloat/ http://neugierig.org/software/chromium/bloat/

kragen 15y ago

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.

MatthewPhillips 15y ago

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

kragen 15y ago
http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html http://www.whatwg.org/specs/web-apps/current-work/complete/v... http://www.webrtc.org/reference http://www.webrtc.org/reference

joejohnson 15y ago

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