
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I agree with the fact that I think we could accomplish all of this through better documentation. I'm not a massive fan of those five different states - I just feel it's a little too confusing for users. Regards, Joshua Lee Tucker @tuckerwales On Tue, Jul 7, 2015 at 5:21 PM, Karsten Loesing <karsten@torproject.org> wrote: - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/15 17:40, Zack Weinberg wrote:
On Tue, Jul 7, 2015 at 10:19 AM, Joshua Lee Tucker <josh@tucker.wales> wrote:
I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the "Exit: Yes" clickable?)
How about "Exit: [Never/Unrestricted/Restricted/Unlikely/Former] (details...)"
Yes, I could imagine adding more states than just Yes and No.
where: "Never" means the relay has never allowed exiting to any port or IP;
Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this.
"Unrestricted" means the relay currently allows exiting to all ports and IPs;
Plausible, though there are hardly any relays permitting all ports.
"Restricted" means the relay currently allows exiting to some ports and IPs, enough to get the exit flag;
I'd simply call this "Yes". All relays with the Exit flag would have this state.
"Unlikely" means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag;
This is probably what I'd call "Restricted" or "Limited". That's for all relays which don't have reject 1-65535 and which also don't have the Exit flag.
"Former" means the relay allowed exiting to something at some time in the past, but doesn't anymore.
This has the same issues as "Never". We'd also need "No" for the reject 1-65535 case.
And in all cases you can click for more details. (The '(details...)' is literal.)
See my earlier response about more details. We can probably explain three or four possible states in easy-to-understand terms. So, yes, this seems plausible, if we can keep it simple. What states should we use, and how should we document those in user language? All the best, Karsten - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVm/yJAAoJEJD5dJfVqbCrNSQH/1q3hS7aMvEPcgCp+E/cLwjy fmYHEilAgOa1hYwf+wZshljQqDQmMxzHCAheIR+db2pPa7ZZfguwR7tZ0Z4NfvIU rwgQrgpGg+W5Zd9bl/2mW7eZFHAAQRpdDzMPy5zlDUHd2pR6tCQNvudhGXhbrlau ZBgaegsnT40dncMu0lChOvy9WHscKVCw3Ip3y9jVd5A01gY95cCS5RNKs3Ma0A6T OFxDZ9dzApika+zbDaTGVb/bYeWuM3QwAcKfjHcg4hf0GkMC8W/FnK/6X1Sfsjp8 omYRvLmispKkMYlvcYPBSGAMLXKcCyrrBTj5LtnPyIyUnmBM05FCIhNPH7KxNe4= =dd+a - -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -----BEGIN PGP SIGNATURE----- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVnBJVCRB1zCF5iNk2lwAAGbYP/iefpIjrTjn4+CJP+TGs NYhUEp5KVMAjOb1kGKjlUPZvh/6irQYmUqZo2A/qNgCIma71Nc3//FA9GN9l dOAYkuQ+seYzy9+OgZmCnkB11JGTTi1/A/nlyo/TAtxgQ6zYNGwa741ZhoSv dGRN4XzvCJjc8Supgpfeb6Aw/av9BGu4UBjdf0BWNuZ66AgcUPdtsC4ldwaN 2/IP3nvHVzU0IA2KyilV+9cpNeAU4xYivCCAo1yLWaOV4AWr9x0CwuxscoV2 mOPdI5/Og0fhoeDKBew3h610p0z1atF8m5flNVL3aUsBBmJzQdYWTOtoYvtD rmAZSiXAm8tZtLYLiWD/sD8ThonNXkzg+8+uRo27TUR7Mem4mZSGeq+nvUAO UTc+K2+03TxqYMIgjFZuEfV9SzcuabI6m2Nhy9T30E7cTKam9/pjHwGV6Qcl o98k1X2zBuGHvYAz8Wnb5x8NBwCAi4Otliewqf9bVKcnD59r4fQunVeys+8/ qGPX/N1dkxhAGOaxx2q/eSbZMxUvFOCNeNbRVwIB88ES2pTNWRyqCFPmyhlv ndrxwkDu1Ib8aFSM2jDFe76D6B07NfbSFjZm9Ifb0z0fW9RZ7RL14QbVQhj6 GkqsgyYZ62b7ThjMnREgIZ6U1LO4FBp8MgKDxV0haVP18AknU24rxInXAPao wNu4 =MmQA -----END PGP SIGNATURE----- On Tue, Jul 7, 2015 at 5:21 PM, Karsten Loesing <karsten@torproject.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/07/15 17:40, Zack Weinberg wrote:
On Tue, Jul 7, 2015 at 10:19 AM, Joshua Lee Tucker <josh@tucker.wales> wrote:
I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the "Exit: Yes" clickable?)
How about "Exit: [Never/Unrestricted/Restricted/Unlikely/Former] (details...)"
Yes, I could imagine adding more states than just Yes and No.
where: "Never" means the relay has never allowed exiting to any port or IP;
Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this.
"Unrestricted" means the relay currently allows exiting to all ports and IPs;
Plausible, though there are hardly any relays permitting all ports.
"Restricted" means the relay currently allows exiting to some ports and IPs, enough to get the exit flag;
I'd simply call this "Yes". All relays with the Exit flag would have this state.
"Unlikely" means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag;
This is probably what I'd call "Restricted" or "Limited". That's for all relays which don't have reject 1-65535 and which also don't have the Exit flag.
"Former" means the relay allowed exiting to something at some time in the past, but doesn't anymore.
This has the same issues as "Never".
We'd also need "No" for the reject 1-65535 case.
And in all cases you can click for more details. (The '(details...)' is literal.)
See my earlier response about more details. We can probably explain three or four possible states in easy-to-understand terms.
So, yes, this seems plausible, if we can keep it simple. What states should we use, and how should we document those in user language?
All the best, Karsten
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJVm/yJAAoJEJD5dJfVqbCrNSQH/1q3hS7aMvEPcgCp+E/cLwjy fmYHEilAgOa1hYwf+wZshljQqDQmMxzHCAheIR+db2pPa7ZZfguwR7tZ0Z4NfvIU rwgQrgpGg+W5Zd9bl/2mW7eZFHAAQRpdDzMPy5zlDUHd2pR6tCQNvudhGXhbrlau ZBgaegsnT40dncMu0lChOvy9WHscKVCw3Ip3y9jVd5A01gY95cCS5RNKs3Ma0A6T OFxDZ9dzApika+zbDaTGVb/bYeWuM3QwAcKfjHcg4hf0GkMC8W/FnK/6X1Sfsjp8 omYRvLmispKkMYlvcYPBSGAMLXKcCyrrBTj5LtnPyIyUnmBM05FCIhNPH7KxNe4= =dd+a -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays