-----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
