The solution would be to allow network enumeration when the user has granted screen capture permission. Justin, is there any reason not to do this?

For client-side remoting, we cannot ask the user for camera, mic, or screen-capture permissions. The client is accessing the audio/video of a *remote* machine, which is *not* the machine they are running Chrome on.
If extra user permissions are needed to get a higher quality of network service (as per section 5.2 of https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-07), then I think it should be a separate permission grant than camera/mic/screen-share.

Relying on "media" permissions to assume a level of trust to access "network enumeration" would not work for client-side Chromoting.

Host-side Chromoting is a different problem. In that case, Chromoting already has complete permission to "access the machine and all websites", via the installed Chrome extension, Native Messaging, and the installed host software. However, I don't see how to propagate those existing permissions into the web-site, unless we could somehow do this in the extension's manifest.json ?

> The client is accessing the audio/video of a *remote* machine, which is *not* the machine they are running Chrome on.

Right, I don't know what I was thinking.

In that case I don't think there's anything we can do, since we need some form of user consent, and having an independent network enumeration permission dialog isn't really an option since it would be hard for users to understand. At least, that's the conclusion we've come to in the past.

There's something I still don't understand. The actual "enumeration" of the networks still happens today. The only thing that's missing is the type of each interface (LAN/WiFi/VPN/...), and therefore the associated network-cost. I'm still not certain of the precise impact of each interface having the same cost.
My concern now is that, if the "network enumeration" permission were actually implemented as its name suggests, it will literally prevent the enumeration of networks. The machine will appear to have only 1 interface - the default one. This would completely break Chromoting if, say, the host were running on a separate VPN, but the website were being accessed on the default interface.

> The actual "enumeration" of the networks still happens today. The only thing that's missing is the type of each interface (LAN/WiFi/VPN/...), and therefore the associated network-cost.

I don't think that's accurate. If enumeration is disabled (due to lack of mic/camera permission), we will only bind sockets to ::/0.0.0.0: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/client/basicportallocator.cc?l=643&rcl=ef75ebef55207d770bc3712004e0680e0fe261f2

We do surface an ICE candidate with the "default" address which we expect to be used, from connecting a socket to 8.8.8.8:53 and seeing what getsockname returns: https://cs.chromium.org/chromium/src/content/browser/renderer_host/p2p/socket_dispatcher_host.cc?l=390&rcl=f2bcdd989cec695add8d1b0414005136d62dbc06

But this doesn't mean it's 100% guaranteed to use that address.

> The machine will appear to have only 1 interface - the default one. This would completely break Chromoting if, say, the host were running on a separate VPN, but the website were being accessed on the default interface.

No? If we bind a socket to ::/0.0.0.0, we'll end up relying on the OS to choose an interface, which may be either the physical interface or the VPN.

> I don't think that's accurate. If enumeration is disabled (due to lack of mic/camera permission), we will only bind sockets to ::/0.0.0.0

But we are still exposing the machine's IP addresses in the candidates that the client sends to the host via signaling, aren't we? When I gather candidates, I see IP addresses in there. For example, if I visit https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
and hit the "Gather candidates" button, I see 3 realistic-looking IP addresses appear on the page (from 2 "host" and 1 "srflx" candidate). At least one of these addresses would be extra information that the web-site doesn't already know (assuming the web-site only knows 1 IP address for the client).

Does this mean that these 3 IP addresses are all coming from the same "default" network interface?
And the camera/mic permission exposes IP addresses from non-default interfaces in addition to the default one?
And, if I were connecting to the web-site over a non-default interface, the IP addresses from ICE gathering would be obtained over a different (default) interface, and so all the IP addresses would be new information?

> If we bind a socket to ::/0.0.0.0, we'll end up relying on the OS to choose an interface, which may be either the physical interface or the VPN.

So, when we gather ICE candidates, Chrome uses the default interface. And when we bind to 0.0.0.0, we expect the OS to choose the same interface? If the VPN is not the default interface, and the Chromoting host is only running on that VPN, it sounds like this would fail? Similarly, if the VPN is the default interface, and Chromoting host was running on a different network, the connection would also fail?

It sounds like the impact of this bug is more than just the incorrect network-cost parameters. All of the non-default interfaces are completely unavailable?

> Does this mean that these 3 IP addresses are all coming from the same "default" network interface?

They all come from binding a socket to ::/0.0.0.0 if that's what you mean. The "host" addresses come from connecting a socket to a well known address (like 8.8.8.8:53) and seeing what getsockname returns. The "srflx" addresses come from sending a request to a STUN server.

> And the camera/mic permission exposes IP addresses from non-default interfaces in addition to the default one?

Yes.

> And, if I were connecting to the web-site over a non-default interface, the IP addresses from ICE gathering would be obtained over a different (default) interface, and so all the IP addresses would be new information?

Yes, though I'd expect that to be rare.

> So, when we gather ICE candidates, Chrome uses the default interface. And when we bind to 0.0.0.0, we expect the OS to choose the same interface?

I don't follow this question; do my answers above clear this up?

> If the VPN is not the default interface, and the Chromoting host is only running on that VPN, it sounds like this would fail?

Not if the Chromoting host exposes its address on the VPN (and signals it to the client, who calls addIceCandidate), meaning the client would be able to send packets to it from its socket bound to ::/0.0.0.0, following the OS's routing rules.

> It sounds like the impact of this bug is more than just the incorrect network-cost parameters. All of the non-default interfaces are completely unavailable?

Not necessarily. See above.


Anyway, can we close this as WontFix? As mentioned in comment 5, we need some form of user consent, but have decided against having an explicit "IP address permission" dialog, so unless that decision changes there's not much we can do.

Thank you for the explanations, very helpful!
It seems there must be *some* impact, but I don't see any unbiased way of measuring what that would be for Chromoting.
We can close this as works-as-designed for now, but we will need to assess the user impact on Chromoting and potentially other use-cases.

Sounds good. To assess the impact, do you have a way to run an experiment and gather statistics for the plugin? If so, you could conditionally call "set_enumeration_permission(ENUMERATION_BLOCKED)" when constructing the plugin's "PepperNetworkManager" and measure how that impacts the success rate.

I have tried calling set_enumeration_permission(ENUMERATION_BLOCKED) inside PepperNetworkManager's ctor, but it still manages to enumerate the networks anyway - confirmed by logging the name of each network in PepperNetworkManager::OnNetworkList(). Maybe there is some other way of simulating a blocked enumeration in the app?

I think this could be because PepperNetworkManager is just a wrapper around the PPB_NetworkMonitor API. The actual enumeration happens inside the Chrome process, and is controlled by the network permissions in the app's manifest. I don't see any easy way to replicate the behavior of a "blocked" app from an app that actually has the enumeration permission in its manifest.