Subject: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO)

From: carlo von lynX <[email-masked]>
Date: Wed, 5 Aug 2015 18:13:45 +0200

Last chance to rebuke the following paragraph or
to introduce a prompt that says something like
"Do you want to allow <domain> to activate direct/
P2P communications?" before I go noisy...

>From https://webrtchacks.com/webrtc-notify/
> Nefarious websites could potentially use this information to fingerprint individuals who do not want to be tracked.

That is not the main concern. Nefarious websites could systematically gather which visitors are using VPNs or Tor… which in some countries indicates they are very probably dissidents. With the real IP address in the pockets the authorities can go visit the potential dissident and see what she or he has been up to. They will most probably find evidence on the computer since dissidents in poor countries aren't particularely educated in operational security. Therefore a plugin that they first need to know about will not fix the problem in time. Thousands (or according to the other poster, millions) may be endangered by the introduction of WebRTC… even if these people never asked for any WebRTC in their browsers and weren't planning to use it for anything.

-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/

---

From: Benjamin Schwartz <[email-masked]>
Date: Wed, 5 Aug 2015 12:37:11 -0400

Tor does not claim to protect against hostile websites unless you are using
the Tor Browser Bundle, which is not subject to this issue (it already
disables WebRTC).

Hyperbole is not a helpful tactic here.

On Wed, Aug 5, 2015 at 12:13 PM, carlo von lynX <
[email-masked]> wrote:

> > Nefarious websites could potentially use this information to fingerprint
> individuals who do not want to be tracked.
>
> That is not the main concern. Nefarious websites could systematically
> gather which visitors are using VPNs or Tor… which in some countries
> indicates they are very probably dissidents. With the real IP address in
> the pockets the authorities can go visit the potential dissident and see
> what she or he has been up to. They will most probably find evidence on the
> computer since dissidents in poor countries aren't particularely educated
> in operational security. Therefore a plugin that they first need to know
> about will not fix the problem in time. Thousands (or according to the
> other poster, millions) may be endangered by the introduction of WebRTC…
> even if these people never asked for any WebRTC in their browsers and
> weren't planning to use it for anything.
>
>
> --
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: carlo von lynX <[email-masked]>
Date: Wed, 5 Aug 2015 18:42:57 +0200

> the Tor Browser Bundle, which is not subject to this issue (it already

Disclaimers are irrelevant here. The question is what the dissidents
are using. Probably they are using Chrome with VPN, or Firefox and VPN.
>From what I heard they aren't even using Tor. Maybe we should ask the
libtech folks what these people are actually using - but from the
last things I learned at the OpenITP meetings that would be it.

> Hyperbole is not a helpful tactic here.

Friendly people seem to be even easier to ignore on unconfortable
topics.

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 05 Aug 2015 10:11:06 -0700

I don't believe this is how the IETF document editing process works. 
Please work with the authors on suggested changes, or submit a draft of 
your own.

Matthew Kaufman

---

From: Adam Roach <[email-masked]>
Date: Wed, 05 Aug 2015 13:07:10 -0500

On 8/5/15 11:42, carlo von lynX wrote:
> Disclaimers are irrelevant here.

Bad advice is bad advice. If someone went around spreading the notion 
that one can protect one's identity with Tor or with a VPN running on 
the same machine as the browser, then that's no better than someone 
asserting that one can protect one's identity by disabling IPv6, running 
an ad blocker, using "private browsing mode," or wearing a hat coated 
with aluminum foil. This was true before WebRTC, and it would remain 
true if we removed every trace of WebRTC from the planet.

If you're really interested helping the parties you're expressing 
concern for, and you have the energy to "go noisy" on a topic, your 
efforts would be best spent evangelizing TorBrowser or some other 
solution that provides some semblance of useful anonymity.

I have sympathy for the problem you're highlighting, but your 
histrionics are undermining your point. We're trying to figure out a way 
to throw out the bathwater while keeping the baby. Your suggestion that 
we instead nuke the bathtub makes you sound like a kook.

/a

---

From: Daniel Roesler <[email-masked]>
Date: Wed, 5 Aug 2015 15:54:13 -0700

While I'm not a fan of Carlo's antics, his concern is very valid and
in my opinion it is highly concerning that members of this group are
attacking his discourse and dismissing his point.

Here's my understanding of his point:

Before WebRTC:
1) Live in oppressive country
2) Buy one of the many popular anti-censorship VPNs
3) Visit NYTimes.com
4) Real IP address not accessible to NYTimes or advertisers

