Design proposals to further improve guard security
I have a couple of proposal sketches that I would like to write for making the prop271 guard algorithm work even better. In particular, I would like to better resist the case where we start up for the first time with a hostile ISP that's determined to control our long-term guard choices.
Activity
changed milestone to %Tor: unspecified
Here are the ideas I have in my notes; they'll need some expansion to become proposals. And possibly to make any sense to anyone.
.....
The main problem this algorithm faces right now is the initial bootstrapping if the ISP is eeeevil. We're not doing worse than previously (I think), but we could do better. Some Ideas to improve this:
-
Mark the initial identity guards as "semi-confirmed" somehow so they can retain priority for a while in case the user breaks out.
-
Maintain a "suspicion index" for each guard: maybe, the number of guard that were down before it when it was confirmed?
-
Maybe, don't confirm guards when the primary guards are down if we're about to retry??? [didn't think about that one so much.]
-
Maybe when a circuit launches earlier than another , if both guards become confirmed, the one that was launched first should be confirmed with earlier confirmed_idx?
-
