- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jul 2019 02:48:42 +0000
- To: public-webrtc-logs@w3.org
> > That would further entice developers in calling getUserMedia when they do not have host candidates (for good or bad reasons) since this will be a one-time call. > > It's already a one-time-call in Chrome today, so I think they're sufficiently enticed. 😉 For the prompt yes. To get host candidates, I believe they would need to call getUserMedia each time, which can be visible and very intriguing/creapy to users. > By exposing it, users can at least see what is happening, and even revoke it with the **X** Right, this is an option I like somehow. With the particular UI illustration, it would seem weird though to expose the information and then allow the user to no longer expose it. > > Ideally, we would be able to identify legit uses of RTCPeerConnection. > > Not possible I think. We'll just end up boosting our successful connection numbers. Not to say this would improve much the connection rate, but a connection that is providing content for a large video element visible in a page seems like a legit case. If the connection is using a TURN candidate, there could be room for optimization. > > Or we would identify cases where leaking the host candidate is not a privacy issue. > > That's `getUserMedia`. Once gUM is granted, its fingerprint surface dwarfs 192.168.1.x. IPv6 temporary addresses are cheaper and have less fingerprint risks. If a device could dynamically be assigned to several temporary IPv6 addresses, the risk would further decrease. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2175#issuecomment-509886023 using your GitHub account
Received on Wednesday, 10 July 2019 02:48:45 UTC