After WebRTC:
1) Live in oppressive country
2) Buy one of the many popular anti-censorship VPNs
3) Visit NYTimes.com
4) Real IP address is leaked to NYTimes and advertisers

Adam, can you please explain how this was possible before WebRTC?

The threat model here is not a targeted attack looking to fingerprint
a specific person. The threat model is that an oppressive regime can
now find the exact IP address of censorship circumventing dissidents
in their country by buying advertising on websites. This constitutes a
real life-threatening scenario for many dissidents across the world. I
completely understand why one would be quite mad at this working group
for not acting when their life or friends'/family's lives are
potentially on the line.

Daniel

On Wed, Aug 5, 2015 at 11:07 AM, Adam Roach <[email-masked]> wrote:
> Bad advice is bad advice. If someone went around spreading the notion that
> one can protect one's identity with Tor or with a VPN running on the same
> machine as the browser, then that's no better than someone asserting that
> one can protect one's identity by disabling IPv6, running an ad blocker,
> using "private browsing mode," or wearing a hat coated with aluminum foil.
> This was true before WebRTC, and it would remain true if we removed every
> trace of WebRTC from the planet.
>
> If you're really interested helping the parties you're expressing concern
> for, and you have the energy to "go noisy" on a topic, your efforts would be
> best spent evangelizing TorBrowser or some other solution that provides some
> semblance of useful anonymity.
>
> I have sympathy for the problem you're highlighting, but your histrionics
> are undermining your point. We're trying to figure out a way to throw out
> the bathwater while keeping the baby. Your suggestion that we instead nuke
> the bathtub makes you sound like a kook.
>
> /a
>
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 5 Aug 2015 19:17:33 -0400

> attacking his discourse and dismissing his point.

I am sorry, but what exactly do you or Carlo actually want?

This group is not internet police. It cannot stop existing browser
behavior. All this group can do is to adjust the standard, which it is
already doing. If it is not doing it fast enough, well, it does not do
anything fast. IETF is not designed for this. If you want to be productive,
propose something and it will be discussed. This is all this group does --
discuss things and sometimes puts them into recommendations, which people
can choose to follow (this is why they are called Requests For Comments,
not laws written in stone).

Also, anything that has anything to do with browser UI actually is not
discussed here. It is managed by W3C. All the discussions on what should
ask for user permission actually needs to go there.

So all Carlo' comments are being dismissed because they are out of place
and out of order, not because the topic is unimportant. His tone does not
help either.
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Aug 2015 16:42:50 -0700

Daniel,

> attacking his discourse and dismissing his point.
​No one is dismissing the issue, and both Chrome and Firefox have worked on
code to provide short-term solution​s (see this work
<https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia/reviews?hl=en>
Justin pointed out to the list and Maire Reavy's post
<https://groups.google.com/forum/#!topic/mozilla.dev.media/L6Rx9ubSjMc>.)

The group is actively discussing this topic and how to manage this going
forward.  A number of technical challenges have been pointed out (both in
VPN configuration and the availability of information on network type to
the browsers).  Continuing to point out the severity of the problem in
threads trying to resolve the problem is not helping progress; code, text,
or data would.

​regards,

Ted Hardie​

​

​

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 05 Aug 2015 17:46:47 -0700

> 4) Real IP address not accessible to NYTimes or advertisers

Unless you have Flash Player 10.0 or later installed, in which case 
RTMFP and a cooperating server does this.

Or you have any number of other plugins (e.g., Java) installed which 
can/will do this.

Or NYTimes.com or an advertiser on there (or the proxy the oppressive 
country you live in transparently runs at the border) injects any number 
of zero-day drive-by attacks, any of which would give full access to 
your machine, including the ability to reveal the IP address (ref: 
http://www.zdnet.com/article/fbi-used-hacking-team-services-to-unmask-tor-user/ 
or 
https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable). 
They'd probably also do other evil things, but it'd start by revealing 
your IP address.

And that's if you simply limit to the browser case. In reality, before 
WebRTC you probably had one or another P2P applications, including 
possibly VoIP apps with P2P media capabilities, which are also routinely 
exposing the full set of addresses you have.

> Adam, can you please explain how this was possible before WebRTC?

I'm not Adam, but see above.

> for not acting when their life or friends'/family's lives are

