[tor-talk] Better bridge management for clients

[Jim]

Nathaniel Suchy wrote:
> I think Tor Browser would need to create a statistics database for the
> bridges you provide it with and run tests over time and choose the
> bridges which have been historically the most reliable.

You might be able to create something useful to the user much more 
simply just from keeping track of normal operation (w/o running extra 
tests).  Perhaps after a bridge the software tried to use could not be 
reached a certain number of times over a certain number of days the user 
could be prompted with something like: "We were unable to contact such 
and such bridge the last 7 attempts over the last 3 days.  Would you 
like to remove it from it from your list of bridges?"

This would reduce the complexity of both the software required and the 
information provided to a user who otherwise might feel overwhelmed with 
statistical data.  Plus the software wouldn't take any action w/o the 
user's knowledge and consent.  (If the user declines when first 
notified, the software could stop prompting him (so as not be annoying) 
but maintain a menu option where the user could see updated statistics 
(bridge unreachable n times in last m days) and where he could still 
delete the bridge from the list if he so chose.)

Jim

> On 5/18/18 12:40 PM, Georg Koppen wrote:
>> 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
>>
>>
>>
>