- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 17 Jan 2018 10:24:45 +1100
- To: Roman Shpount <roman@telurix.com>
- Cc: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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. 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 Tuesday, 16 January 2018 23:25:14 UTC