Subject: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities

From: Colin Gallagher <[email-masked]>
Date: Wed, 24 May 2017 17:35:17 -0700

To:  IETF RTCWeb WG

From:  Colin Gallagher
           https://www.linkedin.com/in/colingallagher
           https://lifeboat.com/ex/bios.colin.gallagher

Request for New Security Review of WebRTC based on observed vulnerabilities
in certain examples

Dear IETF RTCWeb WG,

This request relates to WebRTC.  The WebRTC is in draft at
https://w3c.github.io/webrtc-pc/ and is described also at
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#WebRTC_interfaces

There are certain examples where the use of WebRTC has presented security
vulnerabilities.  While not exhaustive, there are two I wanted to mention
that I had been exposed to recently.

1) The use of a video conferencing service which relies upon WebRTC (that
is a well established service)
2) The examination of a browser based WebRTC version of a decentralized
exchange (that is currently under development)

In both cases the security vulnerability which is described below was the
result of the use of WebRTC.

The problem under consideration is as follows:

As per the first example (the video conferencing service), recently I came
upon a vendor who shall remain unnamed who uses WebRTC as the backbone for
their video conferencing service.  As a result, I found I was unable to
access the service in question without disabling some security settings
which I would have preferred to leave intact.

My system is (based on what the aforementioned service detects) Mozilla/5.0
(X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0.  This is
Ubuntu 16.10 64-bit with Firefox 53.0.2.

However, quite some *long* while back I disabled WebRTC because of the
security vulnerability (described in part here on information security
stack exchange
<https://security.stackexchange.com/questions/82129/what-is-webrtc-and-how-can-i-protect-myself-against-leaking-information-that-doe>).
So as to mitigate this vulnerability, I changed settings in Firefox as
follows:

   1. I typed *about:config* in the address bar
   2. I found the setting *media.peerconnection.enabled*
   3. I set it to *false*

Unfortunately, this setting does not allow Firefox to work with the video
conferencing service in question, which relies entirely on WebRTC.

So I had to go back in and change the media.peerconnection.enabled setting
to *true* in Firefox in order to get it to work with the service in
question. While this enabled me to conference with teams that desire to use
the video conferencing service that rely wholly upon WebRTC, it concerns me
because of the security vulnerability.

One suggested mitigation was having NoScript, but using NoScript was not
helpful (you generally need to disable it for the site you are viewing that
relies upon WebRTC, in order to obtain any functionality, and whether
NoScript is off or on, WebRTC still causes the vulnerability of leaking
information as previously described).

Furthermore, upon reload of the browser, even after setting
media.peerconnection.enabled to *true*, the video conferencing service
wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox and
set it to expose my real IP address as well as allowing the following:

a. navigator.getUserMedia
b. window.MediaStreamTrack
c. window.RTCPeerConnection
d. window.RTCSessionDescription

That seemed to me to be a direct consequence of the persistent and ongoing
security vulnerability in WebRTC.

I contacted the video conferencing service provider and their solution was
simply to state that "If the peer to peer connection is of concern, you can
utilize our premium version which will route traffic through a forwarding
server with in our environment that handles the processing of the video and
sound of all users in the conference and send it to each user individually
rather than using a peer to peer connection."  In other words, they expect
that people should have to pay in order to mitigate this WebRTC security
vulnerability
<https://security.stackexchange.com/questions/82129/what-is-webrtc-and-how-can-i-protect-myself-against-leaking-information-that-doe>,
because they are unwilling to design to protect all users from it.

In a similar fashion, in the second example of the browser based WebRTC
version of a decentralized exchange, the user's financial information is
periodically exposed as a result of the information leakage which is
presently caused by WebRTC.  (Fortunately, this browser based WebRTC
decentralized exchange is under development and is not currently open to
actual usage.)

Although undoubtedly this has been discussed here before, I am asking that
WebRTC security issues be reconsidered and that a new security review be
done to ameliorate or eliminate this problem in terms of WebRTC leaking
this information.  It is my view that WebRTC should be further designed and
developed with an eye to mitigating this serious problem, so that users of
services which might rely partially or wholly upon WebRTC would not have to
be concerned about such information leakage.

Respectfully,
Colin Gallagher

---

From: Justin Uberti <[email-masked]>
Date: Thu, 25 May 2017 13:04:50 -0700

Colin,

This is an important topic, and the group has reviewed this situation in
detail. The results have been written up in this document
<https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>, and to my
knowledge most browsers that support WebRTC currently conform to its
recommendations.

However, I'm not totally clear on your specific technical concern. You
linked to an (now outdated) stackexchange page, but could you provide more
detail about the specific situation you are concerned about?

Justin

On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <
[email-masked]> wrote:

> Request for New Security Review of WebRTC based on observed
> vulnerabilities in certain examples
>
> Dear IETF RTCWeb WG,
>
> My system is (based on what the aforementioned service detects)
> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101
> Firefox/53.0.  This is Ubuntu 16.10 64-bit with Firefox 53.0.2.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Colin Gallagher <[email-masked]>
Date: Fri, 26 May 2017 00:58:09 -0700

Justin,

It's my understanding that various browsers have made an attempt to conform
to the recommendations in the document that you have provided
<https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>.
Unfortunately, at least in Firefox (the most current version) so far as I
can tell, there is a serious vulnerability.  To be more specific, the
problem was observed in my operating system with my current browser, which
is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).  The browser does not
address the WebRTC problems by default.

The stackexchange page that I cited originally is actually not outdated in
the sense that its method of measuring whether or not the WebRTC
vulnerability exists on a given system is still intact and works.  The
stackexchange page suggests two pages to determine whether or not you have
leakage / WebRTC related vulnerability.  These pages are:

1) Browser leaks test for WebRTC https://browserleaks.com/webrtc
2) IP Leaks https://ipleak.net/

