Subject: [rtcweb] New proposal for IP address handling in WebRTC

From: Justin Uberti <[email-masked]>
Date: Sun, 19 Apr 2015 22:49:36 -0700

*Background*
At IETF 92 we proposed a browser mechanism that users could enable to avoid
disclosing their VPN IP to websites as a side effect of ICE candidate
generation. When this mechanism was enabled, the browser would bind only to
0.0.0.0 and ::, and only generate candidates via STUN and TURN; because
these sockets would follow the OS default routing, the only candidate
addresses discovered would be the ones that the website already had access
to (i.e. from the HTTP request).

The primary downsides with this mechanism were:
a) users had to manually enable it (through some potentially non-obvious
preference)
b) when enabled, it caused trombone routing in intranet cases
c) when enabled, it broke pretty much every simple demo page (which
typically don't use STUN servers)

*Proposal*
We now propose a new mechanism that attempts to address these issues. The
new mechanism works like the previous mechanism, but during the candidate
generation process, we call getsockname to obtain the local IP address of
the interface used to talk to the STUN/TURN server. This obtains a *single*
interface IP, which allows the browser to avoid trombone routing, but also
minimizes the amount of IP information revealed to JS. Furthermore, the
STUN traffic continues to go out the default route, meaning that if a VPN
is used, the 'real' public address is still not disclosed. (Naturally, this
has some performance implications, as a user may not always want their
media to go out the VPN.)

For pages that don't use STUN/TURN servers (typically demo pages), there
are a few options to consider:
a) always surface localhost as a candidate when no STUN/TURN servers are
provided (works with existing demos, but may have false positives with
certain apps)
b) always include some default STUN server when no STUN/TURN servers are
provided (similar to above, plus complexity of choosing default)
c) add some RTCConfiguration parameter indicating that the localhost
address is desired (requires updating many demo pages)

None of these choices is ideal, but this seems like a solvable problem.

*Implications for Browsers*
As this mechanism should alleviate the primary security concerns with
interface enumeration, with relatively small impact on user experience, we
propose that this be the default for browsers. For users that don't want to
disclose any local IP information, browsers could expose a preference that
prevents surfacing even the single local IP (i.e. the originally proposed
behavior). For users that want to ensure maximum performance (e.g. to
address the VPN issue above), a similar preference (or permissions grant)
could be exposed that allows enumeration of all IPs.

*FAQ*
Q: WebRTC already requires permission to access getUserMedia. Why not use
that permission to control interface enumeration?
A: Receive-only applications (e.g. streaming media) or datachannel
applications don't require a call to gUM, so there are cases where that
approach would not work.
Q: Is this only for browsers, or also for native apps?
A: This proposal is currently targeted at browsers. Native applications,
especially on mobile, need to be able to access individual interfaces in
order to be able to do seamless wifi-cellular call handover.

We welcome feedback on this proposal.

Guo-wei Shieh and Justin Uberti

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Apr 2015 09:50:33 -0400

Interesting!

Would a dual-stack client do the same procedure for IPv6 and offer both
IPv4 and IPv6 candidates? Would a single IPv6 host candidate be
enumerated, and would it be the one used to contact the STUN/TURN server?

This proposal has potential to reduce the bandwidth used by connectivity
checks quite a bit. Do you see this reduction as significant? Worst case
 would be (1 host, 1 server reflexive, 1 relayed)^2 x (IPv4, IPv6) = 18
checks if I'm not mistaken. That's close to practically negligible.

Simon

