Re: [tor-relays] Tor Metrics issue

[Iain R. Learmonth]

Hi,

> Arisbe:>> I looked up my relays and bridges on Atlas using their nickname, 
> IP>>
address or fingerprint.  I bookmarked these look-ups so that I could>>
easily access the Atlas data for my nodes going forward.
No URLs have changed (planning to change them in the near future but
nothing changed yet, just the theme), this is odd.

>> I took the same tack with Tor|Metrics:  I navigated
>> Home>>Services>>Relay Search>>(node ID)
>>
>> This route works for my relays and I am able to, once again, bookmark
>> each for convenience.  However, this does not work for my bridges.  They
>> give me an error message.  I'm wondering if there is another route to
>> them or if the data for bridges is simply missing.

I'm able to see my bridges fine.

There may be something strange going on with your bridge though that
triggers another code path that my bridges don't. If you could let me
know the hashed fingerprint I can better debug this.

Also, please check your torrc for a PublishServerDescriptor line and
check that you haven't disabled the publishing of the descriptor to the
bridge authority, which is where the data comes from.

If you're running a private bridge, you cannot view this on Relay Search.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 16/11/17 02:36, teor wrote:
> No, I can't, because iOS ad blockers do not provide this information.
> Did you add many resources in the transition?

Short of buying me an iPad I have no idea how to debug this.

The following resources are loaded by Relay Search, and the new ones are
those on metrics.torproject.org. Note that the entire application is
loaded when you access the site, so it either works or it doesn't. If
there is a single JavaScript or template missing, it will just not work.

https://atlas.torproject.org/
https://metrics.torproject.org/js/jquery-3.2.1.min.js
https://atlas.torproject.org/js/jquery.cookieBar.js
https://atlas.torproject.org/css/bootstrap.min.css
https://metrics.torproject.org/js/bootstrap.min.js
https://atlas.torproject.org/css/font-awesome.min.css
https://atlas.torproject.org/fonts/source-sans-pro.css
https://atlas.torproject.org/css/prism.css
https://metrics.torproject.org/js/prism.js
https://atlas.torproject.org/css/style.css
https://metrics.torproject.org/js/script.js
https://atlas.torproject.org/css/atlas.css?v1
https://atlas.torproject.org/js/libs/require/require.js
https://atlas.torproject.org/images/tor-metrics-white.png
https://atlas.torproject.org/images/tor-metrics-wh...@2x.png
https://atlas.torproject.org/js/main.js?v1
https://atlas.torproject.org/js/app.js?v1
https://atlas.torproject.org/js/libs/underscore/underscore-min.js?v1
https://atlas.torproject.org/js/libs/backbone/backbone-optamd3-min.js?v1
https://atlas.torproject.org/js/router.js?v1
https://atlas.torproject.org/js/views/details/main.js?v1
https://atlas.torproject.org/js/views/search/main.js?v1
https://atlas.torproject.org/js/views/search/do.js?v1
https://atlas.torproject.org/js/libs/jssha/sha1.js?v1
https://atlas.torproject.org/js/models/relay.js?v1
https://atlas.torproject.org/js/models/graph.js?v1
https://atlas.torproject.org/js/libs/require/text.js?v1
https://atlas.torproject.org/js/libs/bootstrap/bootstrap-tooltip.js?v1
https://atlas.torproject.org/js/libs/d3js/d3.v3.min.js?v1
https://atlas.torproject.org/js/helpers.js?v1
https://atlas.torproject.org/js/collections/results.js?v1
https://atlas.torproject.org/js/libs/datatables/jquery.dataTables.min.js?v1
https://atlas.torproject.org/js/libs/datatables/dataTables.Sorting.js?v1
https://atlas.torproject.org/js/libs/bootstrap/bootstrap3-typeahead.min.js?v1
https://atlas.torproject.org/templates/details/router.html?v1
https://atlas.torproject.org/templates/details/bridge.html?v1
https://atlas.torproject.org/templates/details/error.html?v1
https://atlas.torproject.org/templates/search/do.html?v1
https://atlas.torproject.org/templates/search/main.html?v1

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridges not found on Nyx

[Iain R. Learmonth]

Hi,

On 15/11/17 07:13, Arisbe wrote:
> I use to review my bridges as well as my relays on Atlas.  Now I don't
> find my bridges on nyx.  Is this something I'm doing wrong?

