[liberationtech] [SPAM:###] Re: Google Unveils Tools to Access Web From Repressive Countries | TIME.com

[Lucas Dixon]

Hi,

I'm jumping in here a little late in this conversation, sorry for that,
been rather busy!

I thought it would be helpful to share some more of the thinking behind
uproxy.

Firstly, I think it's important to realize that it's still early days for
this effort. There's a bunch of things we thought were interesting to
experiment with, and a bunch of basic design goals (which I think are
pretty widely shared, although most people have different views on
different parts of the puzzle).

In terms of the combination of things that we're wanting to start the
uproxy experiment with, here's a short summary:

1. Try friend-to-friend discovery (rather than Lantern-style
Kaleidoscope-style). Moves the incentives structure around.
2. Moving the UI and Transport into the browser setting.
3. Have a pluggable transport, inspired by the work on obfsproxy (the goal
is not that WebRTC/DTLS is the visible transport).
4. ZRTP style of user-authentication.

The basic design concept is to separate discoverability from transport from
UI, so that we can play with each independently. But put the whole thing in
the browser setting, where, we think, we can make it more accessible. This
means we have a bigger code base to depend on and trust. So it's important
to understand the target users: the goal is to improve privacy, security,
and access for a large number of people. Threat models and presentation
matter.

Traffic obfuscation seems very important; otherwise DPI can block a service
as soon as it gets big. I also think it's important to explore combination
of cloud-based and P2P - you generally want to spread your collateral
damage as widely as possible. I'm was impressed by the usage stats for
goAgent.

So, there's quite a lot of different parts here, and I think there's lot of
interesting experiments to try. More generally, as Adam mentioned, I'm
hoping to the effort can develop some helpful generic modules so that many
tools can benefit and try out other experiments.

Final thing I wanted to say: I'm a big believer open-source, independently
reviewed code, and community engagement. So now we are public about working
on this, I'm very excited to be able to have a lot more conversations! :)

cheers,
lucas





On Thu, Oct 24, 2013 at 1:58 AM, Roger Dingledine <arma at mit.edu> wrote:

> 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
> udt transport".
>
> 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
> further.
>
> 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
> else here.)
>
> > 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:
> https://www.torproject.org/docs/bridges )
>
> >  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
> goal.
>
> 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
>
> https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges
>
> 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.
>
> --Roger
>
> --
> Liberationtech is public & archives are searchable on Google. Violations
> of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
>



-- 
Lucas Dixon | Google Ideas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20131024/dd546444/attachment-0001.html>