Le 2015-04-20 01:49, Justin Uberti a écrit :
> *Background*
> At IETF 92 we proposed a browser mechanism that users could enable to
> avoid disclosing their VPN IP to websites as a side effect of ICE
> candidate generation. When this mechanism was enabled, the browser would
> bind only to 0.0.0.0 and ::, and only generate candidates via STUN and
> TURN; because these sockets would follow the OS default routing, the
> only candidate addresses discovered would be the ones that the website
> already had access to (i.e. from the HTTP request).
> 
> We now propose a new mechanism that attempts to address these issues.
> The new mechanism works like the previous mechanism, but during the
> candidate generation process, we call getsockname to obtain the local IP
> address of the interface used to talk to the STUN/TURN server. This
> obtains a *single* interface IP, which allows the browser to avoid
> trombone routing, but also minimizes the amount of IP information
> revealed to JS. Furthermore, the STUN traffic continues to go out the
> default route, meaning that if a VPN is used, the 'real' public address
> is still not disclosed. (Naturally, this has some performance
> implications, as a user may not always want their media to go out the VPN.)
> 
> interface enumeration, with relatively small impact on user experience,
> we propose that this be the default for browsers. For users that don't
> want to disclose any local IP information, browsers could expose a
> preference that prevents surfacing even the single local IP (i.e. the
> originally proposed behavior). For users that want to ensure maximum
> performance (e.g. to address the VPN issue above), a similar preference
> (or permissions grant) could be exposed that allows enumeration of all IPs.
> 
> *FAQ*
> Q: WebRTC already requires permission to access getUserMedia. Why not
> use that permission to control interface enumeration?
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Apr 2015 15:59:37 +0200

> order to be able to do seamless wifi-cellular call handover.

Just checking - what about browsers on mobile?
Wouldn't they want to do seamless handover too?

(if they can be allowed to detect that the interface has changed when a
connection breaks, and add new candidates at that time (which implies
trickle ICE), this may be a minor issue.)

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 Apr 2015 10:28:56 -0400

> are a few options to consider:
This will also affect the applications that only communicate with servers
on public IP. Such applications (especially if they implement ICE-TCP) have
no need for STUN/TURN servers.

Would it make sense to sense to use the IP address used to retrieve the
application via HTTP as a candidate address?

Alternatively, applications that communicate only with the servers on
public IPs will work even if they include candidates with fake IPs. Real
IPs will be resolved as peer reflexive during the ICE connectivity checks.
_____________
Roman Shpount

---

From: Kaiduan Xie <[email-masked]>
Date: Mon, 20 Apr 2015 10:40:03 -0400

For two users on the same VPN, the traffic may go through TURN server
if hairpin is not supported on the router.

/Kaiduan

On Mon, Apr 20, 2015 at 10:28 AM, Roman Shpount <[email-masked]> wrote:
> This will also affect the applications that only communicate with servers on
> public IP. Such applications (especially if they implement ICE-TCP) have no
> need for STUN/TURN servers.
>
> Alternatively, applications that communicate only with the servers on public
> IPs will work even if they include candidates with fake IPs. Real IPs will
> be resolved as peer reflexive during the ICE connectivity checks.
> _____________
> Roman Shpount
>
>
>

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 20 Apr 2015 07:51:57 -0700

[...]
> are a few options to consider:

just checking:
usecases like sharedrop.io (which put the users in the same "room" based 
on the ip address used to connect to the signaling server) are not 
really affected by this, right?

Since users know a-priori that they're on the same LAN, STUN servers are 
not necessary here, but adding them doesn't hurt much either.

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 Apr 2015 10:11:13 -0500

On 4/20/15 09:51, Philipp Hancke wrote:
> Since users know a-priori that they're on the same LAN, STUN servers 
> are not necessary here, but adding them doesn't hurt much either.

If you look at Justin's proposal, you'll note that he suggests that the 
lack of a STUN server means you'll only offer up localhost as a candidate.

In other words, without a STUN server, you can't talk to anyone but 
yourself.

/a

---

From: Randell Jesup <[email-masked]>
Date: Mon, 20 Apr 2015 11:19:12 -0400

On 4/20/2015 1:49 AM, Justin Uberti wrote:
> candidate generation process, we call getsockname to obtain the local 
> IP address of the interface used to talk to the STUN/TURN server.

One concern here is that this is underspecified; I presume this means 
"the interface used to contact the STUN/TURN server by default if you 
don't force it to an interface" (or perhaps the interface used if you 
try to contact those addresses via TCP).  I have concerns about how 
portable this is and how stable the binding would be.  I suspect this 
can be worked through and specified, though.

