- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 17 Jan 2018 13:05:51 +0100
- To: Martin Thomson <martin.thomson@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: Roman Shpount <roman@telurix.com>, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Den 17. jan. 2018 01:29, skrev Martin Thomson: > On Wed, Jan 17, 2018 at 11:14 AM, Stephen Farrell > <stephen.farrell@cs.tcd.ie> wrote: >> 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? > > Yeah, I'll confess that this is part of why I have reservations about > these switches. It encourages a deployment model that centralizes > communications in ways that advantage larger providers. > > Pure peer-to-peer is much harder to get working if you have to > authorize every IP address. The inherent difficulty of implementing > Roman's suggestion to authenticate candidates should make that > obvious. > My suspicion is that the deployable solution is to define webrtc-src: so that people can deploy webrtc-src: without having to say content-src: * So if you do content-src: self, webrtc-src:* you're saying "this page will use WebRTC to connect to random strangers in the night, but you're STILL not going to get scripts from anywhere but here". This leaves an issue with what you are able to do or not do with those blobs you get over the datachannel; I suspect that this is not going to be solved within the CSP toolset, but might be solvable using some form of origin tainting.
Received on Wednesday, 17 January 2018 12:06:20 UTC