On Fri, Oct 16, 2020 at 10:49:43AM +0200, nusenu wrote:
lets see when this graph stops growing https://cryptpad.fr/code/#/2/code/view/1uaA141Mzk91n1EL5w0AGM7zucwFGsLWzt-Es...
Sounds good. I think, based on your graph, that it is a coincidence that we launched the "KISTSchedRunInterval=2" experiment right around this time. That is, your graph shows that the consensus weights for whether to use exit relays solely for exiting went from "100%, always do it" to "a tiny bit less than 100%" *before* we changed the KISTSchedRunInterval value.
I guess we will get another data point when we turn KISTSchedRunInterval back to its default of 10ms, and (we hypothesize) it has no impact on the weights.
why is this relevant? It puts more entities into an end-to-end correlation position than there used to be https://nusenu.github.io/OrNetStats/#tor-relay-operators-in-end-to-end-corre...
Yep. I'm not worried in the short term here, since one of the features of our guard design is that just because a relay suddenly has a chance of being used as a Guard, that doesn't mean it becomes *your* guard. You (your Tor client) already have your guard, and you'll be sticking with it for the next few weeks probably.
So this question matters over the coming weeks or months, because clients will be rotating to new guards and then they will have a tiny chance of picking one of these exits as their guard, each time they rotate to a new guard, which is typically an infrequent event.
*That* said: since the chance of picking any of these exits as your guard is really tiny, I think that means they will have very few users using them as guards, which puts them in a weird position. For example, it means that if you're one of the very rare clients who picked an exit as your guard, then your choice acts as a better fingerprint for you, if you move around, and if there is an attacker that's in a position to watch your local network in each new location.
I don't think we ever intended that edge case to happen, and it's kind of an uncomfortable situation to be in.
I wonder if the right fix is: "if you have the Exit flag, you don't get the Guard flag"?
I think it would mean that the tiny amount of excess capacity on exit relays would get pushed into rarely-but-still-sometimes being used as somebody's middle hop, which seems to me like a much better oucome.
and it might also decrease exit traffic on exits when a tor client chooses an exit as guard
I think load on these exits would increase, not decrease. They're already going to be used for exiting. That is, if you need an exit for your circuit, you're going to use one. The impact of these weights will actually *increase* traffic on exits, because they will be used for exiting like normal (there's no choice) but *also* they will be (very rarely at present, but still more than the 'never' from last week) used in other circuit positions too.
--Roger