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 that much where that is even possible?
For many (most) use cases, CF will operate at a resilience and stability and professionality level far above what they can achieve themselves.
It's actually kinda nice to have half the internet go down at once. People can just stop work, wait a few minutes, and it magically comes back up. Making downtime somebody else's problem is a huge advantage...
However, people continue to use cloudflare because it is easy, solves problems people don't like dealing with, and does the job. I don't know what the alternative pitch is to businesses so that cloudflare isn't so central to the internet.
The problem is that governments worldwide have done little to curb abusive behavior that makes this all but necessary to survive on the Internet:
- India (for US/UK based callcenter scams) and Turkey (for German based) don't do shit against scam callcenters. There have been multiple high-profile Youtubers making videos exposing these scammers and police there hasn't done anything, some have even boasted about having connections to bribed police officers protecting them.
- Russia, China, North Korea and Iran haven't been kicked off of the Internet despite both nations actively running hacking campaigns and sheltering hackers and "bullet proof" hosters.
- Western governments still don't mandate open source or at least audits for Internet-connected appliance software, which means that there are tons of devices (smart cameras, other smart home systems, routers, ...) out there that end up compromised, and on top of that residential Internet connection speeds routinely cross 100 MBit/s these days giving compromised appliances an awful lot of leverage for DDoS attacks (which is the chief use case for employing Cloudflare, AWS Cloudfront+WAF and others).
There simply is too much abuse in the system
In the example, now instead of sharing my IP with a therapist, (who I presumably trust enough to... not ddos me?), I'm sharing the fact that I was talking to a therapist with a company I possibly didn't even know existed.
Better yet, I suppose I can now be barred from accessing webrtc services if said company decides I'm a "threat" based on all the metadata they've been collecting through their other services.
This allows CF to construct a person graph, which is the only power Facebook have in the advertising business. ;)
This will also allow CF to police WebRTC and block people out, like they already do for the rest of the internet. Get ready to answer webRTC captcha(TM) on every call if you use linux or such.
That said, I’m not sure that leaking an IP address is a big deal for most people. (It might be important in Ukraine, though.)
And when the inevitable curation / editorial / policing challenge of running half the internet does knock on their doorstep, they go "well we're not the ones who are supposed to be policing it, but what are you gonna do?!"
Can someone clarify this? WebRTC is encrypted generally even if you leak metadata like IP address. Is Cloudflare stating they will be the middleman and therefore have access to the decrypted video stream?
edit, yes it's encrypted:
> Finally, all video and audio traffic that passes through Cloudflare Calls is encrypted by default. Calls leverages existing Cloudflare products including Argo to route the video and audio content in a secure and efficient manner.
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. Pro: The call depends on a minimal number of parties.
3. Pro: The call is generally more performant, limited only by the connection between both peers.
4. Pro: No need for third-party services other than a network connection.
5. Con: The peer learns your IP which may be used to help identify you or DoS your internet connection.
6. Con: Intermediates anywhere on the network can see which two peers are talking. (With a SFU only the SFU knows the ends of the connection for sure)
> Is Cloudflare stating they will be the middleman and therefore have access to the decrypted video stream?
I see nothing in this article that suggests that they will have access to the decrypted video. However I wouldn't be surprised if that is added in the future.
The reason is that in order to to big calls you need to support multi-quality streams. This can in theory be done on decrypted connections but not all browsers support this right now (notably Firefox). So if you want the widest support you need to do video transcoding at the SFU.
There are also other features such as recording and live-streaming that (generally) require access to the raw video. (Of course this can be done as adding the recorder/streamer as a "peer" to the E2EE call when needed, but that is still giving the keys to the company at this point).
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.
A traditional form of griefing is "get your victim's IP address from a direct-connecting service like Skype and DDOS them while they're doing something latency-sensitive"
For health data that's what you want. So I'd like to see how it would go with the GDPR agencies if used in a medical app.
[1] https://blog.cloudflare.com/announcing-our-real-time-communi...
https://www.vonage.com/communications-apis/video/ https://aws.amazon.com/chime/chime-sdk/ https://www.daily.co/
If Google had just opened their APIs, they could have provided this to everyone...
What do you suggest? Cloudflare should stop releasing products? Regulation that you are only allowed to handle x% of the total internet traffic?
So we're supposed to go use one of thousands of other tiny cloud platform providers?
Okay let's entertain that idea. The first bare minimum items on your vendor approval checklist are things like "can I trust this business to exist in 10 years" , "do they have enough resources to support me when shit hits the fan", and "are they mature enough to deliver on the shiny bullet points on their homepage and in their sales pitch".
Isn't this process going to naturally select a small handful of providers? What am I missing here?
So yeah, not being able to handle more than x% of the internet traffic (unless they're running a real dumb pipe with only IP routing logic) sounds great. I'd welcome anther Bell systems breakup.
Regulation sounds about right. Monopolies are regulated in the real world, so why don't we do the same in the virtual one?
Accusations of hypocrisy is not an argument. Instead of accusing me (and all other detractors) of not criticizing others enough, please elaborate why this isn’t what I described.
Cloudflare (and others) keep releasing products which makes their central role more central and less vulnerable to competition. They ought not to do that, and I would argue for laws which prevent them from doing that if necessary.
Regarding the problem, this kind of problem should not be solved by one central actor. Instead, these problems should be solved by new network and protocol designs.
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.
I'm really getting tired of this kind of hand-wavey response.
I keep hearing this term 'fireside chat' used like this, and ever time there's no actual fire and it's not intimate (10k viewers?). What is it supposed to mean?
>"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
> Calls uses anycast for every connection, so every packet is always routed to the closest Cloudflare location.
Is this true for the UDP media (and data channels) traffic, or just for the initial signaling and connection setup?
If the UDP traffic is all anycast, that's truly impressive engineering work. Bravo!
It is true, both media and signaling is over anycast and advertised from every Cloudflare location. We manage things like ICE and DTLS state in a distributed way.
Super happy to be part of the super talented team that made this happen!
I don't think they've talked much about what happens if the connections gets routed to a different PoP mid-stream.
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
Relatedly, I didn't know that Stream had launched SFU cascading. That's awesome! I'd love to compare notes sometime if you're up for it. (I'm a co-founder of Daily.)