Atlas and Nyx are different things. I've updated the subject and
hopefully someone familiar with Nyx can chime in.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 14/11/17 21:49, I wrote:
>  Can anyone explain how changing things to The New such as Arm to Nyx
> and Atlas to Relay Search advances anything apart from boredom?

In the case of Atlas/Relay Search, we are consolidating codebases into
something more maintainable, with less code duplication and general
duplication of effort.

By integrating Relay Search into the Tor Metrics website, we will also
move towards a more seamless UX and making it easier to discover related
data, the sources of the data and any analysis that might be useful.

On the surface it may look that all that's changed is the theme and the
name, but a lot is going on underneath too.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 14/11/17 18:26, teor wrote:
> No, it isn't: one of the new resources appears to be blocked by AdBlock
> Plus for iOS. So it only works with content blockers turned off. You probably
> want to fix this eventually, because these blocklists are popular. And the
> issue likely affects multiple platforms. But it's not an all iOS devices bug.

I've tested with AdBlock Plus in Firefox and I cannot recreate this problem.

Can you tell me what resource it is that is blocked and what rule it is
matching?

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 14/11/17 20:33, tor wrote:
> A 200px purple banner with a Schneier quote at the top of every page?
> Seriously? What a hideous waste of space. Can anyone explain how this UI
> element is helpful to users? It's awful.

This is the Tor Metrics style used in preparation for merging into the
Tor Metrics website.

A ticket has already been filed to discuss this, but this is not an
immediate priority:

https://trac.torproject.org/projects/tor/ticket/24277

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 14/11/17 17:03, Ralph Seichter wrote:
> I see no more graphs outside their boxes in Chrome, Firefox and Safari.

Yay! (:

> One thing that -- for me -- only works in Chrome and Firefox, but not
> Safari, is the timestamp info shown when moving the mouse pointer over
> the little circle icons in the graphs. Safari does not present any popup
> data, the other browsers do.

Ok. I imagine these probably didn't work before either. They're not the
best graphs and I might look into better ways of generating them at some
point in the future.

For now I'm going to call it "better than it was before" and be happy. I
do remember that the SVG didn't scale on the old Atlas so we were very
quick to drop to single column.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

> On 14/11/17 16:16, Ralph Seichter wrote:
>> https://imgur.com/a/VMJhE -- I see these "graph outside the container
>> box" issues in Chrome, Firefox and Safari. I sure hope it does not just
>> happen to me?

Graphs should now be scaling properly, although I'm not sure what I've
done will work in all browsers, if it's still broken please let me know.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 14/11/17 16:28, Guinness wrote:
> Is it just me or is the font way bigger than it used to be with Atlas?
> I personnaly find it too big, but it is just some cosmetics :)

The style has been merged from the Tor Metrics website. For the most
part this is fixed as all the style decisions have already been made. If
there's a particular area where changes are needed then they can be
addressed, for example I changed to a smaller font size for the results
table. I'd like to keep these changes to a minimum however to focus on
functional improvements, such as the recent addition of Exit Addresses
to the relay details pages.

Thanks,
Iain.





signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 14/11/17 16:16, Ralph Seichter wrote:
> https://imgur.com/a/VMJhE -- I see these "graph outside the container
> box" issues in Chrome, Firefox and Safari. I sure hope it does not just
> happen to me?

This looks to be an issue with the responsiveness of those boxes. I'm
getting that too.

They're meant to go to single column when it's not possible to display
side-by-side.

https://trac.torproject.org/projects/tor/ticket/24276#ticket

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi,

On 14/11/17 16:04, Ralph Seichter wrote:
> I have since removed all cookies and data tied to the torproject.org
> domain from my Safari 11 cache, and now Relay Search seems to work as
> designed. I'm glad, of course, but it still seems weird. At least I have
> screenshots to prove that I did not merely imagine the problems. ;-)

Thanks for following up. (:

I think there may be some issues, with such a large change some breakage
may occur if you have different versions of the JavaScript files and the
templates in your cache.

The Last-Modified dates seem to work, and If-Modified-Since seems to
work too. Maybe Safari is just doing something weird and not
invalidating the cache.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

On 14/11/17 15:35, Ralph Seichter wrote:
> On 14.11.17 13:52, Iain R. Learmonth wrote:
> I also notice that the "new look" does not work in Safari 11 on macOS
> 10.13.1 (High Sierra). For shame! Has nobody tested this?
> 
> Problem detail: When accessing https://atlas.torproject.org/ , the query
> box and explanatory text are missing in Safari. See screenshot at
> https://imgur.com/a/XnA9f . Searching works fine in Chrome and Firefox
> on macOS.

This would seem suboptimal.

I will look into it, unfortunately I have not tested on all the
platforms as I just don't have them available.

I think I have a non-High Sierra (Low Sierra?) box that I may be able to
test on. Were there big changes between these?

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [metrics-team] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi David,

On 14/11/17 13:01, David Goulet wrote:
> Quick question for you. Atlas used to have the search box at all time in the
> corner which for me was very useful because I could do many search without an
> extra click to go back one level down like the new site has.
> 
> How crazy would it be to bring it back? Always hovering in the top corner? :)
> Maybe a ticket would be a better way to ask?

