- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 28 Aug 2014 16:29:13 -0700
- To: public-webappsec@w3.org
A question arose in discussions in the media capture task force around sites being able to forswear access to WebRTC functions. That was in the context of user media (your camera and microphone), but I've concluded based on discussions with the local experts that this isn't really worthwhile doing. WebRTC data channels however, are ripe for exploitation as an avenue unguarded by 'connect-src'. Unlike other sources of script-accessible data, peer-to-peer data is not associated with an origin, so I think that the only thing to do is to clump all WebRTC data into a single group and identify that group with a keyword source. It seems like existing connect-src directives would naturally exclude this new label, unless host-source includes "*", and that's a fairly desirable outcome. WebRTC media features are probably not worthwhile to cover. Although - theoretically - media can alter processing for an origin (for example, through the use of WebAudio or processing video using canvas snapshots), any exposure here would require a fairly complicated set of prerequisites to exploit. For example, a site performing speech recognition might be vulnerable, but then that vulnerability should be quite obvious. Thus, I'd like to suggest a new keyword-source of 'webrtc-data', governing the use of WebRTC data channels. That leaves the option to block 'webrtc-media' in the future. Alternatively, or in addition to that, a single keyword 'webrtc' might cover both, should that be desired. --Martin
Received on Thursday, 28 August 2014 23:29:41 UTC