Daily co-founder here. We try to be very careful with the language we use around security, privacy, and encryption, because it's so important to be able to trust (and verify) all claims. We try to always be clear that with Daily, media streams are end-to-end encrypted when a session is running in peer-to-peer mode, and aren't when a session is running in media server mode.
The WebRTC standard mandates encryption on the wire for each WebRTC connection. Which is really great! But there is currently no standard way to implement true "end-to-end encryption" for calls that are routed through a media server. Calls routed through a media server are separate connections to the server for each client. Each connection is encrypted, but the media server decrypts the RTP packets in order to forward them.
You can definitely implement end-to-end encryption if you have a custom WebRTC build (for example, a native mobile or desktop library). And you can now
sort of hack end-to-end encryption together using the new Insertable Streams standard that is partially supported in Chrome.
But even with the current version of Insertable Streams, you'll have to generate encryption keys at the application level. So if, for example, your provider operates under a regulatory regime that requires they be able to provide law enforcement with access to your media streams, they will be able to do that.
Some video conferencing providers have claimed "end-to-end encryption", meaning "we don't decrypt the media as it flows through our servers." And I understand how they got there. If you do care about security, and you think you're following general security best practices on your media servers, and you don't ever touch the decrypted RTP packets except to forward them, that definitely feels like you're guaranteeing end-to-end encryption in every sense that anyone should care about. After all, for true end-to-end encryption you have to accomplish the key exchange somehow, there will be attack surfaces there, and your customers will want some of their media traffic to be decrypted on your servers for things like recording and transcription. So how is layering on this additional encryption going to actually make your system more secure, given the already very good security provided by the WebRTC point-to-point connections?
But ... end-to-end encryption has a technically precise meaning, so it's a lot better not to claim you're doing it, if you're not.
Another relevant HN comment: https://news.ycombinator.com/item?id=27390377
[ Edited after I re-read this, to be 100% clear: the onus should be on us, the service providers, to say precisely what we do with regards to security. Slingshow, and all of our customers and partners, should be able to depend on us for accurate, clear, and complete security documentation. ]