From: Brad Templeton (brad@templetons.com)
Date: Wed Jan 17 2001 - 12:44:32 CST
On Wed, Jan 17, 2001 at 06:10:42AM -0800, Russ Allbery wrote:
> Brad Templeton <brad@templetons.com> writes:
>
> > Yes, sometimes you have to put up with some pain in order to have civil
> > rights. That may sound trite to you, but it means a lot to some people.
>
> > I'm not saying use tokens because it's easier. Do it because it's right.
>
> Wow, that sure is going to persuade me that you're right, yes sir. What a
> persuasive and well-defended technical argument that was.
No need to get snotty. It was not a technical argument. There is
a technological issue under here -- how to provide spam blocking information
while providing security for the true identity of the user -- but the
question of whether a site does this will be ethical.
Are you suggesting technology comes without ethics?
> I still don't think it makes any sense at all, but maybe I'm just being
> unnecessarily pessimistic. You've increased the complexity of figuring
> out what happened on the server by about an order of magnitude, plus I
> really doubt that, say, IIS is going to implement the above in any way
> that makes it easy to decode tokens (since that isn't going to be a common
> operation). I can think of dozens of things that in practice are going to
> go wrong with this.
Decoding tokens can be done any number of ways. The simplest is just
a log file on the server with the token, message-id and real identity
information. After several years of posting, this file might grow
to consume a penny's worth of disk space. They you find entries with
grep.
For those who can't stand the idea of an audit trail file, one could use
the slightly more complex cryptfunc( realid + date, pw ), and of course
you get back the token by using the decrypt func and knowing the pw.
Why is this all that complex?