Subject: [rtcweb] Relaying for privacy

From: Martin Thomson <[email-masked]>
Date: Wed, 16 May 2012 11:56:15 -0700

On 15 May 2012 18:31, Cullen Jennings <[email-masked]> wrote:
> Might want to add to some use case that when A calls B, and B does not reveal their IP address to A.

I agree, but it's questionable whether this is something we
(ietf/w3c...browsers) need to solve the problem or whether we can rely
on sites respecting privacy appropriately.

Obviously, it's quite simple to allocate a relay for all new sessions
in the browser.  The hard part is knowing when it is OK to reveal
host/reflexive candidates so that the call can proceed without
relaying.

 - Is it when the user grants permission for the site to use
microphone/camera?  This seems wrong.  An individual desire for
privacy is often based on who is asking, which in this case is A, not
the site.  It's plausible that the site can be given permission to
access mic/camera prior to the call arriving.

 - Is it when the user indicates acceptance of the call?  I don't
think that the plan is to signal acceptance through chrome, so this
would have to rely on cues from the site, such as calling
createAnswer.  At that point, if the site wants the media off the
relay, they now have an incentive to fake acceptance.  The same
applies to relying on any other cues from the site, including faking
the _initiation_ of the call, which can be done from both A and B.

 - Is there special chrome that enables this?  Adding more chrome
doesn't sound like a great idea to me, but maybe this behaviour could
be tied to the various "private/incognito mode" options in the
browser.

I did have another related thought, but distractions erased it.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 May 2012 17:54:17 -0400

My view was that we need to make it _possible_ for sites to respect privacy
(via the API), and provide documentation that encourages sites to do so. As
you point out, I think it's difficult for the browser to automatically
figure out what to do here, and when to do it.

The identity of the "called" user may not be a factor in certain
applications (e.g. some p2p game), making it unclear as to whether forcing
use of relay is even the right thing to do.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 15:09:43 -0700

> use of relay is even the right thing to do.

I concur with all this.

I think it's also important to reiterate that this is about the site cooperating
to protect your privacy. If you want to protect the user's IP address from the
site, then the user needs to use Torbutton or some such. And I would want
Torbutton to arrange relay my RTCWEB traffic as well (though likely that
can't go through Tor for performance reasons).

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 19:07:15 -0700

Yes. Tor is too slow to do voice effectively. I would expect torbutton or a torbutton-like to route media through a turn server. This will provide worse privacy than onion routing but better than just letting the server control the routing.

Ekr

On May 16, 2012, at 18:06, 邓灵莉/denglingli <[email-masked]> wrote:

> Hi, Ekr
> 
> I agree with you about the Martin's comments. 
> For the proposal of Torbutton, I have a concern about the employment of
> union routing (encrypting and decrypting several times between the relaying
> nodes along the way) in Tor would be not acceptable to the RTC requirements
> of VoIP use-cases.
> Would this be an issue?
> 
> BR
> Lingli
> 
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Eric
> Rescorla
> 发送时间: 2012年5月17日 6:10
> 收件人: Justin Uberti
> 抄送: [email-masked]
> 主题: Re: [rtcweb] Relaying for privacy
> 
>> My view was that we need to make it _possible_ for sites to respect 
>> privacy (via the API), and provide documentation that encourages sites 
>> to do so. As you point out, I think it's difficult for the browser to 
>> automatically figure out what to do here, and when to do it.
>> 
>> applications (e.g. some p2p game), making it unclear as to whether 
>> forcing use of relay is even the right thing to do.
> 
> I concur with all this.
> 
> I think it's also important to reiterate that this is about the site
> cooperating to protect your privacy. If you want to protect the user's IP
> address from the site, then the user needs to use Torbutton or some such.
> And I would want Torbutton to arrange relay my RTCWEB traffic as well
> (though likely that can't go through Tor for performance reasons).
> 
> -Ekr
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 7138 (20120515) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
>

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Thu, 17 May 2012 13:50:50 +0800

It makes sense to me.
However, considering the relaying burden would not be trivial, I'd further prefer that the enable/disable button be dedicatedly set for the RTCWEB instance in question, rather than the whole pack of connections of the browsers. 
In other words, it is better to be triggered at the time of page-loading for the RTCWEB app for a global configuration (keeping current IP privacy for all callers) or when called by for a specific configuration (keeping privacy for the incoming caller). 
In either cases, the setting can be done through getusermedia as Martin said.

BR
Lingli

-----邮件原件-----
发件人: Eric Rescorla [mailto:[email-masked]] 
发送时间: 2012年5月17日 10:07
收件人: 邓灵莉/denglingli
抄送: Justin Uberti; <[email-masked]>
主题: Re: 答复: [rtcweb] Relaying for privacy

Ekr

On May 16, 2012, at 18:06, 邓灵莉/denglingli <[email-masked]> wrote:

> For the proposal of Torbutton, I have a concern about the employment 
> of union routing (encrypting and decrypting several times between the 
> relaying nodes along the way) in Tor would be not acceptable to the 
> RTC requirements of VoIP use-cases.
> Would this be an issue?
> 
> BR
> Lingli
> 
> -----邮件原件-----
>> privacy (via the API), and provide documentation that encourages 
>> sites to do so. As you point out, I think it's difficult for the 
>> browser to automatically figure out what to do here, and when to do it.
>> 
> cooperating to protect your privacy. If you want to protect the user's 
> IP address from the site, then the user needs to use Torbutton or some such.
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 7138 (20120515) __________
> 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 7138 (20120515) __________

http://www.eset.com

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Thu, 17 May 2012 13:56:38 +0800

Sorry, by " In either cases, the setting can be done through getusermedia as Martin said." I mean " In either cases, the setting could be done through getusermedia as Martin said."
Since according to our experience with chrome so far, media relaying through turn is not yet supported.

Lingli

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 邓灵莉/denglingli
发送时间: 2012年5月17日 13:51
收件人: 'Eric Rescorla'
抄送: [email-masked]
主题: [rtcweb] 答复: 答复: Relaying for privacy

It makes sense to me.

BR
Lingli

-----邮件原件-----
发件人: Eric Rescorla [mailto:[email-masked]]
发送时间: 2012年5月17日 10:07
收件人: 邓灵莉/denglingli
抄送: Justin Uberti; <[email-masked]>
主题: Re: 答复: [rtcweb] Relaying for privacy

Ekr

http://www.eset.com

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 May 2012 18:05:23 -0700

I do not think that any option other than what Eric described is truly
feasible. That is, of the options provided, only the one where the site has
to be trusted bit to reveal your IP is likely to succeed.

getUserMedia provides a cue of a fundamentally different nature to that you
are looking for in this use case. getUserMedia signals that the user is ok
with the site gaining access to their camera/microphone.  That is a
contract between the user and the site, not the two users.

If you don't trust the site, then you are in Torbutton land. That is,
specific UI for this.

I've concluded that we don't need this requirement. There is little that a
browser can sensibly do beyond something like Torbutton.

And I'm not convinced that trying to replicate, or require the replication
of Torbutton, is a great idea either. Tor users understand the value it
provides, most other users won't care for the added complication.

On May 16, 2012 10:59 PM, "邓灵莉/denglingli" <[email-masked]>
wrote:
>
> Sorry, by " In either cases, the setting can be done through getusermedia
as Martin said." I mean " In either cases, the setting could be done
through getusermedia as Martin said."
> However, considering the relaying burden would not be trivial, I'd
further prefer that the enable/disable button be dedicatedly set for the
RTCWEB instance in question, rather than the whole pack of connections of
the browsers.
> In other words, it is better to be triggered at the time of page-loading
for the RTCWEB app for a global configuration (keeping current IP privacy
for all callers) or when called by for a specific configuration (keeping
privacy for the incoming caller).
> Yes. Tor is too slow to do voice effectively. I would expect torbutton or
a torbutton-like to route media through a turn server. This will provide
worse privacy than onion routing but better than just letting the server
control the routing.

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Fri, 18 May 2012 09:17:09 +0800

My mistake. It should be at “peerconnection” rather than “getusermedia” in order to get what we meant.

发件人: Martin Thomson [mailto:[email-masked]] 
发送时间: 2012年5月18日 9:05
收件人: 邓灵莉/denglingli
抄送: [email-masked]; Eric Rescorla
主题: Re: [rtcweb] 答复: 答复: 答复: Relaying for privacy

I do not think that any option other than what Eric described is truly feasible. That is, of the options provided, only the one where the site has to be trusted bit to reveal your IP is likely to succeed.

getUserMedia provides a cue of a fundamentally different nature to that you are looking for in this use case. getUserMedia signals that the user is ok with the site gaining access to their camera/microphone.  That is a contract between the user and the site, not the two users.

If you don't trust the site, then you are in Torbutton land. That is, specific UI for this.

I've concluded that we don't need this requirement. There is little that a browser can sensibly do beyond something like Torbutton.

And I'm not convinced that trying to replicate, or require the replication of Torbutton, is a great idea either. Tor users understand the value it provides, most other users won't care for the added complication.