1452713 - Update webRTCIPHandlingPolicy to match Chrome behavior

Status: VERIFIED FIXED

(WebExtensions :: Compatibility, enhancement, P2)

Description

[Nils Ohlmeier [:drno]]

It looks like when we implemented initially the "disable_non_proxied_udp" setting for network.webRTCIPHandlingPolicy we guessed how to implement it because of lack of documentation https://bugzilla.mozilla.org/show_bug.cgi?id=1312802#c34

But over time it looks like we have now multiple reports that implementers utilizing this API expect a different, more Chrome like, behavior then what we have implemented. See:

https://github.com/gorhill/uBlock/issues/3009
https://bugzilla.mozilla.org/show_bug.cgi?id=1398228
https://bugzilla.mozilla.org/show_bug.cgi?id=1449531#c5

It looks to me like the right thing to do here is to change our implementation to use "media.peerconnection.ice.relay_only" instead of "media.peerconnection.ice.proxy_only" here:
https://searchfox.org/mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6/toolkit/components/extensions/parent/ext-privacy.js#111

Because that allows usage of WebRTC services which provide a TURN server without revealing any host or router/firewall IP address.
Where the setting we use right now only works in case the browser is configured to use a HTTP proxy (without authentication), and the WebRTC service provides a TURN TCP service.

Comment 1

[Nils Ohlmeier [:drno]]

Attachment: Bug 1452713: use relay_only for disable_non_proxied_udp

Review commit: https://reviewboard.mozilla.org/r/235032/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/235032/

Comment 2

[Nils Ohlmeier [:drno]]

Providing a patch in case people agree that this is right thing to do.

Comment 3

[Byron Campen [:bwc]]

Comment on attachment 8966313 [details]
Bug 1452713: use relay_only for disable_non_proxied_udp

https://reviewboard.mozilla.org/r/235032/#review240694

Comment 4

[Andreas Pehrson [:pehrsons]]

Remembering to test this.

Comment 5

[Andreas Pehrson [:pehrsons]]

Comment on attachment 8966313 [details]
Bug 1452713: use relay_only for disable_non_proxied_udp

https://reviewboard.mozilla.org/r/235032/#review241464

No, this doesn't get us the same behavior as chrome.

I haven't done any real tests yet, but "disable_non_proxied_udp" in chrome would use the proxy iff a proxy is set. If a proxy is not set it would use a more relaxed definition. If that permits only TCP, only relay, or everything is not clear to me atm. In [1] juberti (Google) said this regarding their implementation of "disable_non_proxied_udp":
> The UDP question needs some more digging, but the TCP behavior is WAI. The idea for Mode 4 was to force TURN traffic to take the same path as HTTPS traffic, even if it means using TCP and going through a proxy. But if there is no proxy, then it just turns into direct TCP, same as for HTTPS.

With this change we'd allow TURN with a proxy set, no? That would be wrong and would leak the public ip address since the TURN server is owned by the application.


[1] https://bugs.chromium.org/p/chromium/issues/detail?id=767304

Comment 6

[Nils Ohlmeier [:drno]]

