Subject: [rtcweb] Security implications of host candidates

From: Justin Uberti <[email-masked]>
Date: Mon, 2 Jul 2018 16:01:24 -0700

https://tools.ietf.org/html/draft-mdns-ice-candidates-00 has a section
where it talks about the privacy implications of being able to determine
that two browser contexts are running on the same machine by making a
host-host connection and analyzing the connection RTT:

   A successful WebRTC connection between two peers is also a potential
   thread to user privacy.  When a WebRTC connection latency is close to
   zero, the probability is high that the two peers are running on the
   same device.  Browsers often isolate contexts one from the other.
   Private browsing mode contexts usually do not share any information
   with regular browsing contexts.  The WebKit engine isolates third-
   party iframes in various ways (cookies, ITP) to prevent user
   tracking.  Enabling a web application to determine that two contexts
   run in the same device would defeat some of the protections provided
   by modern browsers.

I would think that this concern would still exist even without host
candidates, through either

a) IP matching + user-agent fingerprinting

b) srflx-srflx connections and NAT hairpinning

FWIW, this topic does not appear to be noted in the rtcweb security docs.

---

From: youenn fablet <[email-masked]>
Date: Mon, 2 Jul 2018 17:05:07 -0700

Le lun. 2 juil. 2018 à 16:04, Justin Uberti <juberti=
[email-masked]> a écrit :

> I would think that this concern would still exist even without host candidates, through either
>
It is true that one can probably try breaking this protection using
fingerprinting, and public IP is a great way to converge more quickly.
That said, this is something we should try to fight against.

Aren't the packets supposed to go through the router? In such a case, I
would hope the latency to be roughly the same, no matter whether the
devices are the same or not. That is indeed something that should be tested.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 2 Jul 2018 17:32:35 -0700

> devices are the same or not. That is indeed something that should be tested.

Maybe I don't understand the attack well enough, but if a page running in a
private browsing context tried to communicate with a page not running in a
private browsing context, they would probably see < 1ms RTTs for both
host-host and srflx-srflx candidates in many cases (including cases where
the contexts are on different machines).

---

From: youenn fablet <[email-masked]>
Date: Tue, 3 Jul 2018 09:21:22 -0700

>
> Maybe I don't understand the attack well enough, but if a page running in
> a private browsing context tried to communicate with a page not running in
> a private browsing context, they would probably see < 1ms RTTs for both

This is probably true for good ethernet connections.
Connections over wifi have usually a bigger/less stable latency than local
loop connections.
I uploaded a small example (
https://evening-thicket-98446.herokuapp.com/src/content/peerconnection/datachannel-b2b/)
that computes ping-pong host-host latency through data channel.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 3 Jul 2018 11:16:38 -0700

I wasn't able to get that example to work (tried with 2 Chrome and 2 Safari
instances, got a setRemoteDescription error both times), but I was able to
make a JSFiddle <https://jsfiddle.net/juberti/x7a8ut0q/25/> which does
something similar in a single page. At present, even host-host connections
were seeing a 2 ms RTT, possibly because of the clamping
<https://developer.mozilla.org/en-US/docs/Web/API/Performance/now> that has
been applied to performance.now() to deal with Spectre et al.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 3 Jul 2018 14:40:31 -0700

Updated fiddle (outputs to display as well as console):
https://jsfiddle.net/juberti/x7a8ut0q/37/

On Tue, Jul 3, 2018 at 11:16 AM Justin Uberti <[email-masked]> wrote:

> I wasn't able to get that example to work (tried with 2 Chrome and 2
> Safari instances, got a setRemoteDescription error both times), but I was
> able to make a JSFiddle <https://jsfiddle.net/juberti/x7a8ut0q/25/> which
> does something similar in a single page. At present, even host-host
> connections were seeing a 2 ms RTT, possibly because of the clamping
> <https://developer.mozilla.org/en-US/docs/Web/API/Performance/now> that
> has been applied to performance.now() to deal with Spectre et al.
>
>
>
>
>
>> Connections over wifi have usually a bigger/less stable latency than
>> local loop connections.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 4 Jul 2018 10:35:06 -0700

One other potential complication: while S 4.3
<https://tools.ietf.org/html/draft-mdns-ice-candidates-00#section-4.3>
indicates that mDNS names should not be registered when running in a
private browsing context, it would still be possible for an endpoint
running in a private browsing context to connect to an mDNS address
registered by an endpoint running in a normal browsing context.

