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

[Bernard Aboba <[e-mail]>]

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