Nick Mathewson wrote:
> On Fri, Feb 12, 2010 at 6:10 AM, wrote:
>> This thread is being forked from the original as it doesn't entirely
>> depend on the user(s) using bridges and this problem. I understand
>> the purpose of Tor and know individuals, organizations, as well as
>> governments use Tor, so why be surprised when governments use Tor?
>> But if these individuals are correct, why are dc nodes making the
>> exception with ExcludeNodes and passing through? Is there an attack
>> on Tor certain nodes use to bypass this feature?
>>
>> From: Andrew Lewman
>>
>> "Yes, https://bugs.torproject.org/flyspray/index.php?do=details&id=1090.
>> We're still working on it. In fact, we're working on rewriting the
>> entire codebase around {Exclude}{Entry|Exit}Nodes options."
>
> I'll try to expand on the understand the bug report you are citing,
> since the stuff there really _does_ explain what the problem is,
> albeit in programmer-speak.
>
> The root problem here is in the way that node selection was originally
> written. We needed to solve the question of, "what should we do when
> the user requests that only certain nodes be used, and then makes a
> request that those nodes cannot satisfy?" Some examples where
> excluding nodes can make it impossible to fulfill a request include:
>- Excluding a node, then choosing that node as the exit for a
> particular circuit.
>- Excluding every introduction point for a hidden service, then
> trying to connect to that hidden service.
>- Excluding every distributed directory point for a hidden service,
> then trying to look up its descriptor.
>- Operating a hidden service, when the client picks a rendezvous
> point you've excluded.
>- Trying to connect to an IP:Port when you have excluded every exit
> node that would support it.
>- Trying to bootstrap when you have excluded every directory authority.
>
> In *most* of these cases, we figured that recent requests should
> override old requests, so if the user says "don't do X" and then says
> "do X", they probably meant the latter rather than the former.
> Similarly, we figured that people mostly wanted their requests not to
> break, and would get irritated if excluding nodes meant that their
> hidden service requests could break at random. So (IIUC) we set up
> the code so that some service requests that could only be granted with
> excluded nodes would produce a warning rather than a complete failure.
>
> It turns out this wasn't the choice a lot of people want: they want to
> be able to say "Never ever ever use these nodes. If I ever make a
> request that can only be satisfied with nodes I've excluded, reject
> that request, even if it means I don't get the hidden services I want,
> or I can't bootstrap, or whatever." This isn't a crazy thing to ask
> for at all. As Andrew said, Roger's working on rewriting big chunks
> of the node selection code to support this feature. As Andrew said,
> check out Bug 1090 for the details and progress.
>
> (Another confusing aspect here is that "exclude X as an exit node" has
> been taken by some people to mean that all circuits ending at X should
> be verboten. But circuits can end at a node for reasons other than
> sending traffic out of the network, including accessing a hidden
> service via a rendezvous point, performing a self-test, or accessing a
> directory server. Perhaps what people really want is an
> ExcludeAsLastHop option, and we should build that instead.)
>
> Another goal of the node-selection rewrite, BTW, is to simplify the
> node selection process. It's pretty complex, and there could well be
> more bugs in it. We should also work on specifying the whole thing
> better, so it's easier to tell surprises from bugs; Sebastian said he
> was interested in trying that out in whatever free time he has left.
>
> So that's what's going on here. It is not in fact, a sooper-sekrit
> government backdoor. There is not any exception for nodes in
> Washington, Moscow, Area 51, or the Bermuda Triangle. It's a node
> selection algorithm which was originally written with a false UI
> assumption (that people would want working requests to trump
> configuration settings), and which Roger's been trying to make more
> like what people want. Some of it's already rewritten in 0.2.2.x;
> some will take more work.
>
> And as for whoever thinks that Roger not getting the code rewritten
> fast enough for their taste means that we're a bunch of contemptible
> lying double-dealing sellouts who would sabotage our own life's-work
> for whatever reason: They are mistaken. For my part, I'd rather quit
> software entirely than back-door Tor, and I believe that goes for
> everybody on the project.
>
> Sorry for the intemperate digression.
>
> Hope this helps,
êôçà :)
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul
