W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Moving forward with SDP control

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 19 Jul 2013 14:28:45 -0700
Message-ID: <CAJrXDUF7vO41D6hX=RTnUci=Q3+SPZ-fBnN8+kHtnA8VEr_+gA@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: piranna@gmail.com, Kiran Kumar <g.kiranreddy4u@gmail.com>, Likepeng <likepeng@huawei.com>, Cullen Jennings <fluffy@iii.ca>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
You're right that you don't have to choose the key, and you don't have look
at it if don't want to.  But, it's still given to you, and you still have
to transport it to the remote side.  No matter how buried it is in an
opaque blog, it's still in there.
On Jul 19, 2013 2:02 PM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:

>  Hi Peter,
>
>     It sounds like I'm missing something. As a web developer, I have
> haven't had to choose a SDES crypto key in order to initiate video chat.
> The underlying WebRTC implementation might have done so and I passed this
> opaque blob (SDP) over the wire, but I never had to touch it myself.
>
>     So what am I missing here?
>
> Thanks,
> Gili
>
> On 19/07/2013 3:45 PM, Peter Thatcher wrote:
>
> On Fri, Jul 19, 2013 at 10:55 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
>>  Hi Peter,
>>
>>     That's not necessarily true.
>>
>>    - The only reason the user is exposed to this information in the
>>    first place is because the specification declared the bootstrap process out
>>    the scope.
>>     - Assuming we accept this design decision, we still don't have to
>>    give users access to the internals. The specification can declare this blob
>>    as an off-limits opaque token that MUST NOT be modified by the user.
>>
>>     The only reason the user is currently exposed to implementation
>> details is that the Signaling layer and Application API have been packed
>> into a single structure: SDP. If we separate these two, there would be no
>> need to expose internals to the end-user.
>>
>
>  Then how does the SDES crypto key chosen by one side get to the other
> side?  You can say it's not modifyable, but it's still readable, unless the
> signalling is done over a channel that the JS has no access to or control
> over.
>
>>   Gili
>>
>>
>> On 19/07/2013 1:31 PM, Peter Thatcher wrote:
>>
>> Everything that needs to be signalled needs to be available to the JS
>> because it's up the JS to signal it.  For example, if SDES is used, crypto
>> keys must be available to the JS because its up to the JS to send it to the
>> remote side.  There's no way for you to signal it without having access to
>> it.
>>
>>
>> On Fri, Jul 19, 2013 at 9:49 AM, piranna@gmail.com <piranna@gmail.com>wrote:
>>
>>> >     That is not strictly true. Any immutable low-level property should
>>> be hidden from the application developer. Meaning, as an application
>>> developer I don't care that the signaling layer is using encryption key
>>> "9823cuj980ru890e" and yet (I think) this shows up in the SDP. If I don't
>>> ever need to know about it, I shouldn't have access to it.
>>> >
>>>  +1
>>
>>
>>
>>
>
>
Received on Friday, 19 July 2013 21:29:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC