Re: [webrtc-pc] Permission API for receive-only media and data use cases (#2175)

> > 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 using your GitHub account

Received on Wednesday, 10 July 2019 02:48:45 UTC