Re: What would you like to see in WebRTC next? A low-level API?

If you have a codec, a video, and some data you want to exfiltrate to
the recipient of the video, or to anyone who can see the encoded video,
you have a high bandwidth pipeline available already.

FWIW, I just today read through WebAssembly's interface definitions. It
is the kind of interface you expect to have to assembly: There is no
protection whatsoever of the data that is passed across the interface.
Shared buffers and 32/64-bit pass-by-value - that's it.

The nice part is that there's no way for the WebAssembly function to get
access to things outside the box that haven't been shared with it. The
bad part is that there's no protection for the data inside of the box
from the Javascript.


Den 29. jan. 2018 16:57, skrev Cullen Jennings:
> 
> 
>> On Jan 28, 2018, at 10:05 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>>
>> Den 26. jan. 2018 19:29, skrev Cullen Jennings (fluffy):
>>>
>>>
>>>> On Jan 25, 2018, at 5:45 AM, Emil Ivov <emcho@jitsi.org
>>>> <mailto:emcho@jitsi.org>> wrote:
>>>>
>>>>
>>>> A way to set e2e encryption keys (for something like SRTP double)
>>>> would be great!
>>>>
>>>> Obviously doing that from the regular API wouldn’t make much sense,
>>>> but giving that option to browser extensions would be nice!
>>>>
>>>
>>> Let me generalize this a bit … I think the WG thinking about what APIs
>>> it might have for browser extensions as well as what API for JavaScript
>>> would be a good thing. This keying is one, codecs is another, and
>>> handling the policy around what IP addresses get disclosed is another. 
>>>
>>>
>>
>> Remember that exposing the session keys to Javascript means that anyone
>> who can get to your Javascript context can decrypt your communications,
>> and that anyone who's able to get or set your public/private keypair can
>> impersonate you in a man-in-the-middle attack.
>>
>> Of course anyone who can get at your raw communication can get at your
>> communication anyway, so this might not seem like a big deal. But think
>> through the security model before you ask to set keys.
>>
> 
> The way I would add codecs would be more like … 
> 
> 1. The JS tells the browser where to download a websambly codec 
> 
> 2. The codec implements a well defined API that has things like encode, decode, set target bitrate, pass in configuration parameters etc.
> 
> 3. The browser runs the codec in a context where it has no access to anything that would allow it to exfiltrate the raw data or do other bad things but the browser can call the API to encode and decode stuff
> 
> 4. The JS would be able to set parameters on the codec that the browser would pass in. Note this is data only goes in, does not come out of codec. 
> 
> 5. The browser would generate stats / metrics about the the performance of the codec that the JS could ready. Note the codec can not create it’s own stats. Yes, you can argue we might be able to exfiltrate data at a super low bitrate this way by doing things like changing the output bitrate of the codec based on information it wanted to exfiltrate but this could be done in a pretty safe was and presumable people that cared would not run codecs from questionable services.
> 
> Ignoring the topic of if you think we should work on something like this, let me first ask do you think it might be possible to do something along those lines that could allow plugin codecs while at the same time limited risk of revealing media to the JS. 
> 
> 
>

Received on Monday, 29 January 2018 16:29:30 UTC