[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Hello directly from Jimbo at Wikipedia
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
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...
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
-----END PGP SIGNATURE-----