This working group isn't empowered to "act when their life or 
friends'/family's lives are potentially on the line". This is one of 
*two* working groups producing standards. One might think that these 
standards are being followed by the browser vendors, but in point of 
fact the browser vendors are writing and releasing code ahead of the 
publication of the standards, or in fact before full discussion has 
taken place here or in the corresponding W3C working group.

If one of the IETF drafts itself poses a risk, please follow the 
processes we have for making changes to those documents prior to them 
becoming RFCs. In the meantime, to actually get this changed, that's up 
to the browser vendors to evaluate.

Matthew Kaufman

---

From: Adam Roach <[email-masked]>
Date: Wed, 05 Aug 2015 21:31:28 -0500

> I'm not Adam, but see above.

Thanks -- I think you covered the direct vectors pretty well.

There are more subtle attacks than these, depending on the 
sophistication of your adversary; the "Anonymity and Security" section 
of the Tor FAQ [1] talks through some of these, many of which are 
applicable to VPNs at least as much as they are to Tor. I would 
highlight, in particular, the question titled "Is Tor like a VPN?".

And lest the concerns about VPNs being a single point of privacy failure 
seem esoteric or far-fetched, I'll point out that they're far from 
theoretical [2].

/a

____
[1] https://www.torproject.org/docs/faq.html.en
[2] A lot of electronic ink has been spilled on this one incident: 
https://encrypted.google.com/search?q=lulzsec+logs+nsa -- and, 
naturally, none has been spent on the cases that haven't come to light.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 6 Aug 2015 00:38:29 -0400

On 8/5/2015 7:17 PM, Roman Shpount wrote:
> On Wed, Aug 5, 2015 at 6:54 PM, Daniel Roesler <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> anything fast. IETF is not designed for this. If you want to be 
> productive, propose something and it will be discussed. This is all 
> this group does -- discuss things and sometimes puts them into 
> recommendations, which people can choose to follow (this is why they 
> are called Requests For Comments, not laws written in stone).
>
> discussed here. It is managed by W3C. All the discussions on what 
> should ask for user permission actually needs to go there.

And per the announcements made on discuss-webrtc (the mailing list not 
involved with the standards process), both Chrome and Firefox are moving 
forward with enabling trial mitigations ahead of any changes in the 
standards.  The current efforts are steps towards final solutions, so we 
can find out what the impacts are, and in the process make it possible 
for people to thwart such de-anonymizations proactively.  Also: a 
government such as you describe can *trivially* determine who is using a 
VPN by simply buying their own accounts, looking at the VPN endpoint 
addresses, and monitoring traffic to those IP/IP-ranges from ISPs within 
their country.  Tor avoids (some) of this type of attack, among other 
things.

I'll note that anyone trying to be anonymous needs to actually follow 
some sort of advice on how to do so; they don't suddenly have a 
light-bulb go on and say "I need a VPN!".  The default of browsers isn't 
"safe" for dissidents/etc.  We can enable people to be (more, not 
totally) "safe", but we do need to balance that against other concerns.  
The advice given to people may need to change (use a VPN *and* this 
extension, or use a VPN *and* use private browsing mode - which BTW 
would likely be really good advice anyways! etc.    Or (gasp) use the 
Tor browser bundle on a bootable USB stick (NOT on your HD!)  (Note: We 
may well turn some of these mitigations on by default in private 
browsing mode, for example.)

We can't make all "I think/hear I should be safe if I ..." methods users 
may be using actually *be* safe, though.   See Adam's and Matthew's 
responses.

We're also totally willing to consider other technical solutions, here 
or via a personal draft - though some might have to wait for additional 
spec updates - but as with most of WebRTC, the browsers have been way 
out ahead of the spec.  Realize that if the suggestion is "disable the 
feature for the entire web", or to make it effectively unusable, it's 
not a good suggestion - and ironically may enable more control of 
populations by control of the remaining communications channels (phones, 
etc).  WebRTC also has the potential to be leveraged into something that 
can bypass all sorts of authoritarian controls, and various forms of 
monitoring (using end-to-end encryption, Identity, and low-latency/cheap 
DataChannels), and people are working on such tools.

>
> So all Carlo' comments are being dismissed because they are out of 
> place and out of order, not because the topic is unimportant. His tone 
> does not help either.

Agreed.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: Michael Davey <[email-masked]>
Date: Thu, 6 Aug 2015 15:55:21 +0100

Ted,

Many thanks for your excellent email.  I don't much care for the way that
Carlo is going about trying to instigate change but as an outsider looking
in on this interesting WebRTC project, an acknowledgement of this issue and
the calm, constructive and pragmatic tone of your email is exactly what
*I've* been hoping & waiting for.

On 6 August 2015 at 00:42, Ted Hardie <[email-masked]> wrote:

> ​No one is dismissing the issue, and both Chrome and Firefox have worked
> on code to provide short-term solution​s (see this work

---

From: carlo von lynX <[email-masked]>
Date: Fri, 7 Aug 2015 22:07:07 +0200

> ​No one is dismissing the issue, and both Chrome and Firefox have worked on

I can point you to several mails that did just that.

> <https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia/reviews?hl=en>

The problem are users of popular browsers that by default suddenly
started leaking real IP numbers even when combined with VPN. The
fact that these folks now need to install some extra add-ons is
both an educational nightmare as a way to single them out.

> <https://groups.google.com/forum/#!topic/mozilla.dev.media/L6Rx9ubSjMc>.)

Same problem. As long as the default is to let external providers
have the real IP, any website can be used to uncover dissidents.

Maybe people doing this kind of work should first discuss with us
what they intend to do so that we can tell them what works and what
is pointless.

> threads trying to resolve the problem is not helping progress; code, text,

What the people need to survive is a big fat pop-up prompt asking
them whether they want to share their real IP with the website
asking for it.

It's really not complicated.

So I still don't see why I am not granted the right to be angry.

---

From: carlo von lynX <[email-masked]>
Date: Fri, 7 Aug 2015 22:54:59 +0200

> RTMFP and a cooperating server does this.

Which oppressive regimes did not know until you wrote it here.
Excellent. Now we can only hope that most installations have
already trashed the Flash plugin, otherwise we have yet another
big problem.

If it is correct that you are the author of the technically
quite remarkable RTM*P protocol family, respect to you from
a technical perspective but I must also thank you for having 
created a major problem and admitting it only in the process 
of dealing with another major problem. From my perspective
you are making a very cynical impression if the risk of
people getting jailed or killed leaves you this cold.

> Or you have any number of other plugins (e.g., Java) installed which

Java of course has an API for this at
    https://docs.oracle.com/javase/tutorial/networking/nifs/index.html
but https://docs.oracle.com/javase/tutorial/deployment/applet/security.html
doesn't sound like those enumeration APIs are available to plain applets.

We want facts, not allegations.

> Or NYTimes.com or an advertiser on there (or the proxy the
> oppressive country you live in transparently runs at the border)

Man-in-the-middle attacks systematically on all international connections?
We would have heard of that. I'm the author of Certificate Patrol and only
rarely do I receive news of certs actually getting falsified. You must
already be a target to experience that, and in that case it is easier for
such governments to simply visit you at home.

> injects any number of zero-day drive-by attacks, any of which would

Can those countries afford to buy zero-day backdoors? And can they
systematically detect dissidents this way? No they can't - because
using zero-day backdoors in drive-by attacks on the entire population
in order to be able to detect dissidents would enable some people
to detect the operation, talk about it and report the zero-day so
that it be fixed upstream.

So what you describe here would be an effective way to waste an
expensive zero-day without achieving anything of the intended goal.
But thanks for starting to think about the scenario at all.

> give full access to your machine, including the ability to reveal
> the IP address (ref: http://www.zdnet.com/article/fbi-used-hacking-team-services-to-unmask-tor-user/

Please, Matthew. Read the articles you post before posting them.
Of course authorities can find out the real IP *if they have*
*already compromised the target's system*. So that is completely
outside the scenario that I have brought up. The FBI merely asked
an embarassangly incompetent question.

> or https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable).

Again irrelevant since the people we are talking about in the
scenario aren't using TBB.

> They'd probably also do other evil things, but it'd start by
> revealing your IP address.

Nope, none of the methods you listed are as dangerous as WebRTC
and... since a few days also Flash!

> And that's if you simply limit to the browser case. In reality,
> before WebRTC you probably had one or another P2P applications,
> including possibly VoIP apps with P2P media capabilities, which are
> also routinely exposing the full set of addresses you have.

Sure, dissidents may even be using Skype while also having a
VPN configured for their browser, but Skype does not expose 
the VPN IP if it isn't configured to use it, so the correlation 
fails. Why don't you think harder of the things you write?

> >for not acting when their life or friends'/family's lives are

Excellent, Daniel! I hadn't thought of the scenario that a government
could simply buy advertising instead of having to lure people onto
their own websites. That makes the scenario I described even worse.

> friends'/family's lives are potentially on the line". This is one of

Eh well, I think there one or two RFCs out there that give some
ethical guidelines to *all* working groups, and you shouldn't
lightheartedly dismiss those.

> taken place here or in the corresponding W3C working group.

Yes, which is putting people's lives in danger. So please stop
argueing and simply get them to put a pop-up warning in their that
asks the users whether a website is allowed to bypass the regular
networking routes.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Aug 2015 14:23:14 -0700

> them whether they want to share their real IP with the website
​
This working group discusses the wire protocols for WebRTC.  As noted
above, folks are actively gathering data on what changes to those might
help here and what the impact of each possibility is on the rest of the
operation of the protocol machinery.

If you wish in the mean time to discuss issues of warnings which might come
from browser chrome, you are not talking to the right group.

regards,

Ted Hardie​

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 07 Aug 2015 15:37:28 -0700

> asks the users whether a website is allowed to bypass the regular 

This IETF working group cannot "simply get them" to do *anything*. 
That's not how standards bodies work.

Now, if you'd like to write a draft, or submit changes to the security 
considerations draft, that would be welcome.

Matthew Kaufman

---

From: carlo von lynX <[email-masked]>
Date: Sat, 8 Aug 2015 10:35:29 +0200

On Thu, Aug 06, 2015 at 12:38:29AM -0400, Randell Jesup wrote:
> proactively.  Also: a government such as you describe can
> *trivially* determine who is using a VPN by simply buying their own
> accounts, looking at the VPN endpoint addresses, and monitoring
> traffic to those IP/IP-ranges from ISPs within their country.  Tor
> avoids (some) of this type of attack, among other things.

If VPN has been working for dissidents so far apparently this
*trivial* method didn't work out. It would only show which people
use that specific brand of VPN, but not serve to de-anonymize
specific users, if I understand your scenario correctly.

> I'll note that anyone trying to be anonymous needs to actually
> follow some sort of advice on how to do so; they don't suddenly have
> a light-bulb go on and say "I need a VPN!".  The default of browsers

Sometime during before arab spring word got around on how to do it.
It may be difficult to "update" this word because browsers suddenly
changed their safety features, downgrading a previously safe config
into a dangerous one.

> isn't "safe" for dissidents/etc.  We can enable people to be (more,

Used to be, actually... whatever browsers did, they used to respect
proxy configurations. WebRTC is the thing that thinks it can bypass
proxy and roll its own networking. Maybe it should be disabled by
default whenever any sort of proxy is configured.

> not totally) "safe", but we do need to balance that against other
> concerns.  The advice given to people may need to change (use a VPN
> *and* this extension, or use a VPN *and* use private browsing mode -

Nobody has a list of all dissidents, so the info travels word by
mouth. Risk too high of arriving too late if a new threat is
*deliberately* introduced on a formerly working configuration... 
That is so against user expectations as can be.

> which BTW would likely be really good advice anyways! etc.    Or
> (gasp) use the Tor browser bundle on a bootable USB stick (NOT on
> your HD!)  (Note: We may well turn some of these mitigations on by
> default in private browsing mode, for example.)

Yes, that would be good.. although I'm not sure if the traffic
of a TAILS or such is sufficiently *different* from regular
users that it can bring you trouble. I don't dare to speak for
them on anything like this - I just presume that breaking a
formerly safe configuration is a VERY BAD IDEA.

> We can't make all "I think/hear I should be safe if I ..." methods
> users may be using actually *be* safe, though.   See Adam's and
> Matthew's responses.

Which both didn't quite cut it. The problem is that people
expect a formerly safe construct to remain safe. It's bad
enough if new bugs are found.. but deliberately breaking the
security that people are relying on is rather.. reckless.

> We're also totally willing to consider other technical solutions,
> here or via a personal draft - though some might have to wait for
> additional spec updates - but as with most of WebRTC, the browsers
> have been way out ahead of the spec.  Realize that if the suggestion

And it is to be expected that these browser developers are
reading in on this thread and may possibly understand that having
optional add-ons does not tackle the problem at all.

> is "disable the feature for the entire web", or to make it
> effectively unusable, it's not a good suggestion - and ironically

Lives should be put in the first place, or otherwise you are
actively promoting cynical thinking. But actually it's enough
to extend the permission pop-up from mic/cam to also proxy-
bypassing networking... I would assume that there are ways for
the browsers to figure out if they are supposed to go through
a SOCKS or other proxy and therefore automatically disable 
interface listings. So it is *really not that hard* and it
could have been fixed about a year ago already!

> may enable more control of populations by control of the remaining
> communications channels (phones, etc).  WebRTC also has the

Eh? Regimes do not start abusing another channel when one
no longer works.. they abuse everything they can afford to abuse.
FireChat works in Hong Kong because it doesn't use the Internet,
but which things work in which place depends on a lot of parameters
that are to a large extend unresearched. The circumvention folks
are the experts in this area. Browser vendors should talk this
out with them before coding up random things to make a good
impression but without achieving anything. Tactical tech could
be suitable people to interact with.

> potential to be leveraged into something that can bypass all sorts
> of authoritarian controls, and various forms of monitoring (using
> end-to-end encryption, Identity, and low-latency/cheap

The assumption that the server providing the JS code can be kept
in safe conditions remains one weak point of this architecture.
Also the lack of an evolved built-in distributed hashtable system.
There are reasons why tools like GNUnet took 12 years to be
developed. WebRTC doesn't provide 5% of the necessary code to
do proper end-to-end encrypted, sybil-attack resistant P2P.

> >place and out of order, not because the topic is unimportant. His
> >tone does not help either.
> 
> Agreed.

Sorry for the tone that has worked so far to get you out of
complacency but you haven't successfully rebuked any of my 
"comments."

---

From: carlo von lynX <[email-masked]>
Date: Sat, 8 Aug 2015 10:46:38 +0200

On Fri, Aug 07, 2015 at 03:37:28PM -0700, Matthew Kaufman wrote:
> Now, if you'd like to write a draft, or submit changes to the
> security considerations draft, that would be welcome.

I take this as a long-awaited acknowledgment that the danger
scenario for dissidents truly exists and truly is introduced
by the WebRTC API.

That was the answer I seeked out to get several months ago
when I first came here to ensure this scenario is being dealt
with.

Now it wasn't my intention to spend all this time on it. Feels 
like I opened Pandora's box by asking unwelcome questions.

Now that you understood the problem, can I count on you to
work things out or do I need to get my hands dirty and
co-author IETF documents? Do you really want that?

---

From: Randell Jesup <[email-masked]>
Date: Sat, 8 Aug 2015 15:24:39 -0400

> specific users, if I understand your scenario correctly.

It will show you who's using different VPNs (traffic analysis can likely 
correlate VPN use with inbound traffic to specific sites: put a content 
(or an ad) on a site with a specific set of images, and then correlate 
fetches of those and the sizes/timings with traffic to/from the VPN, and 
you can (close enough for this work) deduce who's using a VPN to browser 
these sites.  If you have the data, it's not hard.  This is not 
NSA-level analysis; any moderately competent network programmer could 
work out how to implement it given access to packet logs of VPN traffic 
from ISPs, which one has to presume they can get.   Similar attacks have 
been made on Tor IIRC, but side-effects and design features of Tor make 
this attack harder (not impossible IIRC) against it.

> changed their safety features, downgrading a previously safe config

Well, things change, and not just browsers.  People intercepting traffic 
learn new tricks too.   Freezing the world because people may rely on 
outdated info is not a great answer.  Finding a way to update the info 
they rely on is a much better answer.  I do understand the concerns.   
Part of the answer may be to have tighter controls by default in Private 
Browsing mode (which they really, really should be using before they 
even get to the point of thinking of a VPN, otherwise someone says "give 
me your computer" (or even "let me see your computer history", and 
you're sunk).

> default whenever any sort of proxy is configured.

Proxies were never intended as a security or anonymity  measure for 
users; they were created because many organizations used proxies to a) 
limit traffic in/out of their network, and b) they used proxy-caches 
(like Squid) to reduce bandwidth by providing a large, shared cache to 
an organization.   Transparent proxies mostly replaced b.  HTTPS traffic 
bypasses (or at least just gets piped through) proxies, of course.  That 
people found another way to use them is cool, but don't assume their 
security properties match the use-case of the users, since it's not part 
of the design.

> That is so against user expectations as can be.

There is this thing called the web, where information on 
best-security-practices for dissidents can be WIDELY published, and then 
those who have it can tell others; exchange thumbdrives, etc. I've heard 
the web is effective for this.

> optional add-ons does not tackle the problem at all.

You should realize many of the people speaking on this thread largely 
*are* the browser developers (though this group is not the one that 
defines the interfaces and UI requirements, just the on-wire protocols).
> in safe conditions remains one weak point of this architecture.

No, it's assumed for this sort of thing you may bootstrap from servers, 
but that the code can be stored and run from local storage.  No central 
server at all.  (Which means no single-point-blocking ala twitter/etc).

---

From: carlo von lynX <[email-masked]>
Date: Sun, 9 Aug 2015 18:43:12 +0200

On Sat, Aug 08, 2015 at 03:24:39PM -0400, Randell Jesup wrote:
> It will show you who's using different VPNs (traffic analysis can
> likely correlate VPN use with inbound traffic to specific sites: put
> a content (or an ad) on a site with a specific set of images, and
> then correlate fetches of those and the sizes/timings with traffic
> to/from the VPN, and you can (close enough for this work) deduce
> who's using a VPN to browser these sites.  If you have the data,
> it's not hard.  This is not NSA-level analysis; any moderately
> competent network programmer could work out how to implement it
> given access to packet logs of VPN traffic from ISPs, which one has
> to presume they can get.   Similar attacks have been made on Tor
> IIRC, but side-effects and design features of Tor make this attack
> harder (not impossible IIRC) against it.

Yes, with a person as competent as you this attack scenario is
likely. So far governments of such countries are unlikely to have
the necessary competence to correlate traffic like that. Hey, we
are talking of governments not competent enough to develop something
trashy like "Galileo." They rather buy it!
 
> Well, things change, and not just browsers.  People intercepting
> traffic learn new tricks too.   Freezing the world because people

You are responsible of THIS specific change and the solution is
really simple. WHY do you want to pursue something that puts
lives at risk if you can simply fix the problem? WHY are you
spending so much time trying to find excuses for yourself and
everybody in the WebRTC business?

I am fully aware of being the only person in here without a
business interest in WebRTC, so I'm not surprised if I'm fighting
this battle alone.

> may rely on outdated info is not a great answer.  Finding a way to
> update the info they rely on is a much better answer.  I do
> understand the concerns.   Part of the answer may be to have tighter

First you make the browser safe by being conservative in the way
it does networking in the case of proxy configuration, if necessary
also with an additional pop-up.. then you spend some time and money
to get in touch with people who *WORK* with dissidents in those
countries everyday (you can even get in touch with several US
government institutions on that topic!) and find out *IF* you can
figure out a solution that suits your business interests better.

But don't go the Monsanto way of first breaking everyhing and then
only stepping half a step back if all of the world got angry.

> controls by default in Private Browsing mode (which they really,
> really should be using before they even get to the point of thinking
> of a VPN, otherwise someone says "give me your computer" (or even
> "let me see your computer history", and you're sunk).

They may be using Private Browsing mode. Is WebRTC fully disabled
in PBM?

> Proxies were never intended as a security or anonymity  measure for

That doesn't matter. You can't tell those young folks that ran the
Tunesian revolution that they shouldn't have done it because they
used proxies in an unintentional way.

> users; they were created because many organizations used proxies to
> a) limit traffic in/out of their network, and b) they used
> proxy-caches (like Squid) to reduce bandwidth by providing a large,
> shared cache to an organization.   Transparent proxies mostly
> replaced b.  HTTPS traffic bypasses (or at least just gets piped
> through) proxies, of course.  That people found another way to use
> them is cool, but don't assume their security properties match the
> use-case of the users, since it's not part of the design.

So your idea of business ethics is - if you used it to fight for
democracy in your country you are on your own because we have
other plans. Your revolution doesn't fit our business plan.

> best-security-practices for dissidents can be WIDELY published, and
> then those who have it can tell others; exchange thumbdrives, etc.
> I've heard the web is effective for this.

Only if they can access the web safely.. if the Chrome update comes
before those websites written in their respective languages are updated,
then authorities will have a way to find out who accesses those websites
before they can fix their setups.

Boom, doomed by having used the web for exactly what you describe.
Your logic is circularely flawed.

> You should realize many of the people speaking on this thread
> largely *are* the browser developers (though this group is not the
> one that defines the interfaces and UI requirements, just the
> on-wire protocols).

Which is good, so we are walking through all possible reasons not
to fix the browser - one by one. By showing you how none of them
really handle the problem or make the problem go away, we slowly
get you to understand how serious the issue is and how much it is
insufficient or unethical to just offer some optional plugin for 
a few paranoid nerds.

> No, it's assumed for this sort of thing you may bootstrap from
> servers, but that the code can be stored and run from local storage.
> No central server at all.  (Which means no single-point-blocking ala
> twitter/etc).

So far all server bootstrap architectures implied that servers can
MITM the communication. And then Snowden says metadata protection
is the most important thing - and WebRTC has not a vague clue on
how to fix that.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Aug 2015 02:40:04 +0100

On 08/08/15 09:46, carlo von lynX wrote:
>  do I need to get my hands dirty and

Yes. Of course we want that. People have said it >1 time.

That is how we do stuff and part (not all) of the reason
why you've been having a hard time getting change - when
someone says "hey you over there need to do some work I've
defined" I think it's safe to say that generates a negative
reaction from IETFers.

That said, for you crafting text to work in *this* context,
you'd have to not be in clean-slate mode whilst writing that
specific text:-)

S.

---

From: carlo von lynX <[email-masked]>
Date: Tue, 11 Aug 2015 22:37:04 +0200

> Yes. Of course we want that. People have said it >1 time.

Then I need to know if there actually is a consensus on
the practical recommendation of
    - disabling the network interface API when proxy is configured
    - otherwise asking user for permission to access such API

And if it's just words in a working draft of something or
if browser vendors will care to comply.

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 11 Aug 2015 21:01:56 +0000

Hi,

You have a choice here I think:

A) Go for a solution draft detailing exactly how this should look like.
You may need to cover both IETF RTCWEB WG as well as W3C WebRTC WG. Often
this requires a considerable amount of work, consensus and often also
experimentation. Not saying that that must be the case here but...

