Hello Firefox, this is Chrome calling
blog.chromium.org
blog.chromium.org
I've been in a long distance relationship for a few years now and Skype has sadly been our main mode of video communication. The app crashes when I search chat history, can take upwards of 90+% of my CPU, literally forcing me to shut down every other application I have running. The forums are full of complaints, all unanswered. We've tried gChat and the plugin either goes undetected or slows down my machine as well (although not as bad as Skype). I'm running a 2010 MBA, so I've got the resources.
So death to Skype, and open arms to WebRTC.
Our codecs are WebRTC-derived, and its pretty stingy with memory and cpu so that's cool.
Do you imagine Sococo is some giant corporation? Its a startup like so many here. I was the 3rd person in the company, the 1st Software Engineer, so I'm pretty proud of the progress we've made in the last couple of years. There are a lot of big players in our market, and we've done a good job of beating them technically even though we're small.
The things which we love about skype, most notably the directory and ease of routing, are currently missing from WebRTC. Someone might come along and make them, but WebRTC is not inherently different from Skype's infrastructure, it's just new. Someone still has to build the supporting services to turn this into a Skype Killer.
Think of it this way. Skype has 2 things that WebRTC doesn't: Signaling and a Directory. Without those two components, you just have a phone without a phone number :/.
Lower barrier, yes. Easy? No, there are still significant costs.
FB is already in bed with Skype though I think so not sure how that would pan out in practice.
I'm not saying that this is relevant, because for the majority of users it isn't. I'm saying this for the hackers who just watched Facebook deny Voxer. If Facebook can capriciously decide who I can and can't talk to, that's not really what I would call an identity. What Facebook gives you is a slice of an identity, the slice it thinks you ought to have.
For many that is enough; for others it is an insult.
If that was your point, I apologize for being redundant.
While stability for particular client-side bits (media, transport, etc) will now now fall on the browser vendor, you're still going to depend on another service for all the niceties (media and signaling relay, contacts, presence, history, etc), and they could screw it up just as badly as Skype, or worse.
Skype could just use WebRTC as another transport -- there's no technical reason they can't.
Wouldn't it be nice if WebRTC pushed video-calling into becoming like e-mail, and you could take to anyone, regardless of what "video-calling app/service" they are using?
WebRTC doesn't define a signaling protocol. There are already protocols for that. SIP, XMPP/Jingle, etc. It would be nice if people started using them more. WebRTC only defines an offer/answer API (which is actually a big difference!)
So having two different services use WebRTC doesn't mean they'll be interoperable. (Unless the services intentionally make an effort to federate.) Any third-party attempt at interop between incompatible services is going to involve spoofing a connection to each service. While that's not impossible, WebRTC really isn't the interoperability panacea that people seem to think.
Google has the infrastructure to make it happen via WebRTC, but it would need to be integrated with accounts and payment.
Ventrilo and Mumble do have far superior support for massive number of people in a chat room. If you're participating in large MMO raids or Eve Online type festivities the Skype doesn't have the necessary features. For my ~5 player parties Skype blows everything else out of the water and isn't even close.
The two codecs have been merged/improved into Opus, which is one of the mandatory audio codecs for WebRTC.
But all three are moving to Opus, so very soon it's not going to be the codec itself that will differentiate audio quality between them.
It's also secure, FOSS, cross-platform, and implements a consistent UI. Skype has none of these.
http://www.webrtc.org/chrome#TOC-Data-Channels-
A shame, because I have a use in mind for them. :)
edit: also, I don't see it as an about:flags flag.
edit 2: I should just tunnel data through video then, what could possibly go wrong?
Enable RTCDataChannel. Mac, Windows, Linux, Chrome OS, Android: Enable experimental RTCDataChannel for peer-to-peer data communications. Disable
Version 26.0.1397.2 dev
I'm glad that you're excited about them. I am too. I hope to have it ready for you soon :).
Out of curiosity - do you mean that you're writing a full SCTP-based implementation, or completing the RTP-based one? The standard draft specifies SCTP, right?
edit: this was addressed in another post.
https://github.com/jinroh/kadoh
It's a JavaScript implementation of the Kademlia DHT. It doesn't support WebRTC as a transport yet, but they're working on it. The code looks pretty reasonable, and they seem to have some momentum going.
It's a hard choice to make.
.mirrored { transform: scaleX(-1); }
However, I do hope the implementations are consistent as to which way it flips the video.
But Jabbles' point still remains: It's a hard choice to make.
I absolutely understand the application in webchat and why you would want it to be mirrored at a page level, but I'm at a loss to understand why the browser implementation would try to reflect that.
How strong is your 'locked' box? It's only a bunch of 1s and 0s.
I wouldn't be surprised. Basically 9/10 people that study cryptography in the US end up working for the NSA. Look at the NSA's budget, and then look at how many cryptography professors there are.
However, that said, IF they managed to decrypt AES somehow, they are severely limited in what they can do with that information. Basically anything they do with the decrypted data has to in no way alert anyone that they have that capability.
So that data DEFINITELY can't be used in court, nor for a whole array of other more covert operations.
It seems unlikely in the extreme that the NSA is both so far ahead of the rest of the world, and so sure that their discoveries will not be replicated for decades.
Sources: http://arxiv.org/ftp/arxiv/papers/1003/1003.4085.pdf http://delivery.acm.org/10.1145/360000/358718/p465-merkle.pd...
The following papers are a good starting point:
[1] Guessing the URLs being browsed by users over an encrypted TLS session: https://research.microsoft.com/en-us/um/people/gdane/papers/...
[2] Guessing the co-ordinates of where a user is scrolling around on Google Maps over an encrypted TLS session: http://www.ioactive.com/pdfs/SSLTrafficAnalysisOnGoogleMaps....
[3] Guessing the content of encrypted VoIP conversations: http://www.cs.unc.edu/~amw/resources/hooktonfoniks.pdf
[4] Guessing communication paths on the Tor network with only a partial view of the network (not strictly related to encryption but the principles of traffic analysis are relevant): http://www.cl.cam.ac.uk/users/sjm217/papers/oakland05torta.p...
[5] Guessing passwords sent over the SSH protocol using keystroke timing analysis: http://users.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf
(a) narrow down or uniquely identify each party
(b) provide information on the mood of each party (are they interrupting other speakers more often than usual?)
(c) guess the nature of the call (information dump from one person to another, one person quizzing another person, ...)
(d) determine the languages used in the conversation
(e) guess demographic information from the conversation including approximate level of education/intellect, age, male/female, ...
(f) narrow down the physical location of speakers who are attempting to mask their identity through intermediate nodes
VoIP is covered by CALEA, but it isn't yet clear if Video is covered. There's a bit of a raging debate about this in Telco circles. There are basically two arguments:
1) Companies that do not operate exchanges are not liable for CALEA compliance
2) CALEA compliance is not clear.
For the first argument, many folks interpret the law as only covering companies that have equipment inside of phone exchanges (CLECs and ILECs). There is a 3rd class of operator that is only IP with no equipment in the exchange. It is not yet clear if this 3rd class has CALEA as a requirement (Goolge is all IP).
On the second point, there's no clear documentation about acceptable formats for release. Can I send raw log files? Does it have to be a csv? None of this is clearly defined anywhere.
In short, it's a lot more tangled when it comes to video. I'm not certain the Feds could've gotten access to Skype monitoring without $MSFT buying Skype.
[1] http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...
As for the abusive client, I say if the ISP has any sense of self preservation, they should be interested to police this themselves. For example, knowing how much bandwidth the client is paying for, they could refuse additional or even cut existing memberships of that client once that limit is reached.
All current home routers are configured to do NAT, so you're not going to be able to have a Skype 2.0 be P2P b/c then you'd need to explain to millions of people how to reconfigure their routers.
Also P2P opens a whole new can of worms when it comes to security.
It is going to have to happen, or there will be no internet.
> All current home routers are configured to do NAT, so you're not going to be able to have a Skype 2.0 be P2P b/c then you'd need to explain to millions of people how to reconfigure their routers.
Current home routers will be replaced within a year or two. They do not last that long. Some people are starting to not have dedicated routers, instead renting equipment from the ISPs.
> Also P2P opens a whole new can of worms when it comes to security.
Firewalls have been around for a long time. We'll survive.
"Current home routers will be replaced within a year or two."
Yeah right! My grandma isn't gunna be changing her router. And she'll be pissed if her stuff stopped working.
At then end of the day, if you have the choice between making a NAT friendly product that everyone can use and a non NAT friendly product that has some extra privacy - you'll be choosing the NAT friendly option.
"Firewalls have been around for a long time." The thing in windows that everyone disables?
NAT is transparent and fool proof. How can you ensure a 3rd party won't be able to connect to your fancy new P2P chat client? Security holes are pervasive in networking code so without NAT and a with a bit of sloppy code, the "bad guys" can at any time connect directly to your computer. Can you imagine the chaos that would happen if there was a zero day bug in a P2P Skype. With NAT 99% of your problems are gone. It's physically impossible to connect to a computer that doesn't have port forwarding.
Unless the US gov't comes in an enforces a switch to IPv6 (like it did with digital TVs and all those subsidized converter boxes) directly connecting to computers isn't going to happen.
It reduces, rather than increases security, since now the communication can be compromised by a security hole at either end (and NAT doesn't stop the machines behind it from being compromised) or at the exchange intermediating between them (which, most likely, neither party has any control over or detailed knowledge of the security practices in place on.)
And major ISPs are deploying IPv6 now: no mandate required.
Exactly. So the onus of security is pushed off solely onto the centralized intermediary. In my example it's the Skype servers.
They can very easily firewall and filter all the connections. They can have a much stricter filter then what you have on your computer. (ex: packets have to very strictly conform to a certain standard generated by the client side program)
Centralized servers are also more secure because you don't have any access to the server code and it becomes virtually impossible to look for exploits.
Also if any bug IS found, then patching it is trivial b/c it's at one central point. If worse comes to worst you just shut down the server and now all your clients are safe.
With P2P communications between Ann and Bob, a compromise of Ann's machine or Bob's machine compromises the communication.
With NAT preventing P2P communication between Ann and Bob and requiring them to communicate through intermediary Charlie who is publicly accessible, compromise at Ann's, Bob's, or Charlie's location compromise the channel.
Systems can be compromised without hosting publicly-visible servers, as has been demonstrated in every remote browser-based exploit ever.
So, Charlie's system may be more secure than Ann or Bob's systems, but that doesn't matter because it doesn't _replace_ Ann and Bob's systems, which are still part of the communication channel. More points of vulnerability always means less security, even if the new point of vulnerability is, considered alone, more secure than the most secure existing node.
How is XMPP/Jingle supposed to work over WebRTC? I.e. in order for the browser to connect to a standalone VoIP client for example (think of implementing Google Talk plugin in pure JavaScript). From what it looks like, this can require some support for this scenario in XMPP servers (not unlike they need something to support XMPP over WebSockets). So this is really an important piece of the puzzle which needs to be ready.
If SDP offer/answer is still being considered for WebRTC, then that should simplify interop a bit since media negotiation shares a common denominator with most other V/VoIP protocols (which is really the only relevant part when we're talking about WebRTC). Of course, all that is moot if both endpoints can't agree on a codec to support. Opus is brand new, and no one cares about VP8. Hardware devices are not likely to be compatible anytime soon (without a transcoding layer in between), which leaves softphones.
Regarding codecs - most XMPP/Jingle clients support VP8 and Opus is catching up too. It's not like there are many of them around anyway. Farstream supports both if corresponding gstreamer components are present.
Given codec and SRTP compatibility with clients, eg GTalk (which I don't know about), you should be good to go.
When all browsers support WebGL and WebRTC I'll be fascinated to see what people more creative than myself can create.
I think I would be more excited if this were distinct plugins running in the respective browsers. Would be much more indicative of a truly free environment, instead of just two of the top contestants doing something.
I guess I can see how it does. I mean, the idea is that this protocol can be used to communicate between two vendors. But, that can already be done. It is done, on a regular basis. What, exactly, makes this special?
tl;dr: This is an evolution of browser standards, not a revolution in consumer software (from an average end-user POV)
From a developer POV, this is pretty cool because now it is (or at least, is well on its way to being) significantly easier to build an app that relies on real-time media shared between peers with only the only onus on the end-user being having an up-to-date browser. The simplest and most obviously useful application of this is a basic VoIP tool.
Also, why is this stuff better than SIP related technology from a while back?
It's like how WebGL is very exciting, to people doing web stuff, even though it has nothing over other similarly named stacks.
The excitement here is that this is a non-flash solution, so technically it will work on any device that can run Chrome, regardless of whether or not it can / wants to run Flash. So in the near future this may make it into Chrome for Android and iOS.
WebRTC is a very necessary step in removing Flash's hooks into the modern internet; after this, there will be very few reasons to support it at all anymore. And that is a very good thing for speed, compatibility, and security.
Neither of these automatically grants any additional security. If anything, it is just tying us to fewer vendors that can do this. I guess it doesn't matter, but I can recall a time when I was able to choose which application handled certain content type. We seem to be saying we do not want that for video now.
Will the framework allow me to create a one to many connection? ie. presentation mode where one person could broadcast their audio / video to many viewers? Or is it simple a 1:1 connection?
"Hello, Joe! System working?"
"Seems to be."
"Okay, fine."
One thing I wonder about tech' like this, is that it is encrypted from you to the service, but there is no assurance of privacy.
Someone who runs a service like this can easy drop in on your calls and ease-drop. Which is a legitimate concern if someone wanted to use this either in a corporate environment or for very private calling (e.g. husband and wife, doctor and patient, etc).
No current video tech' really offers much in the way of assured privacy. Skype used to but it has been largely rolled back since Microsoft took over.
Most of it can be worked around, but for a web developer, there's still a lot of wiring that has to get untangled for it all to work as seamlessly as it appears in the video demos.
Definitely some cool technology, though.
http://stackoverflow.com/questions/14623963/stream-low-laten...
Now, we can videochat using the same program we use to play those silly Flash games instead. And we don't even have to be using the same program, she can use Firefox, and we can still use Chrome.
This also opens new things you can do that you couldn't before. Given that Chrome or Firefox do a lot more than just videochat, we can now embed videochat in all the other things the browsers can do, like in games or live support.
We also used to have to ask another person every time we wanted to talk to each other this way. Now, some of the time, we can talk to each other without asking him first.
Explaining it like you're ten might be more useful:
You know Skype? Well, now we can do that on the Internet [Ed: I know, but you're ten, so bear with me]. Also, we can send the video straight from one computer to another. We used to have to send it far away, to another computer, and then he would send it to the person we were talking to. We can also hide what we are saying from other people.
Pretend you're mailing a letter to Grandma. Before, we had to mail a postcard to our mean aunt, who would send it to Grandma. Now, we can put it in an envelope and send it straight to Grandma's house.