[tor-talk] Better bridge management for clients

[Georg Koppen]

CarlSpackler at getbackinthe.kitchen:
> When using bridges on a daily basis, how may I know which
> work and which don't? (Say for example you added multiple
> bridge lines and not simply one bridge)
> 
> It would be nice to add to the GUI some color coded buttons,
> like "green" for "working bridge" and "red" for "bridge
> is no longer usable" and the user is either given the option
> to tick a box and remove the non functioning bridges with the
> red color beside them or have them pruned automatically before
> all is said and done. An option to save (overwrite) the user's saved
> list of bridges with only working bridges would be nice.
> 
> In addition to this being a healthy way of managing bridges
> for clients, it would prevent users from hammering away
> at IPs where bridges are down, IPs may be dynamic, and some
> poor fool obtaining an IP formerly used as a Tor Bridge and
> wondering why he's seeing all of this incoming traffic!
> 
> Now there may be some internal way of Tor checking this
> but it does no good to the Tor client user if he is reusing
> the same set of bridges every day, with no apparent feedback
> to which are good and which are no longer up.
> 

I think I agree with the general idea and that it would be a benefit to
have some kind of differntiation between "bridge is working right now"
and "bridge is not working right now".

However, I wonder how we (say Tor Browser) should measure that safely
and make sure that it is actually the bridge that is down (maybe there
was just an upstream issue at that time). Or do you mean the latter does
not really matter to users anyway and as long as bridges are not
reachable for whatever reason they should be treated as down? Moreover,
once bridges are marked as down I am not convinced yet we should just
discard them. Bridges are scarce and it might be just a short time the
bridge was/is actually not reachable/down.

An other option could be to incorporate external measurement data but
that comes with the price of enhanced complexity making sure that all
users have up-to-date data about bridge reachability readily available.
And even that is error-prone because even though that external
measurement might indidicate a bridge is down/up that might not match
the experience an individual user has.

So, hrm,
Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20180518/bac6fdcc/attachment.sig>