On Tue, Jul 3, 2018 at 2:40 PM Justin Uberti <[email-masked]> wrote:

>> able to make a JSFiddle <https://jsfiddle.net/juberti/x7a8ut0q/25/>
>> which does something similar in a single page. At present, even host-host
>>> Maybe I don't understand the attack well enough, but if a page running
>>>> in a private browsing context tried to communicate with a page not running
>>>> in a private browsing context, they would probably see < 1ms RTTs for both

---

From: youenn fablet <[email-masked]>
Date: Wed, 4 Jul 2018 14:12:24 -0700

> https://jsfiddle.net/juberti/x7a8ut0q/37/

Right, this shows the local loopback latency.

>> has been applied to performance.now() to deal with Spectre et al.
I updated
https://evening-thicket-98446.herokuapp.com/src/content/peerconnection/datachannel-b2b/,
it should hopefully be more intuitive to use this time:
1. load the page in one device
2. load the link provided by the page on another device
3. click 'call' on the first page
4. a latency value should appear on the page and be continuously updated

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Jul 2018 10:15:29 -0700

Thanks for the new version. I tried a few scenarios and agree that this
technique can identify a same-host situation fairly reliably, especially in
wireless environments; I typically saw ~2 ms latency for same-host and 5-10
ms latency (with occasional spikes) for over-the-air connections.

I'm still not quite sure what we should do about it; as noted, public
IPv4 + user-agent (http://www.whatsmyua.info/) is probably unique in the
vast majority of cases, and the situation is unavoidable with IPv6.

---

From: westhawk <[email-masked]>
Date: Fri, 6 Jul 2018 18:53:36 +0100

I think perhaps we should step back and see if we can block the threat earlier on.

If I understand correctly the issue is that 2 pages of different origin could include 3rd party
javascript that connects to a web service to exchange OA and establish a data channel
between the pages. It then looks at the latency and figures out that the two are on
the same network/device.

Is there a way we can make this prohibitively expensive or inaccurate?

It sorta feels like a same origin policy on the data channel might help.
-Perhaps sign the webRTC certificates with the origin and have DTLS refuse a handshake if
the two ends don’t have a common signature.

I’m obviously very keen to avoid forcing all data channel traffic through TURN.

T.

> On 6 Jul 2018, at 18:15, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Thanks for the new version. I tried a few scenarios and agree that this technique can identify a same-host situation fairly reliably, especially in wireless environments; I typically saw ~2 ms latency for same-host and 5-10 ms latency (with occasional spikes) for over-the-air connections.
> 
> I'm still not quite sure what we should do about it; as noted, public IPv4 + user-agent (http://www.whatsmyua.info/ <http://www.whatsmyua.info/>) is probably unique in the vast majority of cases, and the situation is unavoidable with IPv6.
> 
> 
> 
> On Wed, Jul 4, 2018 at 2:12 PM youenn fablet <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Le mar. 3 juil. 2018 à 14:40, Justin Uberti <[email-masked] <mailto:[email-masked]>> a écrit :
> Updated fiddle (outputs to display as well as console): https://jsfiddle.net/juberti/x7a8ut0q/37/ <https://jsfiddle.net/juberti/x7a8ut0q/37/>
> 
> On Tue, Jul 3, 2018 at 11:16 AM Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
> I wasn't able to get that example to work (tried with 2 Chrome and 2 Safari instances, got a setRemoteDescription error both times), but I was able to make a JSFiddle <https://jsfiddle.net/juberti/x7a8ut0q/25/> which does something similar in a single page. At present, even host-host connections were seeing a 2 ms RTT, possibly because of the clamping <https://developer.mozilla.org/en-US/docs/Web/API/Performance/now> that has been applied to performance.now() to deal with Spectre et al.
> 
> I updated https://evening-thicket-98446.herokuapp.com/src/content/peerconnection/datachannel-b2b/ <https://evening-thicket-98446.herokuapp.com/src/content/peerconnection/datachannel-b2b/>, it should hopefully be more intuitive to use this time:

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Jul 2018 12:35:30 -0700

> the two ends don’t have a common signature.

The issue is that two pages (probably of the same origin) can determine
that they are on the same host even when running in different browsing
contexts (e.g., one being in private browsing mode), by establishing a p2p
connection and measuring latency.

The key questions are a) whether this gives up information that is not
already present (e.g., by looking at your own IPv6 address), and b) what
mitigations might exist.