Please do file a ticket.

Thanks,
Iain.




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Atlas is now Relay Search!

[Iain R. Learmonth]

Hi All,

You may notice that Atlas has a new look, and is no longer called Atlas.
For now no URLs have changed but this is part of work to merge this tool
into the Tor Metrics website.

The style is determined by the Tor Metrics Style, and modifications have
been made to fit this.

The decision was made to deploy these changes before the actual
integration into metrics.torproject.org to allow for other issues to be
worked on. This was a big change and it was tricky maintaining two
branches of the codebase.

Issues should still be reported on the Metrics/Atlas component in the
Tor trac if they arise. When we come to full integration, URLs will
change but there will be a period where we maintain redirects to prevent
any URLs from breaking while waiting for being updated.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] PSA: exclude /var/lib/tor/diff-cache/ from your backups

[Iain R. Learmonth]

Hi,

On 14/11/17 05:03, Roman Mamedov wrote:
> Dear Tor project: this is very bad style to keep that in /var/lib, content
> with properties like this must go into /var/cache/ [1], where it would be
> automatically excluded from backups by default policies in most backup 
> systems.

It does seem that all paths used by tor are relative to DataDirectory,
which has usually been /var/lib/tor. Perhaps a new configuration option
for CacheDirectory, and moving caches to that directory, would be
useful. It would be up to packagers to actually use that option though,
a default of using DataDirectory as CacheDirectory would not be entirely
unreasonable for cases where tor is embedded in other software.

This would seem worthy of a trac ticket if someone could write one up.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor t-shirts

[Iain R. Learmonth]

Hi,

On 21/10/17 09:06, Roger Dingledine wrote:
> That said, the folks handling tshirt requests are the real arbiters
> of how they are interpreting my sentences, so I will defer to them. :)

I was sure we had a bug for this, but I can't find it. Here's a bug I
just filed to include eligibility information for a t-shirt on
Atlas:

https://trac.torproject.org/projects/tor/ticket/23941

It would be great to have someone from the t-shirts team comment here,
as I'm not exactly sure what the criteria are.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Using ContactInfo to publish additional relay properties in a standardized way (opt-in)

[Iain R. Learmonth]

Hi,

On 15/10/17 09:07, nusenu wrote:
>> See proposal 234 [0] for adding bitcoin/zcash/etc addresses.
> 
> Thank you for the pointer. This proposal is from 2014 and I havn't found
> any trac ticket for it, so I guess no one is working on implementing it.
> Once this is implemented I'll remove these fields from [1] if onionoo
> includes these fields.

It would be interesting to see how many relays currently have
bitcoin/zcash or similar addresses in their ContactInfo fields.

> While I agree that it would be nicer to have this as separate fields -
> and this is the way to go on the long run (if anyone implements it) - in
> practice this requires a lot more than people just changing their
> ContactInfo string according to a specification:
> - proposal(s)
> - deployment of new tor version on the network
> - tor code change (implementation)
> - onionoo code change to parse new data
> - atlas code change to display new data

This is true.

> Using ContactInfo does not require any tor/onionoo code change even
> atlas is optional and relay operators don't have to wait for a new tor
> version that supports it. They can basically start using it once the
> specification for the format is done (<1month).

Perhaps then we can use the fields that people choose to use as an
indicator of which ones we should progress to proposals for changes to
the descriptors.

I would suggest though that if these do catch on, perhaps proposing an
AdditionalInfo field as a catch-all field to house future properties
until they can be formalised to avoid doing too much with the
ContactInfo field?

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Using ContactInfo to publish additional relay properties in a standardized way (opt-in)

[Iain R. Learmonth]

Hi,

On 14/10/17 23:01, nusenu wrote a proposal.

The ContactInfo field doesn't need to be overloaded again. ):

