Under what circumstances would it be up to the Web server to decide to make the client interaction quasi-anonymous? Would that not be a entirely up to and the responsibility of the client? By definition, the Web server is not anonymous -- the user had to reach it somehow to get the page in the first place. Likewise, it is well within the power of the server to obfuscate its media address. It is quite likely media is NOT coming from the same IP address as the Web page under normal circumstances, so the server has built-in opportunities to obfuscate its address. Conversely, it is well within the capabilities of the browser to figure out how to obfuscate its media address. More importantly, I have yet to hear a cogent use case for the server saying, "I want this interaction to not have IP addresses *TO PROTECT YOU*." If you are in a scenario where you need protection, you cannot depend on the server. You must depend on yourself, which means you will have a browser that will protect you. Moreover, will not a bad server simply always tell all browsers it connects with to open lots of anonymity relays to DDoS the relays? Saying we want to build something that is only sometimes useful and can only be useful if we trust all sides to do the right thing does not sound very useful.

Am I missing something here?

On Feb 3, 2013, at 6:48 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 
> 
> On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger <eburger@standardstrack.com> wrote:
> To be clear, I think ekr's formulation is the best:
> > 1. If you don't want the server learning your global IP, you need to use Tor or the like.
> 
> To me, this means it is totally orthogonal to RTCweb. If you want to use Tor, a TURN server, an ALG, or foo, that is up to you. That does not impact the protocol.
> 
> That's certainly what I meant to be saying, with the small caveat that
> if you are using media relays (e.g., TURN) they are supposed to be
> reflected in ICE candidate lines.
> 
> 
> > 2. I would suggest that it is simplest to divide the world into host addresses, server/peer
> > reflexive, and relayed and say that the requirement is that the browser must be able
> > to send packets without revealing either of the former two, but that it is not a requirement
> > that it be able to do so in the face of an adversarial server.
> And this is the most reasonable. I guess the concern is we will forget all of this list discussion, and someone will require hard-coded endpoint IP addresses in the protocol, which is what sunk SIP in the early days.
> 
> Inline…
> 
> On Feb 3, 2013, at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> > On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric <eburger@cs.georgetown.edu> wrote:
> > Is what we are really asking for is the ability of the protocol to be TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one particular anonymity network or another into the RTCweb protocol suite.
> >
> > I'm certainly not suggesting that.
> >
> >
> > On the one hand, with my purist hat on, saying it is a requirement to make sure we do not need to have end-to-end connectivity smells a bit weird.
> >
> >> I don't understand this... I don't think anyone is suggesting that.
> 
> Saying we will bake into the protocol the REQUIREMENT that it support good or bad boxes in the middle of the network does not sound like the end-to-end Internet. It sounds more like IMS.
> 
> Which requirement do you think suggests that? I certainly favor requirements that we be
> able to work in the face of as many known classes of intermediaries (NATs, firewalls,
> etc. as possible.) I mean, isn't that the point of ICE supporting TURN and other types
> of relays?
> 
> Is there something wrong with this? Do you think people are suggesting some
> other requirement?
> 
> 
> > On the other hand, with my practical hat on, saying it is a requirement to make sure the protocol works in situations that are NOT the Internet (NATs, a need for an overlay privacy network, etc.) seems like a good thing to do.
> >
> >> As far as I know, the only novel requirement here is that there be a way for Web
> >> application to tell the browser to solely use relayed addresses/candidates
> >> (and hopefully thus not reveal the user's actual location) when communicating
> >> with the peer. There is of course a requirement to be able to work when
> >> behind NATs but that is a functional requirement, not an anonymity one.
> 
> That is asking an awful lot of an application. Moreover, as the cat-and-mouse game of anonymous application communication is ever evolving, I would challenge how meaningful it is to specify a Hidden Bit or Anonymous Bit in the protocol. I would offer that will work as well as the Evil Bit.
> 
> I really am not following what you are saying here about a "hidden bit"?
> 
> There is a very specific requirement being suggested here, namely that applications
> should be able to instruct browsers not to use host or srvflx candidates. This is
> neither a hidden bit, nor an anonymous bit. Rather, it is a mechanism designed
> to allow the site, *if it wishes* to offer a calling service that doesn't immediately
> reveal the caller's location. This isn't a complete anonymity service against
> sophisticated attackers. For that you need something like Tor. Rather, it's an
> easy-to-implement measure that offers location protection against a 
> (relatively common) class of limited attackers.
> 
> What is it you object to about this requirement?
> 
> -Ekr
>