Fan Jiang <fanjiang@thoughtworks.com> writes:

[ text/plain ] Hi George,

Thanks for following up, We have been updating the prop259 actively in recent two weeks,

...

It seems like the latest version of prop259 was posted a few weeks ago: https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html

My understanding is that since then a few things have changed particularly with regards to the dystopic heuristic, and the various filtering torrc options. More discussion happened in the mailing list, but we have not posted a newer version of the proposal yet: https://lists.torproject.org/pipermail/tor-dev/2016-April/010714.html

the newer version of prop259 is sort of feasible again. it's here https://github.com/twstrike/torspec/blob/review/proposals/259-guard-selectio...

Ah great. Will read it and comment on it ASAP. I notice that the prop now contains many many implementation details (like variable names, etc.). Ideally, we should abstract those details and make them look more like a specification.

And, we have our fork of Tor *running* with new proposal: https://github.com/twstrike/tor_for_patching/tree/prop259

How is this going? Does it work as intended? Any graphs? I should find some time and run it myself soon.

...

A few things:

a) Are there still proposal design decisions that need to be taken and we are unclear on? I admit I'm a bit lost in the latest [tor-dev] thread, so maybe I can be of help somehow here?

There are still some issues, like for_directory may leads to maintain two sets of sampled_set independently, which is not yet defined clearly in proposal.

Hm, how come this is happening? I would think that for_directory would now be just another filter (like the ipv6 one etc.) that can be applied on top of the sampled list.

<snip>

c) Let me know if there are any open implementation questions that I could

...

assist with.

About implementation, one problem is when we try to remove the global *entry_guards*, The following functions are still using the global list:

we already get rid of these:

//- update_node_guard_status (OK - called from *set_from_config and // *parse_state. This is an optimization to set the using_as_guard flag.) //- entry_guards_compute_status (OK - when a new consensus arrives) //- log_entry_guards (OK - wont be used) //- add_an_entry_guard (OK - wont be used) //- entry_guard_register_connect_status (OK - wont be used) //- entry_guards_set_from_config (OK - wont be used) //- entry_guards_parse_state and entry_guards_update_state (OK - wont be used) //- choose_random_entry_impl (OK - wont be used)

there are still some remaining:

//- get_entry_guards() //- num_live_entry_guards() //- getinfo_helper_entry_guards() //- entries_retry_helper() //- any_bridge_supports_microdescriptors() // Don't quite understand this, what's a microdescriptors?

A microdescriptor is a new type of relay descriptor that is more compact. (well, it used to be new, but it's a few years old these days and most bridges support it afaik). They were introduced to reduce the download sizes of clients, because asking for thousands of normal descriptors required too much bandwidth. Microdescriptors include almost all the details of normal descriptors (like onion keys, etc.) but in a much more succinct format. That function checks if the bridge supports microdescriptors. If yes, it will ask it for its microdescriptor. Otherwise, it will just ask for the normal descriptor. (I'm actually not sure how that function gets away without checking the bridge version or something.)

//- any_bridge_descriptors_known() // Calling choose_random_entry to check a bridge, which doesn't make sense.

Hah. I didn't know of that function either. That function seems to call choose_random_entry() just to check if bridges have been configured correctly and are ready to use. It doesn't actually use the return value of the function :) Basically, if that func returns not NULL, it means that at least one bridge is live and ready to be attempted.

Another issue is about finding a better way to handle configuration changes, especially for EntryNodes, UseBridges and ReachableAddresses. The treshould numbers like N_PRIMARY_GUARDS should be different in such cases.

Hmm, yes I have not thought how the primary guards heuristic would work when bridges are enabled. Why do you think the thresholds should be different? Thanks for the info. Will try to have feedback on the proposal tomorrow or early next week.