From: Bill Davidsen (davidsen@prodigy.com)
Date: Mon Mar 06 2000 - 14:17:58 CST
Brad Templeton <brad@templetons.com> wrote:
> On Fri, Mar 03, 2000 at 01:49:49PM -0500, Bill Davidsen wrote:
> > Brad Templeton <brad@templetons.com> noted:
> >
> > > However, I still strongly advise that a server simply discard articles
> > > that fail signature tests rather than put any burden on the newsreader
> > > to check such a header.
> >
> > This would be the "new server - any reader" case, but it requires some
> > changes to the server, so it won't be there instantly. And some sites by
> > policy don't honor cancels, etc, and won't do it even though they could.
>
> Saying that sites that don't honour unverified cancels (which are widely
> abused) would not honour signed cancels (which can't, except by key
> compromise, be abused) is a big leap.
Given that a number of commercial news for hire sites advertize that
they carry "absolutely everything," all articles, all groups, I can't
believe for a moment that these sites would suddenly start honoring
cancels. Some don't look for Approved headers, either. And many sites
haven't upgraded in forever, they won't change to provide something the
client can do.
> However, the client effectively can't do signature checking on its own.
> I mean it's not totally impossible but it is impractical. There's really
> little to be gained except through server code, and besides, why even
> suggest that clients have complex signature checking code (and go through
> the large overview burden of it.) when it is simpler to put it in servers.
You have been posting "it's not the way I would do it" criticism of
suggestions for months, and I'm really getting tired of it. When it's
your week to be God, please change everyone's mind, and until then
please cope with the idea that people don't always want to do things
your way, or even the easiest way.
People CAN do it on the client, with small effort to set up, and there
are people who bitch about lost posts every time I block some site
which is hosting hipcrime or friends. I don't see how you can prevent
people from doing it on the client if the server doesn't do it first,
nor why you would possible want to make an effort to prevent it.
> > Some people want to see everything and make their own decisions. As long
> > as there's a mechanism by which both the server and the reader can
> > identify the bogus articles, the goal has been reached.
>
> Really? I mean really you think that the number of people who want
> to read, in-line with other articles, the forgeries is significant? That
> it's more than .01% of the population of USENET? I don't mean the
> ones who want to track them. They can do it by reading a special junk-like
> newsgroup.
I think sites who want to offer cooked news will, and site who want to
offer everything will, and people will vote with their wallets. I
believe in capatalism and think it's a spiffy idea to have them do that.
> You're saying there are really a *lot* of people who want to read the
> forgeries inline? Then we should not have the server check the approved
> header either.
And some servers don't. Which doesn't have any effect on how I run my
server, so I stay out of other people's business. If a transit server
wants to filter, fine. If it doesn't, fine too. If I find a high number
of rejects on a feed I know how to politely ask for less, or different,
or none at all.
> > I'm sure I can do the validation at user level with a trn macro, and I'm
> > sure someone could write a plug-in or whatever for Netscape. If it's a
> > good idea other client software will follow.
>
> Oh, checking a header can indeed be done easily, but why? It's a new
> header to put in the overview, and if you are on a modem line, the overview
> is way too big as it is already. I find it a pain even over DSL!
Did I suggest it should be in overview? I don't recall that. Most sites
will filter in the server, and let the readers download the entire
article. Some might hack overview themselves, as sites do now. I don't
see any need to mandate or prohibit what people choose to do.
> >
> > I'm torn between the elegance of just signed articles which anyone can
> > read and the motivation of encrypted posts which will encourage client
> > providers to add decryption features.
>
> There is no, zero, zip, nada value to encrypting posts in a public newsgroup.
Another "I wouldn't do it that way." Reread the last paragraph until you
see what benefit might result. Feel free to think it wouldn't work, but
I doubt that many would find adding the ability to read encrypted
post directly to the client software was "no value." Feel free to not
add it to your client, or go to great effort to have it for mail and not
for news.
-- -bill davidsen (davidsen@prodigy.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me