Hey, > On second thought, I think using a single USED_GUARDS list here should be OK > for now. That's also what Tor is doing right now, so this behavior can't be > worse than the status quo. > > On this note, we should add a small "Discussion" section on the proposal and > briefly mention these issues that we might want to solve in the future, but we > don't know how now. Both things sound good to me. > It might be a good idea to enumerate the guards for each possible filter we > will add, and then calculate their guard probabilities, to see how likely it is > to randomly choose a guard of that type. If we have filters were there is only > 1% probability of picking a bridge of the right type, then these "your current > network settings make it impossible for us to safely choose an entry guard" > messages might appear more frequently than we would like. I'm not sure we can do this - a lot of the filters will be based on backwards compatibility with the existing Tor configuration options, things such as ReachableAddresses - I'm not sure how to reasonably enumerate all possibilities in a useful way. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev