Able to reproduce on latest stable 61.0.3163.100, latest canary 63.0.3222.0 using windows 10, Ubuntu 14.04 and Mac 10.12.6 with the steps mentioned in original comment. Attaching screencast of same.

This seems to be a Non-Regression issue seen from M-50[50.0.2624.0]. Hence, marking it as Untriaged

Deleted: 767304.mp4 4.1 MB

	767304.mp4 4.1 MB View Download

Well, we are honoring "disable_non_proxied_udp", since we only connect to the TURN server via TCP. But I'm not sure why it's "disable_non_proxied_udp" instead of just "disable_non_proxied", period.

Digging through the commit history I arrived at https://codereview.chromium.org/1309543004, where I found a comment from pthatcher@ saying "TCP to the relay would go through a proxy". So maybe the code reviewers interpreted a TURN server as proxy (though the word "proxy" doesn't appear in the TURN RFC), and didn't consider the case of a TURN server scraping IP addresses?

Justin or Peter, can you explain? Why would we prevent leaking the public IP address over UDP, but not prevent leaking it over TCP? Or in other words, why did we only implement the UDP half of "mode 4"?

I suppose the thinking may have been "this mode is only valuable to enterprises, who will make sure a proxy is configured. But UDP proxies are rare, so we should disable UDP completely to be safe". I don't really see why we'd take that shortcut though, aside from the fact that it requires slightly less code.

For what it's worth up till Andreas presented me with this problem I considered the wording for mode 4 in the IP handling draft to always refer to TURN servers only. But reading it again I think it talks about HTTP proxies. Which then makes this a bug.

But as several people are apparently confused about what mode 4 in the draft is talking about that section of the draft probably needs clarification.

Re comment 4 and comment 6 it's also unclear whether "disable_non_proxied_udp" follows mode 4 in the rtcweb ip handling spec, or something else.

Documentation for this API would be great so other browsers can interop.

Ping for triaging.

Justin or Peter, can you comment on this? Why did we only implement the UDP half of "Mode 4" in the IP handling spec? See comment 4.

I'll do some archaeology on this Friday.

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.

So disabling UDP in case of the presence of a HTTP proxy to avoid accidental bypassing of the HTTP proxy makes somewhat sense.

The spec doesn't say anything regarding what to do in the absence of a proxy. I would argue that from a privacy perspective it doesn't make sense to try to connect only via TCP to the TURN relay. Because if the TURN relay can't be trusted it doesn't matter if you connect to it via UDP or TCP. And if the TURN relay can be trusted it also doesn't matter if the connection is via UDP or TCP.

To follow the arguments brought up here so far I would request that Chrome turns on UDP relaying when no proxy is set.

Although I think the better fix from a privacy perspective would be to have two API options:
- use TURN relay candidates only
- use HTTP Proxies only
Then it is up to the API user (uBlock) to decide the trust level of the given TURN relays.

One problem is that it isn't super easy to determine whether a proxy is to be used, a priori. Some auto-configuration options decide on a per-destination basis whether to use a proxy.

Agreed that if it is known that a proxy is not set, we should be OK to use UDP (basically, it becomes Mode 3).

Use of TURN relay candidates is pretty much entirely a separate thing from this issue; even if you use relay candidates exclusively, the web application can still learn your local addresses from the TURN and/or HTTP traffic.

In summary, it sounds like the intention of mode 4 is "force use of proxy if one is configured, otherwise fall back to mode 3". So we're working as intended. With the caveat that we fall back to a TCP-only version of mode 3 (for reasons described in comment above).