Re: Hello directly from Jimbo at Wikipedia

["Jeffrey F. Bloss" <jbloss@xxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 28 September 2005 05:03 am, Nick Mathewson wrote:

> > Has anyone considered applying a HashCash type solution to this?
>
> Hashcash is often considered, but commonly dismissed, because it
> limits identities based on the wrong resource: computers.

I read "Proof-of-work", thanks for the link. My knee jerk reaction was to 
disagree that it applied to Wikipedia. I assume that spammers and "defacers"  
have differing motivations and resources. A spammer might muster multiple 
machines and be willing to invest more time because they realize some 
tangible ROI. A defacer would typically be an individual, who might give up 
the chase if it cost even a small price.

Then I realized I know exactly squat about Wikipedia.

I was operating under the assumption that the problem was more along the lines 
of nefarious juveniles selectively posting "Kilroy was here" graffiti. 
Something along those lines. If I'm out in left field about the nature of the 
attack against Wikipedia, I'd be happy to be corrected, and forced to agree 
that HashCash would be unsuitable. 

> Sorry, but you've stumbled a personal crusade of mine.
>
> The word is pseudonymous, not pseudo-anonymous.  And the difference is

It's ok. I'm the same way with "hacker".

> >  Tor is an anonymous network by design. And there is a
> > difference.
>
> As one of the designers, I'd like to weigh in.  

I suppose I can permit that.  ;-)

> Tor provides 
> anonymity, but we've never opposed people who wanted to use an
> anonymous system to bootstrap per-service or cross-service
> pseudonymity.
>
> We will never, of course, alter Tor to make people have pseudonyms.
> But letting using pseudonyms is not against our overarching goals.

I assumed as much, but I saw suggestions that the tor network be made 
responsible for providing the mechanism of trust. I felt it was necessary to 
point out that this would inherently weaken Tor.

> >   It's real time nature also compounds any additional partitioning
> > problems a hard-keyed pseudonym setup brings with it.
>
> I don't see any iterable (that is, awful) partitioning attacks here.

No, but I subscribe to the "every little bit" philosophy. I realize 
compromises have to be made in the interests of usability, like the three 
node "bare minimum" default chain, but I fail to see how even a small chance 
that some user might be partitioned was justified in this scenario. 
Especially given the possibility that it it would be trivial to to collect 
multiple nyms. 

In the "classical" nym scenario a user generates a key and ties a nym to it. 
This makes the nym relatively costly. As I saw it suggested, these "nyms" 
would be handed out at the request of any anonymous user, by simply issuing 
them a token. Nothing would prevent an attacker from issuing as many requests 
for tokens as they could pump out at whatever their bandwidth allowed.

Of course I'm sure you're more than aware of all this. I'm preaching to the 
choir master. You may have something up your sleeve for "rate limiting" token 
acquisition. Feel free to educate me in this area too, if you'd like...

[big snip]

- -- 
Hand crafted on September 29, 2005 at 00:32:15 -0400

Outside of a dog, a book is a man's best friend.
Inside of a dog, it's too dark to read.
                                  -Groucho Marx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDO4B/RHqalLqKnCkRAgO5AJ42wmo0w5E4Dwtb2ySnCIYSmVD6fwCbBAg0
MFZS5HGjf7ntlsV8RFIkhrA=
=S4i7
-----END PGP SIGNATURE-----