Search Mailing List Archives
[liberationtech] [SPAM:###] Re: Google Unveils Tools to Access Web From Repressive Countries | TIME.com
arma at mit.edu
Wed Oct 23 22:58:29 PDT 2013
On Tue, Oct 22, 2013 at 11:44:46PM -0700, Adam Fisk wrote:
> We do, however, strongly believe in the potential of WebRTC to provide both
> interesting cover traffic as well as usability improvements that come as a
> result of reusing technology already built into the browser.
I agree! I think the Flash Proxy people have already done some really
neat things with Websocket, and I look forward to seeing more use of
WebRTC in this area.
> Another really vital aspect to both Lantern and UProxy is blocking
> resistance, and particularly the idea that trust networks are a promising
> path forward in that regard.
Yep. I think using trust networks to solve the "how do I learn about a
proxy to use" question could work well for some (many) users. I haven't
looked at all the Lantern details lately, but if I had to guess it
would be Lantern's transport that falls first (to use the phrase from
one of the pluggable transport researchers who was looking at it today,
"udt encapsulated tls handshake is really easy to regex").
Now the point isn't to guess which part will be the weakest link. Or
to say "well ok if they write a DPI rule for it we'll fix it then". The
right goal imo would be to make it so it's easy to switch to the webrtc
transport, or obfs3, or something else that turns out to not be broken
at that time, while still using the same discovery mechanism.
In that sense uproxy as I understand it might be described as "the
lantern discovery mechanism, but with a webrtc transport rather than a
On the flip side if webrtc turns out to not have any background traffic
to blend with yet, the uproxy people would do well to make it easy for
them to pop in some other transport.
And if that flip side turns out to be how things unfold, saying phrases
like "uproxy's broken, lantern's better" will just confuse the situation
At this point it makes sense to say phrases like "the uproxy
people" and even "the current uproxy design", but thinking that when
uproxy-painted-white stops working your best bet is to throw it out
and find a new team to build you a red uproxy... that approach leads
to a lot of wasted money, and not as much forward progress as we could
have. Funders are slowly starting to get it, but as Shava points out,
journalists thrive on maintaining and growing this misunderstanding
about how good free-software engineering should work.
(I think Adam gets most of this, but I'm saying it out loud for everybody
> I think we're seeing this now with private Tor
> networks where bridges are distributed through trusted contacts, and that's
> exactly what we're after with both Lantern and UProxy.
Just to clarify, it isn't private Tor networks. It's one big public
Tor network (everybody needs to use the same one for anonymity),
but private bridges. (Bridges are basically unlisted relays
that let you use as your first hop to reach the public relays:
> The above quote I think
> is an unfortunate combination of a limited understanding of the technology
> and conversation with a reporter who will pick the juiciest sound bites,
> but it's clearly incorrect and just dangerous.
Right -- I think we're all getting more experience than we'd like this
year talking to journalists whose deadline is "in four hours" and who
have no interest in actually learning about the issues. :/
> > I would be more concerned with adversary externaly
> > observing the connections, seeing that a group of people from within
> > country X are connecting to the same ip in country Y , thus relating
> > those people in that group as sharing a node in a social graph, so to
> > each other, while they might not have seen them as related before..
> This is a concern that was discussed at some length yesterday at the Google
> Ideas Summit, and it's a really astute observation others have also made,
> most recently at CTS in Berlin. With Lantern it's considerably less of an
> issue because Lantern uses
> Kaleidoscope<https://github.com/getlantern/kaleidoscope> to
> also share connections of contacts who are not direct friends, in Lantern's
> case up to four degrees away. While that raises its own concerns in terms
> of proxying through essentially total strangers (again with blocking
> resistance as the goal), it does mitigate against social network mapping
> attacks. In both the UProxy and Lantern cases, however, there is more
> thought and research to be done, as it's not immediately obvious how
> significant it is that two people know the same person, particularly when
> that person is inherently living in another country that is uncensored.
> That is by no means an effort to dismiss the critique but rather an
> observation that the conclusions to draw aren't obvious at least to me.
Preventing or slowing the 'social network mapping' attack is an important
But this discussion also reminds me a lot of the "Zig-zag between bridges
and users" attack:
"Start with a set of known bridge addresses. Watch your firewall to
see who connects to those bridges. Then watch those users, and see what
other addresses they connect to. Wash, rinse, repeat."
You can read more about it as attack #10 at
In the Lantern / uProxy case I could probably speed the attack by feeding
users a cookie on one of the censored websites (or a component the
website draws in like an ad network), and then making a list of other
addresses whose requests include that cookie. (But here I am making a
point about how ignoring privacy will harm your circumvention tool, and
you've already declared that you're a circumvention tool not a privacy
tool, so I'll put that point aside for now. :)
I wonder how much change Kaleidoscope would need to implement the 'cells'
idea in the blog post. As you say, much research remains.
More information about the liberationtech