W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: webRTC and Content Security Policy connect-src

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>
Message-ID: <800f6141-da03-19a1-f5ea-829f54f3869a@alvestrand.no>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 17 January 2018 12:06:20 UTC