Re: [rtcweb] ICE exposes 'real' local IP to javascript

I think the concern over private IP addresses is a side issue.

The main issue, as Tim indicates, is the surfacing of interfaces other than
the VPN or proxy when using such a configuration; right now the only
workaround is to disable WebRTC.

I would be in favor of a browser switch that could control whether other
interfaces are enumerated and used when HTTP traffic is being sent through
a VPN or proxy. This is similar to the 'leaky' vs 'sealed' policy described
in RETURN
<https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-5.2>,
and this switch could be set to either value depending on whether the
user/browser wants to optimize for maximizing QoS or minimizing information
disclosure.

On Thu, Feb 5, 2015 at 1:26 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Harald Alvestrand wrote:
> >Den 05. feb. 2015 07:39, skrev Bjoern Hoehrmann:
> >> * Harald Alvestrand wrote:
> >>> We have discussed this before, and concluded that a confirmation dialog
> >>> makes no more sense than having a confirmation dialog for performing an
> >>> XHR request or opening a Websocket - neither of which requires
> >>> confirmation dialogs today.
> >>
> >> Neither of those disclose information not otherwise available to random
> >> web sites, so that is not a valid comparison.
> >
> >"Not otherwise" is a misnomer here. They expose a ton of information
> >(think HTTP headers), but the information they expose is inherent in
> >providing the functionality they do provide. The reason we don't think
> >of them as such is because we've become used to that information being
> >provided.
>
> A XMLHttpRequest message might contain a User-Agent header the content
> of which is available to script through the `navigator` object, and it
> might contain a Cookie header the content of which is already known to
> the server, it might contain a username and password for which the user
> got prompted, it might contain an Accept-Language header that is also
> sent out when requesting an <img>, and so on and so forth. None of the
> examples are similar to the case at hand,
>
>   * there is no getLocalIpAddresses() API
>   * the server does not already know the local IP addresses
>   * the user did not get prompted to provide them
>   * requesting an <img> does not disclose local IP addresses
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
>  Available for hire in Berlin (early 2015)  · http://www.websitedev.de/
>
>