They 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 that much where that is even possible?
They just keep building on top of the things they've already built that are working really well, expanding into related services. Doesn't seem that different from what AWS is doing, just with a different focus and in a different place in everyone's (or the Internet's) stack.
It reminds me the days of Google flourishing in early 2000s: they added more and more wonderful stuff (such as mail, or maps) while improving their flagship offering, search, more and more. A lot of people were their sincere fans.
Isn't that what AWS, Google, Azure, etc. have done forever? Cloudflare is easier to use, and IMO, just plain better.
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...
what you say makes sense and even I doubt that cloudflare will remain committed to being content neutral even if they want to be, a different issue. Government can get corporations to do what they want.
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.
Agreed. I think they do a lot of good for the ecosystem, but there's no reason to give one organization so much trust and to continue centralizing everything you do on their platform. They're very, very good at cultural and enterprise marketing though. My boss and countless others are completely sold that they should handle all of our complexities.
> 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?
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).
I'm having trouble understanding how giving this metadata to a centralized entity makes the transaction more "private".
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.
This infrastructure isn’t needed for two person conversations. What you’ve missing is that in a group situation, you’re not just trusting the group leader, but everyone in the call. The larger the group and the lower the barriers to entry, the worse it is.
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.)
I'm so tired of this FUD cloudflare throws around. So far, I don't see a single cloudflare product that solves the purported problem without introducing three others that they conveniently don't talk about.
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?!"
> "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' devices will be talking only with the Cloudflare network. To your end users, the experience will feel just like a peer-to-peer call, only with added security and privacy upside.
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?
As far as I understood it: the premise of added security is based on the fact that the other WebRTC peers only see Cloudflare's IP instead of your own. Also nobody knows who you are exactly talking to except Cloudflare. I would still expect that the media channels itself still remain encrypted when even when multiplexed by Cloudflare's network.
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.
> 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. 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).
Instead of "patient and therapist" a better example might be "livestreamer and griefer"
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"
Cloudflare has to have access to the decrypted video just like Google Meet does, because browsers by default encrypt to the peer and they are the peer. After all these years there still isn't universal browser support for actual E2EE. What support does exist uses hacky APIs.
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.
This sounds badass to be honest. Having written some WebRTC browser applications from scratch, that architecture turns into a complicated mess real fast, I can only imagine the nightmare that becomes at less than well equipped tech startups. This sounds like the right way to actually solve the problem.
Other long-standing direct competitors include Vonage, who acquired the original WebRTC platform-as-a-service, OpenTok; AWS Chime Video; and Daily (YC W16).
Google missed their opportunity to do this: they've had Google Meet / Hangouts / ... for years. They have the same backend infrastructure that can scale to thousands and low latency to everywhere. Meet already does this with a custom Google protocol in the browser.
If Google had just opened their APIs, they could have provided this to everyone...
Don't forget about Google Fi (which, it seems sometimes, that _Google_ has forgotten about) which ties it all together with traditional carrier services too. Well it did until they sunset Hangouts, I suppose.
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?
Unlike Google or Amazon? What happens when there is an outage on either of those? I think it is great that there is more competition in the space writ large.
> Remote 'fireside chats' where one or multiple people can have a video call with an audience of 10,000+ people in real time (<100ms delay)
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?
As the main author of Janus, I didn't appreciate at all them proactively suggesting Calls as a replacement for existing deployments based on Janus and mediasoup. I'd understand them aggressively marketing against other RTC cloud providers like Agora, Twilio, and others: trying to "steal" users from open source projects (who share everything and so often live on consulting) really feels like a d*ck move, instead, and basically stealing candy from kids.
TLDR: Remember how Skype allowed you to talk directly with one another without pesky servers and middle men positioned to intercept calls and metadata? Remember CALEA (Communications Assistance for Law Enforcement Act to allow wiretapping on digital phone networks)? Remember how Microsoft scrambled to dismantle peer-to-peer infrastructure and switch Skype to a typical server model while simultaneously joining PRISM program? Wouldnt you want to do the same with WebRTC? Why trust your doctor when you can trust Us instead!
>"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
I work on the team that works on Calls. Thank you for the kind words.
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!
Is anycast "just" (!) broadcasting different routes for different parts of the internet for the same IP address? I cannot imagine this is trivial to get right at all.
Speculating here, but I would read this as "anycast" as a concept, where each user is connected to the closest location. versus anycast as in the IP protocol. The complexity far outweighs benefits with routing each UDP packet to different servers within the same session.
I wonder if there's a way to integrate this with https://snowflake.torproject.org/, such that blocking Tor would require also blocking all of Cloudflare?
Short answer: it's not currently possible to do true end-to-end encryption through media servers with a key that is inaccessible from user space.
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
This is the same approach that getstream.io (disclaimer, my startup) and agora.io take for video calling. A global edge network with support for SFU cascading is optimal for the call quality.
The Cloudflare Calls launch post is really well written! But I agree that it perhaps somewhat overstates the uniqueness of their approach, given that Agora, Jitsi-as-a-Service, Stream, and Daily all offer WebRTC platforms with a mesh/cascading SFU architecture.
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.)
rixthefox|3 years ago
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?
seeekr|3 years ago
leokennis|3 years ago
For many (most) use cases, CF will operate at a resilience and stability and professionality level far above what they can achieve themselves.
nine_k|3 years ago
unknown|3 years ago
[deleted]
solardev|3 years ago
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...
ranger_danger|3 years ago
onetimeusename|3 years ago
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.
eastdakota|3 years ago
bombcar|3 years ago
BowBun|3 years ago
remram|3 years ago
mschuster91|3 years ago
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
shiomiru|3 years ago
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.
ghhgfghfghfhf|3 years ago
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.
skybrian|3 years ago
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.)
bryfb|3 years ago
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?!"
Xeoncross|3 years ago
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?
lnsp|3 years ago
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.
kevincox|3 years ago
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).
michaelt|3 years ago
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"
nine_k|3 years ago
throwaway99797|3 years ago
arkh|3 years ago
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.
mwcampbell|3 years ago
leihca|3 years ago
[1] https://blog.cloudflare.com/announcing-our-real-time-communi...
barake|3 years ago
corytheboyd|3 years ago
jgrahamc|3 years ago
tommoor|3 years ago
kwindla|3 years ago
https://www.vonage.com/communications-apis/video/ https://aws.amazon.com/chime/chime-sdk/ https://www.daily.co/
throwaway99797|3 years ago
If Google had just opened their APIs, they could have provided this to everyone...
mcpeepants|3 years ago
teddyh|3 years ago
dewey|3 years ago
What do you suggest? Cloudflare should stop releasing products? Regulation that you are only allowed to handle x% of the total internet traffic?
snarf21|3 years ago
unknown|3 years ago
[deleted]
deeblering4|3 years ago
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?
transientbug|3 years ago
yencabulator|3 years ago
endisneigh|3 years ago
lminiero|3 years ago
rasz|3 years ago
>"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
pwpwp|3 years ago
kwindla|3 years ago
> 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!
dincer|3 years ago
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!
mmastrac|3 years ago
davidz|3 years ago
gnfargbl|3 years ago
gizmo|3 years ago
intrasight|3 years ago
dannyw|3 years ago
Should we be reading deeper into this?
kwindla|3 years ago
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
rasz|3 years ago
tschellenbach|3 years ago
kwindla|3 years ago
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.)
mjreacher|3 years ago
brightball|3 years ago
throwaway787544|3 years ago
[deleted]