Re: Use of getDefaultIceServers

I might be missing some context on the previous brainstorming, sorry if this is a rehash.

One question that comes to mind is whether it is useful for any web app to know the exact list of TURN server URLs.
In particular, do you envision that some web apps would have a list of allowed/disallowed TURN server URLs?

If not, would it be possible to narrow down the decision of the web app to just enable/disable browser provided TURN servers (something like a RTCConfiguration boolean)?
That would reduce the information leakage. ICE candidates would potentially leak some information, this might need some thoughts.

As a side note, step b) might actually depend on the IP handling mode you are in. It would also potentially increase the fingerprinting surface.
 Y


> On Jan 23, 2019, at 10:15 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> 
> 
> So just wanted to put on list a few key things about this 
> 
> 1) the goal here is to allow an app to discover a local TURN server run by enterprises that allows connectivity through the firewall
> 
> 2) the app has no prior relation with the enterprise so it is not like every enterprise can go and configure the address of their TURN server for every WebRTC app that might use this. That would be fine for the huge apps like WebEX but it is a very huge barrier of entry for smaller new apps. That’s not the way to grow an ecosystem.
> 
> How I see this is working is:
> 
> a) The TURN server(s) are configured into the browser via an non specified way. It could be how HTTP proxy gets configured, it could just be the disk, it could have a UI too. 
> 
> b) If the TURN server is usable from the point in the network, the browser reports it in the getDefaultIceServers function
> 
> c) if the apps wants to use it, it passes it back as the browser as one of the TURN servers to use
> 
> We can brainstorm solutions to this but in the past, we did that and came to this. The problem was no good way to all a JS app to auto discover things about the local network. I do think there are many ways to skin this cat and I’m not married to any particular one. 
> 
> An alternative solution was that the browser always use the configured TURN servers and ignore the JS provided ones. This does not work for apps where the app requires a particular TURN server. The TURN server may be embedded into a conference server and you have to use that one on. Or the TURN server may be the way gets in and out of the data center. For whatever reason, some apps only work with their turn servers. I could live without this but when we talked about it before, there seemed to be people that were not happy with the browser changing the TURN servers without interaction with the app. 
> 
> This does add to the fingerprint info - maybe. If the the browser only reports it when it is reachable, then it only gets reported when the browser is inside an enterprise that runs a TURN server. However, the IP address block of the HTTP requests probably reveals the same info in just about ever use case so it’s not clear this does increase the fingerprint. However, this is well worth more discussion. 
> 
> Cisco would like to see this functionality and has said so many time in the past. We are not the only people that have. It is pretty easy to implement in browsers. It may not matter much for apps not used in enterprises. But if web apps fail in an enterprise, then one needs to develop mobile and desktop apps which remove the need to do a web app. 
> 
> 
>

Received on Wednesday, 23 January 2019 18:43:13 UTC