See proposal 234 [0] for adding bitcoin/zcash/etc addresses.

Maybe we can work out new fields for extrainfo documents [1] that could
contain some of this information.

I do think this is a useful thing to look at, but I just don't think
that ContactInfo is the right way to go about it.

[0]:
https://gitweb.torproject.org/torspec.git/tree/proposals/234-remittance-addresses.txt
[1]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n799

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] abuse email for non-exit relay (masergy)

[Iain R. Learmonth]

Hi,

On Fri, Sep 22, 2017 at 04:52:02PM +0100, Pascal Terjan wrote:
> There may be some timing difference, a faster response if the
> connection fails/is rejected vs if nothing is listening

Ah, I hadn't thought of that. Although I guess this would also be the case
if there is congestion or a whole number of other factors?

Thanks,
Iain.



signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] abuse email for non-exit relay (masergy)

[Iain R. Learmonth]

Hi teor,

On Fri, Sep 22, 2017 at 11:14:07PM +1000, teor wrote:
> 
> > On 22 Sep 2017, at 23:03, relay 000  wrote:
> > 
> >> Someone is using the hidden service rendezvous protocol to ask non-exit
> >> relays to scan non-tor IP addresses.
> > 
> > wow, people can misuse my *non*-exit relay to scan (aka send a TCP SYN
> > packet) other systems on the internet?
> 
> Yes.

Can you clarify here that no feedback is given and that this is not a useful
scan?

I assume the remote relay will return the same error whether there is
something listening on the port or not, as it wasn't possible to extend the
circuit.

Thanks,
Iain.



signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Some Dir Authorities blocked

[Iain R. Learmonth]

Hi,

On 17/09/17 04:56, Iain R. Learmonth wrote:
> I'll have a think about this.

I had a little think about this. While the search strategy is something
to consider, I've hacked up a simple tool for building circuits and
detecting, at a very high level, when it fails. I don't yet have the
reason for the failure being captured.

To give an idea, failures are not uncommon but it is far more likely
that the connections will succeed. I ran a trial with random selection
to build two hop circuits.

The most interesting thing I've discovered so far is that it's common
for the connections to fail in one direction but then succeed when the
two relays are reversed. I can't be sure if this is because I can't
reach one of the relays.

Thanks,
Iain.