We'll have some time to discuss in Montreal.

>
>
> On 6 Jul 2018, at 18:15, Justin Uberti <
> juberti=[email-masked]> wrote:
>
>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Performance/now>
>>>> that has been applied to performance.now() to deal with Spectre et al.
>>>>
>>>
>> I updated

---

From: Feross Aboukhadijeh <[email-masked]>
Date: Sat, 7 Jul 2018 15:59:37 -0700

> It sorta feels like a same origin policy on the data channel might help.

This would break use cases like WebTorrent, and many other Decentralized
Web projects that utilize the data channel to send data between cooperating
pages hosted on different origins. Also, as Justin pointed out, this
doesn't solve the issue since two pages on the same origin but in different
browsing contexts could still communicate.

Feross

I write at feross.org and tweet as @feross <https://twitter.com/feross>.
I work on WebTorrent <https://webtorrent.io/>, Standard
<https://standardjs.com/>, and Study Notes <https://www.apstudynotes.org/>.

On Fri, Jul 6, 2018 at 12:35 PM Justin Uberti <juberti=
[email-masked]> wrote:

>> It sorta feels like a same origin policy on the data channel might help..

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Jul 2018 16:34:49 +1000

On Sat, Jul 7, 2018 at 5:36 AM Justin Uberti
<juberti=[email-masked]> wrote:
> The issue is that two pages (probably of the same origin) can determine that they are on the same host even when running in different browsing contexts (e.g., one being in private browsing mode), by establishing a p2p connection and measuring latency.
>
> The key questions are a) whether this gives up information that is not already present (e.g., by looking at your own IPv6 address), and b) what mitigations might exist.

This seems like a fair analysis.  I read the draft and thought a
little about this angle, and I think that it's worth doing something
about, even if I'm not 100% sure of what that would look like.

Other signals, like sharing an address, don't seem to be as reliable
as this.  For instance, having to go to a NAT hairpin might add enough
additional latency that it looks like you are on the same network, but
not necessarily the same machine.  That might be enough information
for a tracker, anyway, so that's a big caveat on any mitigation we
come up with.

I'm not sure that what is proposed (limiting to a top-level browsing
context that isn't also private browsing) is the best way to achieve
the stated policy goals in the draft.  And more fundamentally, there
are probably several policies that browsers might reasonably adopt
along those lines.

For instance, we might reasonably be similarly concerned about
different unrelated top-level browsing contexts using this to link
each other.  I know that Tor Browser would be concerned about this
sort of isolation as much as it would worry about iframes on different
pages.

The best idea I have there is to fail resolution for .local names that
the browser itself has minted for other origins[1].  That way,
connections that are cross-origin and same-host would always at least
hit a hairpin or relay.  Of course, failing resolution so quickly
might leak information, so additional caution might be necessary (I
don't think that it does, provided that a candidate is not entered
into a checklist before resolution occurs, but I'm not sure how that
would be implemented).

This suggests that you could share mDNS names for frames under the
same top-level browsing context without leaking more information,
which could be very useful.

(The data channels thing isn't relevant here, because measuring
connection setup should be enough to link two browsing contexts.  RTP
likely works as well, but it's less easy to use.)

[1] The draft uses the term "execution context" here, which is
probably the right phrase, but it's not really defined.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Jul 2018 14:37:51 -0700

> for a tracker, anyway, so that's a big caveat on any mitigation we

I did some more testing in http://jsfiddle.net/juberti/8n9p5jxk/ (hairpin
tester) and NAT hairpin doesn't always add significant latency. Obviously
it depends a lot on your wifi, but I was able to get 2-3 ms RTT for hairpin
on Ethernet and 6-8 ms RTT for wifi.

Basically, the site can try to connect two contexts via:
a) [existing] public IPv4 (indicates "same network")
b) [existing] IPv6 (indicates "same endpoint")
c) [existing] user-agent (indicates "same OS, same browser, same version")
d) [existing] fonts, gpu, display resolution, etc
e) [new] RTT < 5ms (indicates "probably same machine")

