- From: Danilo Bargen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 Feb 2019 08:46:23 +0000
- To: public-webrtc-logs@w3.org
> And while using mDNS to hide non-default route candidates would likely improve the situation, I'm convinced that we will see _consent_ vs. _no consent_ diverge further. Chrome will apply mDNS only to host candidates of applications that have not requested a getUserMedia permission: https://bugs.chromium.org/p/chromium/issues/detail?id=930339 This is great for media based applications, but confirms your point. There is no equivalent permission request for data channel based applications. Enterprise users of DC-only applications now have the choice between accepting the privacy implications of explicitly giving microphone/camera permissions to an application that does not require microphone or camera, versus accepting the privacy implications of data traffic going through a third party TURN server even though both clients are in the same network. I'm quite convinced that an "allow this application to establish a direct connection" permission request could resolve most of these problems. -- GitHub Notification of comment by dbrgn Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2012#issuecomment-462252761 using your GitHub account
Received on Monday, 11 February 2019 08:46:24 UTC