> This obtains a *single* interface IP, which allows the browser to 
> avoid trombone routing, but also minimizes the amount of IP 
> information revealed to JS. Furthermore, the STUN traffic continues to 
> go out the default route, meaning that if a VPN is used, the 'real' 
> public address is still not disclosed. (Naturally, this has some 
> performance implications, as a user may not always want their media to 
> go out the VPN.)

This has major performance concerns, as many users (especially those who 
use VPNs for other-than-anonymity reasons, such as work VPNs) will 
simply see "WebRTC sucks" and have no real idea as to why - it would be 
very poorly discoverable if at all.

I think browsers would need to find some way to surface this - but it's 
hard to do so without punching data through on the other interfaces to 
see if they're connected to something that can reach the STUN/TURN 
servers.  This may not be visible to the JS, but does generate 
correlatable traffic on those addresses that could de-anonymize you.

> interface enumeration, with relatively small impact on user 
> experience, we propose that this be the default for browsers. For 
> users that don't want to disclose any local IP information, browsers 
> could expose a preference that prevents surfacing even the single 
> local IP (i.e. the originally proposed behavior). For users that want 
> to ensure maximum performance (e.g. to address the VPN issue above), a 
> similar preference (or permissions grant) could be exposed that allows 
> enumeration of all IPs.

I'm not sure there's a way to resolve the paradox of making it work 
well, and making it impossible to leak information; I hope we can 
improve on this compromise to at least make the "your calls suck because 
you have a VPN" somewhat discoverable by users.  The downside is that 
likely means UI changes, and possibly somewhat opaque-to-users 
descriptions required.

I think this is another piecemeal attempt to wallpaper over the mess 
that results when half-hearted/half-understood attempts at anonymity are 
taken by users.  I think a better (and more discoverable/understandable) 
solution is to tie changes in this to higher-level "anonymity mode" 
(very similar to Private Browsing, and perhaps combined with it). If you 
really want/need to by anonymous, you need to lock down a lot more than 
this.  (See discussions of fingerprinting, for example.)

I think this highlights the sort of problem when such 
half-hearted/half-understood attempts are made:
http://arstechnica.com/security/2015/04/op-ed-why-the-entire-premise-of-tor-enabled-routers-is-ridiculous/

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Apr 2015 11:34:38 -0400

> can be worked through and specified, though.

I thought that this is what was implied:

s = socket(...);
connect(s, <stun/turn server>);
getsockname(s, &local_addr);

local_addr would then be advertised as host candidate. Works with both
UDP and TCP, on every platform.

> very poorly discoverable if at all.

Work VPNs very often suck and users already blame them for every problem
they have, real or imaginary...

Simon

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 Apr 2015 10:51:03 -0500

