Re: [tor-dev] Usability Improvements for Atlas (was Re: Globe is now retired)

2016-07-02 Thread Ivan Markin
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

2016-07-02 Thread Mridul Malpotra
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

2016-07-02 Thread Ismael R
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

2016-07-02 Thread nusenu
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