- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Wed, 17 Jan 2018 09:53:09 +0100
- To: public-webrtc@w3.org
Does anyone know of any major webrtc deployment that uses CSP and webrtc today? Best regards Sergio On 17/01/2018 1:14, Stephen Farrell wrote: > 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. >> >>
Received on Wednesday, 17 January 2018 08:54:13 UTC