- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 17 Aug 2015 15:46:31 +0200
- To: Eric Rescorla <ekr@rtfm.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 17/08/2015 15:33, Eric Rescorla wrote: > Do you see a problem with making that behavior (i.e. disabling > RTCPeerConnection on third party embedded context) the default even > if no CSP directive is set (and only use CSP to make it more lax)? > > > That seems to violate the general philosophy of CSP (at least when I was > involved) > that CSP was a belt-and-suspenders mechanism. Right, I'd ask WebAppSec specifically about this. > In addition, I think we would > need to ask what currently valid code it would break. Can you help me figure out the right way to go about this? I assume collecting data about such a change is not something that can be done cheaply, so would the following be the right approach? * ask WebAppSec how they feel about this proposal * if they bless it, come back to this group asking for telemetry data on the plausibility of its deployment * assuming plausibility, create a PR for the WebRTC spec that disables RTCPeerConnection in 3rd-party embedded context * ask WebAppSec to add a rule to CSPx for enabling RTCPeerConnection Dom
Received on Monday, 17 August 2015 13:46:35 UTC