Re: [tor-dev] GSoC: Ahmia.fi - Search Engine for Hidden Services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.04.2014 17:35, George Kadianakis wrote: > Enjoy GSoC :) I will :) > BTW, looking again at your proposal, I see that you are going to > do both popularity tracking and backlinks. Yes, another crawler gathers backlinks from the public WWW and I will start gathering the URL clicks from the users. > How are these two technologies going to interact with each other? > That is, how will the indexer consider the output of those two > features? Django front-end re-sorts the answers from YaCy back-end. See https://ahmia.fi/static/gsoc/re_sort.jpg I have this idea in mind: https://ahmia.fi/static/gsoc/sorter.py The result is sorted according to YaCy result index, number of backlinks and clicks which are scaled. Note the scaling: p_info.backlinks = 1 / (float(index) + 1) etc. sum_function = 3.0*self.yacy + 2.0*self.backlinks + 1.0*self.clicks where 3, 2 and 1 are test coefficients. I will optimize these and made a better model if necessary. However, clicks are easily spoofed and there have to be small coefficient for them. > 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? We can test it when popularity tracking and backlinks crawler are working. - -Juha -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWKhsAAoJELGTs54GL8vA+WAH/1i4sCvvcwotn5b39Ox8yldn Wv6mBxqlIiaoeBj1Eeu+A92QfGvvpxdWDb7Kn3+3u0IO0wXcZlf0SrIri11IgprW 1f8x5BMDYiaFl12dVO/3jfXSmdfKQ24AdKknfK9wuD63266L2Tks/DVURHQKrYaM zTfYJKZNWJtOPxUj45lHknHxDWVzRlmqiksRn1aPwx2EW5dpKCCVkV9ySnJdZW74 DWs1es1rLKj6UVmVl6w88PJ/C1COWhMQspXtYIZ8paZQfMHtEgDxLuifITIHgdBh TdGLUEVteUl5wyCNjDh1Q+ZEkdbMvcpNZuP5D3lUYweHz0cMMOGHC0oaLlJS4KE= =48jK -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] [RFC] Proposal draft: The move to a single guard node
On Thu, Apr 17, 2014 at 2:05 PM, Nicholas Hopper wrote: > On Tue, Apr 15, 2014 at 6:35 AM, George Kadianakis > wrote: >> A patch for the proposal would be useful. If you don't have time to do >> it, just tell me and I will do it myself. > > Here's a patch: > https://www-users.cs.umn.edu/~hopper/single-guard-node.patch The proposal as patched is now proposal # 236. yrs, -- Nick ___ 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/23/2014 10:15 AM, Georg Koppen wrote: [...] > Okay, sounds reasonable. What is the fallback plan for the case the > code is not getting open-sourced during the time you are working on > the topic? Do you have an "internal" deadline like: "If I/we don't > have the code by XXX I'll start an implementation from scratch"? Peter kindly confirmed that I'll be able to access the code (even if it doesn't get published by then.) But, assuming the worst case, I'd start worrying on mid-July. > >> 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). > > Sounds good to me. > > 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/ iQEcBAEBAgAGBQJTWABKAAoJEPb7JcMmVt4gXIYIAJdKJoC3h6rj9mTMkejzuzns 9PO/cxZ3ZB3tvX6CIYrfglgdfnh2SmdlId+kXv0eNhfN3Rz9pAp2QpLBH5CUcQGp ETZIj3/WzlCZNqTcNZv7qge0uL3yiLynEgnqwY2P4TQRnpjC7heVgWD0f2y+IR5s 6H3/NDnK5dGXXl+T+xKqPswPrtgkgYXTl4pkG5YPL52vrGLPRsLYXizovryT3aJ5 LC7ozLjGLCuV1ToAu1/JVON1Qla66UBGGwuiD39+/A6sIJSptSRT6epkOJaWPy7D pClD2whSggnl4nLg2hOPzxpnX/tM08vyPRCSPx4xNezm0KO0BY0kUs3k3E21cYM= =x2jO -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] [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
On Wed, Apr 23, 2014 at 12:46 PM, anonym wrote: [...] > Given the planned release date for Tails 1.0, this actually doesn't look > too bad a compromise. I had a quick look at the other tickets tagged > `024-backport` and nothing seemed very important. For future reference, don't just look at 024-backport -- that's for tickets that are currently in 0.2.5 or later but which should (maybe!) get backported to 0.2.4 after a fix. Also look at the tickets in milestone "Tor: 0.2.4.x-final": those include ones that were never marked as backportable when they were in 0.2.5, but which, after resolving them, somebody decided we should consider for backport anyway. (It doesn't make a difference in this case, IMO, but it's something to be aware of.) > However, before > deciding on this, I'd really appreciate a confirmation from any of you > Tor devs that, as it looks now, the next 0.2.4 release will have no > other important security fixes affecting *Linux* *clients*. So, will it? It depends what you consider a "fix" versus a "feature", and what you think is "important". The only ones I'd consider to maybe meet your criteria are: #9386 #11438 -- those two will make clients significantly more resistant to using bad cryptography at the TLS layer. Also -- since you're asking for a solid confirmation here -- I need to insert the disclaimer that this is only based on what I know about today. I might be forgetting something, and we might learn about something tomorrow that would change all of this. In other words, it's a prediction, not a promise. ;) best wishes, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
23/04/14 16:51, Nick Mathewson wrote: > On Wed, Apr 23, 2014 at 10:28 AM, anonym wrote: >> 21/04/14 12:27, Nusenu wrote: >>> Hi, >>> >>> the code to blacklist heartbleed affected tor directory authority keys >>> has been merged about a week ago [1]. >>> >>> Do you have an ETA on when you are going to release it (tor and TBB >>> packages)? >> >> As the release manager for the Tails 1.0 release I'm also interested in >> an ETA for this. Ideally the Tails image intended for the 1.0 release >> will be built on 2014-04-27 (so this is when we'll truly freeze the >> version of Tor), and released two days later. We Tails developers would >> find it sad if its core piece of software becomes out-dated immediately >> or even just shortly after that. >> >> Nick (or any one else in the loop), do you have any idea of timings for >> the next stable Tor release? > > My goal is to get out a new alpha with the blacklist this week, and an > 0.2.4 release by the end of the month. > > This is a goal; I don't know if I'm going to be able to make it, and I > can't make mpromises there. Thanks for letting us know! > If you like, it could be entirely reasonable to backport the code in > question; the relevant commits are: > > 50ad3939242885b1a1a11688abd0c9756631747f > 46cf63bb42f2818201bc0c39036f2c17e210fcdb > 2ce0750d21d04c39a5a948b3d96203d8f68ae7ad > ef3d7f2f97caf961effd7935dd3231e6bba62ca5 Given the planned release date for Tails 1.0, this actually doesn't look too bad a compromise. I had a quick look at the other tickets tagged `024-backport` and nothing seemed very important. However, before deciding on this, I'd really appreciate a confirmation from any of you Tor devs that, as it looks now, the next 0.2.4 release will have no other important security fixes affecting *Linux* *clients*. So, will it? Cheers! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
On Wed, Apr 23, 2014 at 10:28 AM, anonym wrote: > 21/04/14 12:27, Nusenu wrote: >> Hi, >> >> the code to blacklist heartbleed affected tor directory authority keys >> has been merged about a week ago [1]. >> >> Do you have an ETA on when you are going to release it (tor and TBB >> packages)? > > As the release manager for the Tails 1.0 release I'm also interested in > an ETA for this. Ideally the Tails image intended for the 1.0 release > will be built on 2014-04-27 (so this is when we'll truly freeze the > version of Tor), and released two days later. We Tails developers would > find it sad if its core piece of software becomes out-dated immediately > or even just shortly after that. > > Nick (or any one else in the loop), do you have any idea of timings for > the next stable Tor release? My goal is to get out a new alpha with the blacklist this week, and an 0.2.4 release by the end of the month. This is a goal; I don't know if I'm going to be able to make it, and I can't make mpromises there. If you like, it could be entirely reasonable to backport the code in question; the relevant commits are: 50ad3939242885b1a1a11688abd0c9756631747f 46cf63bb42f2818201bc0c39036f2c17e210fcdb 2ce0750d21d04c39a5a948b3d96203d8f68ae7ad ef3d7f2f97caf961effd7935dd3231e6bba62ca5 best wishes, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-talk] heartbleed: ETA for tor release(s) that blacklist affected directory authority keys? (#11464)
21/04/14 12:27, Nusenu wrote: > Hi, > > the code to blacklist heartbleed affected tor directory authority keys > has been merged about a week ago [1]. > > Do you have an ETA on when you are going to release it (tor and TBB > packages)? As the release manager for the Tails 1.0 release I'm also interested in an ETA for this. Ideally the Tails image intended for the 1.0 release will be built on 2014-04-27 (so this is when we'll truly freeze the version of Tor), and released two days later. We Tails developers would find it sad if its core piece of software becomes out-dated immediately or even just shortly after that. Nick (or any one else in the loop), do you have any idea of timings for the next stable Tor release? Cheers! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC : Rewrite Tor Weather
On Wednesday 23 April 2014 06:05 PM, Oliver Baumann wrote: On Wed, April 23, 2014 1:19 pm, Sreenatha Bhatlapenumarthi wrote: Hi all, My name is Sreenatha(lucyd on OFTC). I am currently a final year undergraduate student at IIITH, majoring in computer science. I'll be rewriting weather this summer as a part of GSoC 2014. My mentors are meejah and karsten. In a nutshell, the weather rewrite project mostly involves two tasks, shifting the data backend to onionoo and closing the weather-specific tickets that are causing an issue at the moment. Besides these, there is also a plan to make use of a postgres database to store weather's subscription data. After this is accomplished, I'll document and test the new weather to make sure it's clean. Further details of my project proposal can be found at [1]. I'm very excited about working with Tor on this project and am happy to receive any sort of feedback and suggestions. Cheers, Sreenatha [1] - https://sites.google.com/site/sreenathadev/gsoc-2014-weather-rewrite ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev Hey Sreenatha, glad to hear you'll be investing some brainpower into weather! Maybe you already heard that there already is a rewrite in progress, which kicked off earlier this year. Main contributors to this are Abhiram and myself, Karsten being our guy we call for help. Sadly, progress has been slow the last couple of months, but we managed to set up a vagrant box and several scripts querying Onionoo. The latter have not yet been fully integrated, but I will point you to Karsten's weather-next branch which (I guess?) can be used for further contribution [1] (vagrant-work is in [2]). There's also a GitHub repo [3] for the standalone-scripts, which should really be regarded as a prototypical implementation of what could/should be done. Feel free to comment on anything, maybe we can assist you should you run into problems! Oh, and please also note the wiki-article [4] where this whole idea originated. You'll also find some trac-tickets related to the rewrite there. All the best, Oliver [1] https://gitweb.torproject.org/user/karsten/weather.git/shortlog/refs/heads/next [2] https://gitweb.torproject.org/user/karsten/weather.git/shortlog/refs/heads/vagrant [3] https://github.com/baumanno/tor-weather-rewrite [4] https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev Hi Sreenatha, Glad to have you on board. It looks like Baumanno has covered pretty all the things I can think of right now :) Let me know If you have any questions. Cheers! Abhiram Chintangal ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC : Rewrite Tor Weather
On Wed, April 23, 2014 1:19 pm, Sreenatha Bhatlapenumarthi wrote: > Hi all, > > My name is Sreenatha(lucyd on OFTC). I am currently a final year > undergraduate student at IIITH, majoring in computer science. I'll be > rewriting weather this summer as a part of GSoC 2014. My mentors are > meejah > and karsten. > > In a nutshell, the weather rewrite project mostly involves two tasks, > shifting the data backend to onionoo and closing the weather-specific > tickets that are causing an issue at the moment. Besides these, there is > also a plan to make use of a postgres database to store weather's > subscription data. After this is accomplished, I'll document and test the > new weather to make sure it's clean. > > Further details of my project proposal can be found at [1]. > > I'm very excited about working with Tor on this project and am happy to > receive any sort of feedback and suggestions. > > Cheers, > Sreenatha > > [1] - https://sites.google.com/site/sreenathadev/gsoc-2014-weather-rewrite > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > Hey Sreenatha, glad to hear you'll be investing some brainpower into weather! Maybe you already heard that there already is a rewrite in progress, which kicked off earlier this year. Main contributors to this are Abhiram and myself, Karsten being our guy we call for help. Sadly, progress has been slow the last couple of months, but we managed to set up a vagrant box and several scripts querying Onionoo. The latter have not yet been fully integrated, but I will point you to Karsten's weather-next branch which (I guess?) can be used for further contribution [1] (vagrant-work is in [2]). There's also a GitHub repo [3] for the standalone-scripts, which should really be regarded as a prototypical implementation of what could/should be done. Feel free to comment on anything, maybe we can assist you should you run into problems! Oh, and please also note the wiki-article [4] where this whole idea originated. You'll also find some trac-tickets related to the rewrite there. All the best, Oliver [1] https://gitweb.torproject.org/user/karsten/weather.git/shortlog/refs/heads/next [2] https://gitweb.torproject.org/user/karsten/weather.git/shortlog/refs/heads/vagrant [3] https://github.com/baumanno/tor-weather-rewrite [4] https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] GSoC : Rewrite Tor Weather
Hi all, My name is Sreenatha(lucyd on OFTC). I am currently a final year undergraduate student at IIITH, majoring in computer science. I'll be rewriting weather this summer as a part of GSoC 2014. My mentors are meejah and karsten. In a nutshell, the weather rewrite project mostly involves two tasks, shifting the data backend to onionoo and closing the weather-specific tickets that are causing an issue at the moment. Besides these, there is also a plan to make use of a postgres database to store weather's subscription data. After this is accomplished, I'll document and test the new weather to make sure it's clean. Further details of my project proposal can be found at [1]. I'm very excited about working with Tor on this project and am happy to receive any sort of feedback and suggestions. Cheers, Sreenatha [1] - https://sites.google.com/site/sreenathadev/gsoc-2014-weather-rewrite ___ 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: > On 04/22/2014 10:35 AM, Georg Koppen wrote: >> 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. Okay, sounds reasonable. What is the fallback plan for the case the code is not getting open-sourced during the time you are working on the topic? Do you have an "internal" deadline like: "If I/we don't have the code by XXX I'll start an implementation from scratch"? > 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). Sounds good to me. 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
