It seems like #1 is a special case of #2, in which the browser overrides
whatever flag is set.  It seems like even in #2, there could be chrome to
mitigate the risk of pages lying.

I agree that #1 would not require standardization.

--Richard

On Monday, February 4, 2013, Matthew Kaufman (SKYPE) wrote:

> I still don't understand how I, as a user, can possibly trust your web
> site to set the flags appropriately so that my browser doesn't execute
> connectivity checks to someone I'm worried might learn my IP address.
>
> I get it in option #1. I set my browser that way, I trust my browser
> vendor, end of story.
>
> In case #2, I go to your site, I don't trust your site, but I decide to
> use it anyway. It gives my addresses away when I do my HTTP GET from it.
> Then I make a call, and it sets the flags however it wants. Or it sets the
> flags to "don't do checks except over TURN" and then it sets up a TURN
> server, but points the TURN server to be the address of the bad guy I
> didn't want my addresses disclosed to and so my connection attempt to that
> TURN server reveals my addresses, etc. How does any of this actually help
> me?
>
> If I really trust the site to protect me, the site runs a media proxy and
> only has me run ICE checks against that (because those are the only far
> candidates in the SDP). It relays the traffic. Done.
>
> Matthew Kaufman
>
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Monday, February 4, 2013 2:05 PM
> To: Matthew Kaufman (SKYPE)
> Cc: Eric Burger; rtcweb@ietf.org
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of
> draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
>
>
>
> On Feb 4, 2013, at 12:56, "Matthew Kaufman (SKYPE)" <
> matthew.kaufman@skype.net> wrote:
>
> > I see two possible readings (either or both of them might be useful):
> >
> > 1. The browser must have a way for its user to force the use of TURN
> servers (and this is only useful if the user also provides the address and
> credentials for the TURN servers) for transmission of media.
> >
> > 2. The browser must have an API that keeps some kinds of candidates from
> being included in the SDP the API generates.
> >
> > #1 seems like a very useful thing to require for users who might
> actually care about their privacy, but I don't think that requirement
> belongs in an IETF document but rather the W3C requirements TR for WEBRTC,
> that appears to have not even been started.
>
> >
>
> I had 2 in mind. I don't think #1 needs standardization
>
>
> > #2 seems highly questionable to me, due to the large number of failure
> modes in both the interpretation of the spec and the ability to circumvent
> the intent...
> >
> > For #2 do you mean "API flag to prevent local candidates from being
> included" or "API flag to prevent server-reflexive STUN-learned candidates
> from being included" or both?
> >
> > For #2 how do you propose a malicious application or page injection not
> simply change the flag?
> >
>
> The intent here is to allow the server to offer an anonymous calling
> service so this threat isn't relevant
>
>
> > For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP and then letting the JavaScript remove the
> "dangerous" candidates before sending the SDP to the server?
> >
>
> This I have a good answer to. You need to suppress checks on this
> candidates because those reveal your address. And even if you think
> stripping in sdp before set local accomplishes this how do you do it for
> trickle ice?
>
>
> > For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP, sending it to the server (which you must trust
> anyway, as it also can change the flag itself *or* derive your IP address
> by looking at where you load pages from), and having the server remove the
> "dangerous" candidates before sending them on to the far client?
> >
>
> Same reason
> > Matthew Kaufman
> >
> >
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Eric Burger
> > Sent: Monday, February 4, 2013 2:53 AM
> > To: Eric Rescorla
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of
> > draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
> >
> > 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 pr
>  otect 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 m