Ending Censorship, P2P-style.
I love it when people find unexpected uses to WebRTC. This one is just such a case. I’d like to thank @aswath for pointing this one out.
Lantern is about getting uncensorted internet access to countries with oppressive governments. To do so, it used P2P networking and an app that acts as a proxy for internet traffic. The interesting thing about it is that it adopted WebRTC technologies to do so and with good reasons.
Adam Fisk, President and CEO of Lantern, took the time to answer some my questions about this interesting service.
What is Lantern all about?
The core concept behind Lantern is that crowdsourcing access to the open Internet is one of the few promising paths forward for bypassing censors in consistently and sustainably blocking resistant way. Lantern makes it easy for anyone in the uncensored world to quickly and easily make their Internet connection available as a gateway to blocked content.
For a downloadable app that just needs connectivity, why bother with WebRTC?
WebRTC offers a number of advantages. First, Lantern relies on peer-to-peer connections to make ordinary users available from their home connections as proxies/access points, and WebRTC’s use of ICE to provide that connectivity across heterogeneous networks is as good as any implementation out there. In fact, there’s a distinct scarcity of good libraries devoted specifically to NAT and firewall traversal, and the Lantern team has parceled out specifically that piece from the WebRTC code base in a library called Natty, available at http://natty.io/.
Beyond simple connectivity, WebRTC also offers cover traffic. Because WebRTC is integrated into the browser, ICE is now a common protocol seen on the Internet. Lantern seeks to blend in with this traffic, forcing censors to block ICE if they want to block Lantern. WebRTC provides what we call cover traffic for Lantern.
Why not go for a browser extension model instead of an app?
Censoring governments have incredible technical capacity at their disposal at every level from hardware to software to human expertise. They have visibility into all traffic coming into and out of the country. While JavaScript in the browser has made incredible progress in recent years, Lantern uses a number of technologies written in different languages, including Go, Python, Java, C++, etc. That language flexibility allows Lantern to do more powerful things and to integrate more powerful technologies that it would be able to with pure JavaScript, giving it more of a fighting chance in the face of censors.
Your app. What other technologies do you wrap into it besides WebRTC?
Lantern also uses a pluggable transport architecture that currently includes FTEProxy (https://fteproxy.org/) and domain fronting (described in more detail at https://trac.torproject.org/projects/tor/wiki/doc/meek). FTEProxy uses regular expressions to specify how traffic over the wire should look, allowing that traffic to conform to whatever protocol we specify. That again allows Lantern to blend in with existing protocols, theoretically forcing censors to block things they don’t want to block in order to block Lantern.
On the frontend we use AngularJS and D3.
Backend. What technologies and architecture are you using there?
We use a number of languages including Java, Go, Python, and C++. We are increasingly moving as much as possible to Go.
Why Go?
We’re porting a lot to Go for a number of reasons:
- It’s got great concurrency primitives, and we do a lot of concurrency
- It’s got great build-in networking, and we do a lot of networking
- It’s super fast and easy to develop in
- It has great cross-compilation and relatively small binaries
We’re also moving away from Java because the download size is so large, which is particularly problematic for users in Iran who don’t have much bandwidth.
What challenges did you have in using WebRTC for GetLantern?
The biggest challenge was extracting the NAT and firewall traversal components from WebRTC into Natty. The WebRTC code base is a monolithic beast and takes forever to build. The NAT and firewall traversal components are relatively small and extremely useful independently. While we haven’t announced Natty publicly at all, we’re already starting to see interest from other developers and projects. We really think Natty will turn into a broadly useful component that’s a part of WebRTC but simply modularized into a separate library that run as a separate process and can be called from any programming language.
Where do you see WebRTC going in 2-5 years?
I think the main innovation will be from web developers using WebRTC for new and exciting applications. The beautiful part about WebRTC is that it creates a new peer-to-peer platform that is only limited by the creativity of developers.
Given the opportunity, what would you change in WebRTC?
I actually think some of the Microsoft team’s criticisms of WebRTC were valid, and they came from extremely experienced developers. WebRTC is far too monolithic and should be a more discrete and reusable assembly of a number of smaller projects that are independently useful. Natty is one example, but things like QUIC should also really be independent projects that happen to be integrated into WebRTC.
What’s next for GetLantern? (It’s really just Lantern =)
We’re continuing to port more and more code to Go, which will significantly reduce the download size. The download size is crucial in places with low throughput, particularly Iran. That will also enable Lantern to be ported to Android.
–
The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.