Re: webRTC and Content Security Policy connect-src

Hiya,

On 16/01/18 23:24, Martin Thomson wrote:
> On Wed, Jan 17, 2018 at 5:50 AM, Roman Shpount <roman@telurix.com> wrote:
>> I almost feel that blocking WebRTC completely and then figuring out correct
>> way to unblock it (through IdP or candidate signing) is a better option.
> 
> This is where I'm at.  Provide a big switch and then investigate more
> granular controls that might allow some sites to get some better
> control.  

Can we ensure that any such big switch or granular control
does not in practice create a major bias towards requiring
involvement from some major web property before a random
web site can deploy WebRTC with CSP?

Maybe I'm overly concerned, but there could be significant
problems with whitelists in this space acting to further
entrench the biggest players generally getting to see or
control JS or traffic, even if the web sites didn't really
want to have that happen.

Cheers,
S.

> Given the complexity of that granular control, shipping the
> big switch would seem to be a good initial strategy.  Though I would
> want to make sure that we had an option to narrow things.
> 
> In designing this switch, we should not preclude the later addition of
> more granular controls, so that needs to be considered as well.
> 
> Finally, using connect-src to govern this is not free of compatibility
> risks.  Sites that have CSP and use WebRTC can't be the empty set at
> this point.  We need to understand whether we can start blocking
> WebRTC if connect-src doesn't list it.  Otherwise, the alternative we
> have is to create a more difficult-to-use mechanism that controls
> WebRTC separate to `connect-src`, with the accompanying risk that
> sites forget to set that control and leave the door unlocked, of
> course.
> 
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)