Re: Hooking nym to wikipedia

[cyphrpunk <cyphrpunk@xxxxxxxxx>]

On 10/3/05, Jason Holt <jason@xxxxxxxxxxxx> wrote:
>
> More thoughts regarding the tokens vs. certs decision, and also multi-use:

This is a good summary of the issues. With regard to turning client
certs on and off: from many years of experience with anonymous and
pseudonymous communication, the big usability problem is remembering
which mode you are in - whether you are identified or anonymous. This
relates to the technical problem of preventing data from one mode from
leaking over into the other.

The best solution is to use separate logins for the two modes. This
prevents any technical leakage such as cookies or certificates.
Separate desktop pictures and browser skins can be selected to provide
constant cues about the mode. Using this method it would not be
necessary to be asked on every certificate usage, so that problem with
certs would not arise.

(As far as the Chinese dissident using net cafes, if they are using
Tor at all it might be via a USB token like the one (formerly?)
available from virtualprivacymachine.com. The browser on the token can
be configured to hold the cert, making it portable.)

Network eavesdropping should not be a major issue for a pseudonym
server. Attackers would have little to gain for all their work. The
user is accessing the server via Tor so their anonymity is still
protected.

Any solution which waits for Wikimedia to make changes to their
software will probably be long in coming. When Jimmy Wales was asked
whether their software could allow logins for "trusted" users from
otherwise blocked IPs, he didn't have any idea. The technical people
are apparently in a separate part of the organization. Even if Jimmy
endorsed an idea for changing Wikipedia, he would have to sell it to
the technical guys, who would then have to implement and test it in
their Wiki code base, then it would have to be deployed in Wikipedia
(which is after all their flagship product and one which they would
want to be sure not to break).

Even once this happened, the problem is only solved for that one case
(possibly also for other users of the Wiki code base). What about
blogs or other web services that may decide to block Tor? It would be
better to have a solution which does not require customization of the
web service software. That approach tries to make the Tor tail wag the
Internet dog.

The alternative of running a pseudonym based web proxy that only lets
"good" users pass through will avoid the need to customize web
services on an individual basis, at the expense of requiring a
pseudonym quality administrator who cancels nyms that misbehave. For
forward secrecy, this service would expunge its records of which nyms
had been active, after a day or two (long enough to make sure no
complaints are going to come back).

As far as the Unlinkable Serial Transactions proposal, the gist of it
is to issue a new blinded token whenever one is used. That's a clever
idea but it is not adequate for this situtation, because abuse
information is not available until after the fact. By the time a
complaint arises the miscreant will have long ago received his new
blinded token and the service will have no way to stop him from
continuing to use it.

I could envision a complicated system whereby someone could use a
token on Monday to access the net, then on Wednesday they would become
eligible to exchange that token for a new one, provided that it had
not been black-listed due to complaints in the interim. This adds
considerable complexity, including the need to supply people with
multiple initial tokens so that they could do multiple net accesses
while waiting for their tokens to be eligible for exchange; the risk
that exchange would often be followed immediately by use of the new
token, harming unlinkability; the difficulty in fully black-listing a
user who has multiple independent tokens, when each act of abuse
essentially just takes one of his tokens away from him. Overall this
would be too cumbersome and problematic to use for this purpose.

Providing forward secrecy by having the nym-based web proxy erase its
records every two days is certainly less secure than doing it by
cryptographic means, but at the same time it is more secure than
trusting every web service out there to take similar actions to
protect its clients. Until a clean and unemcumbered technological
approach is available, this looks like a reasonable compromise.

CP