-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/07/15 14:20, teor wrote:
On 5 Jul 2015, at 19:37 , Karsten Loesing karsten@torproject.org wrote:
Results: do we really need the "Exit: yes" column? Seems pretty redundant to me.
I think this is answered later in this thread. We should probably keep that column. Not sure if exiting to at least one of the two ports 80 and 443 justifies having that column set to yes. But assuming we can figure out good criteria there, having this information might be useful.
If we don't use the same definition as the Exit flag or the policy summary in microdescriptors (which can, in fact, be different), can we please document it somewhere?
For the purposes of ExoneraTor, it makes sense to use a broad(er) definition of Exit, as those using it will likely be answering the question: "Could a client have possibly used this relay as an exit?" Rather than: "Is this a relay which Exits to most places on some ports?" (microdescriptors) "Is this a relay which Exits to some places on common ports?" (consensus flag)
The differences between the consensus Exit flag and microdescriptor policy summaries are already a source of some confusion: https://trac.torproject.org/projects/tor/ticket/11264 https://trac.torproject.org/projects/tor/ticket/11624
Actually, how about we use the same definition as for the Exit flag?
Even if a relay without the Exit flag could have possibly been used as an exit, the probability for clients to choose it is quite low.
I'd say let's make this as simple and least confusing as possible. Re-using the existing definition of the Exit flag makes a lot of sense to me.
Updated the mockup.
Also, there seems to be 24 rows with white background, then 24 with light grey bg. If the search returns eg. 30 results, then only the last 6 would be in grey, and users could potentially think there's something special about those. I'd use a much smaller number, eg. 5 at most, so it's obvious that the background is just there for aesthetic reasons.
Ah, the highlighted rows contain results for the searched date, whereas the other rows are for the previous and next date. The idea is to always search +/- 1 day in order not to rely on users figuring out timezones correctly. Maybe the highlighting is too implicit though. I'll leave it out. It's not worth explaining to users what the highlighting is about, and it's particularly not worth confusing users with it.
"The two extreme time zones on Earth (both in the mid Pacific) differ by 26 hours." https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
So can we possibly change this to +/- 26 hours? (or, perhaps, 30 hours, just in case some region adjusts its timezone another hour or two out?)
For the sake of those in Kiribati, Samoa, Tonga and the eastern New Zealand islands on one side, and the US Minor Outlying Islands on the other.
But no timezone can be more than -12 or +14 hours away from UTC, so I think we're good by including the previous and next 24 hours of any given date. That being said, I'm not good at timezones, so it's quite possible that my math is wrong.
Tim
Tim Wilson-Brown (teor)
Thanks for your feedback!
All the best, Karsten
teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays