CSP-like mechanism for disabling RTCPeerConnection API?

[zenhack]

Hi everyone,

Apologies in advance if this is the wrong place to start this discussion (if so, I would appreciate being pointed in the right direction).

Background: I contribute to Sandstorm (https://github.com/sandstorm-io/sandstorm), a platform for self-hosting web applications, which as part of its security model wants to prevent applications from "phoning home," giving its users privacy from the apps' developers. There are a few loose ends to tie up before it can actually do that by default, most of which we have a plan for and just need to do the work, but WebRTC presents a vector for leaking information that I don't think we can solve without browser modifications, so I wanted to get a discussion going re: whether we can move the standard in a direction that accommodates our use case.

Per the spec:

https://www.w3.org/TR/webrtc/#privacy-and-security-considerations

...the webrtc threat model assumes it's ok for the page to communicate with whoever it wants -- after all, it can already communicate with the server, so there's not much point in trying to block other connections, as the server could just proxy or the like.

But this runs counter to the Sandstorm model, where the server is running in a sandboxed environment where by default it does not have network access -- and thus cannot relay information to the developer on behalf of the client.

We use Content-Security-Policy to block most other mechanisms for communicating with the outside world from the browser, but as far as I can tell there's no way for a server to tell the browser "don't let this page use RTCPeerConnection." I'd like to propose adding a mechanism along those lines.

Are others open to a mechanism along these lines?

(There are some other things I'd like to see in the API to help make writing Sandstorm apps that actually have use for webrtc features easier, but those should probably be treated as separate issues).

[dontcallmedom]

linking to previous discussions on the topic w3c/webappsec-csp#92 w3c/webappsec-csp#287

[zenhack]

Thanks for the pointers. I commented on the latter, I'll close this in favor of further discussion there.