[tor-dev] GSoC: Ahmia.fi - Search Engine for Hidden Services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm a student who is starting to work with ahmia.fi search engine as a part of Google Summer of Code. :) The proposal is online here https://ahmia.fi/gsoc/ In practise, I have now time and funding to develop my search engine. George is my primary mentor and Moritz the backup mentor. Today, I will submit all the required documents (the tax forms etc.) to Google. After that, I think I will speed up with code base in the GitHub :) Cheers, Juha -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTViWUAAoJELGTs54GL8vAuC8H/jSdgBCRQM/3l3mX5Uig9fgM wacPsxm6RJd3Sw+JJpYgoRP1nDqI513haP4Z6s//tR3Vn5RyQ/u7ik3QdFEVKbJD KqnQ4Eaf5hT4xsJwBXZIjzW6uhbYaq1GmUJi4eaglwUrgIgJrHzDbOz/p8q71O1z rLnrS1vrsvMzY4rU0dRe1/S9LyPWTUAfpVMINa54RPmNjMzrTT/WUnlcQWo9cY3a SRrT2MVz5nwBEXJuhZUmC3L6XLL8RX2TgzGwVyYOUfMlNuZdcSaOOTvF7gKVZVZQ hGhr/V40iNm5BOAcQ2TVaxuR5HjxSFWUp15T8ux+xxyN/Yp9EeaDjsAsTVegq0w= =QMfR -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
Gunes Acar: Sorry everyone for the long pause. I wrote down a proposal (and some code) to address issues raised by Mike and George: https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf Looking for your comments and critics... I am happy with getting 1), 2) and 3) done in that order but am a bit wondering why that does not match your suggestion in the timeline. There you plan doing something like 2) (+ maybe the Implement fingerprinting tests from 1)), 3) and 1). Is there a reason for this? I am asking as porting the Panopticlick and getting something live to use seems to be the most tricky part of your proposal (I might be wrong here, though). Having this as the last item to work on contains the nonnegligible risk that it won't get finished which would we sad... On 03/21/2014 11:39 PM, Peter Eckersley wrote: I think we're fine with open sourcing under the Affero GPLv3. Wow. I almost missed that one in all the quoted emails and it did not make it to tor-dev. But good to hear that we have something to build upon. Thanks, Peter. Georg signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] GSoC: A Framework for Website Fingerprinting Countermeasures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, My name is Marc Juarez and I'm a PhD student at KU Leuven [0]. I'm going to work in the GSoC project A Framework for Website Fingerprinting Countermeasures [1] that will be mentored by Mike Perry and Yawning Angel. I'm very excited about this project because my research now is on website fingerprinting topics. The main goal of the project is to implement the building blocks for a future padding based website fingerprinting countermeasure [2,3] as a pluggable transport. These days I'll be familiarizing with obfsproxy and twisted and getting things ready to start coding on May 19th. I will try to keep everybody updated and I'm looking forward to any advice and comments. If anybody needs to contact me, this is my main email and my oftc username is mjuarez. Best, - -- marc [0] http://homes.esat.kuleuven.be/~mjuarezm [1] http://homes.esat.kuleuven.be/~mjuarezm/GSoC14Proposal.pdf [2] https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks [3] https://trac.torproject.org/projects/tor/ticket/7028 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTVj4UAAoJEGfJ5xfgazlxNC0H/2mBLaaqoxk3oAPcFBqagJDN 2gWU0VA0o3XXzVxAvuB5ikEimNKmCGVimMGhC71shZe3Ot26AzJtD3dqFSNGtucB 5lzZR/tcsHjp2TDChePnQH/iDHNMY+VrdakkM/gjWorqjQHutrqGW+1crhkwscCO nJEcA4kinrQQc4mN/xTNHva6HDFx99e9Qs6N6sbumsdlNO3cew7Ly0NhTs7Jn4Jm U1/JlmnCfNyIArd65Ywcaqsb7ZMnKcu00DT34/1uNYqAbxEP+MQ3yH2IJjDHVgM3 7L1wTCM0OjsWVmVu5boQqsTeneRh0LzfdtBKdmQQJqfsPOgcOjskyALHwcjXt5s= =v9eI -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] New BridgeDB Distributor (was: Re: New BridgeDB Distributor (Twitter/SocialDistributor intersections, etc.))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 With isis' and sysrqb's permission, moving the new BridgeDB Distributor (and maybe general bridgedb distributor architecture discussion) thread onto tor-dev@. On 04/15/2014 10:30 PM, Kostas Jakeliunas wrote: On 03/29/2014 10:08 AM, Matthew Finkel wrote: (I look the liberty of making this readable again :)) On Fri, Mar 28, 2014 at 08:00:17PM +0200, Kostas Jakeliunas wrote: isis wrote: Kostas Jakeliunas transcribed 7.9K bytes: Hey isis, wfn here. [...] Hi! Howdy! I'm super excited to hear you're interested in working on this! [...] [...] a couple of questions (more like inconcrete musings) [...]: Would you personally think that incorporating some ideas from #7520[1] (Design and implement a social distributor for BridgeDB) would be within the scope of a ~three+ month project? The way I see it, if a twitter (or, say, xmpp+otr as mentioned by you/others on IRC) distributor were to be planned, it would either need to - incorporate some form of churn rate control / Sybil attack prevention, via e.g. recaptcha (I see that twitter direct (=personal) messages can include images; they'll probably be served by one of twitter media CDNs (would need to look things up), but it's probably safe to assume that as long as twitter itself is not blocked, those CDNs won't be, either); Yes, this stuff is already built, and wouldn't be too hard to incorporate. However, as I'm sure you already understand, there is no Proof of Work system which actually works for users while keeping adversaries out. For sure, we always have to keep this in mind. Hopefully there's a compromise that kinda-works, and eventually, given some more metrics/diagnostic info intersected with OONI hopefully being able to say which bridges don't work from which countries, it'll be possible to actually carry out tests in a kind-of-scientific/not-blind-guessing way.. At this point I just assume our adversary will always have more resources than us no matter which mechanism we use. More people, more compute power/time, more money. At this point I think we only have two things that they don't. We have more bridges and more love for people. Leveraging this is...not easy, however. :( POW is useful in some cases, for example, to prevent an asshole from crawling bridgedb so that they can add all bridges to a blacklist. When dealing with state-level adversaries I agree with isis that they're of little use. Agree. - or take an idea from the social distributor in #7520, namely/probably, implement some form of token system. This is not very doable in 6 weeks. It also, sadly, requires the DB backend work (which I'll be doing over the next three months, but might take more time). Aha, understood, yes. So basically, ideally I'd write code that could *later on* be easily extendable in relevant ways. But no tokens for now. Ideally this sounds like a good idea, however I'm not sure we (or at least I) have a good handle on what bridgedb will look like in 6-12 months. It's undergoing a lot of change right now. Don't interpret this as saying this is a bad idea because the more abstract and extensible you make this distributor the more useful it will be. I'm just a little worried about writing something for the future. Perhaps there's a good way to design and plan for this, though. Yeah, understood. As I understand it, isis is changing some things in bridgedb (bridgedb.Distributor, etc) right now / these days. For now, the idea is to have a thing that works that is more or less completely decoupled from the bridgedb codebase. If we do this right, it will hopefully be relatively easy to then integrate it in a way that will make sense at that point in time (e.g. as part of bridgedb.Distributor, *or* as a client to a core RESTful distributor/api/service that gives bridges to other 'third-party' distributors (see below.)) It might be possible to have some simplistic token system with pre-chosen seed nodes, etc. Of course, security and privacy implications ahoy - first and foremost, this would result in more than zero places/people knowing t he entire social graph, unless your and other people's ideas (the whole Pandora box of; I should attempt an honest read of rBridge, et al.; have only skimmed as of now) re: oblivious transfer, etc. were incorporated. Here it becomes quite difficult to define short-ish term deliverables of course. I know that you did quite a lot of research on the private/secure social distributor idea. Really, you don't want to get into this stuff. Or do, but don't do it for GSoC. I've spent the past year painfully writing proofs to correct the erro rs in that paper, and discovered some major problems for anonymity in old tried-and-true cryptographic primitives in the process. This is a HUGE project. Sounds insanely intense, in both a good and a bad way! It's
Re: [tor-dev] GSoC: Ahmia.fi - Search Engine for Hidden Services
Juha Nurmi juha.nu...@ahmia.fi writes: Hi, I'm a student who is starting to work with ahmia.fi search engine as a part of Google Summer of Code. :) The proposal is online here https://ahmia.fi/gsoc/ In practise, I have now time and funding to develop my search engine. George is my primary mentor and Moritz the backup mentor. Today, I will submit all the required documents (the tax forms etc.) to Google. After that, I think I will speed up with code base in the GitHub :) Enjoy GSoC :) BTW, looking again at your proposal, I see that you are going to do both popularity tracking and backlinks. How are these two technologies going to interact with each other? That is, how will the indexer consider the output of those two features? Also, with your newly acquired knowledge about backlinks, how long is it going to take your incorporate them in ahmia? Are you actually going to do it during the Use an another crawler to search .onion pages from the public Internet phase? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] GsoC: Revamp GetTor
Hi all! My name is Israel Leiva, and I'll be working on the Revamp GetTor [1] project during this GsoC. My mentors will be sukhe and mrphs. What I propose is to redesign the current GetTor code in order to make it oriented to modules, which the users can access via common services (like SMTP, for instance) and get the required info (packages or links). The idea is that this new design could allow the implementation of new modules in the future. You can find more details about my proposal in [2]. Needless to say I'm very excited and honored to collaborate with the Tor project and community! [1] https://www.torproject.org/getinvolved/volunteer.html.en#revamp_gettor [2] http://ileiva.github.io/gettor_proposal.html Best, -- israel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] GSoC: Implement consensus diffs
Hello everyone, My name is Daniel and this summer I'll be working on consensus diffs [0], heavily based on proposal 140 [1]. This should allow for quicker and scalable consensus udpates, which will have more weight as the consensus grows larger. I've never gotten involved in Tor before, so I'm really looking forward to this summer. My intention is to use a simplified ed format as described on proposal 140, but I am open to alternatives and suggestions. As far as the diff creation algorithm, I plan on using a dynamic programming algorithm for the Longest Common Substring problem. Like before, comments are very welcome. I will spend the following couple of weeks looking at alternative diff formats and algorithms, rather than start coding this early. It would be appreciated if any ideas regarding any of the two aspects were posed during this time, so that afterward I can start their implementation. I will always be lurking on #tor-dev, #tor-project and #tor under the nick 'mvdan'. I am also subscribed to the tor-dev and tor-talk mailing lists. And lastly, my PGP fingerprint is below - encrypted mail is welcome :) Regards. [0] https://www.torproject.org/getinvolved/volunteer.html.en#consensusDiffs [1] https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/proposals/140-consensus-diffs.txt -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpitSPQNrbXY.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC: Implement consensus diffs
On Tue, Apr 22, 2014 at 05:02:23PM +0200, Daniel Martí wrote: Hello everyone, My name is Daniel and this summer I'll be working on consensus diffs [0], heavily based on proposal 140 [1]. This should allow for quicker and scalable consensus udpates, which will have more weight as the consensus grows larger. I've never gotten involved in Tor before, so I'm really looking forward to this summer. My intention is to use a simplified ed format as described on proposal 140, but I am open to alternatives and suggestions. As far as the diff creation algorithm, I plan on using a dynamic programming algorithm for the Longest Common Substring problem. Like before, comments are very welcome. The proposal (140) doesn't appear to discuss the client fingerprintability aspect of this: they reveal the last time they used Tor (if recentish). Say you're a mobile client that gets a dynamic IP address. With this, you reveal that you probably aren't or maybe are the same person that was last seen over there at that particular time. What are the implications here? -- Ian Goldberg Associate Professor and University Research Chair Cheriton School of Computer Science University of Waterloo ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 10:35 AM, Georg Koppen wrote: Gunes Acar: Sorry everyone for the long pause. I wrote down a proposal (and some code) to address issues raised by Mike and George: https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf Looking for your comments and critics... I am happy with getting 1), 2) and 3) done in that order but am a bit wondering why that does not match your suggestion in the timeline. There you plan doing something like 2) (+ maybe the Implement fingerprinting tests from 1)), 3) and 1). Is there a reason for this? I am asking as porting the Panopticlick and getting something live to use seems to be the most tricky part of your proposal (I might be wrong here, though). Having this as the last item to work on contains the nonnegligible risk that it won't get finished which would we sad... Sorry for putting it in a confusing way. The reason was that there is a strong chance that after August I'll be able to access the Panopticlick data (and probably the code), as an EFF volunteer/contractor. I thought it might be a better idea to work after that, assuming Peter may give some valuable advices on the process too. If code gets published before August, I can start to work earlier. Also what is missing in the timeplan is my intention to implement ~everything except the backend a part of the QA process, and then reuse the code in the ultimate website (your suggestion). In addition to the new tests, I'll be working on the machine readable output, entropy calculation and submitting test machine fingerprints to a central database as a part of (2). Let me know if that makes sense or I can revise the timeplan (e.g. leave (3) to the end). On 03/21/2014 11:39 PM, Peter Eckersley wrote: I think we're fine with open sourcing under the Affero GPLv3. Wow. I almost missed that one in all the quoted emails and it did not make it to tor-dev. But good to hear that we have something to build upon. Thanks, Peter. Georg ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTVou+AAoJEPb7JcMmVt4ggu8H/j/ELTPqgWZkIVjOVxCw6SH6 TvsQvLD5IK1g2sQ1wC9GNK65rRXZCQBJeX1AS9dC8iyyCDsQ5yXy1lnBikSF4yHp nyMUqgs9k2xE/g5mWLex3fg7/2VGxN58F+gOi8SUTLNr028Mp61ayjxOj1GVB4pQ Awz4c1HWqx9PvgoAka8HvT2Wi7YKP7hFUF1UQBnFg+EmT67ploMdNeVPDGU2OJUO f00630cS6/4n8Z8X77rWNDknwMz30ZM2T9bGf0sSnn1zneRbdtUEZUBd8Yyns4UP f0dyeyyL1W7NXLNu4FdtyxIACFkUV1IoFDCJuu8OC1QPChPJby4LJZ1c5FvgEVY= =NiSt -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] GSoC: Orbot and Orfox
Hey everyone, I'm Amogh Pradeep, a student at International Institute of Information Technology, I have been accepted as a GSoC student this year and I am going to work on the android app for tor, Orbot as well as a new browser implementation called Orfox. Orfox is a new idea, the aim is to implement a complete browser based on GeckoView which has been built by Mozilla. This would hopefully replace the current Orweb browser as the default browser that works with Orbot. For more details on my project, and the proposal itself, you can find it at [0]. I'm online on OFTC and freenode under the nick amoghbl1, feel free to contact me anytime. Best, Amogh Pradeep, Developer, Student. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] GSoC: BridgeDB Twitter Distributor
Hi all, I'm excited to be able to spend another summer-of-code together with Tor (how impudent!) :) My name is Kostas (wfn on OFTC), primary mentor is isis and secondary mentor is sysrqb. I'll be working on writing a new BridgeDB Distributor[1]. I've set my primary task to designing and implementing a Twitter-distributor-bot (see proposal[2]): a Twitter bot answers personal (direct) messages, does rate control if needed, and gives bridge lines to users. There should be enough time to at least start on another distributor (right now I'm thinking about an XMPP-based one, as the federated-network-nature allows for some neat censorship circumvention approaches.) But there's also value in implementing a generic/core distributor that could give bridges to third-party distribution systems over a (say) RESTful API. Will see how things go, but core task for now is a twitter-based distributor. For further ideas, discussion, etc., see a separate tor-dev@ thread: https://lists.torproject.org/pipermail/tor-dev/2014-April/006742.html Ideas are very much welcome indeed! [1]: https://www.torproject.org/getinvolved/volunteer.html.en#newBridgedbDistributor [2]: http://kostas.mkj.lt/gsoc2014/gsoc2014.html -- Kostas. 0x0e5dce45 @ pgp.mit.edu ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC: Implement consensus diffs
On Tue, Apr 22, 2014 at 11:10:27 -0400, Ian Goldberg wrote: The proposal (140) doesn't appear to discuss the client fingerprintability aspect of this: they reveal the last time they used Tor (if recentish). Say you're a mobile client that gets a dynamic IP address. With this, you reveal that you probably aren't or maybe are the same person that was last seen over there at that particular time. What are the implications here? As far as I understand, Tor clients fetch the consensus documents from a random authority at first, and then from caches at somewhat random times - reading from [0] at section 5.1. Since it starts using caches and building circuits after fetching the first consensus from an authority, I don't see how anyone could identify a client. Sure, a cache will know for how long has a client been disconnecten when it asks for a diff starting at e.g. yesterday. But was it that same cache who gave it the previous diff? Or are you talking about regular traffic too? I might have not understood you well - if that's the case, please explain with a bit more of detail. Anyway, downloading the entire consensus file from either an authority or a cache will always be possible, if that's what you are concerned about. But we want diffs to be usable in a secure manner just like entire consensuses are. [0] https://gitweb.torproject.org/torspec.git/blob/refs/heads/master:/dir-spec.txt -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgpKixfa_1FLD.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
