- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Aug 2021 08:25:06 +0000
- To: public-webrtc-logs@w3.org
> So one other place I think I see to enforce this is the notion of administratively prohibited ice candidates described in the 1.0 spec. This has the advantage over the constructor that its somewhere the spec already allows failure, and it makes it clear how we would extend it to filtering ice candidates, turn servers, etc. Two questions: > > 1. Am I correct in thinkikng that simply treating all candidates as administratively prohibited would effectively stop webrtc from doing anything with the network? > > 2. Do others think this is a good aproach? A word of warning when it comes to filtering: As mentioned way back in https://github.com/w3c/webappsec-csp/pull/287#issuecomment-366446690, more than an on/off switch is more likely to provide a false sense of security than anything else. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/pull/81#issuecomment-901714056 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 August 2021 08:25:08 UTC