Re: [tor-dev] Usability Improvements for Atlas (was Re: Globe is now retired)
Hi, I've also recently improved Atlas but it changes major part of the user experience. So this is a kind of Request For Comments. Most of the changes are my vision of how-it-should-all-look-like. The most notable changes are: * There is no super-wide list of relays that doesn't fit even into Tor Browser window (panels instead with upstatus indication) * Responsive design for narrow screens * Updated navigation bar with new version of Bootstrap * Vector icons for flags and other * Stretching of the graphs You can review all the changes at [1] and deployed version at [2]. Please let me know if you have any ideas/suggestions. P.S. Some of functions like list sorting, display range, detailed search and maybe more are broken/gone now. I'm wondering if these functions are useful? [1] http://hartwellnogoegst.onion/atlas/log/?h=new-design [2] http://hartwellnogoegst.onion/deploy/atlas-new-design/ -- Ivan Markin ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC '16] Exitmap Improvements Project - Status Report #3
Hi everyone! For the past week, I have shifted my focus to the main sub-project of continuous scanning in Exitmap. What we'll be trying to achieve is having the Exitmap utility running in the background and running the various modules. This report recounts one week worth of work since my 2nd report was on 26th June. Work done: --- 1. Wire-framed the structure of how continuous scanning will work. Major components that will be focused on are (a) Periodically updating the network consensus to scan for new or previously invisible exit nodes for malicious behaviour, (b) A mechanism that keeps a close eye on some exit nodes while does not care much for nascent exit relays or well established guard nodes, and (c) Add as much randomization as possible for these scans to make it more difficult for a malicious exit relay to distinguish regular traffic from scanner activity. 2. IRC meeting with my primary mentor Philipp Winter (phw) to discuss some of the features and how will go about implementing them. Some points arrived at from the discussion: a. Need to create an asynchronous element for periodically fetching consensus data and to integrate the element with the existing Exitmap functionality. b. Find a way to update the Tor micro-descriptors and use new consensus for the modules. I still need to find a way to programmatically force the Tor client to update its consensus at the moment specified. Damian Johnson (atagar) advised me to use the FetchDirInfoEarly parameters that helps. If anyone has any more information about this, it would help a lot. I will be scouring through the control-spec for the same. c. Create an algorithm to give more weightage to some exit nodes from consensus depending on what the criteria is. We need to come up with a selection mechanism that selects nodes visible in the say 0-24 hours time frame but is not a node that has just come or has been around the Tor network for some time. Some research still needed on this aspect. Have a great weekend everyone! -- Mridul (mtyamantau) = PGP keyID: 0xb716e33ab6d0a653 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSOC 16] Ahmia status update #3
Hi everyone, I'm working on ahmia.fi, the hidden service search engine and you're reading status update #3. Since last time, I've been moving forward with the django "rewrite". A little context: The current main goal of the project is too regroup all data related to search into our elasticsearch index (sites content, tor2web stats) so we can use it to give better search results. Since I'm focusing on the django part, I'm removing a lot of search logic which is now done by elasticsearch. For instance, banned websites will be store in our main index and elasticsearch will filter them before returning search results. This is a different behaviour from now, where banned websites are stored in a PostgreSQL database and filtered at the django level. I'm also taking advantage of this rewrite to accomplish the following goals: - Compartimentalize what should be in apps : I plan to do three apps : search, stats and api - Remove deprecated code/files - Remove every linter error/warning : I worked on this one, but some warning could not be remove without a rewrite. - Update django version : We are using Django 1.7 which is not supported anymore. - Use a more coherent url scheme (while keeping retro-compatibility) - Use a more coherent API behaviour (also while keeping retro- compatibility) - Write more tests to verify correctness After this rewrite, we will have three apps in our Django website: Search will focus on pages related to search results, querying our index to get results. It will be later improved with !bang syntax or some other keywords to specify a date range, a specific .onion website, etc. Stats will focus on statistic visualization (most popular .onion, etc). It could be later improved with a "Ahmia trend" interface to view searches over time. Api will focus on the API part of the website. I have a couple ideas but will discuss them in a later report. During the next two weeks, I will continue my work on this rewrite. See you in two weeks :) Ismael ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] onionoo: poor reverse DNS results
Hi Karsten, some time ago I reported onionoo's poor reverse DNS results https://trac.torproject.org/projects/tor/ticket/18342 and it didn't change since then. As of 2016-07-02 08:00 (tpo instance) 3144 out of 8473 (~37%) still have no reverse DNS result (=IP address). Do you have an idea whether this will improve sometime before 2016-09-01? thanks, nusenu btw: Thanks for working around the maxmind AS problem with reverting to the May version. 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