|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Hold on to your news servers
John M. Brown wrote: > Wouldn't it be nice if people actually quoted things correctly.... > > Quoting from his FAQ as posted on inet-access. > > " THIS CANCEL ADVISORY SYSTEM IS OPT-IN; THE CANCELS > WILL *NOT* BE GENERALLY INJECTED BACK INTO THE USENET > NEWS STREAM. " I presume you are referring to me. Here's the train of logic. Karl's system is opt-in. His cancels never make it to Usenet. Then something goes wrong, and cancels leak to Usenet. Now every Usenet news admin in the world must change their system, and/or every Usenet user in the world posting binaries must register with Karl's system. At that point, Karl's system is now opt-out. At that point, Karl's system is cancelling legitimate, on-topic posts made by users wholly unrelated to his new business and his customers. This entire line of logic depends on the likelihood of something going wrong with Karl's system, where cancels leak out onto Usenet at large. (Remember, for his "opt-in" claim to be true, his system must never fail.) Now we turn to history. _Every_ attempt to prevent article leakages on Usenet has failed. Chris Lewis' (?) example was ClariNet -- they have far more money, lawyers, and connections than Karl ever will, but they continue to battle leaks. The logic connection is now made. All news admin opinions I've read in the past 48 hours agree with my own -- cancel leakage is likely, if not inevitable. And if this wasn't enough justification, here's a further list of problems, which I sent to Karl and copied to a newsadmin list. Note the lack of response to certain key items in the second post. Jeff P.S. Sorry for the verbosity. My last public post on the subject. Karl will hang himself without my help :) [ First post -- my take on problems with his system -- he responded to all points ] 1) No accountability. If your goal was to make these cancels public, it would be trivial to shift the blame and put yourself in a position where the downstream peer gets all the heat. 2) No privacy. Requiring registration in order to post is a great idea for cutting down spam, but it's the Usenet equivalent of a poll tax. Individuals who do register have given up a slice of privacy in order to do so. Individuals who do not register may have their post canceled. Anonymity is treasured by many on Usenet. 3) No leak detection. I can guarantee that your cancels will leak all the time unless you peer only with clueful admins -- not just admins who pay a fee, or say they run a news site. Take a look at Usenet II and see how their software works, and how their network-within-a-network is set up. (even they have leaks, but it is less frequent than your system, in its current incarnation, will wind up) 4) Censorship. Cancelling means you are denying someone a voice. In this case, _your_ system denies anyone who has not registered with your service a voice. And if one of your peers decides to leak your cancels, you are now censoring the entirety of Usenet. 5) Attacking the wrong end of the problem. Once again, an anti-spam solution is presented that tackles the problem after it becomes a problem -- after the article has been posted, and after the article hits all the peers on the backbone. The net effect of your plan is to _increase_ the bandwidth consumed by Usenet. [ Second post -- he objected to the last sentence, and asserted that his system catches 50% of the bad articles before they reach news sites. I respond... ] Cancels have always increased bandwidth. The past few years have seen an increase in bandwidth, in no small part BECAUSE of cancels. It's an arms race -- cancels come out more quickly, so spammers post more, more quickly. Graphs show that most articles reach well-connected sites within 30-60 seconds of being posted. Almost all articles reach sites within 10-15 minutes of being posted. Because of high-speed news routing, a cancel that arrives _before_ the actual article is the exception, not the rule. One must introduce artificial delays before early cancels become effective at all. Hard numbers have been posted on news.software.nntp and news.admin.net-abuse.usenet proving this. I'm interested to see if you have anything beyond wild guesses disputing this. [ no response to any of the 'hard facts' above... ] Finally, the biggest problem with your proposal is cancel leakage. The cancels WILL leak. History has proven this time and time again with semi-private hierarchies. And when the cancels leak, two things will happen. First, the resulting cancel storm will kill many slower sites. Second, when the binaries disappear all over Usenet, you will have _thousands_ calling their ISPs and complaining. Maybe one or two will sign up with your system. The rest will put their money, influence, and muscle towards cutting your peers and you off Usenet. Please don't interpret this as a threat -- simply a prediction. To summarize, you have a worthy goal. Nobody on any newsgroup or mailing list has disputed this. But your implementation, your means to an end, leaves much to be desired.
|