B) Make an informational draft about the problem(s) with some example use
cases/deployments. May also include a chapter of proposed solutions as
input to discussion.

Have this question socialized/discussed at IETF94 Yokohama. Perhaps in the
RTCWeb WG or the SaaG-meeting using the ‘draft’ as input.

I think putting down this discussion in a brief (less is more You know)
draft will be helpful to move this forward.

Regards
Göran

-----Original Message-----
From: rtcweb <[email-masked]> on behalf of carlo von lynX
<[email-masked]>
Date: Tuesday 11 August 2015 22:37
To: IETF RTCWEB <[email-masked]>
Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents
with WebRTC (HOWTO)

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Aug 2015 16:59:41 -0500

>      - disabling the network interface API when proxy is configured

I'm not sure this has been discussed in earnest here or elsewhere. 
There's been some discussion of maybe pushing all RTP traffic through am 
HTTP proxy when one is configured [3], but this has been highly 
controversial.

The problem is that, while HTTP proxies were designed with a number of 
purposes in mind -- see page 10 of [1], and section 2 of [2] -- none of 
them were "making it appear that a user is in a different part of the 
network than he really is." They can be *used* to do that (with a lot of 
caveats [3]), but their primary purposes lie elsewhere.

What you're advocating only makes sense in the context of appearing to 
come from a part of the network that you're not in. It's kind of a 
tail-wagging-the-dog approach: if you're using proxies for their 
designed purpose, then this disabling is not what you want to happen. In 
the intended use cases, what you want is the ability to discover some 
kind of local TURN server that does for RTP what HTTP proxies are 
designed to do for HTTP (again, see section 2 of [2]).