On 4/20/15 00:49, Justin Uberti wrote:
> IP address of the interface used to talk to the STUN/TURN server. This 
> default route, meaning that if a VPN is used, the 'real' public 
> address is still not disclosed. (Naturally, this has some performance 

I think this is an incremental improvement on the previous proposal that 
is worth adding.

> experience, we propose that this be the default for browsers.

Okay, you had me until here.

The idea about choosing the address that we would use to route to a TURN 
server makes some assumptions about network architectures that don't 
hold in the general case. For those users who are willing to accept 
increased latency (sometimes), decreased quality (sometimes), and 
reduced connection rates (sometimes) in exchange for obscuring certain 
aspects of their network configuration, that's probably okay. You're 
making things slightly worse, but for a real benefit. Well, a real 
benefit for those specific users.

The problem is that, despite the noise and fury that's resulted from 
this issue, the number of users for whom it is a real concern is an 
infinitesimally small fraction of those people who will ever use a web 
browser. And I'm not okay with taking an across-the-board service 
degradation for all users based on something that the overwhelming 
majority of them won't care about.

I'll repeat what I said at the mic in Dallas: for users looking for the 
level of obscurity that you're proposing to provide, WebRTC isn't the 
only concern with regards to modern web browser operation. To get this 
correct requires a vast amount of work, and it's not something that 
anyone is likely to get right by themselves, regardless of level of 
ability. You need a comprehensive approach, such as that described at 
<https://www.torproject.org/projects/torbrowser/design/>. To really get 
this correct, you usually need to have someone take care of the heavy 
lifting for you, which means running something like TorBrowser

If we turn your proposed behavior on by default, we're doing the 
equivalent of putting a locked deadbolt on the bathroom window while 
leaving the front door unlocked, open, and made out of cardboard.

So I'm all for including this ability as something that users can turn 
on, and I'd be happy to brainstorm ways to expose this to users in ways 
other than deep, dark prefs tweaking. But I think it would be a very 
detrimental overreaction to hobble WebRTC by default just to solve a 
problem for a tiny fraction of users.

/a

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Apr 2015 10:59:04 -0700

I agree with Adam's assessment here.

Have you considered whether enabling this selectively would be of any
value?  Say, for third parties...

On 20 April 2015 at 08:51, Adam Roach <[email-masked]> wrote:
>> minimizes the amount of IP information revealed to JS. Furthermore, the STUN
>> traffic continues to go out the default route, meaning that if a VPN is
>> used, the 'real' public address is still not disclosed. (Naturally, this has
>> some performance implications, as a user may not always want their media to
>> go out the VPN.)
>
>
> I think this is an incremental improvement on the previous proposal that is
> worth adding.
>
>
>> propose that this be the default for browsers.
>
>
> server makes some assumptions about network architectures that don't hold in
> the general case. For those users who are willing to accept increased
> latency (sometimes), decreased quality (sometimes), and reduced connection
> rates (sometimes) in exchange for obscuring certain aspects of their network
> configuration, that's probably okay. You're making things slightly worse,
> but for a real benefit. Well, a real benefit for those specific users.
>
> The problem is that, despite the noise and fury that's resulted from this
> issue, the number of users for whom it is a real concern is an
> degradation for all users based on something that the overwhelming majority
> of them won't care about.
>
> level of obscurity that you're proposing to provide, WebRTC isn't the only
> concern with regards to modern web browser operation. To get this correct
> requires a vast amount of work, and it's not something that anyone is likely
> to get right by themselves, regardless of level of ability. You need a
> comprehensive approach, such as that described at
> <https://www.torproject.org/projects/torbrowser/design/>. To really get this
> correct, you usually need to have someone take care of the heavy lifting for
> you, which means running something like TorBrowser
>
> If we turn your proposed behavior on by default, we're doing the equivalent
> of putting a locked deadbolt on the bathroom window while leaving the front
> door unlocked, open, and made out of cardboard.
>
> So I'm all for including this ability as something that users can turn on,
> and I'd be happy to brainstorm ways to expose this to users in ways other
> than deep, dark prefs tweaking. But I think it would be a very detrimental
> overreaction to hobble WebRTC by default just to solve a problem for a tiny
> fraction of users.
>
> /a
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Apr 2015 20:46:04 +0200

> value?  Say, for third parties...
Assuming that by "enabling this selectively", you mean "reveal less
information than before"....

As far as I can tell, the only selectivity that would make sense would
be to enable this for the whole "drive-by web"; I can't figure out any
conditions under which it would make sense to enable this for <some
thing> and disable it (revealing more information) for a random URL that
users click on.

Which leaves us with the option of enabling this new mechanism for the
"drive-by web", and having the old, more information-revealing mechanism
for installed apps.

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Apr 2015 12:02:40 -0700

> thing> and disable it (revealing more information) for a random URL that

You are describing the harder meta-problem of determining what sites
users actually trust.  That's a hard problem.  And I would never make
solving that problem a condition on anything.  If anything, that
argument is cause to not break the world and turn this on for
everyone, it's a reason to keep the API functional.

I mentioned third parties.  That's a very simple technical thing to
accomplish.  If we can more precisely identify when NOT to share
information, that would help a great deal.  Or, if someone manages to
solve the trust problem (hah!), then we can talk about degrading the
experience for the untrustworthy.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Apr 2015 22:59:26 +0200

Den 20. april 2015 21:02, skrev Martin Thomson:
> solving that problem a condition on anything.

I think we agree on this point.

  If anything, that
> experience for the untrustworthy.

What do you mean by "third parties", and why should one trust them less
than others?

I'm sure there's a reference somewhere, but I don't know what it is.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Apr 2015 14:19:19 -0700

> I'm sure there's a reference somewhere, but I don't know what it is.

Sorry, I thought this was well understood.

First party: what you see in the funny bar at the top that no one pays
attention to
Third party: those that provide the images you see

---

From: Justin Uberti <[email-masked]>
Date: Mon, 20 Apr 2015 15:13:50 -0700

> In other words, without a STUN server, you can't talk to anyone but

Not exactly true; in the case where one side has a public IP, a STUN server
is not needed. As Roman points out, even without a STUN server, you can
still generate binding requests which will cause prflx candidates to be
created on the remote side.

---

From: Tim Panton <[email-masked]>
Date: Tue, 21 Apr 2015 11:56:12 +0100

> On 20 Apr 2015, at 14:50, Simon Perreault <[email-masked]> wrote:
> 
> Interesting!
> 

We should _only_ send IPV6 candidates with temporary addresses, not the ones derived from
the hardware mac address. 

Chrome currently _prefers_ temporary addresses but will send a hardware one if
no temporary is available.

T.

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Apr 2015 08:13:52 -0700

On Tue, Apr 21, 2015 at 3:56 AM, Tim Panton <[email-masked]> wrote:

> ​Just for clarity, I assume you mean IPv6 address derived according RFC
4941, right?

Ted​

---

From: tim panton <[email-masked]>
Date: Tue, 21 Apr 2015 16:18:40 +0100

> On 21 Apr 2015, at 16:13, Ted Hardie <[email-masked]> wrote:
> 
> ​Just for clarity, I assume you mean IPv6 address derived according RFC 4941, right?

Yes.
OSX labels them ' autoconf temporary'
Which is how I tend to think of them.

T.

---

From: carlo von lynX <[email-masked]>
Date: Tue, 21 Apr 2015 17:46:58 +0200

On 20 April 2015 at 08:51, Adam Roach <adam at nostrum.com> wrote:
> [...] And I'm not okay with taking an across-the-board service

Okay, let's just for a minute make sure that even if it only few
are affected, these few are not facing a threat of life or death.

Envision the typical young dissident with his Windows PC using
some VPN to access critical information. My impression is these
folks are not aware of how much safer they could be by using
TBB with Tor bridges, and for their purposes all the risks of
getting fingerprinted aren't even relevant *as long as the
authorities can't find a way to follow the fingerprinted browser
to its physical position* (something the NSA probably can, but
the NSA is outside of this threat model). So until everyone in 
their social surroundings hasn't been taken away to prison, they 
will continue as always - and if the web browser in the meantime
has introduced a way for authorities to reveal their whereabouts,
that could cost some lives.

Possibly all the other bugs in the JS "security" model are not 
half as dangerous to these people than the ability for an authority
to inject JS code that will reveal the physical IP number of a
dissident.

Correct me if I got something wrong but to me it looks like we
have a serious case of lives at risk, in particular since this
weakness is now known to the general public.. those authorities
may be slow and dissidents like to make fun of them in order to
feel less helpless.. but these authorities might just pick any 
time soon to start flying webrtc drones into living people.
 
I hope I got something wrong.

-- 
  E-mail is public! Talk to me in private using Tor.
  torify telnet loupsycedyglgamf.onion		DON'T SEND ME
          irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
         http://loupsycedyglgamf.onion/LynX/    OR FACEBOOGLE

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 22 Apr 2015 00:58:54 +0200

>Third party: those that provide the images you see

If being "first party" comes with any sort of potential commercial ad-
vantage, you can be sure that plenty of people will argue their stuff is
first party stuff, regardless how ridiculous the argument may be. See
e.g. W3C's "Tracking Protection" list archives.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Apr 2015 16:19:10 -0700

On 21 April 2015 at 15:58, Bjoern Hoehrmann <[email-masked]> wrote:
> first party stuff

I don't think arguing has any material effect here.  Your origin is
either displayed in the address bar (presumably because you served the
primary HTML) or it is not.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Apr 2015 08:40:22 +0200

Changing the subject, since we're off at a tangent..

> primary HTML) or it is not.

