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

[Stefan Håkansson LK <[e-mail]>]

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