As such, e) doesn't add a lot, and as noted above, has false positives and
likely false negatives.

> into a checklist before resolution occurs, but I'm not sure how that

If we decide to take action here, this seems like a reasonable approach.
You'd still be able to link cross-browser usage, but not cross-context
(intra-browser) usage.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 07:48:10 +1000

> e) [new] RTT < 5ms (indicates "probably same machine")

My thought was that this only creates a valid "same-network" signal.
But the number of instances of one host per network is high enough
that the distinction might be meaningless.  But that's not the point,
the point was to avoid creating a new signal.

One thing that I found helpful in thinking about this was the
question: "What would Tor Browser do?"  And in that case, the proposed
tweak does work: a hairpin over the Tor network expands the anonymity
set considerably.

---

From: youenn fablet <[email-masked]>
Date: Mon, 9 Jul 2018 14:58:26 -0700

Thanks for the feedback.

> are probably several policies that browsers might reasonably adopt

Agreed, browsers might have different constraints and security rules (ITP
in Safari for instance) that should be taken into consideration when
solving that particular issue.

It seems also that, given that this is quite tied to browsers and execution
contexts, guidelines might better fit in W3C land if we think there is a
need for such guidelines.
For instance, W3C specs could use some IETF defined hooks to provide
guidelines on how to set the MDNS policy/MDNS names to be used by a
particular ICE agent.

> into a checklist before resolution occurs, but I'm not sure how that

There is also the issue of detecting same browser clients by failing
connections.
Let's say a web site identifies three clients A, B and C behind a NAT.
If A is able to connect to both B and C without TURN but B and C are not
able to connect with each other without TURN, a web site could probably
infer that B and C are running on the same browser and are not able to
connect with each other because of this rule.

While this case is not super likely for top level pages (and anyway, the
user somehow trusts the page and might already be authenticated with), this
might more often happen with third party tracking iframes.

> which could be very useful.

Agreed if these frames are same-origin with the top-level browsing context.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Jul 2018 15:19:17 -0700

> tweak does work: a hairpin over the Tor network expands the anonymity

Well, Tor browser would really need all WebRTC traffic to flow through Tor,
to prevent linking sessions via the srflx IPs.

But let me get to the point. Adding the limitations discussed for .local
has minimal downside, but what, if anything, should we do with IPv6 host
candidates? If we decide that we want to prevent host-host IPv6
connections, there will be implications for datachannel applications.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 08:42:36 +1000

On Tue, Jul 10, 2018 at 8:19 AM Justin Uberti <[email-masked]> wrote:
> Well, Tor browser would really need all WebRTC traffic to flow through Tor, to prevent linking sessions via the srflx IPs.

The anonymity set would be the hosts on the same exit node, which I
assume is >1.  More to the point, different top-level contexts use
different circuits, and therefore (likely) different exits.  IOW, as
proposed, the linking there is fine.

> But let me get to the point. Adding the limitations discussed for .local has minimal downside, but what, if anything, should we do with IPv6 host candidates? If we decide that we want to prevent host-host IPv6 connections, there will be implications for datachannel applications.

I don't think that we should treat v6 specially here.  If it is a host
candidate, use mDNS or don't provide it.  That avoids making a
judgment about the relative prevalence of v6 NAT and other such
things.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Jul 2018 16:32:20 -0700

On Mon, Jul 9, 2018 at 3:42 PM Martin Thomson <[email-masked]>
wrote:

> > Well, Tor browser would really need all WebRTC traffic to flow through
> Tor, to prevent linking sessions via the srflx IPs.
>

If Tor is already forcing all WebRTC traffic through a Tor proxy, it
doesn't need this tweak; TURN is the only option. This is somewhat
academic, but it points out an issue with the WWTBD framing.

> judgment about the relative prevalence of v6 NAT and other such

The reason for the different treatment is that it could be argued that v6
addresses, being already public and unique, don't constitute a new signal.
That makes the tradeoff with datachannel impact less clear.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Jul 2018 17:24:14 -0700

On Mon, Jul 9, 2018 at 4:35 PM youenn fablet <[email-masked]> wrote:

>
> > The reason for the different treatment is that it could be argued that
> v6 addresses, being already public and unique, don't constitute a new
> signal. That makes the tradeoff with datachannel impact less clear.
>
>
> If they are public, cannot they be discovered and exposed as srflx?

