Tor in Google Summer of Code 2017

by atagar | February 28, 2017

Interested in coding on Tor and getting paid for it by Google? If you are a student, we have good news for you: we have been accepted as a mentoring organization for Google Summer of Code 2017!

Here's the facts: GSoC gives you the opportunity to work on your own Tor-related coding project with one of the Tor developers as your mentor. Your mentor will help you when you're stuck and guide you in becoming part of the Tor community. Google pays you for the three months of your project, so that you can focus on coding and don't have to worry about how to pay your bills.

Did we catch your attention? These are your next steps: Go look at the Google Summer of Code FAQ to make sure you are eligible to participate. Have a look at our ideas list to see if one of those projects matches your interests. If there is no project on that list that you'd want to work on, read the documentation on our website and make up your own! Come to the tor-dev@ list or #tor-dev on OFTC and let us know about your project idea. Communication is essential to success in the summer of code, and we're unlikely to accept students we haven't heard from before reading their application. So really, come to the list or IRC channel and talk to us!

Finally, write down your project idea using our template and submit your application to Google before April 3rd.

We are looking forward to discussing your project idea with you!

Comments

Please note that the comment area below has been archived.

GSoC is a well known way to get people working on valuable open source projects. It's not some sort of sketchy business deal where Tor Project signs itself over to Google employees and developers. The reality is, Google does a lot for the FOSS world, and especially for security.

It's bad to think of Google as one big monolithic entity. It's true that many of Google's activities are bad (targeted advertising, malicious use of big data, monopolistic practices, skewing search results for political purposes), but it's so large that many other activities are entirely beneficial. Many of the bugs found and fixed in Tor may not have been found if lcamtuf had not been hired to work on AFL by Google. The secure Copperhead OS for Android would absolutely not be as secure as it is now if it weren't for Google. Many security improvements in Linux would not exist today if it weren't for Google pushing for them.

GSoC is no different. Google benefits from FOSS. They see the entire ecosystem as important, so they promote it. There's no conflict of interest when both Tor Project and Google mutually benefit from a more free and open source ecosystem. There's no conflict of interest when both Tor Project and Google mutually benefit from a more secure world.

As a side note, this is true for pretty much all companies. Google puts a lot of money into effort into improving the security of free and open source software. They put a lot of money into fuzzing research and fuzzing popular open source projects (OSS-fuzz). Microsoft puts a lot of money into researching new mitigations for memory safety and memory allocation hardening (their malloc rivals OpenBSD's), and even formally verifies some of their core code (HTTP.sys for example). Intel puts significant money into research for security techniques that can be implemented in hardware (RDRAND, RDSEED, SMEP, SMAP, UMIP, SGX, MPX, CET, MPK, VT-x, VT-d, and, of course, NX). Apple puts a lot into... uh... Well at least they keep a lot of things open source even if they don't really contribute to the FOSS ecosystem, and at least they hired LegbaCore to harden their UEFI, but I can't say much more for them on that front.

You should never assume that a company is entirely monolithic and all evil. I do not mean to defend Google. I think it is, overall, a rather nasty company. But you should not make the implicit assumption that any project which Google runs or funds is going to cause a conflict of interest for Tor Project to participate in.

(To mods: I posted a reply to this explaining why it is not a conflict of interest days ago, and it was not approved. Is there any reason why? This is the first time this happened.)

Anonymous (not verified) said:

March 02, 2017

Permalink

What about porting Rachel's anti-stylometry code to a usable R package? I'd like to see a utility like gedit spell check, which identifies distinctive vocabulary/grammar/syntax and suggests entropy maximizing alternatives. Vocabulary should be easy; grammar and syntax no doubt harder. See the existing package

https://sites.google.com/site/computationalstylistics/stylo

for a first take on the crudest kinds of attach we want to defend against.

Anonymous (not verified) said:

March 05, 2017

Permalink

Tor is just a government sandbox they port to other projects internally, or to their proxy corporations.

Plus it seperates the majority of people who fall into other government spyware using regular internet into distinct groups for the FBI to than set-up honey traps for Tor users and other VPN users.

Governments which cannot "break" Tor have two options:

o attempt to circumvent Tor itself by attacking vulnerable components in browsers, Tor node routers, etc.,

o attempt to perform confirmation attacks to deanonymize users without actually breaking Tor itself (probably an option only available to FVEY),

o attempt to spread FUD to dissuade dissidents from using Tor.

We appear to have here an instance of the third strategy.

Both the Snowden and Vault 7 leaks (of NSA and CIA cyberespionage techniques up to spring 2013 and fall 2016 respectively) imply that USIC cannot break Tor.

You are wrong on at least one point: Tor is not a "VPN".

You make some other strong claims without presenting any evidence or even plausibility arguments.

Both the Snowden leaks (valid thru spring 2013) and the Vault 7 leaks (valid thru fall 2016) show that USIC (and presumably cryptanalysis done by rival alliances) probably are not close to "breaking" Tor or strong crypto generally; rather, spooks continue to rely on breaking into computers/devices/networks using common vulnerabilities in browsers, routers, etc.

If a mole had successfully snuck a "backdoor" broadly defined (e.g. subtly broken crypto) into Tor these leaks (for future leaks) would likely reveal this. This in itself would be an argument inside USIC not to even try to sneak in a backdoor.

Not that Tor Project should assume they won't try even though that would probably not be very smart-- at any time our enemies might become desperate, without notice to us.

Anonymous (not verified) said:

March 12, 2017

Permalink

What about implementations of new key-exchange algorithms suitable for post-quantum?

Tor should have more than one ready to go in case one is unexpectedly broken and thus rendered useless for remaining safer in a quantum-cryptanalytic world.