Re: [rtcweb] WG last call comments on use-case and requirement document, “hide IP address”

[Martin Thomson <[e-mail]>]

Here's how I see it.

1. Is where I, as a user of the browser (or, more likely, as
administrator for the user of the browser) decide that I don't want
host candidates exposed to *anyone*.  This means that I would like to
be able to request that the browser do the following:
a) use the TURN server that I configure
b) don't provide base addresses or provide bogus base addresses

This is entirely a negotiation that occurs between browser users and
browsers.  API requirements are zero.

That doesn't mean that we're off the hook entirely.  We can do a),
perhaps, with some DHCP and DNS messing around, but it's not possible
to convey b) through those channels.  I'm sure that some people will
argue that we don't want to try to solve this problem, but given the
complete mess that has been made of HTTP proxy discovery (wpad,
proxy.pac, ...) and the way that users use browsers, I think that this
is something that needs to be done.  (I've just thought of some actual
feedback on Andy's draft...)

2. is a no-brainer.  If I want to use a service that I trust to
protect my anonymity, then that's great.  Here I agree with Bernard,
this is common enough, important enough, and easy enough to solve.
Adding a means to request anonymity is a good thing.

3. is a security considerations problem



On 29 April 2013 09:14, Bernard Aboba <[e-mail]> wrote:
> For Case 2 there are real customers out there (e.g. Women's shelters, Forensic psychologists dealing with criminals, etc.) so I would favor including it.
>
> For case 1, I think we need a bit more detail on the adversary model. Is this the same as Case 2 (e.g. Hiding from another user, not the web server or STUN server?) I can imagine scenarios where granular candidate control would be useful. Not sure I would put all those cases in the privacy bucket, though.
>
> On Apr 29, 2013, at 7:12, "Stefan Håkansson LK" <[e-mail]> wrote:
>
>>
>>
>> This relates to the comments to the WG last call of the use-cases and requirements document [1].
>>
>> This is a discussion starting from A25 “ It must be possible for the application to refrain from exposing the IP address”.
>>
>> Discussed a lot ([2]-[24]). I think there are several aspects here that are discussed, and we need to separate them to enable a more fruitful discussion. The browser being configured to not reveal addresses applies to at least the following cases:
>>
>> 1) Private domain with NAT where the internal structure should be hidden can configure their browsers to not reveal that inner structure by only providing relay or NAT external candidates, none from the private space.
>>
>> 2) An user wants to avoid having their actual location revealed to any other user of the same service.
>>
>> 3) The user wants to be prevent revealing their point of attachment to the network even to the web service.
>>
>> This results in different functional requirements
>>
>> 1) Requires browser support but also configuration to determine which candidates are ok and which are not. It may be fine with server reflexive candidates and not only relay candidates
>>
>> 2) A browser could help, but is not required for this. The browser may have clearer understanding from where the different candidates were gotten and thus understand if they reflect a privacy issue or not.
>>
>> 3) Needs additional anonymity service, like TOR and something that prevents any actual interface addresses to be revealed to the web-app.
>>
>>
>> I think 3) is out of scope (that is how I interpret the discussion), but it is not clear to me if we want to meet 1) or 2) or both with this requirement. I would like input on this topic.
>>
>> Stefan
>>
>>
>> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06136.html
>>
>> [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06198.html
>> [3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06219.html
>> [4] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06220.html
>> [5] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06221.html
>> [6] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06222.html
>> [7] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06223.html
>> [8] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06233.html
>> [9] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06234.html
>> [10] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06235.html
>> [11] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06236.html
>> [12] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06238.html
>> [13] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06240.html
>> [14] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06241.html
>> [15] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06245.html
>> [16] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06247.html
>> [17] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06248.html
>> [18] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06253.html
>> [19] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06256.html
>> [20] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06259.html
>> [21] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06260.html
>> [22] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06261.html
>> [23] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06262.html
>> [24] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06180.html
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb