Re: [webrtc-extensions] Add a CSP check to RTCPeerConnection.addIceCandidate(). (#81)

So, from my perspective, I am more concerned by the additional complexity introduced by trying to do the filtering later in the pipeline than I am exposing the CSP policy to client javascript.

For the former, the failure mode is clear: we miss a place where something needs to be blocked, and so it is possible to exfiltrate data. The negative consequences of leaking this bit of CSP to the client are much less obiviously (to me) terrible, and my instinct is that it isn't worth the extra complexity to make sure the app can't tell the difference between webrtc being disabled and the network being flaky.

To try to keep this moving forward:

@annevk,

1. How strongly do you feel about attempting to emulate failure modes for other network APIs?
2. Are there concrete problems with exposing this bit of CSP, or is it just the general principle of "better to expose less?"

@alvestrand/@jan-ivar/other webrtc people, who are more familiar with the implementations:

* Are there places other than the RTCPeerConnection constructor that seem like good candidates to be the choke point, i.e. places where we could add a single local check to block everything?
* I think the addIceCandidates works from an *API* perspective, but what I'm inferring is that an implementation that avoids doing anything with the network would probably be more complex in this case. Have I understood that correctly, or is this still something that would be relatively simple to implement?

-- 
GitHub Notification of comment by zenhack
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/pull/81#issuecomment-983928461 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 1 December 2021 18:14:01 UTC