However, that raises a potentially interesting approach. One of the 
things we're working on in the TRAM working group is exactly this kind 
of TURN server discovery. If we had some means of learning this from a 
configured HTTP proxy (and a means of this field saying "and only use 
relayed candidates"), then the web browser might be able to use it as an 
alternate discovery mechanism. If we add this kind of discovery, then 
proxies that are deployed for the purposes you care about -- appearing 
to come from a different part of the network than the one you're in -- 
can point your browser to a TURN server that is colocated with the HTTP 
proxy. That way, WebRTC traffic will originate from the same point in 
the network as HTTP traffic. It also seems possible that we could 
include some way for this field to basically say "don't use WebRTC if 
you're using this proxy."

>      - otherwise asking user for permission to access such API

Based on discussions that I've seen so far, I believe that more people 
oppose such a proposal than support it -- but it's not clear to me that 
there's consensus in either direction. It's easier to call for consensus 
around text in an internet-draft, though, than suggestions in an email. 
At the very least, it would be the first step in determining what kind 
of compromise might be reached.

/a
____
[0] 
https://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03
[1] https://tools.ietf.org/html/rfc7230
[2] https://tools.ietf.org/html/draft-nottingham-http-proxy-problem-01
[3] For example, what would you make of a connection that originates 
from an IP address in Ireland, but has a date that appears to be in 
UTC+3:30, and a language setting of "fa-IR"?