[tor-dev] Usability Improvements for Atlas (was Re: Globe is now retired)
Hi All, On 29/06/16 09:56, Karsten Loesing wrote: > tl;dr: Globe is now retired in favor of an improved Atlas. Atlas is improved, but I'd like to improve it further. I've been tackling #6787 looking to improve the homepage and make Atlas easier to use for someone that isn't already a Tor expert. The changes I'm proposing in my fix for #6787 [1] do make some noticeable UI changes and I just want to gather some opinions on whether or not Atlas users feel that this is taking it in the right direction. The "Top 10 Relays" page was added to Atlas in order to make sure that functionality was not lost when shutting down globe. (See #5430 [2]) In my proposed patch, I'm also adding an "Authorities" page and adding text to both of these pages to explain what you're seeing. These are linked from the homepage, and from the top navbar. I'm also moving the introduction and explanation of the Atlas features from the About page to the homepage and introducing a new Help page that explains the details that are found in the relay details pages. You can find a live example of this patch at: https://irl.github.io/atlas/#/ and a full list of changes are detailed in #6787. Please let me know if you can see any reason to not merge this, or if you have any suggestions for small changes before merging. Thanks, Iain. [1]: https://trac.torproject.org/projects/tor/ticket/5430 [2]: https://trac.torproject.org/projects/tor/ticket/6787 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] txtorcon 0.15.1
Hi, On Fri, Aug 12, 2016 at 02:40:10AM +0400, meejah wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > There was a small issue in 0.15.0 noticed by the Debian reproducible > builds (thanks irl@debian for your packaging work!) Will get this packaged over the weekend. (: For those interested, I am also packaging txtorcon for jessie-backports and for Ubuntu suites on deb.tpo, as this is a dependency of ooniprobe. Thanks, Iain. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] txtorcon 0.15.1
On Fri, Aug 12, 2016 at 10:21:41PM +0400, meejah wrote: > "Iain R. Learmonth" writes: > > > Will get this packaged over the weekend. (: > > Sweet :) Got distracted over the weekend but starting on this now. > > For those interested, I am also packaging txtorcon for jessie-backports and > > for Ubuntu suites on deb.tpo, as this is a dependency of ooniprobe. > > FWIW, I have seen a few warnings recently about txtorcon being removed > from testing because tor will be. But, I'm not sure that tor should be a > *dependency* of txtorcon (just recommended). Obviously, it's not going > to be super useful without a Tor to talk to ;) but you might have built > tor yourself from source etc. (or even have it running on a different > machine). Everything in the Debian archive should be able to run with only things installed from the Debian archive. Debian policy requires that Tor be a dependency of txtorcon as without Tor, it's pretty useless. The warnings do seem to have gone away now, so I guess Tor is fixed. (: Thanks, Iain. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Not enabling IPv6 on check.torproject.org?
Hi, On Thu, Aug 18, 2016 at 11:13:08AM +, isis agora lovecruft wrote: > - Patching Check [1] to use server descriptors (rather than networkstatus >documents) and to additionally (in the Stem script) pull IPv6 addresses >from stem.descriptor.server_descriptor.RelayDescriptor.or_addresses. With IPv6 this can be more complicated, as relays may be using "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC4941) which means that these IP addresses may change often. We should probably give some advice to relay operators to ask them to disable privacy extensions? Thanks, Iain. signature.asc 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] Joining Tor Project's software infrastructure
Hi, On Tue, Oct 04, 2016 at 07:11:47PM -0400, Jesse V wrote: > > I'm also not sure what's the exact policy on gitian and > > deb.torproject.org, and whether third-party applications (like OnioNS) > > can be placed there. > > That's fine. It's not a big deal, but I would eventually like to have > reproducible builds on the official system. For now I have a few ideas > for reproducibility, so it's not a priority at present. If the software is stable, and reproducibly built, I would aim for placing it into the Debian archives. I maintain ooniprobe on deb.torproject.org, but primarily for Ubuntu users and I would prefer that Debian users are using the version from the Debian archive. One issue we run into is that in trying to support older distributions, we often then have to take on maintaining backports for various packages and in some cases this is a lot of overhead and careful version number management. If you wanted to set up your own Debian repository, that would also be an alternative solution for the short-term. > 1) I will finish all the primary components and ensure that they all > mesh together nicely. This involves a lot of testing and changes on my > end. This is currently where I am. > 2) I will deploy an alpha build to the approximately dozen volunteers > that have expressed interest so far. I will distribute RPMs, DEBs, and a > build of the Tor Browser that includes my libraries. I will help run the > servers and they can test out the components, particularly the onion > service and client software. > 3) Fix bugs and deploy into beta. > 4) I'll post on tor-dev or tor-relays asking for volunteers to help test > the server end. This is part where the system starts to become > decentralized. > 5) Fix bugs, grow based on interest, add more documentation, expand the > project page, etc. > 6) When everything seems stable and feature-complete, announce it so > that everyone can test out the stable builds. I cannot see that any of this actually requires the use of Tor Project infrastructure. If you really cannot set up a Debian repository for distributing pre-release packages, I can provide you with a simple repository set up to use. Thanks, Iain. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor and IP2Location LITE
Hi, On 23/08/17 03:45, KL Liew wrote: >> How is your accuracy for data centres? > > I don't aware of any research papers targeting data center only. > IP2Location should be highly accurate because we are using network > routing information to determine physical location instead of registrant > address. > > For example, IP2Location is reporting 185.56.163.144 as in France after > reviewing the network routing information as below. However, if you > search the same IP address in other geolocation providers, you might see > it as reported as North Korea, a country with limited Internet access. It is possible that this address is used by North Korea, they don't have a massive IP allocation and I would expect that perhaps there are some tunnels, but I can't figure out where MaxMind have got this idea from. I think GeoIP is actually a far more difficult problem when it's not typical residential customers. Satellite customers, for instance, may use IP blocks that are spread across multiple countries. I would expect that cloud providers and larger datacenter providers are using tunnels of sorts between their datacenters. Tunnels kill any visibility into the real routing path. When attempting to perform GeoIP for routers, the problem is compounded as you don't know who really owns the router based on IP addresses alone, routers having multiple IP addresses, etc. With the influx of new TLDs and TLDs being chosen for vanity purposes, they are also not a useful indicator. I fear its the smaller providers, the more Tor-friendly providers, that are missing or inaccurately represented in the databases. When it comes to measuring the accuracy of databases for datacenters, I wonder if there could be some means for relay operators to self-report a location and then we can compare this with different databases. Is there a safe way for relay operators to prove that they control a relay and self-report the location of the relay without us having to have an extra field in relay descriptors or overload the contact field? Some sort of out-of-band means? Thanks, Iain. 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
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
Hi, On 15/11/17 11:35, Alec Muffett wrote: > 8) So, to pass concrete advice on the basis of experience: rather than > pursue novel headers and reinvent a bunch of established, > widely-understood web redirection technologies, I would ask that Tor > focus its efforts instead upon providing a service - perhaps a listener > service embedded in little-t tor as an enable-able service akin to > SOCKSListener - which can accept a request from , > receive an newline-terminated IP address, and return a set of flags > associated with that IP (exit node, relay, whatever) - or "none" where > the IP is not part of the tor network. Riff on this protocol as you see > fit. Is this not what TorDNSEL does? https://www.torproject.org/projects/tordnsel.html.en Thanks, Iain. 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