The standard trick (ten years ago when I last looked seriously at least)
for advertisers being first-party is that they serve the shell of the
advert off a piece of Javascript in your document, and then they pull in
the real content by JS-includes and dynamically built HTML. All first party.

The other trick (which only works with large hosting companies, and only
works to get around cookie restrictions, not same-origin policy, I
believe) is to serve the embedded content from a subdomain of the host's
domain that is served off the advertiser's servers.

It's not so much what they argue, it's what the parties agree to do as a
result of the argument.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 22 Apr 2015 17:14:39 -0700

On Mon, Apr 20, 2015 at 8:51 AM, Adam Roach <[email-masked]> wrote:

> server makes some assumptions about network architectures that don't hold
> in the general case. For those users who are willing to accept increased
> rates (sometimes) in exchange for obscuring certain aspects of their
> network configuration, that's probably okay. You're making things slightly
> worse, but for a real benefit. Well, a real benefit for those specific
> users.
>
> requires a vast amount of work, and it's not something that anyone is
> likely to get right by themselves, regardless of level of ability. You need
> a comprehensive approach, such as that described at <
> https://www.torproject.org/projects/torbrowser/design/>. To really get

I certainly understand this position. But I wonder if we are overestimating
the downside and underestimating the upside.

My sense is that any service degradation will be mainly limited to cases
where the user is using a VPN for work, and media ends up tunnelled where
it would otherwise go direct. But pretty much all the other cases result in
the same routing as in our current implementations. And even cases where
routing is suboptimal could perhaps be resolved by adding an explicit
permission request for full interface access.

