Re: Moving forward with SDP control

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
>
>
>
>