webrtc insertable streams

[ovari]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: support webrtc insertable streams
• Specification or proposal URL:
  • Explainer
  • Specification
  • GitHub Repository
  • Chrome Platform Status
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1631263
• Mozillians who can provide input (optional):

Other information

Insertable streams provide a hook between the RTP (de)packetizer and the encoder/decoder as described here:
http://www.w3.org/2019/09/18-mediaprocessing-harald-insertable-media-processing.pdf

The Jitsi team implemented an end-to-end encryption by using the insertable streams of Chrome with the Jitsi Meet system:
https://jitsi.org/blog/e2ee/

This allows their video bridge (Selective Forwarding Unit) to easily forward packets whatever they are encrypted or not, whatever the receiver quality is.

On the end points, the insertable stream can be processed into a separated thread (or process ?), besides the usual (de)packetizers and encoder/decoder.

The Jitsi Community Call (Streamed live on 21 Apr 2020) at 21’30” stated that access allows:

• end-to-end encryption
• adding more reliability with forward error correction

100% support for Firefox (and other non-Chrome browsers)
jitsi/jitsi-meet#4758

What do you think?

Thank you

[dbaron]

cc @jan-ivar @nils-ohlmeier @martinthomson

It would be useful to get:

• some links to what the actual proposals/specifications are here [ Edit: I found them, and edited the initial comment to add them ]
• your opinions
• cc:ing whoever else is involved in those discussions as well.

[ovari]

Want to Ditch Zoom? Jitsi Offers an Open-Source Alternative

As we spend more time on videoconferences, concerns mount about trust. Emil Ivov says you shouldn't have to trust anyone.

The Jitsi team is working on a way to offer end-to-end encryption, even with a central server, thanks to a new feature of Google Chrome called "Insertable Streams," which makes it possible to add an additional layer of encryption. It won't be necessary for a Jitsi Meet or 8x8 Video Meeting server to decrypt both layers of video before forwarding it to others. That means that in the future you might not need to trust 8x8 with your encryption keys, because it won’t need them to do the work of routing video streams. And without those keys, someone snooping on the central server will only be able to see scrambled video.
https://www.wired.com/story/zoom-jitsi-offers-open-source-alternative-zoom/

[pdarcos]

Insertable streams are hugely important for privacy in webRTC.
I hope you support it fully ASAP.

Useful article on why this is so important

http://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/

[peterHoburg]

As a Firefox and Jitsi user adding support for webrtc insertable streams is really import to me. Right now using Jitsi is the only time in my day when I have to switch off of Firefox and onto Chrome.

Firefox having support for one of the fist TRUE E2EE video conferencing solutions, and hands down the best FOSS solution would be a big win for the entire FOSS community.

As a developer I would be willing to help where I can. I am still learning Rust and haven't written production c/c++ for years, but if a more senior dev has any smaller tasks that need to be done for this I am willing to jump in and help.

[ovari]

Gecko: Positive with comments. Official position requested at #330, but no reply yet. During workgroup discussions they stated that they are OK with adopting this API, but they are opposed to recommending it for end-to-end encryption until a module for key management is part of the Web platform. Their view is that key management should not be done in JavaScript.

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/XFO4OXrdSRA/tnSr3g18AwAJ

[5trongthany]

I would really like to see this added, as it would offer massive privacy improvements for webRTC. I use jitsi for calls a lot, and this would enable end to end encrypted calls to be a reality. It would also help improve performance of many other platform's calling abilities. With everything being work from home lately, I see this as an important tool to implement.

[sapkra]

@dbaron Are there any updates? This is a very important security feature which is still missing in firefox.

Is there anything we can help with?

[DavidBM]

@dbaron Seems to not be working at Mozilla anymore (first line from his profile): https://github.com/dbaron

Maybe @martinthomson or @tantek ?

[martinthomson]

So this isn't as wonderful as it is being made out to be here, but it is something we're supportive of as part of a larger strategy to improve the ability to protect media. For group video calling, being able to say with confidence that the service that forwards media can't read that media is a useful step.

The IETF is spinning up an SFrame effort to work on the encryption format (just say no to bespoke crypto), the W3C is working on getting the API right, but even once that is complete, there is more work needed on other aspects like key management. Otherwise, this could be little better than security descriptions version 2 in terms of the practical protection offered. There are also practical limitations to the amount of protection this provides that will need to be worked out.

I'm going to put in a "worth prototyping" position, but I will remind people that this isn't the place for advocating for what gets implemented in Firefox. This is something that the media team needs to work out. As always, anyone willing to volunteer some code can dramatically change that situation.

[alfredonodo]

Any news?

[AkselRocks]

Also interested in news.
Following ...

[alfredonodo]

Mozilla is finally working on this.

[alfredonodo]

Finally, starting from 117 version, firefox has RTCRtpScriptTransform aka insertable streams.