From: Brad Templeton (brad@templetons.com)
Date: Mon Mar 06 2000 - 14:50:11 CST
On Mon, Mar 06, 2000 at 03:17:58PM -0500, Bill Davidsen wrote:
> 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.
Possibly, but I don't see this as a reason to try. There may be sites that
don't have cancels on (because they are hugely abused) that are willing to
run pgpmoose and its replacement -- such as a moderator's ability to do
a signed cancel in their group.
The fact that some sites will ignore the spec is not a reason against moving
forward.
>
> > 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.
I contradict this for factual reasons, not because it is the way I would
do it. Have you really thought through what it would take to do it in
properly in the client? It requires:
a) The client have complex signature checking code (though one would
hope a library will appear.)
b) The client have code to maintain a database of certificates for
approved parties.
c) The signatures and certificates would need to go in the overview
for this to really work. We're talking anywhere from 300 bytes
to, in some proposals, a *KILOBYTE*. If you read news over NNTP
on less than a megabit pipe, I contend this is not only not easy,
it's entirely not practical. Overviews are too large as it is.
The alternative is not particularly useful. You end up seeing an
article menu full of the forgeries and spam, and when you select
for reading, the newsreader sucks down the headers, checks the
sigs and only then skips the article for you.
I don't know about you but I don't usually even select the spam
and forgeries for reading from my menus. I think the *whole
point* of the verification is to get the forgeries out of the
article selection menu. But not at the cost of kilobyte overview
entries.
d) The client needs a way to listen to, or get access to, a stream
of new certificates and in particular, certificate revocations.
That means a lot of complexity in the client, it has to in effect
before every session (and perhaps during sessions) slip over to
a special newsgroup to read the certificate revocations and new
certificates, and then maintain its own CRL database. It means
a delay at the start of every newsreading session, and is again
not very practical on modem/iDSL/ISDN level links.
I am frankly astounded that you think clients would want to do this.
Anything short of this has forgeries still showing up in the menus, and
provides no working revocation system.
And all for what? The server needs to understand signatures anyway to
understand signed control messages. So you want all this for what? So
you can, if using such a server, have the ability to read the forgeries
inline with other postings?
I say, have the server put rejected forgeries into a "forgery" newsgroup
like "junk". Have it, if you insist, leave a placeholder in the overview
which old newsreaders will treat as a missing article but you can use to
quickly go fetch the article from the forgery group. That will give you
what you want.
Why do you want it?
> 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.
Sure, but there are limits. If almost nobody really wants to read
forgeries inline, is it worth doing what I outline above and burdening
everybody (and newsreader authors) to make it happen?
>
> 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.
Yes, but in effect you're saying that it makes sense to have the spec
say that checking the approved header is optional and that newsreaders
should include code to check the approved header.
While we *could* do that, because the burden is much lower than for
certificates, is that the right design?
> 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.
If a newsreader is going to check a header, and it's the sort of header
you need to decide whether to show the user a headline, it has to be in
the overview or it's not going to be practical.
> > >
> > 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
Ok, I see your point, it's a way to force people into adopting new clients.
There are a lot of other ways to do that.