Just a suggestion

[full-disclosure () lists netsys com (Snow, Corey)]

> -----Original Message-----
> From: Steve [mailto:steve () videogroup com]
> Sent: Wednesday, August 28, 2002 12:49 PM
> To: full-disclosure () lists netsys com
> Subject: Re: [Full-disclosure] Just a suggestion
>
>
> On Wednesday 28 August 2002 12:34 pm, Snow, Corey wrote:
> > Uniformity of enforcement is difficult (impossible?) to 
> achieve on any
> > moderation policy that is content-based.
>
> Clearly written policies are easy to follow. F.ex:
>
> Msg intended to disrupt the list with threats and degrading 
> comments are not 
> to be let through.


OK, I'll bite. You'll first have to define "intended" and "disrupt". With a
policy like this, the determination of what is "intended" to "disrupt" is
left in the hands of the moderator. Once again, you will have a disparity.
If I were to take a group of 5 people, present them with this policy, then
give each one them the entirety of the traffic that has traversed this list,
I can guarantee you that the "acceptable" list would be different for each
person.

Even the most clearly written policy that requires a decision based on
content will create a situation where uniformity of moderation is
impossible. I would assert that this would be the case even with a single
moderator, as even the most level-headed human being will make different
decisions based upon mood, time of day, whether they were in a hurry or not,
etc. And a group or panel of moderators simply increases the perception of
uneven enforcement of policy.

The essential problem is that any content-based moderation policy (i.e.,
content type "a" is acceptable, while content type "b" is not) requires
people to interpret what is content of type "a" (legimate security
discussion) and what is content of type "b" (everything else). Some of the
postings on here arguably fall into either category, depending upon your
point of view.

If you are the moderator, everyone else is suddenly subject to your point of
view on what is acceptable content. And if the shoe is on the other
proverbial foot, you might be subject to someone else's interpretation of
what is acceptable.

 Conversly you could replace any four 
> letter words with 
> "[bleep]" 
> Others where the same message is sent repetitively (twice or 
> more) seemingly 
> from the same, or not, address should be stopped.

I think that some common-sense anti-abuse policies (only subscribers may
post, EMP gets you booted, etc) can take care of most of these problems. And
"four-letter words" aren't something I have any heartburn over. The nice
thing about non content-related policies is that they can be evenly
enforced. EMP and/or spam, threats of physical violence, etc- these are all
within the easy reach of a "drop from subscriber list" policy. None of them
require moderation of the list.

> It's easy to tell what belongs and what does not. If the 
> indended purpose is 
> to have an outlet for security holes and liabilities, then a 
> discussion about 
> someone being an a[bleep] is OT. (Of course a discussion list 
> could have all 
> that for those who don't mind.)

Actually, I disagree that it's "easy" to tell. See my point above about the
5 moderators. If I were to pick 5 people at random from this list and ask
them to moderate the postings thus far made to this list based upon a
written policy (and not their personal feelings) I can still promise you
that the list is going to be different in every case.

The problem is not with the postings at the extreme of either end- at one
end, you have the "please see #phrack/EFNet for more information" messages
EMP'd with forged source addresses. That would obviously be out of line of a
policy like you stated. At the other end you have "FreeBSD Security Notice
FreeBSD-SN:02:05", which obviously would be acceptable under such a policy.

The issue arises with the middle ground. Postings that contain some
disparaging comments but good information. Or Aliver's recent go-round with
xxt. Or even this discussion. It's these postings that fall somewhere in the
middle of that policy description that would be subject to uneven
moderation. 

> I've not really read the list description to write the 
> policies, but I bet if 
> I did I could write ones that could not be misinterpreted and 
> would be 
> supported by 80%. Assuming 20% is just trying to create trouble.

That's a big assumption. You can't really categorize people on here (or
anywhere) that easily. Define "create trouble". :-) Is telling people that
you don't like their viewpoint because they're a (white | black)hat and
you're not creating trouble? Some might think that this discussion we're
having is arguably stirring up trouble. Hell, there's been "trouble" (as I
see it) over the definition of "hacker".

> These simple rules would drop the noise level a lot, and 
> letting all sec 
> related posts through, without lowering the value of the list.

I may not agree with you on what constitutes "security related". Some might
think that only advisories and vendor announcements are security related.
Others might think that general discussions about security are
security-related. It's all a matter of interpretation, and until we invent
the perfect, unbiased moderator, you can't fairly moderate based on content.
("fairly" being the best word I could come up with. I have no problem with
moderation per se, as no one is forcing anyone to participate in a moderated
discussion, such as bugtraq or vuln-dev). But if you want to have fully open
(full disclosure) discussions, you can't close the door to on anyone's POV.

Corey M. Snow- csnow () deltadentalwa com
I don't speak for my employer.
 

#########################################################
The information contained in this e-mail and subsequent attachments may be privileged, 
confidential and protected from disclosure.  This transmission is intended for the sole 
use of the individual and entity to whom it is addressed.  If you are not the intended 
recipient, any dissemination, distribution or copying is strictly prohibited.  If you 
think that you have received this message in error, please e-mail the sender at the above 
e-mail address.
#########################################################