Regarding upside, these issues are very complex and hard to explain even to
technical people unless they have a comms background. This leads to
widespread confusion and misleading pronouncements, which could become a
headwind for WebRTC adoption.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 23 Apr 2015 02:10:42 -0400

On 4/22/2015 8:14 PM, Justin Uberti wrote:
> On Mon, Apr 20, 2015 at 8:51 AM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     equivalent of putting a locked deadbolt on the bathroom window
>     while leaving the front door unlocked, open, and made out of
>     cardboard.
>
>     So I'm all for including this ability as something that users can
>     turn on, and I'd be happy to brainstorm ways to expose this to
>     users in ways other than deep, dark prefs tweaking. But I think it
>     would be a very detrimental overreaction to hobble WebRTC by
>     default just to solve a problem for a tiny fraction of users.
>
>
> I certainly understand this position. But I wonder if we are 
> overestimating the downside and underestimating the upside.
>
> My sense is that any service degradation will be mainly limited to 
> cases where the user is using a VPN for work, and media ends up 
> tunnelled where it would otherwise go direct. But pretty much all the 
> other cases result in the same routing as in our current 
> implementations. And even cases where routing is suboptimal could 
> perhaps be resolved by adding an explicit permission request for full 
> interface access.

Are you thinking of a constraint on new RTCPeerConnection? (or 
createOffer...) Or something separate from a specific PeerConnection, 
since certain patterns will result in the same page making a series of 
PeerConnections (in parallel or series).  We don't want a page to 
repeatedly have to request access...

Of course, #include <user/dialog/blindness>, but it would be (somewhat!) 
safer-by-default, modulo Adam's cardboard analogy limiting the total 
effectiveness.