sqlite> select * from partitions;
80150521E1606A3C66FBD0502417775C06E83530|91516595837183D9ECD1318D00723A8676F4731C|REV|2017-09-17
06:55:42
C78AFFEEE320EA0F860961763E613FD2FAC855F5|57F5C55A6D76832400D679B4D6DCE6312CB724DD|FAIL|2017-09-17
06:55:58
721F8C234700A49C6CB42B8905719C4472698EEF|D01956B555BA59D422D994D41AC9634183974597|FAIL|2017-09-17
06:56:02
A39E63BF03742663C3945E774C71AD3B6DB935C5|C7FDF95CE03E8387780F75C9CD22B9A88C956BC9|FAIL|2017-09-17
06:56:08
1C173D4513B5BA66202E02CD4F61304FD4CC6C62|F2A6F1BB8ADD47CC9CC67928EA8EA7FDB3F92533|REV|2017-09-17
06:56:11
E5434A08ABDB8578C76BCDA3EECC22B5226D2CB4|77204802405A7DF1E7BD3BC579F8D1D7FB81DFD4|FAIL|2017-09-17
06:56:17
A0639496103E4F0C721E4CD31BD22CC9EF94C4CE|3C79699D4FBC37DE1A212D5033B56DAE079AC0EF|REV|2017-09-17
06:56:19
80150521E1606A3C66FBD0502417775C06E83530|C7BA56FA43EA6650E1644EA05CEC3A90F559B748|REV|2017-09-17
06:56:21
273C58C7764D2718A11FB7BA2205FC147948D7FE|8F2DDD78AC99CA0CFBFAF83CA33CE87785BB12C5|FAIL|2017-09-17
06:56:22
A2C2F9B652D6CFC6E0E329ED4577797CC9AD6BAB|655886ECB83A40E1BE989513D8C5C608D4B968C9|REV|2017-09-17
06:56:31
6DE375E172280727AEDCCA774D105692DEBF882A|A8A81263CB00469D98FF8E46A5A63FC4691BF3EA|REV|2017-09-17
06:56:41
88C615AC5F9591BFD48DB578B252B89A72F5C3AB|FF95E280D0DA09331EAE6B6C90F390A809D8FF9C|FAIL|2017-09-17
06:57:11
C9860279669435F6F237A04CC70849A3AB2BCB3B|5CA77202F93CDD06114A2F49309805F1881AE3E8|FAIL|2017-09-17
06:57:25
BA9E17048076E99AE359207A9436B7C07D1194C4|91716855ACF3C33C3EE49AAA046FA15486FDBDD5|FAIL|2017-09-17
06:57:26
7723B1B4B2B4D9D161209F770079A6F0A5A929BC|984096B174736E641F25B1B18312DA8629F1B2C4|FAIL|2017-09-17
06:57:48
D4691414A1C98DD3E022A0FFB1A2E11634BD0D21|887E2B73EDA109C09ADEBD6B1E788FDF620646B7|FAIL|2017-09-17
06:57:51
A07581D99FB42018B284484437DD60A0BA2BA254|8F46628BBDC55AA1065A6DB957E3A0187FD0C65F|FAIL|2017-09-17
06:58:04
A9B4409C72172BF3388B72CECB3F22538131F7C6|BD4C647508162F59CB44E4DFC1C2B2B8A9387CCA|REV|2017-09-17
06:58:13
4D6F22DE54C9CC48C15E2C01D53385D05D9AF31B|3B3D1284AAE1C039D3D0FB3BBAC38F2B0775FDED|FAIL|2017-09-17
06:58:17
18046895412A1185A1F3715D5FD2987CDC8C4B91|8E7093C928C5FF8D8E854A312002A582F131728F|FAIL|2017-09-17
06:58:25
A0639496103E4F0C721E4CD31BD22CC9EF94C4CE|A1D947A7751938A78FD00D971FC9098B5F397C6A|REV|2017-09-17
06:58:45
D7A6E23AEFB37D241D4408598434C7A6CB36F261|549FCA8AD9A43C8289A32D7702CDEDFE47029A43|FAIL|2017-09-17
06:58:56
5CECC5C30ACC4B3DE462792323967087CC53D947|4EADA139AC7A6EB32242BE10E662D9339A228A1F|REV|2017-09-17
06:59:03
926344F6AA5FFA5B64E677929BA118FE222D2B10|A790828A47B3C5E1AA6FFA8413998F28C105E4FD|REV|2017-09-17
06:59:23
8D2F90F1E216D5F9D9AB03B8BA7BF3167DD2D859|132AC31797DC7285E365AFDF5393C11158059CBB|FAIL|2017-09-17
06:59:35
8783261406392FFD39F41AD4D8F3293460A27EFD|A58151DB952DE7821AAB96948894D937149C301B|REV|2017-09-17
06:59:50
465E967E36285F2EB7B0683E2085829803F07C31|1399C98B3A8F90ABF7ACBFED9B38EE37CA294CF6|REV|2017-09-17
07:00:02
4110885745B673A45FDF150BE1CAC01FFAD640F1|18046895412A1185A1F3715D5FD2987CDC8C4B91|FAIL|2017-09-17
07:00:06
8352FAC3EA88A399A4F2F95CE762786944E75B06|1D503952419FF24F0764762245855DF8DC73391B|FAIL|2017-09-17
07:00:07
721F8C234700A49C6CB42B8905719C4472698EEF|44B7778B1D9A17237572A61B62F4487386BF728F|FAIL|2017-09-17
07:00:15
7A665FD6A05BB8EDD5362A7E25AEEA7D1F8122DC|92FE5D1485CCDA66822964DDFE6CCF3936218653|REV|2017-09-17
07:00:20
3CF4C6996B185090A576DB2170802FE9986F0553|1C1C275B8E9F8D0824424DDFABCA488BA24756B0|FAIL|2017-09-17
07:00:24
D665C959571041972EA8C0DD77559EF5579BA112|7DAF1969E80543C75369E4C88D32836487D6F09C|FAIL|2017-09-17
07:00:51
1702F6888757D679AFBEC9842F4B98E9B02B6D40|2DE827E0A349AEBE42E233F3B5ABE821321BFC8D|FAIL|2017-09-17
07:01:04
11FDAEE6B7F67B28A2BE88126625E21B467287EF|EBE1BDE602EC578A60B5EA5C84D996FA4052787B|FAIL|2017-09-17
07:01:18
FB8BEE7BF2606879496317BB42D0792EAA62153A|E64625ED5B01A1F0E97BCF0B5D431A432A24F408|FAIL|2017-09-17
07:01:21
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Some Dir Authorities blocked

