3 ms·
No, because the specification is more general than that. The specification is about being able to add a input/output transform step, so you can add encryption o
by capableweb 7y ago
No, because the specification is more general than that. The specification is about being able to add a input/output transform step, so you can add encryption on top of WebRTC streams, via this new API.
JavaScript encryption/decryption seems to work fine for the most basic use cases, but if you have many streams you need to do encryption/decryption for you, you probably want to use native browser APIs for it or WebAssembly.
- kodablah 7y agoRight, I understand it's more general, but there is a use cases section in the explainer that putting this there might have value. In other cases where encryption is used (e.g. fetch, webrtc itself, etc), often we ask the browser to do it due to, among other things, the performance benefit of not doing it in JS or WASM. I'd have to test using window.crypto.subtle.encrypt or tweetnacl something to check the overhead (I do see the webcodec examples show a write/readable stream which allows promise-based encryption). Arguably this could have been done at the conn level w/ raw RTC data instead of the media stream level so I wouldn't have to handle data channels separately, but I see the value in sharing with other use cases of client-side stream manip.