Open Bug 1783489 Opened 2 years ago Updated 26 days ago

Implement CSP 'webrtc' directive


(Core :: DOM: Security, enhancement, P3)





(Reporter: bugzilla, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [domsecurity-backlog1])

CSP3 now has a "webrtc" directive. It accepts the values 'allow' and `'block'. This is particularly useful since WebRTC doesn't go through Fetch.

The "webrtc" directive was added in April.


Blocks: CSP
Blocks: csp-w3c-3
No longer blocks: CSP
Severity: -- → S3
Priority: -- → P3
Whiteboard: [domsecurity-backlog2]
Ever confirmed: true
Whiteboard: [domsecurity-backlog2] → [domsecurity-backlog1]

We need this in Peergos to enable us to run untrusted web apps over private data, without the possibility of the app stealing the data.

We describe the use case more and link related browser issues here:

See also github issue The editor's draft includes several features that no one has shipped, which doesn't have a clear decision on removing webrtc, but dveditz commented positively.

Even after this is fixed, there would probably still be ways of exfiltrating data. E.g. I am not sure if WebTransport couldn't be used just like WebRTC. (Edit: Seems like WebTransport is covered by connect-src)

CSP never had the stated goal of preventing exfiltration. In fact, there are known exfiltration mechanisms that CSP will not be able to stop, regardless of the browser. Even Chrome plans to remove navigate-to (or maybe they already unshipped?).

That being said, I think this is a laudable goal and there's value in exploring corner cases & bypasses in order for us to make a better attempt at taking this into consideration for future standard work. But so far, it shouldn't be expected to be reliable.

Aside: I know most requests in web specifications are based on the fetch concept and could likely be prevented with a ServiceWorker but Shift+Reload bypasses it and navigations are never in scope of a ServiceWorker.

I think it depends on the threat model assumed. In our design the untrusted web app is served from a service worker on a sandboxed iframe on an isolated subdomain (it is E2E encrypted, so it's decrypted in an outer trusted context and passed to the ServiceWorker to serve). As far as I'm aware the dns-prefetch and webrtc are the only current exfiltration avenues. Our design is explained more here:

If there are other exfiltration avenues then I am of course very interested.

Another app, Deltachat, has come up with various ways to try and disable webrtc manually:

You need to log in before you can comment on or make changes to this bug.