And of course the point being made here is that there's a difference 
here between successfully fingerprinting someone, and identifying their 
external DHCP address that can lead to a knock on the door. Of course, 
if the attacker is halfway competent, successfully fingerprinting 
someone (without external IP) is most of the work required to knock on 
the door (since you can then take that fingerprint and match it against 
zillions of other records which identify the fingerprint as  Joe Shmoe, 
123 Main St - so the front door really is made of cardboard).

> Regarding upside, these issues are very complex and hard to explain 
> even to technical people unless they have a comms background. This 
> leads to widespread confusion and misleading pronouncements, which 
> could become a headwind for WebRTC adoption.

True - regardless of the facts, if it's seen as "dangerous", it will 
hurt.  Of course, it silently and inexplicably sucking for a major 
(though far from majority) class of users will hurt too.  If there's 
some way to make it not silent about sucking, that would help a lot in 
shifting the balance.  Ideas?

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 26 Apr 2015 21:24:21 -0600

I'm still more of a fan of going with a solutions of "if you want your VPN to hide your IP address, make sure you use a VPN that hides your IP address." - that is to say don't use a split tunnel VPN if you want to make sure all your traffic only goes down the VPN. 

I don't think the "default route" is as straight forward as that. For example, if the VPN is v4 only, but there is a v6 connectivity too, then the default route for v6 packets is not over the VPN but default route for v4 might be over the VPN. I think we would need to understand how cases like this work. If we add in the type of multpath proposal that people want for WiFi / Cellular handover. It's complicated with some VPNs - for example, the IOS VPN can look at the DNS information to decide what the default route might be for  a given flow so the default route for one flow might not be the same as for another flow. 

> On Apr 19, 2015, at 11:49 PM, Justin Uberti <[email-masked]> wrote:
> 
> Background
> At IETF 92 we proposed a browser mechanism that users could enable to avoid disclosing their VPN IP to websites as a side effect of ICE candidate generation. When this mechanism was enabled, the browser would bind only to 0.0.0.0 and ::, and only generate candidates via STUN and TURN; because these sockets would follow the OS default routing, the only candidate addresses discovered would be the ones that the website already had access to (i.e. from the HTTP request).
> 
> a) users had to manually enable it (through some potentially non-obvious preference)
> c) when enabled, it broke pretty much every simple demo page (which typically don't use STUN servers)
> 
> Proposal
> We now propose a new mechanism that attempts to address these issues. The new mechanism works like the previous mechanism, but during the candidate generation process, we call getsockname to obtain the local IP address of the interface used to talk to the STUN/TURN server. This obtains a *single* interface IP, which allows the browser to avoid trombone routing, but also minimizes the amount of IP information revealed to JS. Furthermore, the STUN traffic continues to go out the default route, meaning that if a VPN is used, the 'real' public address is still not disclosed. (Naturally, this has some performance implications, as a user may not always want their media to go out the VPN.)
> 
> For pages that don't use STUN/TURN servers (typically demo pages), there are a few options to consider:
> a) always surface localhost as a candidate when no STUN/TURN servers are provided (works with existing demos, but may have false positives with certain apps)
> b) always include some default STUN server when no STUN/TURN servers are provided (similar to above, plus complexity of choosing default)
> c) add some RTCConfiguration parameter indicating that the localhost address is desired (requires updating many demo pages)
> 
> Implications for Browsers
> As this mechanism should alleviate the primary security concerns with interface enumeration, with relatively small impact on user experience, we propose that this be the default for browsers. For users that don't want to disclose any local IP information, browsers could expose a preference that prevents surfacing even the single local IP (i.e. the originally proposed behavior). For users that want to ensure maximum performance (e.g. to address the VPN issue above), a similar preference (or permissions grant) could be exposed that allows enumeration of all IPs.
> 
> FAQ
> Q: WebRTC already requires permission to access getUserMedia. Why not use that permission to control interface enumeration?
> A: Receive-only applications (e.g. streaming media) or datachannel applications don't require a call to gUM, so there are cases where that approach would not work.
> A: This proposal is currently targeted at browsers. Native applications, especially on mobile, need to be able to access individual interfaces in order to be able to do seamless wifi-cellular call handover.
>