4 ms·

> "With a traditional WebRTC implementation, both the patient and therapist’s devices would talk directly with each other, leading to exposure of potentially se

> "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?

lnsp 4y ago
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.
- treis 4y ago
  It doesn't say that Cloudflare can't or doesn't access the encrypted data. It seems to be written in a way that everyone would assume they can't but AFAICT it doesn't explicitly say it. Which makes me think they phrased it like this for a reason but I definitely could be wrong.
nine_k 4y ago
"If you don't trust each other, trust us": a very understandable value proposition. Also very understandable trade-offs.
- ranger_danger 4y ago
  Personally I wouldn't want even more people involved in my medical communications. Imagine if this data was leaked or sold and then used against you, like say for instance, receiving a consultation or help regarding an abortion or drug habit.
arkh 4y ago
> the patient and therapist’s devices would talk directly with each other 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.
throwaway99797 4y ago
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.
kevincox 4y ago
> 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).
- throwaway99797 4y ago
  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 for scaling.
  - kevincox 4y ago
    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 layer in the WebRTC stack to manage this and allowing the Selective Forwarding Unit (SFU) to be allowed to drop chunks without messing up the connection. However it is definitely possible to do all of this over WebRTC with full E2E encryption (see Jitsi Meet).
michaelt 4y ago
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"

lnsp 4y ago

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.

treis 4y ago
It doesn't say that Cloudflare can't or doesn't access the encrypted data. It seems to be written in a way that everyone would assume they can't but AFAICT it doesn't explicitly say it. Which makes me think they phrased it like this for a reason but I definitely could be wrong.

nine_k 4y ago

"If you don't trust each other, trust us": a very understandable value proposition. Also very understandable trade-offs.

ranger_danger 4y ago
Personally I wouldn't want even more people involved in my medical communications. Imagine if this data was leaked or sold and then used against you, like say for instance, receiving a consultation or help regarding an abortion or drug habit.

arkh 4y ago

> the patient and therapist’s devices would talk directly with each other 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.

throwaway99797 4y ago

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.

kevincox 4y ago

> 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).

throwaway99797 4y ago
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 for scaling.
- kevincox 4y ago
  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 layer in the WebRTC stack to manage this and allowing the Selective Forwarding Unit (SFU) to be allowed to drop chunks without messing up the connection. However it is definitely possible to do all of this over WebRTC with full E2E encryption (see Jitsi Meet).

michaelt 4y ago

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"