Was hoping they'd release a stand-alone TURN service first. The WebRTC-based product I've been working on for months now (finally wrapping up v1) is one-to-one by nature, and I actually want the connection to be peer-to-peer when possible. But access to a TURN server in every Cloudflare datacenter would be nice.
Cloudflare Calls
81–90 of 132 posts
Re: Cloudflare Calls
#82Why did Cloudflare say "encryption" but not "end-to-end encryption"? Should we be reading deeper into this?
Longer answer...
WebRTC was designed as a fundamentally peer-to-peer protocol. The spec defines (and basically mandates) the use of end-to-end encryption. Which is great! Among other things, this means that browsers can implement e2e in a standardized and provably secure way.
On top of WebRTC's fundamental peer-to-peer-ishness, you can build an architecture to forward or process media and data streams through media servers. This is what Cloudflare has done, and what every major WebRTC platform/project does in order to scale up participant counts, improve performance by moving routing closer to the network edge, and implement things like recording. But there's no support (yet) in the WebRTC spec for encrypting media streams so that they can be handled and routed by a media server without decrypting them.
There's ongoing work on this. Here's a nice blog post covering how the early working group effort was being organized: callstats.io/blog/2018/06/01/examining-srtp-double-encryption-procedures-for-selective-forwarding-perc
Re: Cloudflare Calls
#83>"With a traditional WebRTC implementation, both the patient and therapist’s devices would talk directly with each other, leading to exposure of potentially sensitive data such as the IP address... When using Calls, you are still using WebRTC, but the individual participants are connecting to the Cloudflare network
Re: Cloudflare Calls
#84Why did Cloudflare say "encryption" but not "end-to-end encryption"? Should we be reading deeper into this?
Re: Cloudflare Calls
#85Earlier quoted context omitted.
WebRTC is end-to-end encrypted to the peer. So you're right, when you do actual peer to peer WebRTC between you and another user in a browser, you have end-to-end encrypted communication. When you go through a server, it's just another peer. So the word end maybe doesn't fit anymore, because it's a server that is the peer and they can decrypt the stream. Transcoding is pretty common at that stage because it's helpful…
That isn't necessarily true. I guess it is a bit opaque but when you negotiate a WebRTC connection you get a key and a list of network endpoints that you can use. It is entirely possible to add a proxy server in that list of endpoints without giving the proxy server a key as far as I am aware. That being said for big calls you start wanting to do selective forwarding and you probably need to drop down to a lower laye…
Chrome implements experimental user-space media stream processing APIs that allows you to build "end-to-end encryption" at the javascript level. But, to me at least, it's a bit hand-wavy to call that "end-to-end encryption" because the keys are created, managed, and accessible from user-space. And neither Safari nor Chrome yet support these APIs.
There's ongoing work on this: https://datatracker.ietf.org/wg/perc/documents/
Re: Cloudflare Calls
#86They really do want to be the center of everything it seems. I wish they would stop trying to be the Cisco of Networking in the sense of trying to convince a lot of people to let them handle critical network functions for a ton of networks. All it will take is one major outage for everyone to see this is a bad idea. Why trust a cloud provider who could go down and take half the Internet with it? Why centralize it tha…
History always repeats itself. Popular company gets too big, then splits up, then slowly merges back, ala AT&T.
Re: Cloudflare Calls
#87Another “Let’s make Cloudflare the central server of the Internet” service, from what I can see.
I'm really getting tired of this kind of take. You never really see that if AWS adds a product, or GCP adds a product or any other products from bigger CDNs. What do you suggest? Cloudflare should stop releasing products? Regulation that you are only allowed to handle x% of the total internet traffic?
Which take is that? An opinion or outlook that differs from your own?
>"You never really see that if AWS adds a product, or GCP adds a product or any other products from bigger CDNs."
Sure, you do. When AWS released it's DocumentDB(MongoDB competitor) and "Open Distro for Elasticsearch" there was plenty of uproar, both form the companies behind these products as well as the community. Those concerns were also registered on HN.
Re: Cloudflare Calls
#88> "With a traditional WebRTC implementation, both the patient and therapist’s devices would talk directly with each other, leading to exposure of potentially sensitive data such as the IP address... When using Calls, you are still using WebRTC, but the individual participants are connecting to the Cloudflare network. If four people are on a video call powered by Cloudflare Calls, each of the four participants' device…
> WebRTC is encrypted generally even if you leak metadata like IP address. Yes, WebRTC does end-to-end encryption by default. The IP is "leaked" because the peers directly connect to one another, so they will naturally require each others' IP address (which is required to talk to one another). There are both upsides and downsides to direct P2P connections. 1. Pro: The minimal number of parties can analyze the call. 2…
It definitely used to be true that most p2p routes were lower latency than bouncing through a server at, say, an AWS data center. In 2019 we looked closely at this and it was fairly rare to see cases where latency was improved by switching over from a p2p connection to an SFU (media server) connection. Now, the reverse is true. It's usually the case that routing through a media server at AWS (or any other major provider) is as good or better than a p2p route between any two end users.
Early in the pandemic, we assumed this was a temporary thing. ISPs had not built out their networks expecting much upstream traffic. But they'd adjust.
well, ISPs have evolved. Now we see much better performance in general than we did early in the pandemic. But we still see better performance to "the backbone" than we do between ISPs.
Another step in the Internet become less of a decentralized network, perhaps.
Re: Cloudflare Calls
#89Earlier quoted context omitted.
AWS is going for "the internet's backend". I don't see how that's any different. A SPOF is still a problem, no matter where in your stack it lives.
They're positioned to have much wider reach than even AWS. You probably wouldn't put AWS in front of GCP or Azure. You might put CloudFlare in front of any of those. And once you've done that, well, they offer these other services that compete with the backend you're already using.... Their position in the stack has a great deal of market relevance, which translates to risk if they realize that potential, because the…
Re: Cloudflare Calls
#90I suppose this would be mostly a direct competitor to Twilio's solution that's a few years old now: https://www.twilio.com/webrtc
https://www.vonage.com/communications-apis/video/ https://aws.amazon.com/chime/chime-sdk/ https://www.daily.co/