That's a good point; I had forgotten about NAT64. v6 STUN isn't widely
deployed, but if we did want to hide NAT64 v6 addresses, we could make this
work.

However, if we consider NAT64 to be an entirely temporary situation, this
may not make sense.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 Jul 2018 09:56:17 +0200

Thoughts:

- If I want to find out that I'm on the same host as another context
that I can communicate with in *any* fashion, I've got lots of games I
can play.

Example: Measure memory pressure, allocate 1 Gbyte in one context,
measure memory pressure again. This works for any measurement that's
available to both contexts and relates to the whole system.
Example: Measure the local clock's skew compared to some reference clock
(NTP-fashion). If the skew is the same down to the nanosecond, same host
is likely.
Example: Allocate any resource that can only be accessed from one
context at a time. Loop, asking for it, in the other context. Release it
in the first context, and check the timing on when the other one gets it.

In general, anything that can potentially be used as a covert channel
can be used more easily to figure out if we're on the same host.

My conclusion: Defending against this attack isn't worth the trouble.
We've already lost.

- Nevertheless, we're finding that the MDNS mode has implications that
we don't perceive fully yet.

My conclusion: This is an additional mode, not a replacement for one of
the other modes. We should continue to specify both.

On 07/10/2018 02:24 AM, Justin Uberti wrote:
>
>
> On Mon, Jul 9, 2018 at 4:35 PM youenn fablet <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > The reason for the different treatment is that it could be
>     argued that v6 addresses, being already public and unique, don't
>     constitute a new signal. That makes the tradeoff with datachannel
>     impact less clear.
>
>
> deployed, but if we did want to hide NAT64 v6 addresses, we could make
> this work.
>
> However, if we consider NAT64 to be an entirely temporary situation,
> this may not make sense.
>
>

-- 
Surveillance is pervasive. Go Dark.

---

From: Lennart Grahl <[email-masked]>
Date: Wed, 11 Jul 2018 16:22:34 +0200

> the other modes. We should continue to specify both.

I'm treating this thread as a follow-up to the "IP handling: Using mDNS
names for host candidates" thread, so this refers to both drafts and the
PR for ip-handling (https://github.com/juberti/draughts/pull/103).

Harald, I second your conclusions. Regarding mDNS, I see potential for
the following three "intermediate" modes:

- Mode 2.a: Enumerates all addresses but only the default route's
interface addresses are exposed as host candidates. All other addresses
are hidden via mDNS.
- Mode 2.b: The mode 2 as described in ip-handling-09.
- Mode 2.c: Only expose the default route's interface addresses hidden
via mDNS.

2.a is a minor improvement but will fix issues for users who would be
able to establish a direct connection over a different route but the
default one.

2.c is a major restriction over 2.b and 2.a. since it will break the
ability to establish direct connections in a corporate network.

Regarding the ip-handling document: It's probably okay to restrict the
default mode further from ip-handling-09's mode 2. FWIW, it might even
be okay to give implementations the freedom to choose any of the
available modes as their default (let's be honest, many browser vendors
have already done so anyway). But only if all use cases have access to
an adequate way to request consent to achieve mode 1 or at least 2.a.
Specifically, this should be a MUST in the ip-handling document. Because
if that is not guaranteed, some less obvious already existing use cases
(think of sharedrop.io for example) will be further discriminated and
without a TURN server can be completely broken. Not to mention the
impact on delay and throughput caused by hairpinning or even relaying.

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Wed, 11 Jul 2018 16:01:30 -0700

Thanks for the suggestions on intermediate modes. I think we're converging
on the following potential replacements for Mode 2:
2b) IPv4 mDNS + RFC 4941 IPv6
2d) mDNS of any private IPv4/IPv6  + any public v4/v6 (as determined via
STUN query)

2d) is basically your 2c), but exposing any IPs that would already be
visible to the server. This would basically give all the privacy benefits
of Mode 3 (although, unlike Mode 3, it does allow host-host connections).

Your 2a) probably makes more sense to consider as a derivative of Mode 1,
essentially a 1b), since it exposes all interfaces. I don't know if that
provides a lot of value, since Mode 1 already requires trust, but I'd be
open to arguments for this.

