The relevant section in the spec https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-09#section-5.2

Taking a look.

I think disable_non_proxied_udp is working as intended in WebRTC, but I agree that it doesn't give you mode 3.
Can you check if default_public_interface_only gives you what you want?
That should set the chrome/WebRTC parameters enable_multiple_routes/PORTALLOCATOR_DISABLE_ADAPTER_ENUMERATION and enable_default_local_candidate/PORTALLOCATOR_DISABLE_DEFAULT_LOCAL_CANDIDATE appropriately.

webRTCIPHandlingPolicy enum: https://developer.chrome.com/extensions/privacy#type-IPHandlingPolicy
Config parsing in WebRTC: https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/peer_connection_dependency_factory.cc?type=cs&q=webRTCIPHandlingPolicy+f:webrtc&sq=package:chromium&g=0&l=368
Lower level of config parsing in WebRTC: https://cs.chromium.org/chromium/src/content/renderer/p2p/port_allocator.cc?type=cs&sq=package:chromium&g=0&l=40
Comments for lower level config enums: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/base/portallocator.h?gsn=PORTALLOCATOR_DISABLE_STUN&l=43

Sorry, looking again I see that you want mode 4, not mode 3.
I think this would mean Chromium needs to set disable_non_proxied_udp only if a proxy is configured.
I'm not sure if an extension can do this or not.

https://developer.chrome.com/extensions/proxy might help you implement mode 4 in the extension.

Closing as working as intended, but I opened https://crbug.com/874254 for providing better support in Chromium (so an extension wouldn't have to do the work).

Not sure I follow, isn't webRTCIPHandlingPolicy suppose to follow https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-09#section-5.2
if so, I assumed:
"default_public_and_private_interfaces" - mode 2
"default_public_interface_only" - mode 3
"disable_non_proxied_udp" - mode 4
as they roughly state what those modes mean.

If so, in mode4, if traffic is not going through an http proxy, it should behave like mode3, which suppose to gather srflx candidates but no host candidates.

Still getting up to speed on this myself.

For context, webRTCIPHandlingPolicy was introduced in Chrome 48 (January 2016) and implements an older version of that draft (probably https://tools.ietf.org/html/draft-shieh-rtcweb-ip-handling-00) where mode 4 was "Force TCP and proxy." This is the version the code seems to implement (disable all UDP).

I think it should be fine to have disable_non_proxied_udp correspond to the newer draft's mode 4 (no need for a new option like I suggested in the other issue).

I believe the underlying issue here is that proxying UDP isn't supported in our implementation of WebRTC. The draft says: "If the proxy does not support UDP (as is the case for all HTTP and most SOCKS [RFC1928] proxies), or the WebRTC implementation does not support UDP proxying, the use of UDP will be disabled, and TCP will be used to send and receive media through the proxy." We don't support UDP proxying, so UDP is disabled. I'm guessing no one has implemented this yet because proxies won't support it. I'll open a new issue to track UDP proxying support in Chromium's WebRTC.

Support Proxied UDP Connections in WebRTC: http://crbug.com/874632

nice, what about the fallback to mode3 in case there is no proxy ?

Maybe we still need a new value in webRTCIPHandlingPolicy for that. I'll revisit tomorrow.

I think it should conform to the 4 modes specified in the spec.
The current behavior of "disable_non_proxied_udp" breaks webrtc applications, when the user behind no proxy - without any privacy benefit. 
The user's public ip on the http path can be identified without webrtc - so I don't understand why block the public ip gathering (srflx) from webrtc.

I agree we should have a way to use mode 4. I think we will end up with a new setting for webRTCIPHandlingPolicy, which we will track here: https://crbug.com/874254

Hi! Nils Ohlmeier told me his current understanding of mode 4 is that it should always fall back to mode 3 in case no proxy has been set. Please see the discussion on the IETF mailing list: https://mailarchive.ietf.org/arch/msg/rtcweb/N44due2pcmxK9CCD5BOddnDEB0g

Cheers
Lennart