Re: [liberationtech] [SPAM:###] Re: Google Unveils Tools to Access Web From Repressive Countries | TIME.com
Thanks Adam, I appreciate your note, and I'm glad to hear what you have to say. Forgive me, but I don't agree with you that everyone at Google Ideas shares our goals. Look into some of the other work that Jared Cohen does and it becomes apparent that for him and his ilk, human rights concerns only exist within dictatorships, not democracies. Some of his colleagues have put people I know directly at risk, and that I cannot forgive easily. So while I'm glad to see that Lantern is behind this, I'm deeply disappointed to see Cohen's involvement. Best, Jillian On Tue, Oct 22, 2013 at 11:44 PM, Adam Fisk af...@bravenewsoftware.orgwrote: Hi Everyone- First off, apologies for the radio silence. My libtech reading has decreased in direct proportion to the volume of traffic, which seems in turn to have increased in direct proportion to my personal volume of work, so I'm a bit late to the game. To provide some context, over at Brave New Software we're still primarily focused on Lanternhttps://www.getlantern.organd have been rolling out a series of 1.0.0 beta releases we would greatly appreciate everyone's feedback on. We've been trying hard to improve our documentation, and all of our code is of course open sourcehttps://github.com/getlantern/lantern with an ever improving body of more detailed documentationhttps://github.com/getlantern/lantern/wiki we're in the process of migrating https://github.com/getlantern/lantern-docs. That said, we have been involved with UProxy https://uproxy.org/ since the earliest stages and have written some of the code, but with the University of Washington and Google Ideas really doing the heavy lifting. 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. One of the primary goals of both Lantern and UProxy is to build solutions that can scale to a large number of users without incurring unsustainable costs, and allowing ordinary users to provide access easily is a huge part of that effort. 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. 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. I will say that I completely agree with both the criticisms on some of the messaging and with the security approach (which applies to both uproxy and Lantern), and I'll elaborate on that. At BNS we have not controlled any of the messaging, but as you said Roger, the following: It's completely encrypted and there's no way for the government to detect what?s happening because it just looks like voice traffic or chat traffic. is a gross overstatement. I'm personally of the belief that the above is simply not possible or at the very least extremely hard and unsolved, as I think we've discussed a bit in person with regard to the efforts to disguise Tor traffic as Skype traffic. I'm not sure I've ever said this directly, but I'll say now publicly that you're one of the technologists I personally hold in the highest possible regard, and I always welcome any criticisms you may have. You've also given Lantern really valuable advice from its earliest days, which I really appreciate. 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. I also quickly wanted to also acknowledge Sascha's excellent point about trust network mapping: 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 Kaleidoscopehttps://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
Re: [liberationtech] [SPAM:###] Re: Google Unveils Tools to Access Web From Repressive Countries | TIME.com
Thanks for the note Jillian, and I fully admit I have a tendency to be bit overly optimistic about these things and perhaps have too much faith in the ability of corporations to ultimately be productive partners. There's an inherent misalignment of incentives that is problematic outside of the individuals involved. I think your skepticism is essential and all of our continued vigilance warranted. That said, I know the rest of the uProxy team itself is aware and even wary of these issues, so I think you're right to point out that painting all of Google Ideas with the same brush is dangerous. I only know a tiny sliver of Google Ideas well, and that's the uProxy team, but I can certainly attest to the uProxy team's recognition of the complexity involved from a larger political perspective and even from the perspective of Google's involvement. The only ultimate hedges here are structural, of course, and I think it will help a great deal when the uProxy GitHub repository is opened up to the public. I want to emphasize again that the University of Washington and Google Ideas really did the heavy lifting on uProxy, with the BNS not contributing as much as we'd like primarily because we've had our hands full with Lantern. That's also not an effort to distance ourselves from it but rather an effort to give credit where credit is due. Working off an open source repository, however, uProxy has the advantage of a really strong team of highly skilled engineers with input from other parts of Google including engineers with more of a security focus as well as from the highly skilled team over at UW. I think the open source nature of the project really tips the scales here and makes Google participation unquestionably a net positive in that they're able to pour resources into promising technology that everyone in the community can scrutinize. I think the non-technical aspects are where things have the potential to derail, but I'm hopeful we can all help prevent that. That's the report from my window on the world. -Adam On Thu, Oct 24, 2013 at 8:00 AM, Jillian C. York jilliancy...@gmail.comwrote: Thanks Adam, I appreciate your note, and I'm glad to hear what you have to say. Forgive me, but I don't agree with you that everyone at Google Ideas shares our goals. Look into some of the other work that Jared Cohen does and it becomes apparent that for him and his ilk, human rights concerns only exist within dictatorships, not democracies. Some of his colleagues have put people I know directly at risk, and that I cannot forgive easily. So while I'm glad to see that Lantern is behind this, I'm deeply disappointed to see Cohen's involvement. Best, Jillian On Tue, Oct 22, 2013 at 11:44 PM, Adam Fisk af...@bravenewsoftware.orgwrote: Hi Everyone- First off, apologies for the radio silence. My libtech reading has decreased in direct proportion to the volume of traffic, which seems in turn to have increased in direct proportion to my personal volume of work, so I'm a bit late to the game. To provide some context, over at Brave New Software we're still primarily focused on Lanternhttps://www.getlantern.organd have been rolling out a series of 1.0.0 beta releases we would greatly appreciate everyone's feedback on. We've been trying hard to improve our documentation, and all of our code is of course open sourcehttps://github.com/getlantern/lantern with an ever improving body of more detailed documentationhttps://github.com/getlantern/lantern/wiki we're in the process of migrating https://github.com/getlantern/lantern-docs . That said, we have been involved with UProxy https://uproxy.org/ since the earliest stages and have written some of the code, but with the University of Washington and Google Ideas really doing the heavy lifting. 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. One of the primary goals of both Lantern and UProxy is to build solutions that can scale to a large number of users without incurring unsustainable costs, and allowing ordinary users to provide access easily is a huge part of that effort. 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. 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. I will say that I completely agree with both the criticisms on some of the messaging and with the security approach (which applies to both uproxy and Lantern), and I'll elaborate on that. At BNS we have not controlled any of the messaging, but as you said Roger, the following: It's completely encrypted and there's no way for the government to detect
Re: [liberationtech] [SPAM:###] Re: Google Unveils Tools to Access Web From Repressive Countries | TIME.com
Now that's what I call a productive, collaborative email. Awesome. Thanks Roger. Responses inline. 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). Yup completely agreed. The UDT piece of Lantern is definitely the weak link, although I will say it's also an interesting weak link in that there's unlikely to be a censor out there now that can quickly DPI some pretty weird UDP packets going across the wire at least using currently available software. Then again, maybe you know something I don't, and maybe it is possible to apply a global regex rule to all UDP traffic from some of these boxes (clearly it's possible generally, but is it possible country-wide *now*?). Lantern does also use TCP when NAT-PMP or UPnP are working on one of the endpoints, so it's a combination of the two. 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. Precisely, albeit with the TCP caveat above. 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 ) Excellent point. 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. :/ Umm, yeah. I need to learn to STFU =). 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. Yup. Kaleidoscope addresses the issue of discoverability through first choosing which proxy addresses get propagated via a random walk but then routing along that random walk consistently after that first route selection, if that makes sense, such that new nodes in the system can't learn about all of the existing nodes because all existing routing is consistently using the formerly-chosen routes. So it's similar to the cell ideas in the sense that it's like a courier who initially didn't know the shopkeeper she's supposed to drop off a letter too such that a letter gets passed along, but once the courier knows the shopkeeper she never goes to any other shopkeeper. Definitely more work to be done, but we're really interested in interoperating using pluggable transports for sure. The other part in terms of discovery is really interesting as well, and I'd be happy to talk more about it. Interestingly I think that part is extremely easy. Really all Lantern does is log into Google Talk and then give mode peers/bridges advertise Lantern support through the -lan- extension in their Jabber ID. You could argue there's a privacy leak there, but the only peers that see that
Re: [liberationtech] [SPAM:###] Re: Google Unveils Tools to Access Web From Repressive Countries | TIME.com
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 Kaleidoscopehttps://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