[Iain R. Learmonth]

Hi,

On 17/09/17 00:56, Roger Dingledine wrote:
> Actually, no, we want it to be the case that all relays can reach all
> relays. The less true that becomes -- that is, the less clique-like
> the network topology becomes -- the more complicated the anonymity
> measurements become, and that is potentially quite bad.

I would love to be able to add an "unreachable relays" box to Atlas to
let operators see which relays they can't reach.

I'll have a think about this.

Thanks,
Iain.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Would you also like to have family-level atlas pages?

[Iain R. Learmonth]

Hi All,

This is clearly something that operators want.

> https://nos-oignons.net/Services/index.en.html

This looks like a great idea. I can't promise immediate progress on
this, but I'll file a trac ticket shortly and hopefully progress can be
made soon.

Thanks,
Iain.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] new Atlas feature: Not Recommended Tor Version

[Iain R. Learmonth]

Hi,

On Sat, Mar 04, 2017 at 08:23:00PM +, nusenu wrote:
> > [10:55]  Why does Atlas shows the "not recommended software"
> > icon under "Flags" ? B/c this python snippet sjhows, that it is not a
> > flag in the (old) meaning: flags =
> > controller.get_network_status(relay=srv.nickname).flags

We're looking at adding a new category of "Properties" that are flag-like
things that are also not Tor spec flags. This will include the "Not
Recommended" flag, and will also later include an IPv6 flag and a "Currently
Running" flag to distinguish relays that are actually running from those
that were last seen to have the Running flag when they were running but
currently aren't.

If you would like to comment on this, please do so on this ticket:

https://trac.torproject.org/projects/tor/ticket/21635

Thanks,
Iain.



signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas: Short term bandwidth charts missing ?

[Iain R. Learmonth]

Hi,

On Thu, Jan 26, 2017 at 11:07:10PM +, Iain R. Learmonth wrote:
> Following the Metrics Team meeting today, it was decided to remove these
> graphs, at least until we can come up with something better.

Those graphs for which data will never be present (3 days and 1 week
traffic) no longer attempt to be drawn on Atlas since this morning.

Thanks,
Iain.



signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas: Short term bandwidth charts missing ?

[Iain R. Learmonth]

Hi,

On Sun, Jan 22, 2017 at 09:55:43AM +0100, mistral.re...@posteo.net wrote:
> Many thanks for the reply including the link to the open ticket! I really
> hope that this gets sorted out at some point. I spent quite some time to
> sort out what might be wrong with my setup but good to know the issue is not
> on my side.

Following the Metrics Team meeting today, it was decided to remove these
graphs, at least until we can come up with something better.

> I think both - short-term and long-term - statistics are valuable.
> Short-term to control the impact of changes (some OS fine-tuning, routing
> changes, bandwidth changes,...) and long-term to see how stable everything
> is and how much a node is actually used and how it develops over time.

Indeed. The data is still present for the shorter-term graphs, though at a
lower resolution. If you would like higher resolution data for your relays,
you could take a look at:

 https://www.atagar.com/arm/

> To avoid misreading and confusion there should be no blank chars shown on
> Atlas when there is nothing available to fill them with data. This includes
> long-term charts where no recent data is shown (e.g even on a five-year
> graph I would expect to see data even if the node is maybe up for two years
> only).

Agreed. There was originally code to detect when data is missing, but it
doesn't seem to work anymore. I will need to dig into that futher.

Thanks for raising this issue and hopefully the fix can be reviewed and
deployed shortly.

Thanks,
Iain.



signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] VPS for Exits and non-Exits

[Iain R. Learmonth]

Hi,

On 06/07/16 18:25, tor relay wrote:
>> I've been running an exit node for over a year on OVH now, no problems
>> so far. Highly recommended (especially since they give me 10TB of
>> traffic for about 10$USD/month; considering I use about 7-8TB of that
>> per month, it's well worth it).
> 
> OVH is used to much by tor operators already (>12% of the tor network
> capacity is there).

Not the most performance enhanced page on the web but:

https://metrics.torproject.org/bubbles.html

This bubble graph shows where relays are located by autonomous system.
If you're looking to set up new relays, attempting to grow smaller
bubbles here (the names should be googleable enough) or trying to add
new ones would definitely be preferred over adding more to OVH.

It's great that OVH are Tor-friendly, but diversity of the network is
important.

Thanks,
Iain.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Iain R. Learmonth]

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-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays