4 ms·

"Cutting-edge" implies that these guys managed to apply secure E2E encryption, but I can't find any references to it on the website. Correct me if I'm wrong.

supermatt 7y ago
You are wrong. This is the current state of webrtc. Without considerable hacks (patent-encumbered unaccelerated wasm ffmpeg encoding of pixel data, rolling your own SRTP-like encrypted stream over datachannels and full mesh distribution of keys) this is not currently possible for anything other than a full mesh. Whenever an SFU (effectively a MITM) is involved (needed for more than a small number of participants) e2e encryption is lost. If/when Insertable Streams are commonplace, this will be possible without so many hacks. Edit: I see I was downvoted for correcting you, but there was an article on this very subject yesterday: https://webrtchacks.com/you-dont-have-end-to-end-encryption-e2ee/ https://webrtchacks.com/you-dont-have-end-to-end-encryption-...
- fulafel 7y ago
  The video transmitted over webrtc srtp is natively dtls encrypted between peers.
  - supermatt 7y ago
    Yes, that is the "full mesh" that I mention in my comment... This platform - and jitsi/janus/zoom/whatever - all use an SFU for more than a handful of participants.
    - fulafel 7y ago
      But thats very doable. And no need for the unaccelerated ffmpeg wasm afaics, and no need to use a "sfu". I don't know what Mediasoup does, was just commenting on what webrtc can do re the "the current state of webrtc" subject.
      - supermatt 7y ago
        Do you have any examples of a webrtc video conferencing platform that provides a sufficient user experience over full mesh with 4 or more participants on disparate internet connections? Im just saying that this library (and similar platforms) ARE the cutting edge of webrtc. At small number of participants, they use full mesh (which is e2ee), but at larger scale, they need to use an SFU (which is not e2ee without jumping through some crazy hoops - but this is being worked on)
        fulafel 7y ago
        No (but i hope they exist, havent looked) - however not all webrtc apps are general videoconf platforms. You don't even need servers if you go full p2p.
        supermatt 7y ago
        You still need servers to handle the signalling, perform ICE and TURN where applicable.
        fulafel 7y ago
        Only if you need to support users without full internet connectivity. Again webrtc can be used in many different requirement contexts.
        supermatt 7y ago
        You can certainly manually handle the signalling to set up the offer/answer. e.g. read them out to your peer(s). You would still need some form of STUN server (but there are a number of 'freely accessible' ones, even configured as defaults in some browsers) to get your reachable address/port/proto. You cant, AFAIK, handle this manually - it is handled internally as part of ICE. Then you would need to manually handle the signalling of these as well. Thats the bare minimum you have to do to peer over webrtc under ideal circumstances, but its certainly doable. So you do that for each peer. If you (or a peer) change streams you will do the same thing all over again
    - kabes 7y ago
      For some reason I can't reply to fulafel. But a full mesh is definitely not very doable when you're dealing with a larger amount of people. Close to all conferencing solutions today are working via an SFU for a reason. E2E encryption via the SFU gets more and more attention and is being worked into the spec. But it can't be counted as state of the art in webRTC today
      - fulafel 7y ago
        Most calls are not between large amount of people, a portion of webrtc applications would rather compromise on particiant # than security.
        supermatt 7y ago
        For small numbers of participants, many of these platforms use full mesh (which is e2e encrypted).
        fulafel 7y ago
        Yep, but you can't trust that e2e is a property of the app then, unless it prominently features in the ui.
        supermatt 7y ago
        You are 100% correct. The product I work on signals this to the user, and asks for confirmation before "upgrading" to an SFU.

supermatt 7y ago

You are wrong. This is the current state of webrtc. Without considerable hacks (patent-encumbered unaccelerated wasm ffmpeg encoding of pixel data, rolling your own SRTP-like encrypted stream over datachannels and full mesh distribution of keys) this is not currently possible for anything other than a full mesh. Whenever an SFU (effectively a MITM) is involved (needed for more than a small number of participants) e2e encryption is lost. If/when Insertable Streams are commonplace, this will be possible without so many hacks. Edit: I see I was downvoted for correcting you, but there was an article on this very subject yesterday: https://webrtchacks.com/you-dont-have-end-to-end-encryption-e2ee/ https://webrtchacks.com/you-dont-have-end-to-end-encryption-...

fulafel 7y ago
The video transmitted over webrtc srtp is natively dtls encrypted between peers.
- supermatt 7y ago
  Yes, that is the "full mesh" that I mention in my comment... This platform - and jitsi/janus/zoom/whatever - all use an SFU for more than a handful of participants.
  - fulafel 7y ago
    But thats very doable. And no need for the unaccelerated ffmpeg wasm afaics, and no need to use a "sfu". I don't know what Mediasoup does, was just commenting on what webrtc can do re the "the current state of webrtc" subject.
    - supermatt 7y ago
      Do you have any examples of a webrtc video conferencing platform that provides a sufficient user experience over full mesh with 4 or more participants on disparate internet connections? Im just saying that this library (and similar platforms) ARE the cutting edge of webrtc. At small number of participants, they use full mesh (which is e2ee), but at larger scale, they need to use an SFU (which is not e2ee without jumping through some crazy hoops - but this is being worked on)
      - fulafel 7y ago
        No (but i hope they exist, havent looked) - however not all webrtc apps are general videoconf platforms. You don't even need servers if you go full p2p.
        supermatt 7y ago
        You still need servers to handle the signalling, perform ICE and TURN where applicable.
        fulafel 7y ago
        Only if you need to support users without full internet connectivity. Again webrtc can be used in many different requirement contexts.
        supermatt 7y ago
        You can certainly manually handle the signalling to set up the offer/answer. e.g. read them out to your peer(s). You would still need some form of STUN server (but there are a number of 'freely accessible' ones, even configured as defaults in some browsers) to get your reachable address/port/proto. You cant, AFAIK, handle this manually - it is handled internally as part of ICE. Then you would need to manually handle the signalling of these as well. Thats the bare minimum you have to do to peer over webrtc under ideal circumstances, but its certainly doable. So you do that for each peer. If you (or a peer) change streams you will do the same thing all over again
  - kabes 7y ago
    For some reason I can't reply to fulafel. But a full mesh is definitely not very doable when you're dealing with a larger amount of people. Close to all conferencing solutions today are working via an SFU for a reason. E2E encryption via the SFU gets more and more attention and is being worked into the spec. But it can't be counted as state of the art in webRTC today
    - fulafel 7y ago
      Most calls are not between large amount of people, a portion of webrtc applications would rather compromise on particiant # than security.
      - supermatt 7y ago
        For small numbers of participants, many of these platforms use full mesh (which is e2e encrypted).
        fulafel 7y ago
        Yep, but you can't trust that e2e is a property of the app then, unless it prominently features in the ui.
        supermatt 7y ago
        You are 100% correct. The product I work on signals this to the user, and asks for confirmation before "upgrading" to an SFU.