Enhanced. Fixing. Solving. Enterprise grade. Improving. Completing.
I've been seeing this too much lately.
Companies decide to market their product as a way to "fix" WebRTC. The gall.
I understand where this comes from. Marketing is a lot about FUD. How to put fear in your potential customer until the only thing left for him to do is buy.
If you look closely, though, none of them really "fixes" WebRTC. The only thing they are doing is using WebRTC in a way that may fit you as a customer.
An example?
Companies who "fix" WebRTC by adding signalling to it. Or adding authorization. Or having it connect to PSTN.
This isn't about "fixing". This is about supporting a specific scenario or feature in a product - not even related to WebRTC itself.
Others "fix" WebRTC by having it work on IE (forcing a plugin on the user or using Flash). Again, less about WebRTC, and more about the use case.
And you know what? WebRTC doesn't offer notifications either - I am sure you can go ahead and "fix" WebRTC by adding push notifications to your app on top of WebRTC!
WebRTC is a very powerful building block, but that's about all it is - a building block. You'll need to add additional building blocks to create a solution with it, so no - you aren't fixing it - you are just implementing your use case with it.
Please.
Stop fixing WebRTC. It isn't broken.
Just focus on solving a real world problem for a real customer and be done with it.
Hi Tsahi, great post.
I'm wondering what's your take about opt-in enablement of the WebRTC Data Channel?
I mean, most browsers will ask for a user's permissions to allow things like obtaining the user's location via the Geo API etc. In light of this, the uncontrolled experience provided by the WebRTC Data Channel API looks a bit unsecure in my opinion.
orcaman,
Degine unsecure first. It isn't the IP addresses or the RTP routes that are "protected" by user's permission but rather the access to the camera and mic which are protected - with or without peerconnection accesss.
Data Channel on its own doesn't make any data not already available to the code, so theoretically, whatever can be sent on the data channel could be just as easily sent over a websocket.
Only thing left is the debate around local IP addresses, which I see as rather useless in most cases (I'll let you in on a little secret - all of my home IP addresses are 10.0.0.x).
I mean secure in an applicative way. For example, using WebRTC, I can connect an unsuspecting user to a P2P mesh network in order to share content. This means the user's upload stream is used without his permission and knowledge. Do you find this behavior acceptable? I think it's a bit border-line, and would expect Google to make this feature an opt-in one.
How is that any different than your browser sending the SAME data to a URL of its choice through JS code on a websocket?
Don't forget the "optimized webrtc", aka "we took the BSD-licensed google thing, added five lines of code and sell it"
Yap. Missed that one this time.