Re: [rtcweb] Preserving stream isolation when traversing the network

[Martin Thomson <[e-mail]>]

On Mar 6, 2014 2:38 PM, "Jim Barnett" <[e-mail]> wrote:
>
> On the scoping question, suppose SideA creates isolated streams (that can
only be sent to SideB) while SideB creates unprotected streams to send to
SideA.  Are SideA's streams treated as unprotected, or are SideB's treated
as isolated?  Normally I would think that the weakest restriction would
win, so that both sides' streams would be unprotected, but it would come as
quite a surprise to A that something B did could cause his streams  to lose
isolation (in his own browser, I mean - A obviously can't control what B
does with the stream once it gets there.)

The idea is that ÄĻŁ streams/tracks would be protected and that means that
both sides would have to apply the same treatment.

That has several consequences, some of which could be considered negative.
There are a few API niceties that could be added here to mitigate these.  I
omitted those from the first analysis, but I've added them here.

For streams that change between isolated and non-isolated, there are two
ways we handle this.  We already have guidance that streams should send
black/silence if they are (or become) isolated.  And streams that become
non-isolated fail safe.  These protections are the most important, because
they are fundamental properties required by the web sandbox.

The scenario you describe is where each side starts with a different idea
about what isolation properties are required.  Without any other
mechanisms, this fails safe - the (D)TLS handshake would be required to
fail when implementations detect a mismatch in isolate state.

In order to avoid issues with this, we probably need to consider the
addition of a flag in SDP.  That flag would be advisory only, but it would
ensure that you could surface an error in createAnswer that indicates this
mismatch prior to having the problem blow up in less obvious ways.

BTW, we don't have to, but for mixed streams on one side, we should add an
error to createOffer/createAnswer to block the creation of SDP when there
are mixed isolation on streams.  Again, that avoids the issue of having
things break in non-obvious ways later.