I think the main outstanding question is what we want the final Mode 2 to
be (2b vs 2d), and the key sub-question is whether we think there's enough
benefit in hiding private RFC 4941 addresses. However, we may need
experimental data to properly consider the tradeoffs.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jul 2018 14:52:32 +0200

Den 12. juli 2018 01:01, skrev Justin Uberti:
> Thanks for the suggestions on intermediate modes. I think we're
> converging on the following potential replacements for Mode 2:
> visible to the server. This would basically give all the privacy
> benefits of Mode 3 (although, unlike Mode 3, it does allow host-host
> connections).
> 
> Your 2a) probably makes more sense to consider as a derivative of Mode
> 1, essentially a 1b), since it exposes all interfaces. I don't know if
> that provides a lot of value, since Mode 1 already requires trust, but
> I'd be open to arguments for this.
> 
> I think the main outstanding question is what we want the final Mode 2
> to be (2b vs 2d), and the key sub-question is whether we think there's
> enough benefit in hiding private RFC 4941 addresses. However, we may
> need experimental data to properly consider the tradeoffs.
> 

I must be missing something - if both endpoints hide public v4/v6
addresses using mdns (whether they are host addresses or learned via
STUN), we preclude communication outside the local mDNS domain.

Either there's an use case I haven't thought about, or this means that
only local-to-local connections can be set up.

If one endpoint reveals its public IP and the other doesn't,
communication outside the local domain will only happen if initial
packets can make it from the one who's hiding its IP to the one who isn't.

That's a *severe* restriction.

> 
> 
> On Wed, Jul 11, 2018 at 7:22 AM Lennart Grahl <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     (think of sharedrop.io <http://sharedrop.io> for example) will be
>     further discriminated and
>     [email-masked] <mailto:[email-masked]>

---

From: youenn fablet <[email-masked]>
Date: Thu, 12 Jul 2018 08:21:16 -0700

> STUN), we preclude communication outside the local mDNS domain.

I do not think addresses learned via STUN are to be hidden, they are
already known from any web site.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 12 Jul 2018 11:55:14 -0700

> That's a *severe* restriction.
In neither case would we hide public addresses. The key distinction between
2b and 2d is that 2b does not hide *private* IPv6 addresses (e.g., NAT64
addresses) because they already have short lifetimes (unlike private IPv4s).

---

From: Manuel Kasper <[email-masked]>
Date: Tue, 17 Jul 2018 13:27:08 +0200

Disclosure: I work for Threema GmbH, whose main product is the "Threema" messenger (threema.ch), and would like to provide our view of the consequences of this proposal.

We use WebRTC data channels for our web client to establish a connection between the app on a smartphone and a browser on a desktop/laptop. Most of the time, the person who is using the web client connects to the same network with both devices.

The ability to send data (messages, audio, video, files, images) from and to the app without relaying it via a server is the main reason why we use WebRTC.

We have around 5 million users, and a significant portion of them use our enterprise product in corporate networks. Some of them will have IPv6 disabled, and our experience also shows that NAT loopback support is scarcer than one might think.

Because of that, I think the current proposal is a threat for our use case and would severely impact our users' experience. We are definitely on privacy's side (it is in fact our main focus along with end-to-end encryption), but at present we don't have an appropriate way to request consent from the user. Unless that is ensured by this document, the default mode should not be weakened.

- Manuel

> On 12 Jul 2018, at 01:01, Justin Uberti <[email-masked]> wrote:
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 17 Jul 2018 10:33:09 -0400

> On Jul 11, 2018, at 19:01, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Thanks for the suggestions on intermediate modes. I think we're converging on the following potential replacements for Mode 2:
> 2d) mDNS of any private IPv4/IPv6  + any public v4/v6 (as determined via STUN query)

Can you please explain what do you consider as a private IPv6 vs a public IPv6 address?

Thanks
  Nils Ohlmeier

---

From: Justin Uberti <[email-masked]>
Date: Tue, 17 Jul 2018 09:04:42 -0700

Private IPv6 would be one behind NAT, e.g. NAT64. The IPv6 is not exposed
to the outside world.

On Tue, Jul 17, 2018 at 7:33 AM Nils Ohlmeier <[email-masked]> wrote:

>
> On Jul 11, 2018, at 19:01, Justin Uberti <