(In reply to Andreas Pehrson [:pehrsons] from comment #5)
> Comment on attachment 8966313 [details]
> Bug 1452713: use relay_only for disable_non_proxied_udp
> 
> https://reviewboard.mozilla.org/r/235032/#review241464
> 
> No, this doesn't get us the same behavior as chrome.
> 
> I haven't done any real tests yet, but "disable_non_proxied_udp" in chrome
> would use the proxy iff a proxy is set. If a proxy is not set it would use a
> more relaxed definition. If that permits only TCP, only relay, or everything
> is not clear to me atm. In [1] juberti (Google) said this regarding their
> implementation of "disable_non_proxied_udp":
> > The UDP question needs some more digging, but the TCP behavior is WAI. The idea for Mode 4 was to force TURN traffic to take the same path as HTTPS traffic, even if it means using TCP and going through a proxy. But if there is no proxy, then it just turns into direct TCP, same as for HTTPS.
> 
> With this change we'd allow TURN with a proxy set, no? That would be wrong
> and would leak the public ip address since the TURN server is owned by the
> application.

Lets start with: Firefox always uses HTTP proxies if a HTTP proxy is configured.

With this change the expected behavior in Firefox would be:
- with no HTTP proxy set
  - with no TURN server available no candidates are given out
  - if the website provides a TURN relay give out the relay candidates
- with a HTTP proxy configured in Firefox
  - since we don't support ICE TCP through proxies no candidates are given out if no TURN server is available
  - only a if a TURN TCP relay is configured it would connect through the HTTP Proxy to the TURN server and give out the relay candidates

In other words:

With the current code Firefox only ever connects if a HTTP Proxy is configured AND the page offer a TURN TCP relay.

With the new patch it does the same if a HTTP Proxy is configured, but also only uses the TURN relay via UDP or TCP if no HTTP proxy is configured.

How can we make this work more like Chrome if we don't even know how this API affects Chrome's behavior?

Comment 7

[Andreas Pehrson [:pehrsons]]

(In reply to Nils Ohlmeier [:drno] from comment #6)
> (In reply to Andreas Pehrson [:pehrsons] from comment #5)
> > Comment on attachment 8966313 [details]
> > Bug 1452713: use relay_only for disable_non_proxied_udp
> > 
> > https://reviewboard.mozilla.org/r/235032/#review241464
> > 
> > No, this doesn't get us the same behavior as chrome.
> > 
> > I haven't done any real tests yet, but "disable_non_proxied_udp" in chrome
> > would use the proxy iff a proxy is set. If a proxy is not set it would use a
> > more relaxed definition. If that permits only TCP, only relay, or everything
> > is not clear to me atm. In [1] juberti (Google) said this regarding their
> > implementation of "disable_non_proxied_udp":
> > > The UDP question needs some more digging, but the TCP behavior is WAI. The idea for Mode 4 was to force TURN traffic to take the same path as HTTPS traffic, even if it means using TCP and going through a proxy. But if there is no proxy, then it just turns into direct TCP, same as for HTTPS.
> > 
> > With this change we'd allow TURN with a proxy set, no? That would be wrong
> > and would leak the public ip address since the TURN server is owned by the
> > application.
> 
> Lets start with: Firefox always uses HTTP proxies if a HTTP proxy is
> configured.
> 
> With this change the expected behavior in Firefox would be:
> - with no HTTP proxy set
>   - with no TURN server available no candidates are given out
>   - if the website provides a TURN relay give out the relay candidates
> - with a HTTP proxy configured in Firefox
>   - since we don't support ICE TCP through proxies no candidates are given
> out if no TURN server is available
>   - only a if a TURN TCP relay is configured it would connect through the
> HTTP Proxy to the TURN server and give out the relay candidates
> 
> In other words:
> 
> With the current code Firefox only ever connects if a HTTP Proxy is
> configured AND the page offer a TURN TCP relay.
> 
> With the new patch it does the same if a HTTP Proxy is configured, but also
> only uses the TURN relay via UDP or TCP if no HTTP proxy is configured.
> 
> How can we make this work more like Chrome if we don't even know how this
> API affects Chrome's behavior?

My testing of "media.peerconnection.ice.relay_only" in Firefox vs "disable_non_proxied_udp" in chrome (through uBlock Origin) gives some differences:
- HTTP proxy set AND protection enabled:
  - Firefox gathers relayed-udp (selected), relayed-tcp (nominated) (though the relayed-tcp candidate does not show as added in chrome://webrtc-internals)
  - Chrome gathers relayed-tcp (selected) (chrome://webrtc-internals also shows a relayed-tls candidate, but it's not in about:webrtc)
- HTTP proxy NOT set AND protection enabled:
  - Firefox gathers relayed-udp (selected), relayed-tcp (nominated), relayed-tls (nominated)
  - Chrome gathers relayed-tcp (nominated), relayed-tls (selected - shows in about:webrtc as prflx)


From the name alone, I don't think we can get away with allowing non-proxied udp while "disable_non_proxied_udp" is enabled.

Comment 8

[Nils Ohlmeier [:drno]]

After chatting with bwc about this I think our conclusion is that the Chrome implementation is broken. Because they seem to gather TURN TCP, but block TURN UDP independent of a HTTP proxy being configured or not. From a privacy perspective that makes no sense, because if you assume the TURN server is owned by the person who wants to learn your IP address TURN over TCP (not through the HTTP Proxy) will still give away your public IP address.

So I think we have two choices here:

#1 Since Chrome still gives away TURN relay candidates we can lower Firefox implementation onto the same level, with the difference that we would also allow TURN UDP in that case. That is what this patch does. It results in people with Firefox and uBlock still being able to use most WebRTC service. And since most evil people don't provide TURN servers yet it might be acceptable.

#2 We insist that Chromes behavior is broken in that they allow TURN TCP to succeed with no Proxy available. Then we leave our implementation as is and keep telling people who complain about Firefox behavior with uBlock, that Chrome in fact is broken.

I think the really solution would be to extend the privacy extension API to have one value which allows TURN in general and another value which allows connections through HTTP proxies only. But I'm not sure how to accomplish this.

Comment 9

[Shane Caraveo (:mixedpuppy)]

cc/mconca

(In reply to Nils Ohlmeier [:drno] from comment #8)

> I think the really solution would be to extend the privacy extension API to
> have one value which allows TURN in general and another value which allows
> connections through HTTP proxies only. But I'm not sure how to accomplish
> this.

We can handle the webextension api from our side if support for the options exist.

From the webextension side of things...

- It would be preferable to be compatible with chrome so long as we're not sacrificing security or privacy in any detrimental fashion.
- If the difference between chrome and firefox is important to address, but it will expose minor security or privacy issues that we are willing to live with, we could consider a notification to the user when that happens.
- If we cannot be compatible and do not want to make a change, we can remove the chrome option and document it, possibly adding a new option to do what we currently do if that is useful.

Mike, any opinion here?

Comment 10

[Nils Ohlmeier [:drno]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #9)
> We can handle the webextension api from our side if support for the options
> exist.
> 
> From the webextension side of things...
> 
> - It would be preferable to be compatible with chrome so long as we're not
> sacrificing security or privacy in any detrimental fashion.
> - If the difference between chrome and firefox is important to address, but
> it will expose minor security or privacy issues that we are willing to live
> with, we could consider a notification to the user when that happens.
> - If we cannot be compatible and do not want to make a change, we can remove
> the chrome option and document it, possibly adding a new option to do what
> we currently do if that is useful.

So then option #3 might be then that we add another value, something like 'relayed_only', which we set to our internal media.peerconnection.ice.relay_only option. That new option should allow people to use WebRTC calling services. And we leave the 'disable_non_proxied_udp' option untouched and say it's more strict then Chromes implementation.

Would it make sense to even add another value 'http_proxy_only', with the same setting as 'disable_non_proxied_udp' for now. And meanwhile try to convince the Chrome guys to drop this confusingly named option 'disable_non_proxied_udp' and adapt our new values?

Comment 11

[Andreas Pehrson [:pehrsons]]

(In reply to Nils Ohlmeier [:drno] from comment #8)
> After chatting with bwc about this I think our conclusion is that the Chrome
> implementation is broken. Because they seem to gather TURN TCP, but block
> TURN UDP independent of a HTTP proxy being configured or not. From a privacy
> perspective that makes no sense, because if you assume the TURN server is
> owned by the person who wants to learn your IP address TURN over TCP (not
> through the HTTP Proxy) will still give away your public IP address.

Should we fix this in the ip-handling spec [1]? 
If we're going to add more modes for extensions, won't that boil down to updating [1] accordingly too?

It seems to me that "disable_non_proxied_udp" is intended to map to "Mode 4", which reads like this in the spec:
> Force proxy: This forces all WebRTC media traffic through a
> proxy, if one is configured.  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.  Use of
> TCP will result in reduced quality, in addition to any
> performance considerations associated with sending all
> WebRTC media through the proxy server.


Mode 4 leaves a big hole on what is expected when a proxy is not configured though, so we could do something more permissive than we do today and still be compliant.

The chrome intention for that state seems to be to follow https traffic, though they haven't explained why they disable UDP. [2]

If we had a mode that acted like "media.peerconnection.ice.proxy_only" when a proxy is set and "media.peerconnection.ice.relay_only" when a proxy is not set, it seems to me like we'd have something compliant to [1] while still being functional with uBlock Origin [3], [4].

I'd also like to point out that #1 in comment 8 is not exactly what the current patch here achieves, as comment 7 indicates it will let UDP traffic (at least) bypass the proxy.

Nils, thoughts?


[1] https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=767304#c11
[3] https://github.com/gorhill/uBlock/issues/3009
[4] bug 1398228

Comment 12

[Nils Ohlmeier [:drno]]

I think you are right, that the spec is less then clear for this use case.

The problem is that the IETF process on this spec is already past the point of making big changes. But I gave it a try https://mailarchive.ietf.org/arch/msg/rtcweb/sPUVPTI8-pe_quI7AdRi--72cdY

Interesting is that Justin here https://bugs.chromium.org/p/chromium/issues/detail?id=767304#c13 just admitted that if no HTTP proxy is configured TURN should be used via UDP or TCP. So that would be our relay only mode.

So then the problem boils down to:
- if a proxy is configured use proxy_only mode
- if no proxy is configured use relay_only mode

Problem is we don't a way to support that as of right now, or Byron?

Comment 13

[Mike Conca [:mconca]]

I absolutely do not want to do anything counter to the Mozilla mission. If the way Firefox has implemented this is "correct" from a security/privacy point-of-view, then that is how we should proceed. The incompatibility with Chrome should be documented on MDN, and I think a bug should be filed with Chromium.

I do like the idea of adding more modes for extensions that give developers more flexibility, but (again) this should only be done in ways that preserve user security and privacy. I'm sounding a bit dogmatic about this, but user privacy is a cornerstone of the Mozilla mission and the Firefox product. Bending, even a bit, in order to maintain compatibility with a market leader doesn't feel right.

Comment 14

[Byron Campen [:bwc]]

(In reply to Nils Ohlmeier [:drno] from comment #12)
> I think you are right, that the spec is less then clear for this use case.
> 
> The problem is that the IETF process on this spec is already past the point
> of making big changes. But I gave it a try
> https://mailarchive.ietf.org/arch/msg/rtcweb/sPUVPTI8-pe_quI7AdRi--72cdY
> 
> Interesting is that Justin here
> https://bugs.chromium.org/p/chromium/issues/detail?id=767304#c13 just
> admitted that if no HTTP proxy is configured TURN should be used via UDP or
> TCP. So that would be our relay only mode.
> 
> So then the problem boils down to:
> - if a proxy is configured use proxy_only mode
> - if no proxy is configured use relay_only mode
> 
> Problem is we don't a way to support that as of right now, or Byron?

   There's no pref for that, no. We would need to make some code changes to support that.

Comment 15

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8966313 [details]
Bug 1452713: use relay_only for disable_non_proxied_udp

use someone on the team for webext reviews, I'm fine doing that part.

Comment 16

[Nils Ohlmeier [:drno]]

I don't have the capacity any more to work on this any time soon.

Comment 18

[Ryan Alderete]

Attachment: Bug 1452713 - Update webRTCIPHandlingPolicy to match Chrome

Previously, the network.webRTCIPHandlingPolicy "disable_non_proxied_udp" only
enabled the use of WebRTC if a proxy was configured and the WebRTC service
supported TURN TCP.

This aims to match Chrome's behavior by forcing the use of a proxy if one is
configured, otherwise falling back to mode 3 (default route only).

Comment 19

[Shane Caraveo (:mixedpuppy)]

This will need a doc change on the webextension privacy api page.

This should probably also be release noted somehow for extension devs, perhaps also as a part of a blog update? (@Fallen)

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/57b8410f0239
Update webRTCIPHandlingPolicy to match Chrome r=bwc,mixedpuppy

Comment 21

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/57b8410f0239

Comment 22

[Alex Cornestean]

Hello,

Will this fix require manual validation? If yes, please provide some steps to reproduce in order to correctly test it and also, please set the "qe-verify+" flag. Otherwise, could the "qe-verify-" flag be added? Thanks!

Comment 23

[Ryan Alderete]

Yes, this will likely require manual validation.

Prior to this fix, the "disable_non_proxied_udp" API setting for "network.webRTCIPHandlingPolicy" (equivalent to setting the "media.peerconnection.ice.proxy_only" preference to true) would only allow WebRTC if the user had a proxy configured AND the web application provided a TURN server.

After this fix, "disable_non_proxied_udp" (now equivalent to turning on the preferences "media.peerconnection.ice.default_address_only", "media.peerconnection.ice.no_host", and "media.peerconnection.ice.proxy_only_if_behind_proxy") should offer the same level of WebRTC functionality as the API setting "default_public_interface_only" when the user does not have a proxy configured. The case where a proxy is configured does not change.

The added "proxy_only" API setting offers the same behavior as the old "disable_non_proxied_udp" API setting.

The exact behavior can be validated using something like the Trickle ICE test page (https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) to verify that the same types of candidates are gathered for each API setting/preference configuration that is supposed to produce equivalent results.

If verifying functional equivalency to Chrome is all that is desired, then use one of the WebRTC samples to ensure that WebRTC can still be used when the "disable_non_proxied_udp" API setting is on and (1) no proxy is configured, (2) no TURN server is provided by the application, or (1) and (2).

Comment 24

[Miruna Curtean]

Attachment: No candidates and TURN server broken.gif

First of all it should be noted that the way we've tested the "proxy configured" requirement in order to try and reproduce the issue was through using the FireX Proxy extension (https://addons.mozilla.org/en-US/firefox/addon/firex-proxy/?src=search).
Knowing that, we tried on Firefox 69.0a1 /20190703162038 to set the "media.peerconnection.ice.proxy_only" preference to true, the proxy applied to one foreign country and used the https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ site.
Over there we added a Turn server (url: 'turn:numb.viagenie.ca',
credential: 'muazkh',username: '[e-mail]') and clicked on the "Gather candidates" button while also watching the results in the console.
No candidates were found and the following error message was received "ICE failed, your TURN server appears to be broken, see about:webrtc for more details" when trying to test with 4 more Turn server addresses.
This message is in fact received all the time as long as the preference is turned on.

On Firefox 70.0a1/ 20190901094958, after turning on the preferences ("media.peerconnection.ice.default_address_only", "media.peerconnection.ice.no_host", and "media.peerconnection.ice.proxy_only_if_behind_proxy") with no proxy configured and no Turn server added, we did not receive any candidates.
Console output was the following:
Creating new PeerConnection with config={"iceServers":[{"urls":["stun:l.google.com:19302"],"username":"","credential":""}],"iceTransportPolicy":"all","iceCandidatePoolSize":"0"}
Again, no candidates even after addding a TURN server, with or without adding a proxy through the extension- see console output.
Creating new PeerConnection with config={"iceServers":[{"urls":["stun:l.google.com:19302"],"username":"","credential":""},{"urls":["turn:13.250.13.83:3478?transport=udp"],"username":"YzYNCouZM1mhqhmseWk6","credential":"YzYNCouZM1mhqhmseWk6"}],"iceTransportPolicy":"all","iceCandidatePoolSize":"0"}
All in all, we can't confirm that the results are equivalent, since on FF69 an error is received, but on FF70 no candidates are found when testing.
Could it be that we're doing something wrong and if so, could you give us a step by step method of testing?
thank you

Comment 25

[Ryan Alderete]

Your method seems mostly correct; I just have a few observations.

TURN requests are going to be sent over UDP unless the TURN server has been configured to use TCP. The "proxy_only" preference essentially disables the use of UDP, so that can explain the error that is received in that case. I'm not entirely sure where Firefox is when it comes to sending TURN-TCP through an HTTP proxy. This patch wasn't meant to change the behavior of the "proxy_only" preference at all, so my interpretation of it may not be entirely correct.

I'm unable to reproduce what happened to you with the preferences ("media.peerconnection.ice.default_address_only", "media.peerconnection.ice.no_host", and "media.peerconnection.ice.proxy_only_if_behind_proxy") turned on. Is it possible that the "media.peerconnection.ice.proxy_only" preference was also turned on? That preference is the stricter one and would override the others. With those 3 preferences enabled, the "proxy_only" one disabled, and the Google STUN server left in, I would expect the following:

no proxy + no TURN:    srflx
proxy + no TURN:    same as "proxy_only" + proxy + no TURN  *
no proxy + TURN:    srflx, relay
proxy + TURN:    same as "proxy_only" + proxy + TURN  *

* With how your TURN server is configured, you might get the error here

Let me know if you have more questions.

Comment 26

[Alex Cornestean]

Hello,

Based on the information you have provided, we have set up the testing environment in the following way:

• media.peerconnection.ice.default_address_only, media.peerconnection.ice.no_host and media.peerconnection.ice.proxy_only_if_behind_proxy were turned ON
• media.peerconnection.ice.proxy_only was made sure to be turned OFF
• FireX Proxy extension (https://addons.mozilla.org/en-US/firefox/addon/firex-proxy/?src=search) has been installed
• the Google STUN server was left in throughout all tests carried out via https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
• 3 TURN servers were used to carry out the tests:

• url: turn:numb.viagenie.ca / credential: muazkh / username: [e-mail]
• url: turn:192.158.29.39:3478?transport=udp / credential: JZEOEt2V3Qb0y27GRntt2u2PAYA= / username: 28224511:1379330808
• url: turn:192.158.29.39:3478?transport=tcp / credential: JZEOEt2V3Qb0y27GRntt2u2PAYA= / username: 28224511:1379330808

These are the results we have obtained per use of TURN servers:

Via turn:numb.viagenie.ca :

no proxy + no TURN → only srflx
no proxy + TURN → srflx + relay
proxy + no TURN → “ICE failed, add a TURN server and see about:webrtc for more details” error in console + no candidates were gathered
proxy+ TURN → “ICE failed, your TURN server appears to be broken, see about:webrtc for more details” error in console + no candidates were gathered

Via turn:192.158.29.39:3478?transport=udp :

no proxy + no TURN → only srflx
no proxy + TURN → only srflx
proxy + no TURN → “ICE failed, add a TURN server and see about:webrtc for more details” error in console + no candidates were gathered
proxy + TURN →”ICE failed, your TURN server appears to be broken, see about:webrtc for more details” error in console + no candidates were gathered

Via turn:192.158.29.39:3478?transport=tcp :

no proxy + no TURN → only srflx
no proxy + TURN → only srflx
proxy + no TURN → “ICE failed, add a TURN server and see about:webrtc for more details” error in console + no candidates were gathered
proxy + TURN → no candidates were gathered

While media.peerconnection.ice.proxy_only IS ACTIVE:

no proxy + no TURN → “ICE failed, add a TURN server and see about:webrtc for more details” in console + no candidates were gathered

no proxy + TURN (UDP) →”ICE failed, your TURN server appears to be broken, see about:webrtc for more details” error in console + no candidates were gathered
proxy + TURN (UDP) → “ICE failed, your TURN server appears to be broken, see about:webrtc for more details” error in console + no candidates were gathered
proxy + no TURN (UDP) → ”ICE failed, add a TURN server and see about:webrtc for more details” error in console + no candidates were gathered

no proxy + TURN (TCP) → ”ICE failed, your TURN server appears to be broken, see about:webrtc for more details” error in console + no candidates were gathered
proxy + TURN (TCP) → no errors, but no candidates were gathered
proxy + no TURN (TCP) → ”ICE failed, add a TURN server and see about:webrtc for more details” error in console + no candidates were gathered

The tests were performed on the latest Nightly version (71.0a1 / 20190909214621) under Windows 10 Pro 64-bit and macOS High Sierra 10.13.6.

Please let us know whether these results are correct/expected under the circumstances mentioned above. Thanks !

Comment 27

[Ryan Alderete]

Yes, those results appear consistent with my expectations for each of the given circumstances.

Comment 28

[Alex Cornestean]

Hello,

Thanks Ryan ! Based on your comment above, closing the issue as Verified Fixed.

Comment 29

[Philipp Kewisch [:Fallen][📱📆]]

I'm going to need some help figuring out how to document this, but I'm happy to mention it!

Comment 30

[Eric Shepherd [:sheppy]]

I have documentation updates in flight; I've added the new flag to the list on the page for privacy.network and hope to add actual explanations for each of the values shortly after checking on a couple things; that's not part of this issue directly so I'm clearing the DDN status.

I've also got a BCD update that adds a note about the change in Firefox 70.

Comment 31

[Eric Shepherd [:sheppy]]

I will ask here, though, if anyone could help me clarify my understanding of the permitted values for this setting. Finding actual explanations has been impossible; everything is just conversions of one obscure constant name to another from library to library. :D

I think I'm close to getting these right but could really use confirmations and corrections before I add descriptions to the docs. My current best guesses are:

default - Everything is handled the browser's default way

default_public_and_private_interfaces - if the device has multiple interfaces, use only the default ones; no proxy required; both public and private interfaces allowed

--> Question: I think "private interface" here means a host interface, but I could be wrong, in which case what does it mean? VPN? An interface that can't be pinged?

default_public_interface_only - same as default_public_and_private_interfaces but no host interfaces allowed

disable_non_proxied_udp - same as default_public_interface_only but also requires the use of a proxy if the UA has one configured

proxy_only - only proxied connections are permitted (requires TURN on TCP)

Let me know where I'm wrong here; would like to be sure this information is included in the docs instead of just a simple list of these flags.

Comment 32

[Andreas Pehrson [:pehrsons]]

(In reply to Eric Shepherd [:sheppy] from comment #31)

I will ask here, though, if anyone could help me clarify my understanding of the permitted values for this setting. Finding actual explanations has been impossible; everything is just conversions of one obscure constant name to another from library to library. :D

I think I'm close to getting these right but could really use confirmations and corrections before I add descriptions to the docs. My current best guesses are:

default - Everything is handled the browser's default way

default_public_and_private_interfaces - if the device has multiple interfaces, use only the default ones; no proxy required; both public and private interfaces allowed

--> Question: I think "private interface" here means a host interface, but I could be wrong, in which case what does it mean? VPN? An interface that can't be pinged?

default_public_interface_only - same as default_public_and_private_interfaces but no host interfaces allowed

disable_non_proxied_udp - same as default_public_interface_only but also requires the use of a proxy if the UA has one configured

proxy_only - only proxied connections are permitted (requires TURN on TCP)

Let me know where I'm wrong here; would like to be sure this information is included in the docs instead of just a simple list of these flags.

The canonical explanation of these modes is in ietf-rtcweb-ip-handling. default, default_public_and_private_interfaces, default_public_interface_only and disable_non_proxied_udp map to mode 1, mode 2, mode 3 and mode 4, respectively.

proxy_only is our old version of mode 4, prior to this bug, that was not entirely up to spec in that it disallows any peer connection from connecting if a proxy is not set. There's still some value in this mode, since it's the only mode that guarantees that no ip addresses leak to remote peer or application, regardless of other settings (proxy).

Not sure if you read all bugmail, so setting needinfo as an FYI.