Currently for Browser leaks test for WebRTC (due to that I have again
changed settings in my system so that I will not have to be exposed to this
vulnerability) the settings show up on the page as:
RTCPeerConnection×False
RTCDataChannel×False
ORTC (Microsoft Edge)×False (for example....)

And under IP leaks, it currently shows "No leak, RTCPeerConnection not
available."

*That is because:*

(A) I have (again) changed my settings in about:config back to the following

   1. I typed *about:config* in the address bar
   2. I found the setting *media.peerconnection.enabled*
   3. I set it to *false  (it was previously set at true, so as to allow
   WebRTC to work, but this exposed information which I would not have wanted
   to be exposed)*

(B) And I also have changed my settings back to the following

in the WebRTC 0.1.3 extension for Firefox I have set it to no longer expose
my real IP address as well as no longer allowing the following:

To be clear, *these mitigations that I have employed above would be
unnecessary if WebRTC had not been designed in such a manner that it so
clearly exposes so much user information.*

In the document you provided
<https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>, titled
"WebRTC IP Address Handling Requirements -
draft-ietf-rtcweb-ip-handling-03," it is stated that:

*"1. If the client is behind a NAT, the client's private IP addresses,
typically [RFC1918 <https://tools.ietf.org/html/rfc1918>] addresses, can be
learned. *

* 2.  If the client tries to hide its physical location through a VPN,
       and the VPN and local OS support routing over multiple interfaces
       (i.e., a "split-tunnel" VPN), WebRTC will discover the public
       address for the VPN as well as the ISP public address that the
       VPN runs over.

   3.  If the client is behind a proxy (a client-configured "classical
       application proxy", as defined in [RFC1919], Section 3
<https://tools.ietf.org/html/rfc1919#section-3>), but
       direct access to the Internet is also supported, WebRTC's STUN
       [RFC5389 <https://tools.ietf.org/html/rfc5389>]checks will
bypass the proxy and reveal the public
       address of the client."*

All of these are obvious vulnerabilities and serious problems (not
only #2 as the document suggests).

It is stated in the document that,

*"we want to avoid solutions that disable WebRTC or make it harder to use."*

Yet, so far as my observations of WebRTC in the current version of
Firefox with Ubuntu 16.10 have shown,

there appears to be no other choice other than to disable WebRTC
because its use completely compromises

privacy and thus makes all other aspects of your system more difficult
generally.

It is stated in the document you cited that the goals here are to
"Provide a privacy-friendly default behavior which strikes the
      right balance between privacy and media performance for most users
      and use cases. (and) For users who care more about one versus
the other, provide a
      means to customize the experience."

This has clearlly not been accomplished in the context of Ubuntu 16.10
64-bit with Firefox 53.0.2 (64-bit).

Hence my request for a new security review of WebRTC based on observed
vulnerabilities.

On Thu, May 25, 2017 at 1:04 PM, Justin Uberti <[email-masked]> wrote:

>> As per the first example (the video conferencing service), recently I
>> came upon a vendor who shall remain unnamed who uses WebRTC as the backbone
>> for their video conferencing service.  As a result, I found I was unable to
>> So I had to go back in and change the media.peerconnection.enabled
>> setting to *true* in Firefox in order to get it to work with the service
>> in question. While this enabled me to conference with teams that desire to
>> use the video conferencing service that rely wholly upon WebRTC, it
>> concerns me because of the security vulnerability.
>>
>> That seemed to me to be a direct consequence of the persistent and
>> ongoing security vulnerability in WebRTC.
>>
>> I contacted the video conferencing service provider and their solution
>> was simply to state that "If the peer to peer connection is of concern, you
>> can utilize our premium version which will route traffic through a
>> forwarding server with in our environment that handles the processing of
>> the video and sound of all users in the conference and send it to each user
>> individually rather than using a peer to peer connection."  In other words,
>> they expect that people should have to pay in order to mitigate this
>> WebRTC security vulnerability
>> Although undoubtedly this has been discussed here before, I am asking
>> that WebRTC security issues be reconsidered and that a new security review
>> be done to ameliorate or eliminate this problem in terms of WebRTC leaking

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 May 2017 20:48:03 +0800

Colin,

I'm not really sure what you think the new information is here.

The draft that Justin referred to reflects the consensus view of the RTCWEB
WG
about the best balance between privacy and usability, and yes, it does
result in
the server learning your default RFC 1918 address, so it's not surprising
that
accounts for the results you are seeing with Firefox. If you think there's
a defect
where Firefox isn't conforming to the spec, then you should file a bug, but
otherwise I'm not really seeing what there is for the WG to reconsider

-Ekr

On Fri, May 26, 2017 at 3:58 PM, Colin Gallagher <
[email-masked]> wrote:

> Justin,
>
> It's my understanding that various browsers have made an attempt to
> conform to the recommendations in the document that you have provided
> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer
> expose my real IP address as well as no longer allowing the following:
>
> "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03,"
> it is stated that:
>
>        application proxy", as defined in [RFC1919], Section 3 <https://tools.ietf.org/html/rfc1919#section-3>), but
>        [RFC5389 <https://tools.ietf.org/html/rfc5389>]checks will bypass the proxy and reveal the public
>        address of the client."*
>
> All of these are obvious vulnerabilities and serious problems (not only #2 as the document suggests).
>
> Yet, so far as my observations of WebRTC in the current version of Firefox with Ubuntu 16.10 have shown,
>
> there appears to be no other choice other than to disable WebRTC because its use completely compromises
>
> privacy and thus makes all other aspects of your system more difficult generally.
>
> It is stated in the document you cited that the goals here are to "Provide a privacy-friendly default behavior which strikes the
>       and use cases. (and) For users who care more about one versus the other, provide a
> This has clearlly not been accomplished in the context of Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).
>
> Hence my request for a new security review of WebRTC based on observed vulnerabilities.
>
>
>
>
>> <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>, and to
>> my knowledge most browsers that support WebRTC currently conform to its
>> recommendations.
>>
>>> There are certain examples where the use of WebRTC has presented
>>> security vulnerabilities.  While not exhaustive, there are two I wanted to
>>> mention that I had been exposed to recently.
>>>
>>> 1) The use of a video conferencing service which relies upon WebRTC
>>> (that is a well established service)
>>> In both cases the security vulnerability which is described below was
>>> the result of the use of WebRTC.
>>>
>>> Unfortunately, this setting does not allow Firefox to work with the
>>> video conferencing service in question, which relies entirely on WebRTC.
>>>
>>> setting to *true* in Firefox in order to get it to work with the
>>> service in question. While this enabled me to conference with teams that
>>> desire to use the video conferencing service that rely wholly upon WebRTC,
>>> it concerns me because of the security vulnerability.
>>>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 26 May 2017 14:53:14 +0200

It seems to me that you don't want WebRTC. For WebRTC to work IPs must be
exposed. So not sure what you are asking for.

---

From: Colin Gallagher <[email-masked]>
Date: Fri, 26 May 2017 10:13:23 -0700

It is quite clear what I am asking for.  I am asking for a new security
review of WebRTC.  To quote my original request as posted:

"I am asking that WebRTC security issues be reconsidered and that a new
security review be done to ameliorate or eliminate this problem in terms of
WebRTC leaking this information.  It is my view that WebRTC should be
further designed and developed with an eye to mitigating this serious
problem, so that users of services which might rely partially or wholly
upon WebRTC would not have to be concerned about such information leakage."

In other words, I would like WebRTC to be reviewed for this very obvious
security issue and redesigned so that it does not leak this information
when utilized in browsers.

Some developers who have considered using WebRTC (to develop a browser
based WebRTC version of decentralized currency exchange) have observed this
persistent security vulnerability and rather than accept the problems it
would pose for users, the developers have instead contemplated
incorporating onion routing among peers to mitigate the problem of IP being
revealed or associated with messages.

However, it should not only fall to developers who are considering using
WebRTC to find some elaborate workaround or fix to the privacy problem with
their particular application.  WebRTC itself needs to be fixed as well.

Respectfully,

Colin Gallagher

On Fri, May 26, 2017 at 5:53 AM, Iñaki Baz Castillo <[email-masked]> wrote:

>> The stackexchange page that I cited originally is actually not outdated
>> in the sense that its method of measuring whether or not the WebRTC
>>>> One suggested mitigation was having NoScript, but using NoScript was
>>>> not helpful (you generally need to disable it for the site you are viewing
>>>> that relies upon WebRTC, in order to obtain any functionality, and whether

---

From: Justin Uberti <[email-masked]>
Date: Fri, 26 May 2017 10:49:56 -0700

Colin,

As Eric mentioned, the group has reviewed this exact issue, and the
aforementioned document represents the result of the review.

I am still not quite clear on the exact technical issue you would like to
see addressed and why it is, as you claim, a serious vulnerability.

Comments inline.

> All of these are obvious vulnerabilities and serious problems (not only #2 as the document suggests).
The document discusses #1 and #3 in detail, and outlines mechanisms that
can be used to address these cases if needed.

If, despite the findings in the document, you think that these are indeed
serious problems, it would be good to outline exactly why.

> Hence my request for a new security review of WebRTC based on observed vulnerabilities.
To my knowledge, the document addresses these goals. If you believe Firefox
is not conforming, please file a bug; if you think the document is in
error, please point out where and why.

---

From: Colin Gallagher <[email-masked]>
Date: Fri, 26 May 2017 11:14:27 -0700

It seems the consensus of the group here is essentially a refusal to
further review and potentially redesign WebRTC to remove the serious
security vulnerabilities that it presents to its users.

Thank you for your time.  I will not further respond to this thread.

On Fri, May 26, 2017 at 10:49 AM, Justin Uberti <[email-masked]> wrote:

> To my knowledge, the document addresses these goals. If you believe
> Firefox is not conforming, please file a bug; if you think the document is
> in error, please point out where and why.
>
>>
>>
>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 26 May 2017 14:07:58 -0700

Colin,

The group is absolutely willing to consider new evidence and arguments.

However it is not enough to say that there are "obvious security issues"
without any explanation of why these issues are serious and/or why the
existing document's treatment of them is flawed.

Help us understand your specific technical concerns.

Justin

On Fri, May 26, 2017 at 11:14 AM, Colin Gallagher <
[email-masked]> wrote:

>>>    3. I set it to *false  (it was previously set at true, so as to
>>>    allow WebRTC to work, but this exposed information which I would not have
>>>    wanted to be exposed)*
>>>
>>>> This is an important topic, and the group has reviewed this situation
>>>> in detail. The results have been written up in this document
>>>>> 2) The examination of a browser based WebRTC version of a
>>>>> decentralized exchange (that is currently under development)
>>>>>
>>>>> However, quite some *long* while back I disabled WebRTC because of
>>>>> the security vulnerability (described in part here on information
>>>>> security stack exchange
>>>>> media.peerconnection.enabled to *true*, the video conferencing
>>>>> service wouldn't work until I installed the WebRTC 0.1.3 extension for
>>>>> Firefox and set it to expose my real IP address as well as allowing the
>>>>> following:
>>>>>
>>>>> In a similar fashion, in the second example of the browser based
>>>>> WebRTC version of a decentralized exchange, the user's financial
>>>>> information is periodically exposed as a result of the information leakage
>>>>> which is presently caused by WebRTC.  (Fortunately, this browser based
>>>>> WebRTC decentralized exchange is under development and is not currently
>>>>> open to actual usage.)
>>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 May 2017 17:34:20 -0700

Colin - 

Are you claiming that the recommendations of the document Justin refers to are inadequate, or just that some browsers have not fully or correctly implemented it? 

If the former, what would you propose to change?

> On May 26, 2017, at 10:49 AM, Justin Uberti <[email-masked]> wrote:
> 
> Colin,
> 
> As Eric mentioned, the group has reviewed this exact issue, and the aforementioned document represents the result of the review.
> 
> I am still not quite clear on the exact technical issue you would like to see addressed and why it is, as you claim, a serious vulnerability.
> 
> Comments inline.
> 
>> On Fri, May 26, 2017 at 12:58 AM, Colin Gallagher <[email-masked]> wrote:
>> Justin,
>> 
>> It's my understanding that various browsers have made an attempt to conform to the recommendations in the document that you have provided.  Unfortunately, at least in Firefox (the most current version) so far as I can tell, there is a serious vulnerability.  To be more specific, the problem was observed in my operating system with my current browser, which is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).  The browser does not address the WebRTC problems by default.
>> 
>> The stackexchange page that I cited originally is actually not outdated in the sense that its method of measuring whether or not the WebRTC vulnerability exists on a given system is still intact and works.  The stackexchange page suggests two pages to determine whether or not you have leakage / WebRTC related vulnerability.  These pages are:
>> 
>> Currently for Browser leaks test for WebRTC (due to that I have again changed settings in my system so that I will not have to be exposed to this vulnerability) the settings show up on the page as:
>> RTCPeerConnection×False
>> RTCDataChannel×False
>> And under IP leaks, it currently shows "No leak, RTCPeerConnection not available."  
>> 
>> That is because:
>> 
>> I typed about:config in the address bar
>> I found the setting media.peerconnection.enabled
>> I set it to false  (it was previously set at true, so as to allow WebRTC to work, but this exposed information which I would not have wanted to be exposed)
>> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer expose my real IP address as well as no longer allowing the following:
>> 
>> To be clear, these mitigations that I have employed above would be unnecessary if WebRTC had not been designed in such a manner that it so clearly exposes so much user information.
>> 
>> In the document you provided, titled "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03," it is stated that:
>> 
>> "1. If the client is behind a NAT, the client's private IP addresses, typically [RFC1918] addresses, can be learned.
>> 
>>  2.  If the client tries to hide its physical location through a VPN,
>>        application proxy", as defined in [RFC1919], Section 3), but
>>        [RFC5389]checks will bypass the proxy and reveal the public
>>        address of the client."
>> 
> The document discusses #1 and #3 in detail, and outlines mechanisms that can be used to address these cases if needed.
> 
> If, despite the findings in the document, you think that these are indeed serious problems, it would be good to outline exactly why.
>> 
>> "we want to avoid solutions that disable WebRTC or make it harder to use."
>> 
> To my knowledge, the document addresses these goals. If you believe Firefox is not conforming, please file a bug; if you think the document is in error, please point out where and why.
>> 
>> 
>> 
>>> This is an important topic, and the group has reviewed this situation in detail. The results have been written up in this document, and to my knowledge most browsers that support WebRTC currently conform to its recommendations.
>>> 
>>> However, I'm not totally clear on your specific technical concern. You linked to an (now outdated) stackexchange page, but could you provide more detail about the specific situation you are concerned about?
>>> 
>>> Justin
>>> 
>>>> On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <[email-masked]> wrote:
>>>> To:  IETF RTCWeb WG
>>>> 
>>>> From:  Colin Gallagher
>>>> Request for New Security Review of WebRTC based on observed vulnerabilities in certain examples
>>>> 
>>>> Dear IETF RTCWeb WG,
>>>> 
>>>> This request relates to WebRTC.  The WebRTC is in draft at https://w3c.github.io/webrtc-pc/ and is described also at https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#WebRTC_interfaces
>>>> 
>>>> There are certain examples where the use of WebRTC has presented security vulnerabilities.  While not exhaustive, there are two I wanted to mention that I had been exposed to recently.
>>>> 
>>>> 1) The use of a video conferencing service which relies upon WebRTC (that is a well established service)
>>>> 2) The examination of a browser based WebRTC version of a decentralized exchange (that is currently under development)
>>>> 
>>>> In both cases the security vulnerability which is described below was the result of the use of WebRTC.
>>>> 
>>>> As per the first example (the video conferencing service), recently I came upon a vendor who shall remain unnamed who uses WebRTC as the backbone for their video conferencing service.  As a result, I found I was unable to access the service in question without disabling some security settings which I would have preferred to leave intact. 
>>>> 
>>>> My system is (based on what the aforementioned service detects) Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0.  This is Ubuntu 16.10 64-bit with Firefox 53.0.2.
>>>> 
>>>> However, quite some long while back I disabled WebRTC because of the security vulnerability (described in part here on information security stack exchange).  So as to mitigate this vulnerability, I changed settings in Firefox as follows:
>>>> 
>>>> I typed about:config in the address bar
>>>> I found the setting media.peerconnection.enabled
>>>> I set it to false
>>>> Unfortunately, this setting does not allow Firefox to work with the video conferencing service in question, which relies entirely on WebRTC.
>>>> 
>>>> So I had to go back in and change the media.peerconnection.enabled setting to true in Firefox in order to get it to work with the service in question. While this enabled me to conference with teams that desire to use the video conferencing service that rely wholly upon WebRTC, it concerns me because of the security vulnerability.
>>>> 
>>>> One suggested mitigation was having NoScript, but using NoScript was not helpful (you generally need to disable it for the site you are viewing that relies upon WebRTC, in order to obtain any functionality, and whether NoScript is off or on, WebRTC still causes the vulnerability of leaking information as previously described).
>>>> 
>>>> Furthermore, upon reload of the browser, even after setting media.peerconnection.enabled to true, the video conferencing service wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox and set it to expose my real IP address as well as allowing the following:
>>>> 
>>>> That seemed to me to be a direct consequence of the persistent and ongoing security vulnerability in WebRTC.
>>>> 
>>>> I contacted the video conferencing service provider and their solution was simply to state that "If the peer to peer connection is of concern, you can utilize our premium version which will route traffic through a forwarding server with in our environment that handles the processing of the video and sound of all users in the conference and send it to each user individually rather than using a peer to peer connection."  In other words, they expect that people should have to pay in order to mitigate this WebRTC security vulnerability, because they are unwilling to design to protect all users from it.
>>>> 
>>>> In a similar fashion, in the second example of the browser based WebRTC version of a decentralized exchange, the user's financial information is periodically exposed as a result of the information leakage which is presently caused by WebRTC.  (Fortunately, this browser based WebRTC decentralized exchange is under development and is not currently open to actual usage.)
>>>> 
>>>> Although undoubtedly this has been discussed here before, I am asking that WebRTC security issues be reconsidered and that a new security review be done to ameliorate or eliminate this problem in terms of WebRTC leaking this information.  It is my view that WebRTC should be further designed and developed with an eye to mitigating this serious problem, so that users of services which might rely partially or wholly upon WebRTC would not have to be concerned about such information leakage.
>>>> 
>>>> Respectfully,
>>>> 
>>>> Colin Gallagher
>>>> 
>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 May 2017 17:41:09 -0700

Based on your messages so far I am not clear what you are asking for the IETF RTCWEB WG to do. You have not filed any issues against the IP Handling document so it is not clear if you feel it needs to be changed or even what it is may sdonf. Nor are you posting your request to the SDO (W3C) that actually owns the API and reviews its privacy and security implications. 

> On May 26, 2017, at 11:14 AM, Colin Gallagher <[email-masked]> wrote:
> 
> It seems the consensus of the group here is essentially a refusal to further review and potentially redesign WebRTC to remove the serious security vulnerabilities that it presents to its users.
>